Technical Planning

/technical-planning

Purpose

Translate the Design into a technical plan grounded in the current system and aligned with risks, constraints, and NFRs. Run as a sub-agent and return a draft section to the orchestrator; do not write the plan artifact directly.

Ownership

• Edit only the ## Technical Plan section in the plan template.
• Do not modify other sections except updating Risks/Assumptions/Tests when needed.

Inputs

• Problem Definition
• Challenge Artifacts
• Context Snapshot (if available)
• Constraints, NFRs, and decision log

Required outputs (Technical Plan)

• Named integration points (interfaces, APIs, data contracts).
• Proposed architecture changes and integration steps.
• Failure modes per integration point.
• Explicit invariants and non-changes.
• NFR alignment (perf/security/privacy/cost/operability).
• Risks/assumptions/tests updated to reflect technical reality.
• Draft section content for ## Technical Plan

Sub-agent output contract

Return a single block in this shape:

DraftSection:
<exact section content for ## Technical Plan (must include the section header)>

Checklist:
- <criterion>: Pass | Fail

Questions:
- <if blocked>

Notes:
- <optional risks/assumptions/tests updates>

Malformed output handling

• If you cannot produce the exact section header or required fields, return Questions explaining what is missing and leave DraftSection as N/A.

Success criteria (gate: TechnicalClarity)

• Integration points are explicit and named.
• Failure modes exist for each integration point.
• Risks/assumptions/tests are updated and consistent.
• Invariants are listed and respected.
• NFRs are addressed or explicitly deferred with DR entry.

Decision Log / DR reference integrity (hard rule)

• Any DR-xxx referenced in the Technical Plan MUST already exist in the plan’s Decision Log.
• Do not write “per DR-xxx” unless:
  • that DR exists, OR
  • you also instruct the orchestrator to create it (and include the exact decision text to log).
• If you cannot locate/confirm the DR id, remove the reference and instead describe the decision plainly (and/or request a DR to be created).

Process

1. Identify integration points and named interfaces.
2. Describe architecture changes and sequencing.
3. Enumerate failure modes per integration point.
4. Update risks/assumptions/tests to match the plan.
5. Confirm invariants and non-changes.
6. Check NFR alignment and document tradeoffs.

Output template

Use this exact structure in ## Technical Plan:

## Technical Plan
### Integration Points
- ...

### Proposed Architecture Changes
- ...

### Failure Modes (per integration point)
- ...

### Invariants / Non-Changes
- ...

### NFRs alignment
- ...

UX rules (no "go read the plan")

• If you need user confirmation on a technical choice or integration point, paste the relevant excerpt(s) in the chat response (interfaces/integration points, failure modes, key risks).
• Summarize what changed and what decision (if any) is needed, without requiring the user to open the plan artifact.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.