/code-forge

name: code-forge
description: "Generate implementation code from an approved design blueprint or verbal requirements. Composes context anchoring, architecture, clean code, DDD, security, and test quality into an inside-out implementation workflow. Use when moving from design to code, implementing approved contracts, or when the user says 'implement', 'code this', 'build it', 'forge the code', or 'generate the code'."

Code Forge

Required Skills

Read and apply:

1. `framework:knowledge-priming` -- Load project context (stack, architecture, conventions) so implementation matches the real project. (always) 2. `framework:context-anchoring` -- Find and load the feature's context anchor doc; enrich it as implementation decisions are made (Create / Load / Enrich behaviors). (always) 3. `framework:learning-harvest` -- Load prior operational learnings to inform implementation at session start; harvest new ones at session end. (always) 4. `framework:collaborative-judgment` -- Surface genuine judgment calls as structured options instead of silently assuming. (always) 5. `framework:architecture` -- Layer placement, dependency direction, structural validation. (always) 6. `framework:clean-code` -- Craft guardrails: SRP, naming, complexity, error handling. (always) 7. `framework:domain-driven-design` -- Aggregates, entities, value objects, domain services. (conditional: domain-layer components only) 8. `framework:secure-coding` -- Trust bounds, injection prevention, secrets handling. (conditional: trust-boundary code only) 9. `framework:test-quality` -- AAA structure, isolation, assertion quality, naming. (always when writing tests)

Workflow

Step 1: Establish Implementation Context

1. Run `framework:learning-harvest` Load behavior. Focus hint: "implementation session — focus: implementation craft, quality signals, reliability". 2. Run `framework:context-anchoring` Document Discovery: scan the context base directory (per the atom's Config Resolution) for an existing anchor doc covering this feature's implementation.

• **Found** → Load behavior. Present the structured acknowledgment: feature name, **status**, decision count, open questions, constraints. **STOP:** Honor every logged decision and constraint as an active commitment.
• **Not found** → ask the user: "Is there a design doc or blueprint for this feature, or do we work from what we've discussed?" Accept either answer gracefully:
• Doc provided → load it and follow it.
• Proceed without → all atom rails still apply; there is simply no approved design doc to reference. Work from the verbal requirements in conversation.

**Design completeness check** — run both gates before Step 2 (no context doc exists → skip both, proceed as **"Without approved design"**):

**Check 1 — status:** Read the context doc frontmatter `status`.

• `approved` → pass.
• `complete` → this feature was already implemented. If the current request is new scope, recommend `/design-blueprint` for a fresh design pass; if the user confirms proceeding on the existing design, continue as **"With approved design"** (Check 2 still applies).
• Anything else (including `draft` or a missing field) → **STOP:** "Context doc not approved (`status: [value]`). Run `/design-blueprint` first. Proceed anyway?" On confirmation → log it in the Decisions Log and continue as **"Without approved design"**.

**Check 2 — levels present:** Scan the body for `## Design: Level 3` and `## Design: Level 4`.

• Both present → pass.
• Either missing → **STOP:** "Missing [Level 3 / Level 4 / both]. Proceed anyway?" On confirmation → log the absent levels in the Decisions Log and treat them as gaps to fill during implementation.

Both pass → proceed as **"With approved design"**.

Step 2: Plan Implementation Order

**With approved design**: extract the component list and layer assignments from the context anchor doc. Use the Level 2 (Components) decisions for layer placement and Level 3 (Interactions) for dependency flow.

**Without approved design**: classify the required components into architecture layers using the layer definitions from `framework:architecture`. For each component determine:

• What is its primary responsibility? (business rules, data access, coordination, external I/O)
• Which layer in the loaded architecture doc matches that responsibility?
• What dependency constraints apply to that layer?

If `framework:architecture` resolved no layer definitions (neither defaults nor a custom doc), surface it: "No architecture rules available. Run `/architecture-refiner` to define your architecture standards. Proceeding without architecture guidance." Continue with the remaining atom rails.

Present the proposed layer assignments to the user for approval before proceeding.

In both cases, plan an **inside-out implementation order** following the dependency direction from the loaded architecture doc — start at the innermost layer (no outward dependencies) and work outward, so each layer's dependencies already exist when it is built.

Classify each operation per the flow patterns in the loaded architecture doc (e.g., command vs query flows, or the equivalent distinction in your architecture style).

Present the implementation plan — ordered component list, layer assignments, flow classifications — and confirm with the user before writing code. If the user rejects or corrects the plan, revise and re-present it. **STOP:** Never start coding on an unagreed plan.

After the plan is approved, ask the user to choose a **review mode**:

> "How should we review the implementation?" > 1. **Layer-by-layer** (recommended) — implement each layer fully, pause for review before the next. One review point per layer. > 2. **Full autonomy** — implement everything end-to-end, present the complete result. One review point at the end. (If a blueprint exists, still pause on any deviation from the approved design.) > 3. **Component-by-component** — pause after each individual compon