implement

Architecture Document Implementation

Translate an HLD or LLD into working code through phased, verified implementation with goal-backward verification. Performs gap analysis, establishes must-haves before execution, and verifies the actual goals were achieved — not just that tasks completed.

When to Use

Use after an HLD or LLD is finalized and ready for implementation. Works best with LLDs (which contain file-level implementation plans), but can also work from HLDs at a higher level.

Use --resume to continue from a paused implementation session.

Source Integrity Rules

Every factual claim about the codebase must be verified through tool calls in this session.

1. Cite your work. When referencing code, patterns, or architecture, cite the specific tool call that discovered it (file path + line number from Read, Grep result, Explore agent finding).
2. Never reference prior Claude sessions or Claude memory. Do not source implementation decisions from auto-memory, MCP memory tools, or cross-session context.
3. Assumptions are labeled, not hidden. If you lack evidence for a claim and cannot research it, explicitly label it as an assumption.

Process

Human-in-the-loop: Never proceed past a decision point without user approval. Each implementation phase requires explicit sign-off before moving to the next.

Resume Check

If --resume is set or .continue-here.md exists in the project root:

1. Read .continue-here.md
2. Present what was completed, what remains, and any anti-patterns encountered
3. Ask: "Resume from where we left off?"
4. If yes: skip to the recorded next action
5. If no: start fresh (rename .continue-here.md to .continue-here-<timestamp>.md)

---

Phase 1: Absorb the Design Document

1. Read the document at the path provided via $ARGUMENTS. If no path is provided, ask which HLD or LLD to implement.
2. Detect document type (HLD vs LLD) from content and structure:
   • LLD indicators: method signatures, sequence diagrams, file-level implementation plan, error catalogs
   • HLD indicators: component diagrams, trade-off analysis, high-level architecture
3. If HLD: check if a corresponding LLD exists (look for lld- variant of the filename, or references in the HLD). If found, suggest reading both. If not, note that implementation will proceed at a higher level of abstraction.
4. Extract key elements:
   • Goals — what the implementation achieves
   • Components — modules, services, files involved
   • Implementation phases — if the doc defines them
   • File-level plan — specific files to create/modify (LLD)
   • Dependencies — libraries, services, infrastructure
   • Assumptions — stated assumptions that need validation
   • Open questions — unresolved items from the design process
   • D-XX decisions — if the context file has numbered decisions, extract them for coverage tracking