outline

Structure Outline (P Phase — Part 1)

If the design document is the destination, the outline is the route map. It shows the phases, their order, what new types and interfaces emerge, and where to verify correctness along the way. Think of it as C header files: signatures and types, not function bodies.

This is NOT a plan. Plans map ~1:1 to code and run 8+ pages. The outline is ~2 pages and stays at the structural level.

If individual file paths were provided, read them all fully.

If no parameters provided, respond with:

"I'll create a structure outline for your task. Point me to the thoughts folder (e.g., thoughts/001-auth-endpoint/), or provide the design document and research findings."

Then wait for the user's input.

If design.md is still draft or has unresolved open questions, stop and tell the user:

The design document still has unresolved questions. Please finalize it first:
  run /qrspiv:design thoughts/<id>-<title>/

Do not proceed with an unapproved design.

For each phase, determine:

• What changes in this phase (files, components, layers)
• What depends on this phase completing before the next can start
• Where a meaningful verification checkpoint exists

Structure Outline: [Feature/Task Name]

Implementation Phases

Phase 1: [Name] — [one-line goal]

Changes: [which files/components/layers are touched] New types/interfaces:

• TypeName in path/to/file.ext — [what it represents]
• functionSignature() in path/to/file.ext — [what it does] Depends on: nothing (starting point) Verify: [how to confirm this phase works — test command, manual check, etc.]

Phase 2: [Name] — [one-line goal]

Changes: [which files/components/layers are touched] New types/interfaces:

• ... Depends on: Phase 1 Verify: [verification checkpoint]

Phase N: [Name] — [one-line goal]

...

Type & Interface Summary

[Compact listing of ALL new types, interfaces, and function signatures introduced across all phases. This is the "header file" view — everything in one place.]

Testing Checkpoints

[Ordered list: after each phase, what should pass]

1. After Phase 1: [what to verify]
2. After Phase 2: [what to verify] ... N. Final: [end-to-end verification]

Files Touched

[Complete list of files that will be created or modified, grouped by phase]

</template>

<critical>
- Stay structural. "Add a `RetryConfig` struct to `config/retry.go`" is good. "The struct should have fields for maxRetries (int), backoffMs (int)..." belongs in the plan, not here.
- New types and function signatures are the core value. If the outline doesn't show the shape of the new code, it's too vague.
- If the outline exceeds ~80 lines, you're writing a plan. Pull back to the structural level.
</critical>
</step>