القائمة
Write a formal design spec from brainstorming output or requirements. USE WHEN design approved, write spec, formalize design, spec document.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Create and validate skills for forge modules. USE WHEN create skill, new skill, write skill, validate skill, check skill, skill structure, skill conventions.
Create, validate, evaluate, and iterate skills for forge modules. USE WHEN create skill, new skill, write skill, validate skill, check skill, skill structure, skill conventions, test a skill, run skill evals, benchmark a skill, skill not triggering, optimize skill description. Not for adopting community skills (AdoptArtifact) or shipping artifacts downstream (PublishArtifact).
Create, validate, or place behavioral rules in forge modules. USE WHEN create rule, new rule, write rule, capture rule, add a rule, graduate a correction or convention to a rule, validate rule, rule conventions, where does this rule belong, or the user runs /Rule.
Scaffold a workshop project: a VCS spine (git + jj colocate + entire + forge hooks), the private/public/assets flow layout with a .tlp manifest, a .claude/ that mounts the knowledge vault, and on-demand satellites (vault folder-note, data dir, private remote). USE WHEN starting a new project, initializing a folder for work, adding a vault note or data dir or remote to a project, archiving a project, or the user runs `project` / `atlas`.
Collaborative ideation before implementation — explore context, clarify intent, propose approaches. USE WHEN starting creative work, new features, design decisions, or modifying behavior.
Execute an implementation plan inline — task by task in a single session — then finish the work: verify, present integration options (merge, PR, keep, discard), and clean up the workspace. USE WHEN executing plan, run plan, implement plan, inline execution, implementation complete, deciding merge strategy, finishing a feature branch or workspace.
| name | DesignSpec |
| version | 0.1.0 |
| description | Write a formal design spec from brainstorming output or requirements. USE WHEN design approved, write spec, formalize design, spec document. |
Produce a formal design specification from approved brainstorming output or direct requirements. The spec is the contract between design and implementation — Plan and DeveloperSprint consume it.
docs/specs/YYYY-MM-DD-<topic>-design.mdScale sections to complexity. Simple specs skip sections that don't apply.
Before presenting the spec, verify:
| Check | Question |
|---|---|
| Completeness | Could someone implement this without asking questions? |
| Consistency | Do all sections agree with each other? |
| Clarity | Is every term unambiguous? No "should", "might", "maybe"? |
| Scope | Does this solve the stated problem without gold-plating? |
| YAGNI | Is every feature justified by a stated requirement? |
| Thought | Reality |
|---|---|
| "The design is clear enough, skip the spec" | If it's clear, the spec writes fast. If not, you need it more. |
| "I'll fill in the details during coding" | That's not a spec, it's a wish list. |
| "Edge cases can wait" | Edge cases found during coding cost 10x more to handle. |
| "The user already approved the design" | Design approval is not spec approval. Write it down. |
| "This spec is too short" | Short specs for simple problems are correct. Don't pad. |