/design-blueprint

name: design-blueprint
description: "Run a complete design workflow -- from establishing context through four progressive design levels (Capabilities, Components, Interactions, Contracts) to an approved blueprint. Composes knowledge-priming, context-anchoring, learning-harvest, collaborative-judgment, design-first, architecture, and domain-driven-design into one process. Handles both new features (create context doc) and resuming existing work (load context doc). Level 5 (Implementation) is delegated to code-forge. Use when starting a design, planning architecture, or when the user says 'design a feature', 'blueprint', 'start designing', 'plan the architecture', or 'let's design before coding'."

Design Blueprint

Required Skills

Read and apply in order before Step 1:

1. `framework:knowledge-priming` -- Load the project knowledge base so every decision grounds in the real project. (always) 2. `framework:context-anchoring` -- Create or load the feature's living context doc (Create / Load / Enrich behaviors). (always) 3. `framework:learning-harvest` -- Load prior operational learnings 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:design-first` -- Owns the 5-level methodology. Its Entry Assessment, Complexity Calibration, Simplicity Check, and Level Completion Protocol govern Step 2. (Step 2) 6. `framework:architecture` -- Validate components, layers, dependency direction, and boundary rules (design mode). (Levels 2-4) 7. `framework:domain-driven-design` -- Model aggregates, entities, value objects, events, and contracts (design mode). (Levels 2-4)

Additional Instructions

**STOP: Before Step 1, read `additional_instructions.design_blueprint` (one line or a list) from `.lattice/config.yaml`.** No file or no key → skip silently.

When lines are found:

1. Show them verbatim under "Additional instructions (from config):". 2. **Highest priority — apply them for the whole session, including on resume.** On any conflict with anything else in this skill — steps, gates, STOP rules — or with its Required Skills, standards documents, or operational learnings, the config line wins.

Workflow

Step 1: Establish Context

1. Run `framework:learning-harvest` Load behavior. Focus hint: "design session — focus: design patterns, reliability, structural health". 2. Set up the feature's living doc with `framework:context-anchoring`:

• **Discover**: run context-anchoring Document Discovery — scan the context base directory (per the atom's Config Resolution) for an existing anchor doc matching the feature name or frontmatter.
• **Found** → Load behavior. Present the structured acknowledgment: feature name, status, decision count, open questions, constraints. Then run the resume check below.
• **Not found** → Create behavior. Confirm the feature name, summary, and requirement doc link with the user before creating. Then begin Step 2 — the Entry Assessment sets the entry level.

3. **Resume check** (when a doc was found) — derive the earliest incomplete step from the doc itself. **STOP:** Never re-walk agreed work:

• `status: approved` → design is finished. Say so and stop; suggest `/code-forge`.
• No sections starting `## Design: Level` → begin Step 2 — the Entry Assessment (and its spec rule) sets the entry level.
• Some levels persisted → summarize the approved levels briefly, then resume at the first missing level at or after the recorded entry level (the `[Entry]` Decisions Log entry; older docs without one → treat entry as Level 1).
• Every level from entry through Level 4 persisted, but no `## Design Summary`, or `status` ≠ `approved` → go directly to Step 3.

4. **Requirement constraints**: read `requirement_doc` from the context doc frontmatter.

• Absent → skip.
• Local path, unreadable → STOP: "Requirement doc not found at `[path]`. Verify before continuing."
• Local path, readable → read it and extract `## Technical Constraints`. Treat as non-negotiable — same authority as architecture rules. Surface to the user before the first level is presented.
• External reference (URL, ticket ID, or other non-local-path identifier) → resolve via a connected MCP tool if one can. If none is connected or the fetch returns nothing, ask the user to paste the current constraints — expected, not an error.
• Either path resolved to the spec itself (not pasted constraints only) → Step 2's spec rule applies.
• Conflict during design → surface via `framework:collaborative-judgment`. The user decides; record the change back in the requirement doc's `## Technical Constraints` if local, or in the Decisions Log if external — this molecule never writes to an external system.

5. **Write the back-link**: if `requirement_doc` resolved to a readable local file, add to its `## Links` section (create it at the end if missing): `- Design: [{context-doc-filename}]({path from the requirement doc to this context doc})`. Several context docs may link one requirement (e.g. one per platform) — one line each. One discrete file edit; skip if this context doc's link is already present.

Step 2: Walk the Design Levels

Run design-first's Entry Assessment first: state the proposed entry level from its Complexity Calibration table and wait for confirmation. Record the confirmed entry level in the Decisions Log: `[Entry] Start at Level N (name) — rationale.` If key use cases or success criteria are unclear, surface them via `framework:collaborative-judgment` before producing the first level output.

**Spec as Level 1**: when the context doc has no `## Design: Level` section yet and `requirement_doc` resolved to the spec itself, the spec is Level 1. Do not re-validate it — spec quality belongs to requirement-forge.

• Propose entry at Level 2 or the calibrated level, whichever is later, and offer: "Level 1 comes from the li