Menu
Generate system architecture, machine-readable schemas, and UI mockups. Spawns planner + ui-designer concurrently.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | design |
| description | Generate system architecture, machine-readable schemas, and UI mockups. Spawns planner + ui-designer concurrently. |
| context | fork |
/design
No arguments. Reads from specs/stories/ and produces architecture documents, machine-readable schemas, and HTML mockups concurrently.
This is the third gate in the SDLC pipeline. Two agents run concurrently in a single message: a planner agent produces system architecture and machine-readable schemas, while a ui-designer agent produces self-contained HTML mockups. After both complete, a post-completion validation step verifies that UI data shapes align with API contracts.
specs/stories/ must exist and contain story files. If it does not, halt and tell the human to run /spec first.
In a single message, invoke both agents using the Agent tool. Do not wait for the planner to finish before starting the ui-designer.
Prompt:
Read all files in specs/stories/. Design the full system architecture for this project.
Write the following files to specs/design/:
system-design.md — High-level architecture overview: components, data flows, infrastructure topology, key design decisions and rationale.
api-contracts.md — Every API endpoint in detail: method, path, request schema (headers, params, body), response schema (success and error shapes), authentication requirements, rate limits. Use a consistent format for each endpoint.
api-contracts.schema.json — OpenAPI 3.0 JSON Schema representing all endpoints defined in api-contracts.md. Must be valid and parseable.
data-models.md — Every data entity: field names, types, constraints, relationships, indexes, and example records.
data-models.schema.json — JSON Schema (draft-07 or later) for every entity in data-models.md. Must be valid and parseable.
folder-structure.md — Full proposed directory tree for the implementation, with a one-line annotation for each directory explaining its purpose.
component-map.md — A table mapping every story ID (from specs/stories/) to the specific files that will be created or modified to implement it.
deployment.md — Deployment architecture: environments (dev/staging/prod), CI/CD pipeline steps, infrastructure-as-code approach, secrets management strategy, rollback procedure.
Prompt:
Read all files in specs/stories/ and specs/design/api-contracts.md (if it exists; wait or proceed with story context if not yet available).
For every story with layer "UI", create a self-contained HTML mockup:
- The mockup must be a single .html file with all CSS and JavaScript inlined (no external dependencies).
- Use realistic mock data that matches the field names and types defined in api-contracts.md.
- Show the primary happy-path state. Include at least one empty/error state as a toggle or commented section.
- Label each interactive element with its API call (e.g., "POST /api/auth/register").
- The filename must match the story ID: E{n}-S{n}.html
Write all mockups to specs/design/mockups/.
After both agents complete, perform a validation pass:
specs/design/api-contracts.mdspecs/design/mockups/api-contracts.mdReport the validation results:
| Artifact | Purpose |
|---|---|
api-contracts.schema.json | OpenAPI 3.0 schema — machine-readable by the evaluator for contract testing |
data-models.schema.json | JSON Schema — used by builder agents to generate type-safe code |
component-map.md | Maps stories to implementation files — used by builder agents for routing |
These are new in this pipeline. forge_v2 produced only markdown documents. The .schema.json files enable automated validation in later pipeline stages.
| File | Purpose |
|---|---|
specs/design/system-design.md | Architecture overview |
specs/design/api-contracts.md | Human-readable API contracts |
specs/design/api-contracts.schema.json | OpenAPI 3.0 machine-readable schema |
specs/design/data-models.md | Human-readable data model definitions |
specs/design/data-models.schema.json | JSON Schema for all data entities |
specs/design/folder-structure.md | Proposed directory tree with annotations |
specs/design/component-map.md | Story ID → implementation files mapping |
specs/design/deployment.md | Deployment architecture and CI/CD plan |
specs/design/mockups/E{n}-S{n}.html | One self-contained HTML mockup per UI story |
Human approval is required before proceeding to /build.
After presenting all artifacts and validation results, ask: "Does this architecture and these mockups look correct? Approve to proceed to /build, or provide corrections."
user_name field but the API contract defines username, the downstream evaluator will flag a mismatch.folder-structure.md and component-map.md are the routing instructions for the build phase. Missing or vague entries cause agents to create files in wrong locations..schema.json files before presenting for human review.Autonomous build loop with Karpathy ratcheting, GAN evaluator, and session chaining. Iterates story groups until all features pass or stopping criteria met.
Socratic interview to create a Business Requirements Document. First step in the SDLC pipeline.
Evaluation patterns — sprint contract format, three-layer verification, scoring rubric references.
Standard GitHub issue workflow. Branch, reproduce, fix, test, PR.
Generate production code and tests for a story group using agent teams for parallel execution.
Refactor existing code for quality, performance, or maintainability. Enforces six quality principles with ratchet gate.