Quick

Purpose

For changes small enough that a full grill→blueprint→tdd→integrate pipeline is overkill. /quick reads the code, confirms the approach with you, then implements and tests.

If the change turns out to need architectural discussion, hand off to /grill-with-docs.

Execution

Phase 1: Understand

1. Read the user's request.
2. Search the codebase for the relevant files — the controller, service, DAO, DTO, mapper XML that the change touches.
3. Read CONTEXT.md (if it exists) for domain terminology. If CONTEXT-MAP.md exists, read it and read each context relevant to the topic; if unclear which context applies, ask the user.
4. Form a clear understanding: what changes, where, and why.

Output: a one-paragraph summary of what you understand the task to be, plus the files and layers involved. List any key method signatures or query fragments that will change (e.g. getUser response gains age: Integer).

Phase 2: Confirm

Before writing any code, present to the user:

1. What you'll change — specific layers and direction (not implementation details).

2. ADR check — will this change introduce a new architectural decision?

   No ADR needed → present the plan and ask: "Proceed?"

   ADR possibly needed → warn the user and let them decide:

   "This change may introduce a new architectural decision ([brief reason]) and could be larger than a quick change. Do you want to:

   • Execute — proceed without an ADR, update CONTEXT.md only
   • ADR + execute — write a new ADR and update CONTEXT.md, then execute
   • Blueprint — the change is substantial; run /blueprint for a full plan instead
   • Grill — hand off to /grill-with-docs instead"

3. Wait for confirmation. Do not proceed until the user responds.

Phase 3: Implement

Read docs/house-style.md if it exists, then implement the change following the project's existing patterns — DTO → Mapper XML → Service, or whatever layering the codebase uses. Then write a focused unit test that exercises the new or changed behaviour.

For a new field: add the field across all layers, then write one test asserting the field is present with the expected value.

For a changed query: update the query, then write or update a test asserting the new behaviour.

For multi-file changes serving one behaviour: implement all files, then write the test that covers the end-to-end behaviour.

Prefer unit tests (mock external dependencies). Use a lightweight integration test only when the behaviour must be verified across layers. Run the test for this change to confirm it works.

Phase 4: Report

1. Run the module's test suite to confirm no regressions. If the change crosses module boundaries, widen the scope accordingly.
2. Report what was changed, what tests were added, and the test results.

Rules

• /quick handles one behaviour — a single change serving one goal. Scope questions are resolved in Phase 2.
• ADR judgment follows the same three-condition test as /grill-with-docs: hard to reverse, surprising without context, the result of a real trade-off.
• No interactive prompts beyond the Confirm phase. No checkbox tools.