jonfazzaro

continuous-specification

Use whenever a production-code change alters executable behavior—features, fixes, integrations, migrations, scripts, performance work, or behavior-changing refactors. Establish behavior through small executable expectations and green checkpoints.

Code & Development Listed

ensemble-review

Use when the user asks for an ensemble, panel, cross-model, or independent multi-model review of a document, plan, proposal, runbook, or source file.

Code & Development Listed

micro-commits

Micro-commits process for committing early and often as code is written. Use whenever writing or changing code, especially alongside Continuous Specification or TDD — each green spec run is a commit opportunity.

Data & Documents Listed

nullables

Specifies behavior without mocks using Nullables. Use when writing specifications, especially specifying code with external I/O (HTTP, files, databases, clocks, random numbers), designing infrastructure wrappers or replacing mocking libraries.

Code & Development Listed

refactoring

Use when refactoring code, or when an in-scope readability or design problem obstructs requested work. Improve code form without changing behavior.

targeted-mutation-testing

Use when a changed production class or component has branching, lifecycle or asynchronous behavior, guards, error recovery, authentication, serialization, or an external-integration seam and needs file-scoped mutation testing before completion.

specification-structure

Use whenever editing a test or specification file, including *.test.* and *.spec.*. Use alongside Continuous Specification and TDD. In suites that already use describe, structure new or changed tests with readable when/given contexts and outcome-focused it captions; preserve flat suites without describe.

describe-structure

Required whenever adding, editing, or restructuring tests or specifications, including *.test.* and *.spec.* files. Use for unit-test coverage, regression tests, TDD, mutation testing, bug fixes, and refactoring—even when the user does not name test structure. Invoke before writing test code. In suites that already use describe, structure every new or changed test as component → when [action] → given [condition] → outcome-focused it; preserve flat suites without describe.

AI & Automation Listed

discovery-trees

Render a concise, color-coded text Discovery Tree whenever communicating a coding plan, specification, plan adjustment, newly discovered work, or completion of a planned task. Use it proactively during implementation to make the current state, dependencies, and viable next tasks easy for a human to assess and choose between. Do not use it for a simple isolated answer or task with no meaningful plan.

AI & Automation Listed

ensemble-working

Facilitate a human-and-agent ensemble through one collaborative AI pattern while working on a shared task. Use when a team wants to think together, compare approaches, or maintain shared ownership instead of having one person prompt alone.

AI & Automation Listed

debuzz

Translate Claude's previous response (or any pasted text) into plain, direct English by using the local Pi CLI through OpenRouter, with audience modes (colleague/manager/director) controlling how detailed versus high-level the result is. Use whenever the user invokes /debuzz, asks to "de-buzzfeed" a reply, says "say that in normal english" / "translate that to regular person english", asks for a manager- or exec-friendly version of a reply, or complains that a response sounds hypey, dramatic, listicle-like, or "like buzzfeed".