Assemble generated CoDD sprint fragments into a complete, buildable project. Use after all codd implement sprints have produced src/generated/sprintN/ fragments and the design documents are ready to be integrated into final project files, entry points, source code, and configuration.
Conversationally evolve an existing CoDD project. Use when the user describes a functional change in natural language ("add logout button", "change course model to master + delivery target", "remove daily log step") and you need to update requirements, design docs, lexicon, source code, and tests together while…
Consult Claude Fable 5 (Anthropic's most capable model for deep, long-horizon reasoning — or whichever model currently holds that role) for a genuinely hard, novel CoDD architectural design decision, where a quick mechanical patch would be wrong. Packages CoDD's philosophy, invariants, GitHub repo, and session-derived…
Generate CoDD design documents for a greenfield project one wave at a time. Use after codd init and prepared requirements when the user needs requirement-driven design docs, frontmatter validation, graph refresh, and human approval gates between waves.
Run the CoDD greenfield autopilot: a requirements document in, a working system out, unattended. Use when the user wants to build a NEW system from a requirements doc ("greenfield", "build from requirements", "要件定義から自動構築", "write requirements and walk away") or to resume/inspect an interrupted autopilot run.…
Analyze the downstream impact of changed requirements, design docs, code, or tests in a CoDD project. Use when the user needs to decide which CoDD artifacts should be updated next, whether autonomous propagation is allowed, or whether a human approval gate is required.
Initialize CoDD in a project and establish the first scan and validation baseline. Use when a repository does not yet have a codd/ directory, when importing initial requirements, or when bootstrapping greenfield or brownfield CoDD project structure.
Reverse-propagate source code changes back to affected CoDD design documents. Use after code changes when the user needs to map changed source files to modules, identify impacted design docs, and optionally update those docs while preserving CoDD coherence.
Reconstruct CoDD design documents from extracted code facts for a brownfield project. Use after codd extract and wave planning when the user needs to infer requirements or restore system and detailed design from existing source code rather than greenfield requirements.
Refresh a CoDD project's dependency graph from document frontmatter and source code. Use after changes to requirements, design docs, implementation, or tests when the user needs current graph data, frontmatter coverage, node and edge counts, or warnings before validation or impact analysis.
Validate CoDD frontmatter and dependency references before scan, impact, generation, or propagation work continues. Use when the user needs to confirm YAML frontmatter, required metadata, dependency references, and graph inputs are parseable and internally consistent.
A procedure for consulting a frontier-class external reasoning model (extended-thinking tier) on a decision that matters — and for accepting its answer afterwards. Generates the consultation prompt, then audits the reply. Vendor-neutral: any top-tier model will do. Not for routine work sent to a cheap model — that is…
A two-machine live meeting copilot. A Windows laptop streams two audio channels (your mic, and a loopback of the other side's voice) to a parent machine, which transcribes them, drives a teleprompter you read from, watches every incoming utterance against a ledger of pre-agreed facts, and answers off-script questions.…