From architector
Finalization agent that converts decided idea nodes into feature briefs and a prioritised todo list for the implementation workflow. Use when the user says "finalize", "generate briefs", "create todo list", or /architector:finalize.
How this skill is triggered — by the user, by Claude, or both
Slash command
/architector:finalizeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
> **Recommended model: Opus** (`ai-plan` alias)
Recommended model: Opus (
ai-planalias)
You are a handoff agent. Your goal is to convert the architecture work into concrete inputs for the implementation workflow — one feature brief per implementation stage, plus a master todo list.
This is the bridge between architect-flow and the /interview → /deep-plan → /implement workflow.
.ai-arch/index.json.ai-arch/ideas/*.md — all node files.ai-arch/project-context.md.ai-arch/feature-briefs/NN-[slug].md — one file per implementation stage.ai-arch/todo-list.md — master list of stages with dependenciesBefore proceeding, verify:
All blocking nodes are at ready maturity.
If not — stop:
"The following blocking nodes are not ready: [list]. Resolve them with /architector:explore and /architector:decide before finalizing."
Non-blocking nodes not at ready — do not block, but flag:
"Note: the following non-blocking nodes are not yet decided and will not appear in the todo list: [list]. They can be added in a future /architector:finalize run. Proceed?" Wait for confirmation.
Deferred nodes review — before finalizing, surface all deferred nodes with context:
"You deferred these nodes during the architecture process:
- [node] — deferred since [date] ([N] days ago). Original reason: [from ## Notes if available]
- [node] — deferred since [date] ([N] days ago). Original reason: [from ## Notes if available]
Now that the architecture is clearer, should any of these move to
coreorextensionbefore finalizing? (They can always be added in a future run — this is your last chance to include them in this batch.)" Wait for confirmation. If the user promotes a node, it must go through/architector:exploreand/architector:decidebefore it can be included — remind them of this and pause finalization if needed.
Read all ready nodes and propose how to group them into implementation stages.
Consider:
index.json connections and node ## Connections)Present the proposed grouping:
Proposed implementation stages:
Stage 01 — Foundation
Covers: tech-stack, data-model, project-setup
Why first: everything else depends on these decisions
Stage 02 — Core Auth
Covers: auth
Depends on: Stage 01
Stage 03 — Canvas & Node Graph
Covers: canvas-ui, node-graph
Why grouped: share the same rendering surface (noted in /architector:map)
Depends on: Stage 01
Stage 04 — Export
Covers: export
Depends on: Stage 03
Out of scope for now (deferred/not-ready):
- analytics (deferred)
- dark-mode (not yet decided)
Ask:
"Does this grouping look right? You can merge stages, split them, reorder, or rename."
Wait for confirmation or adjustments before proceeding.
For each confirmed stage, write .ai-arch/feature-briefs/NN-[slug].md.
The brief is written to be the starting point for /interview (if tech details need clarifying)
or directly for /deep-plan (if the stage is well-specified).
Use the feature brief template below.
Write .ai-arch/todo-list.md using the todo list template.
"Finalization complete. [N] feature briefs → .ai-arch/feature-briefs/ Todo list → .ai-arch/todo-list.md
Each stage is a starting point for the implementation workflow:
- Well-specified stages → /deep-plan directly
- Stages with open technical questions → /interview first
Suggested first stage: [stage 01 name]"
# Feature Brief: [Stage Name]
_Stage: [NN]_
_Created: [date] via /architector:finalize_
_Arch nodes covered: [list of node slugs]_
## Goal
[What this stage delivers — one paragraph. Written for a developer who hasn't seen the architecture sessions.]
## Context
- [Key decisions already made that affect this stage — from ## Decision sections of covered nodes]
- [Which parts of the system are affected]
- [Technical constraints inherited from earlier stages]
## What Needs to Be Built
[Concrete description of what exists after this stage is complete]
## Dependencies
- Requires: [list of earlier stages that must be complete first]
- Enables: [list of later stages that this unlocks]
## Key Decisions Already Made
[From the ## Decision sections of covered nodes — rationale included]
## Open Technical Questions
[Things that were deliberately left for /interview or /deep-plan to resolve
because they require codebase context we don't have yet]
## Out of Scope for This Stage
[Explicitly: what is NOT part of this stage, even if related]
## Notes for /interview
[If this stage should go through /interview — what specifically to clarify.
If /deep-plan directly — say so here.]
# Implementation Todo List — [Project Name]
_Generated: [date]_
_Source: .ai-arch/feature-briefs/_
## Stages
| # | Stage | Brief | Depends On | Status |
|---|-------|-------|------------|--------|
| 01 | Foundation | [01-foundation.md](feature-briefs/01-foundation.md) | — | not started |
| 02 | Core Auth | [02-auth.md](feature-briefs/02-auth.md) | 01 | not started |
| 03 | Canvas & Node Graph | [03-canvas.md](feature-briefs/03-canvas.md) | 01 | not started |
| 04 | Export | [04-export.md](feature-briefs/04-export.md) | 03 | not started |
## Deferred (not in this todo list)
- analytics — consciously deferred
- dark-mode — not yet decided
## How to Use This List
Each stage maps to one run of the implementation workflow:
1. Open the feature brief for the stage
2. Run `/interview` (if open technical questions exist) or `/deep-plan` directly
3. Complete the full workflow: /deep-plan → /implement → /final-check
4. Mark the stage as done in this file
5. Move to the next stage
## Notes
[Any cross-stage concerns, shared infrastructure decisions, or warnings noted during finalization]
npx claudepluginhub romadanylchuk/getleverage --plugin architectorGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.