code-forge
Code Forge generates production-ready implementation code from design blueprints or verbal requirements by integrating knowledge priming, context anchoring, domain-driven design, clean code principles, security standards, and test quality practices. Use this skill when moving from approved designs to code, implementing contracts, or when the user explicitly requests implementation work such as "implement this," "code it," "build it," or "forge the code."
git clone --depth 1 https://github.com/techygarg/lattice /tmp/code-forge && cp -r /tmp/code-forge/skills/molecules/code-forge ~/.claude/skills/code-forgeSKILL.md
# Code Forge ## Required Skills Read, apply: 1. `framework:knowledge-priming` -- Load proj context (stack, arch, conventions) so impl matches real proj (always) 2. `framework:context-anchoring` -- Load/find context anchor doc; enrich as impl decisions made (always) 3. `framework:learning-harvest` -- Load prior operational learnings inform impl; harvest new patterns at session end (always) 4. `framework:collaborative-judgment` -- Surface real judgment calls w/ structured opts vs silent assume (always) 5. `framework:architecture` -- Layer place, dep direction, struct valid (always) 6. `framework:clean-code` -- Craft rails: SRP, naming, complexity, err handle (always) 7. `framework:domain-driven-design` -- Aggregates, entities, VOs, domain svcs (conditional: only when touch domain folder) 8. `framework:secure-coding` -- Trust bounds, injection prevent, secrets mgmt (conditional: only boundary-cross code) 9. `framework:test-quality` -- AAA struct, isolation, assert quality, naming (always when write tests) ## Workflow ### Step 1: Establish Implementation Context Use `framework:learning-harvest` Load behavior. Focus hint: "implementation session — focus: implementation craft, quality signals, reliability". Prior learnings about coding patterns, recurring quality issues, and failure modes inform implementation from the start — e.g., learnings say "anemic domain models keep appearing," push behavior into entities. Learnings flag "missing input validation on VOs," validate in constructors from start. Use `framework:context-anchoring` Doc Discovery check existing context anchor doc for feature impl. - **If found** → Load (context-anchor Load behavior). Present struct ack -- feature name, decision count, open Qs, constraints. Honor all logged decisions/constraints as active commits. - **If not found** → Nudge user: "Have design doc/blueprint for feature? Or work from discussed?" Accept either graceful. - User provides doc → load, follow. - Proceed without → all atom rails still apply; just no struct blueprint ref. Work from verbal reqs in convo. ### Step 2: Plan Implementation Order **With blueprint**: Extract component list, layer assigns from context anchor doc. Use L2 (Components) decisions for layer place, L3 (Interactions) for dep flow. **Without blueprint**: Classify req components→arch layers using layer defs from `framework:architecture`. Each component, determine: - Primary responsibility? (biz rules, data access, coord, external I/O) - Which layer in loaded arch doc matches responsibility? - Dep constraints for that layer? If `framework:architecture` no loaded layer defs (neither defaults nor custom doc resolved), warn: "No arch rules avail. Run `/architecture-refiner` define arch standards. Proceed w/o arch guidance." Continue w/ only remaining atom rails. Present proposed layer assigns→user for approval before proceed. Both cases, plan **inside-out impl order** following dep direction from loaded arch doc — start innermost layer (no outward deps), work outward. Each layer's deps should exist when built. Classify each op per flow patterns in loaded arch doc (e.g., cmd vs query flows, or equiv distinction your arch style). Present impl plan -- ordered component list, layer assigns, flow classifs -- confirm w/ user before write code. After plan approved, ask user choose **review mode**: > "How review impl?" > 1. **Layer-by-layer** (rec) -- Impl each layer fully, pause for review before next. One review pt/layer. > 2. **Full autonomy** -- Impl everything end-to-end, present complete result. One review pt at end. (If blueprint exists, still pause any deviation from approved design.) > 3. **Component-by-component** -- Pause after each individual component for feedback. Max review pts. Default **layer-by-layer** if user no preference. ### Step 3: Implement Per Component Each component in planned order, gen **code+tests together** -- tests not afterthought. Every component: - **Place correct arch layer** per `framework:architecture`. Valid dep direction follows loaded arch rules. - **Apply `framework:clean-code` self-valid** during gen. Run inline checks: SRP comply, meaningful naming, low cyclomatic complexity, proper err handle, no magic vals, clean func sigs, no dead code, appropriate abstract level, clear control flow, minimal comments (code self-doc). - **Write tests** using `framework:test-quality` self-valid. Conditional checks per component: - **If domain layer** → Apply `framework:domain-driven-design` self-valid. - **If trust boundary** (HTTP handler, external API call, user input process, file I/O) → Apply `framework:secure-coding` self-valid. - **If blueprint exists** → Verify component fulfills L4 (Contracts) spec. Flag any deviation from agreed contract. **Post-Gen Verification** (applies every component, all review modes): After gen each component, before present→user: 1. Run **Self-Valid Checklist** from each applicable atom against every func/class this component. Atoms use imperative STOP-verify lang -- follow literally. 2. Run **Active Anti-Pattern Scan** from each applicable atom. Check every box scan list. 3. Violations found → fix before present. Don't present code you know violates atom checklist. 4. Judgment calls flagged (see each atom's Ambiguity Signals) → collect. Present using `framework:collaborative-judgment` protocol before show code. Don't silent resolve. 5. All checks pass, no flagged judgment calls → present w/ brief comply note (e.g., "All clean-code, DDD checks pass"). Keep one line when clean -- only verbose when report violations, fixes. **Pacing -- follow user's chosen review mode**: - **Layer-by-layer**: Impl all components within layer, present full layer (code+tests) for review before next layer. - **Full autonomy**: Impl all layers continuous. Present complete impl (all code+tests) at end. Skip→Step 4 (Cross-Component Verif) after all components done. - **Component-by-component**: Present each component w/ tests in
Audit and fix all Lattice documentation, README, docs/, GitHub issue templates, and CLAUDE.md to ensure they are fully aligned with the current skill inventory. Documentation drift is the most common source of user confusion in Lattice — a skill exists in the codebase but not in the docs, or a renamed skill leaves a stale reference in the bug report template. If you've made any change to skills/ and haven't run this, run it now. Use when the user says 'align docs', 'audit docs', 'update documentation', 'skill align', 'check docs are in sync', 'audit skill inventory', 'ensure docs are aligned', 'are the docs up to date', or 'what needs updating'. Standalone — does not call other skills.
Create a new Lattice skill — atom, molecule, or refiner — following all framework conventions. Writing skill files manually almost always produces convention violations: wrong section order, missing confirmation gates, defaults.md without the right structure. This skill knows all of that and guides you through it. Use whenever adding any new atom, molecule, or refiner to Lattice, or when the user says 'create a new skill', 'add an atom', 'add a molecule', 'add a refiner', 'build X for Lattice', 'new lattice skill', or 'skill forge'. Does not validate, align docs, or deploy — those are separate skills you run after.
Deep behavioral audit of a Lattice skill — proposes 3 review personas relevant to the skill, runs independent scenario analysis from each persona's perspective, then merges only the high-confidence, practical findings into a severity-ordered gap report with proposed fixes. Structural validation (conventions, cross-references) is skill-validate's job — this skill finds gaps that would realistically surface when someone actually uses the skill: missing scenario handling, ambiguous instructions, silent failure cases, and behavioral inconsistencies. Filters out theoretical edge cases, low-likelihood speculation, and findings owned by other skills. Use after writing or significantly changing any skill, or when the user says 'review this skill', 'deep review', 'does this skill work', 'find gaps in this skill', 'stress test this skill', 'review from different angles', or 'skill review'. Standalone — does not call other skills.
Validate any Lattice SKILL.md against all tier conventions — atoms, molecules, and refiners. Catches structural errors, broken cross-references, and convention violations before they reach the repo. If you just wrote or modified a Lattice skill file and haven't run this yet, run it now — manual review consistently misses the same categories of errors this skill is specifically designed to catch. Use when the user says 'validate this skill', 'check this skill', 'does this follow conventions', 'review this skill file', 'check my SKILL.md', or 'skill validate'. Reports PASS/FAIL with specific file-and-section findings and actionable fixes. Standalone — does not call other skills.
Architectural thinking partner for an existing repository — scans the codebase, conducts a structured interview, agrees on current architectural state and recommended direction, and produces a shareable insights document. Scoped to one repository, module, or folder. Does not execute transformation — it orients. Use when the user says 'assess my codebase architecture', 'what direction should my codebase go', 'architecture compass', 'understand my architecture', 'audit architecture drift', 'architectural assessment', or 'help me understand what is wrong with my codebase'.
Facilitate a structured conversation to define architecture principles for a repository. Supports multiple architecture styles: clean architecture (default), hexagonal / ports & adapters, modular monolith, or custom. Produces a formal architecture document that the corresponding atom will use. Use when setting up a new project, defining architecture standards, or when the user says 'setup architecture', 'define layers', 'architecture principles', 'help me define my architecture', 'hexagonal architecture', 'modular monolith', 'ports and adapters', or 'define my architecture style'.
Enforce architectural rules when generating or modifying code. Defaults to clean architecture; supports any architecture style via the architecture-refiner. Validates layer responsibilities, dependency direction, and structural constraints using the loaded architecture rules. Use when generating code, reviewing architecture, creating new files, or when the user mentions 'architecture', 'layers', 'structure', 'dependency rules', 'hexagonal architecture', 'ports and adapters', 'modular monolith', or 'onion architecture'. Also use when reviewing generated code for structural compliance.
Investigate, reproduce, and safely fix a bug with regression protection. Composes context, diagnosis, architecture, code quality, and testing guardrails into a reproduce-first repair workflow. Use when the user says 'fix this bug', 'debug this', 'investigate this failure', 'patch this regression', 'repair this issue', or 'why is this broken'.