[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M786P0ASCBMPX19MYDFZE91V":3,"skill-same:01M786P0ASCBMPX19MYDFZE91V":58},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":28,"commitSha":29,"skillDirectory":30,"forksCount":14,"repositoryHtmlUrl":31,"repositoryHomepageUrl":6,"ownerHtmlUrl":32,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":33,"install":34,"resources":47},"01M786P0ASCBMPX19MYDFZE91V","sp-design",null,"Use when a project needs a DESIGN.md design-system contract, design-system synthesis, UI style refinement, or design readiness audit before UI work proceeds.","chenziyang110\u002Flaunchdeck","chenziyang110","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F43693913?v=4","01M7863EBWK1D0P6A29YGEMAS4","Robin11","01M7863ECM1VB6RXDMHTW90D2T",0,"MIT","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fsp-design\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: \"sp-design\"\ndescription: \"Use when a project needs a DESIGN.md design-system contract, design-system synthesis, UI style refinement, or design readiness audit before UI work proceeds.\"\ncompatibility: \"Requires spec-kit project structure with .specify\u002F directory\"\nmetadata:\n  author: \"github-spec-kit\"\n  source: \"templates\u002Fcommands\u002Fdesign.md\"\n---\n## Invocation Syntax\n\n- In this integration, invoke workflow skills with `$sp-plan`-style syntax.\n- References such as `\u002Fsp.plan`, `\u002Fsp.tasks`, or `next_command: \u002Fsp.plan` are canonical workflow-state identifiers and handoff values.\n- Preserve those canonical state tokens exactly in artifacts and workflow state; do not rewrite them to this integration's invocation syntax.\n\n\n\n## Workflow Contract Summary\n\n- **When to use**: A project needs product-wide interface style, design-system tokens, platform UI rules, or design readiness review before specification, planning, tasks, or implementation.\n- **Primary objective**: Produce, refine, synthesize, or audit the root `DESIGN.md` design-system contract without implementing UI code.\n- **Primary outputs**: `DESIGN.md`, `.specify\u002Fdesign\u002Fdesign-state.md`, `.specify\u002Fdesign\u002Freferences.md`, `.specify\u002Fdesign\u002Foptions.md`, and `.specify\u002Fdesign\u002Freview.md`; stable design rules in `.specify\u002Fmemory\u002Fproject-rules.md` only when they should become shared project defaults.\n- **Default handoff**: After user review, recommend exactly one next command: `\u002Fsp.discussion`, `\u002Fsp.specify`, `\u002Fsp.plan`, or the originally blocked workflow.\n- **Execution note**: This summary is routing metadata only. Follow the full contract below end-to-end rather than inferring behavior from the description alone.\n\n## Blocked Exit Contract\n\nIf blocked after safe recovery, read and follow\n`.specify\u002Ftemplates\u002Fworkflow-blocker-template.md` and its JSON schema. Never\nreturn only an error or “ask a human”; preserve state and keep agent-capable\nrepair agent-owned. Set `human_action_required: true` only for authority,\ncredentials, protected systems, human decisions\u002Freviews, or physical access.\nTailor steps, expected results, failure paths, evidence, and resume action to\nCI, visual review, or product decisions. Never claim completion.\n\nFor a feature runtime blocker, do not invent `resume_argv` or overwrite an\nexisting blocker. The CLI returns a read-only `show_argv` and structured\n`resolution_action`; `next_argv` stays empty while evidence is missing. After\nthe criteria are proven, attach sanitized evidence using the action's declared\ninput and execute its base argv. It restores the same owner and keeps the full\nblocker audit.\n\n# sp-design: Design System Workflow\n\nYou are running `sp-design`. This is a design-system workflow, not an implementation workflow.\n\n## Objective\n\nProduce, refine, synthesize, or audit the project's root `DESIGN.md` design-system contract so downstream UI work has a stable visual and interaction system before implementation starts.\n\n## Process\n\nFollow the phase lock, intake, synthesis, review, and closeout steps below. Keep the work design-only unless the user explicitly starts a downstream implementation workflow after reviewing the design output.\n\n## Workflow Phase Lock\n\n- Create or resume `.specify\u002Fdesign\u002Fdesign-state.md` before substantial design synthesis.\n- Set durable state with:\n  - `active_command: sp-design`\n  - `phase_mode: design-only`\n  - `current_stage: context-intake`\n  - `allowed_writes: DESIGN.md, .specify\u002Fdesign\u002Fdesign-state.md, .specify\u002Fdesign\u002Freferences.md, .specify\u002Fdesign\u002Foptions.md, .specify\u002Fdesign\u002Freview.md, .specify\u002Fmemory\u002Fproject-rules.md`\n  - `forbidden_actions: edit source code, edit tests, write CSS\u002Ftheme implementation files, create UI components, create feature specs, create plan artifacts, create task artifacts`\n- When resuming after compaction, read `.specify\u002Fdesign\u002Fdesign-state.md` before continuing.\n\n## Allowed Writes\n\n- `DESIGN.md`\n- `.specify\u002Fdesign\u002Fdesign-state.md`\n- `.specify\u002Fdesign\u002Freferences.md`\n- `.specify\u002Fdesign\u002Foptions.md`\n- `.specify\u002Fdesign\u002Freview.md`\n- stable design rules in `.specify\u002Fmemory\u002Fproject-rules.md` when they should become shared project defaults\n\n## Forbidden Writes\n\n- source code\n- UI components\n- CSS or theme implementation files\n- tests\n- business feature specs\n- plan or task artifacts outside the active design workflow\n\n## Modes\n\nInfer the mode from the user's request:\n\n- `create`: generate a new project design system from product context.\n- `synthesize`: transform references into an original design system.\n- `refine`: update an existing `DESIGN.md`.\n- `audit`: inspect whether the current design system is enough for upcoming UI work.\n\nIf the mode is ambiguous, choose the smallest safe mode and state the assumption.\n\n## Intake\n\n1. Read `DESIGN.md` if it exists.\n   If it declares `design_system.status: bootstrap`, treat it as a starter to\n   replace, not an approved constraint or evidence that design work is done.\n2. Read `.specify\u002Fdesign\u002Freferences.md`, `.specify\u002Fdesign\u002Foptions.md`, and `.specify\u002Fdesign\u002Freview.md` if they exist.\n3. Read `README.md`, project handbook files, existing UI surfaces, and existing design files. Use the command's shared Learning intake for project rules and reusable lessons.\n4. Use project cognition to locate likely UI entry points, token\u002Ftheme owners,\n   reusable component owners, responsive\u002Fstate patterns, visual or accessibility\n   tests, and design assets; verify every selected route in live files before it\n   becomes design evidence.\n5. Classify the experience separately by work type, surface type (`landing`,\n   `product-workspace`, `hybrid`, or `existing-pattern-maintenance`), and\n   platform (`web`, `mobile`, `desktop`, `tui`, or `cli`).\n6. If references are supplied as URLs, screenshots, text notes, existing design files, or imported summaries, assign each an explicit intent: `exact`, `preserve-structure`, `inspiration`, `extract-tokens`, or `do-not-copy`.\n7. When built-in presets help, read one of the shipped preset files such as `.specify\u002Ftemplates\u002Fdesign-library\u002Fworkbench-precision.md` or `.specify\u002Ftemplates\u002Fdesign-library\u002Fworkbench-precision.md` and treat it as inspiration, not as a forced brand.\n\n## Synthesis Rules\n\n- Write the project's own `DESIGN.md` as the final output.\n- Present two or three project-specific design directions when creating or synthesizing a design system.\n- Before proposing them, name the product subject, audience, and single user job.\n- Each direction must state a visual thesis, content thesis, interaction thesis,\n  signature element, platform fit, state strategy, safe system choices, and any\n  deliberate creative risk with its gain and cost.\n- Give every direction an inspectable visual artifact such as a moodboard,\n  rendered static composition, or screenshot. Ask the user to approve the\n  visual direction before writing or replacing `DESIGN.md`; a prose label alone\n  is not approval.\n- Ask the user to approve a direction; approval refers to its inspectable visual\n  artifact and recorded tradeoffs, not only its name.\n- Preserve existing project rules unless the user approves a design-system change that supersedes them.\n- Do not copy external brand names, protected visual identity, proprietary token names, or third-party file text into the final design system.\n- Normalize approved direction into `spec-kit-design-v1` YAML front matter plus readable Markdown guidance.\n- Set `design_system.status: approved` and record\n  `design_system.approval.status`, the selected direction, and concrete product\n  or repository `source_refs`, plus `approval.visual_refs`. Record\n  `product_context` and `direction_contract`. Remove unresolved placeholders and generic\n  starter choices that are not justified by those sources.\n\n## Output Contract\n\nThe workflow output is a root `DESIGN.md` contract plus supporting `.specify\u002Fdesign\u002F*` state, references, options, and review artifacts when relevant.\n\n## Required DESIGN.md Shape\n\n`DESIGN.md` must contain:\n\n- YAML front matter with `design_system.schema: spec-kit-design-v1`\n- `design_system.status: approved` plus approval direction and source refs\n- product subject, audience, single job, and approved visual reference\n- visual, content, and interaction theses plus one signature element\n- `design_system.name`\n- `design_system.version`\n- `design_system.platforms`\n- token categories for `color`, `spacing`, `radius`, and `typography`\n- component required states and token references\n- accessibility intent\n- Markdown sections for `Product Feel`, `Platforms`, `Component Rules`, `Anti-Patterns`, `UI QA Checklist`, and `Design Change Policy`\n\n## Review\n\nBefore closeout:\n\n1. Run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@6fbbf08a0b6833bb783ec6b418d567776b197ae4 specify design lint --level ready` when the CLI helper is available.\n2. Write `.specify\u002Fdesign\u002Freview.md` with:\n   - selected mode\n   - inputs read\n   - approved direction\n   - approved visual reference\n   - platforms covered\n   - design-system risks\n   - lint result\n   - recommended next workflow\n3. Ask the user to review the written design before downstream workflows consume it as locked input.\n\n## Closeout\n\nClose with the design-system status, changed files, lint result, and exactly one recommended next command.\n\n## Guardrails\n\n- Do not edit source code, tests, CSS\u002Ftheme implementation files, UI components, feature specs, plan artifacts, or task artifacts from this command.\n- Do not clone protected brands or copy third-party design files into `DESIGN.md`; synthesize project-owned design principles and tokens.\n- Do not let downstream workflows treat an unaudited or contradictory `DESIGN.md` as locked input.\n\n## Project Learning\n\nThe CLI is the only agent-facing Learning read surface:\n\n1. Run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@6fbbf08a0b6833bb783ec6b418d567776b197ae4 specify learning start --command '\u003Cclassic-command-name>' --format json` before deeper non-trivial work.\n2. Select summaries by applicability and triggers; use `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@6fbbf08a0b6833bb783ec6b418d567776b197ae4 specify learning list --command '\u003Cclassic-command-name>' --format json` only to filter or page.\n3. Execute one matching card's `show_argv`. Do not parse Learning storage.\n\nAfter minimal live inspection identifies a reused operation or changed entry point, rerun targeted recall with current code, tests, and task\u002Fcontract evidence, for example `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@6fbbf08a0b6833bb783ec6b418d567776b197ae4 specify learning list --command '\u003Cclassic-command-name>' --context 'operation_owner=\u003Cowner>' --context 'consumer_owner=\u003Cconsumer>' --context 'outcome=\u003Cresult-family>' --format json`. Do not derive these facets from archived specifications. An exact operation-owner match may surface a cross-command candidate even when the new consumer differs; treat it as a candidate, expand one `show_argv`, verify it against live evidence, and do not auto-apply it.\n\nWhen the entrypoint outcome audit is triggered, persist the live facets as `learning_context`, the contextual invocation as `learning_search_refs`, and returned refs as `learning_candidate_refs`. Record exactly one `applied`, `not_applicable`, or `deferred` item in `learning_dispositions` for every candidate. Do not silently ignore a candidate: applied Learning traces to requirement\u002Fconsequence refs, not-applicable needs current evidence, and deferred needs an explicit deferral ref.\n\n`start`, `list`, and `show` are read-only. Current repository evidence,\n`.specify\u002Fmemory\u002Fconstitution.md`, and explicit user direction override stale or\ncandidate Learning.\n\nAt closeout, corrections, retries, route changes, recovery, false leads, hidden\ndependencies, validation\u002Ftooling\u002Fstate\u002Fcognition gaps, constraints, and near\nmisses are capture signals. Prefer `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@6fbbf08a0b6833bb783ec6b418d567776b197ae4 specify learning capture-auto`\nfrom owning state; manual capture includes summary, problem, action, triggers,\nsuccess criteria, avoid items, exceptions, and evidence.\n\n- `fast`: skip unless the task escalates.\n- `accept`, `analyze`, `ask`, `auto`, `constitution`, `explain`,\n  `implement-teams`, `taskstoissues`, and `team`: consume-only; do not violate\n  their write boundaries to capture.\n- Other non-trivial workflows: consume before deeper work; capture reusable\n  signals at closeout or record a no-learning decision.\n\nThe `policy` returned by the CLI is authoritative when prompt wording drifts.\n\n[AGENT] For project-cognition-backed semantic intake, routing, audit, resume, or final-claim gates, read `references\u002Fsemantic-work-contract.md`.\n\n## Detailed References\n\nRead [Reference index](references\u002FINDEX.md) before applying shared semantic contracts.\n\n- [semantic work contract](references\u002Fsemantic-work-contract.md)\n\n## Adaptive Artifact-Phase Execution\n\nThis partial governs artifact-producing adaptive phases such as `sp-design`, `sp-plan`, and `sp-tasks`. `sp-implement` has its own task-level adaptive controller; debug, map, PRD, and other workflows keep their command-specific execution contracts.\n\nSelect the execution mode before dispatch:\n\n- `light`: low-risk, single-lane artifact work that is safe for leader-inline synthesis.\n- `standard`: bounded planning or task-generation work where native subagents should be used when available.\n- `heavy`: safety-critical, cross-boundary, high-risk, or hard-to-packetize work that requires safe native delegation before synthesis continues.\n\nRecord the adaptive decision fields exactly:\n\n- `execution_model: adaptive`\n- `execution_mode: light | standard | heavy`\n- `workflow_status: ready | blocked`\n- `dispatch_shape: leader-inline | one-subagent | parallel-subagents | subagent-blocked`\n- `execution_surface: leader-inline | native-subagents | none`\n- `capability_degraded: false | true`\n- `blocked_reason: required when blocked`\n\nUse `choose_subagent_dispatch(command_name=\"plan\" | \"tasks\", snapshot, workload_shape)` as the shared policy contract. Derive `workload_shape.lightweight_safe` from workload shape and risk keys; do not invent a separate template-only boolean.\n\nDispatch rules:\n\n- Light mode records `dispatch_shape: leader-inline`, `execution_surface: leader-inline`, `workflow_status: ready`, and `capability_degraded: false`.\n- Standard mode uses native subagents when available: one validated lane records `one-subagent`; two or more isolated lanes record `parallel-subagents`.\n- Standard mode may degrade to leader-inline only when native subagents are unavailable and no high-risk trigger is present; record `capability_degraded: true`.\n- Heavy mode must use native subagents with safely packetized lanes. If native subagents are unavailable, or if the work cannot be packetized safely, record `workflow_status: blocked`, `dispatch_shape: subagent-blocked`, `execution_surface: none`, and `blocked_reason`.\n\nArtifact-writing delegated lanes must use writable, execution-capable native subagents. If the runtime exposes role, sandbox, or permission choices, select a role\u002Fsandbox that can write the declared handoff file. Do not dispatch a read-only explorer, reviewer, or diagnostic lane when the lane must write a filesystem handoff; read-only lanes may provide supplemental evidence, but they do not satisfy `one-subagent` or `parallel-subagents` handoff requirements. The lane contract's allowed write scope must include the exact expected handoff path and must forbid unrelated writes unless the command explicitly assigns an additional generated artifact. If a delegated lane returns prose, idle state, or an unwritten handoff, stop or re-dispatch with a writable lane and the valid handoff path.\n\nDelegated lanes still require structured handoffs before synthesis. If delegated lanes were used, consume the one lane manifest and every accepted lane result before final output; do not duplicate the same events into evidence-index and checkpoint logs. If no lanes were delegated, report the delegated-lane field as `none`.\n\nManaged-team fallback is not part of adaptive plan\u002Ftasks dispatch. Do not route blocked adaptive planning or task generation to `sp-teams`, managed-team lifecycle language, or a durable team fallback from this command.\n\n## Codex Subagent Capability Discovery\n\n- Execution model: preserve the workflow's existing `subagent-mandatory`, `subagents-first`, `adaptive`, or `subagent-assisted` policy.\n- Dispatch shape: preserve the workflow's existing dispatch shape; use `subagent-blocked` only after the discovery step below fails or is unsafe.\n- Execution surface: prefer `native-subagents` when the current runtime supports it; use `none` only after recording the unavailable or unsafe surface.\n- Native subagent capability discovery: Before recording `subagent-blocked`, confirm the current runtime exposes `spawn_agent`, `wait_agent`, and `close_agent`; if they are not visible, use the active tool discovery mechanism for multi-agent or subagent tools first.\n- Do not record `subagent-blocked` until this capability discovery step is complete and the exact unavailable or unsafe surface is recorded.\n- Native subagent dispatch: Dispatch bounded subagents through `spawn_agent`.\n- Join behavior: Rejoin with `wait_agent`, integrate, then `close_agent`.\n- Preserve this workflow's existing packet, handoff, artifact, and result schema; this section only governs capability discovery before dispatch or blocked-state recording.\n","## Invocation Syntax\n\n- In this integration, invoke workflow skills with `$sp-plan`-style syntax.\n- References such as `\u002Fsp.plan`, `\u002Fsp.tasks`, or `next_command: \u002Fsp.plan` are canonical workflow-state identifiers and handoff values.\n- Preserve those canonical state tokens exactly in artifacts and workflow state; do not rewrite them to this integration's invocation syntax.\n\n\n\n## Workflow Contract Summary\n\n- **When to use**: A project needs product-wide interface style, design-system tokens, platform UI rules, or design readiness review before specification, planning, tasks, or implementation.\n- **Primary objective**: Produce, refine, synthesize, or audit the root `DESIGN.md` design-system contract without implementing UI code.\n- **Primary outputs**: `DESIGN.md`, `.specify\u002Fdesign\u002Fdesign-state.md`, `.specify\u002Fdesign\u002Freferences.md`, `.specify\u002Fdesign\u002Foptions.md`, and `.specify\u002Fdesign\u002Freview.md`; stable design rules in `.specify\u002Fmemory\u002Fproject-rules.md` only when they should become shared project defaults.\n- **Default handoff**: After user review, recommend exactly one next command: `\u002Fsp.discussion`, `\u002Fsp.specify`, `\u002Fsp.plan`, or the originally blocked workflow.\n- **Execution note**: This summary is routing metadata only. Follow the full contract below end-to-end rather than inferring behavior from the description alone.\n\n## Blocked Exit Contract\n\nIf blocked after safe recovery, read and follow\n`.specify\u002Ftemplates\u002Fworkflow-blocker-template.md` and its JSON schema. Never\nreturn only an error or “ask a human”; preserve state and keep agent-capable\nrepair agent-owned. Set `human_action_required: true` only for authority,\ncredentials, protected systems, human decisions\u002Freviews, or physical access.\nTailor steps, expected results, failure paths, evidence, and resume action to\nCI, visual review, or product decisions. Never claim completion.\n\nFor a feature runtime blocker, do not invent `resume_argv` or overwrite an\nexisting blocker. The CLI returns a read-only `show_argv` and structured\n`resolution_action`; `next_argv` stays empty while evidence is missing. After\nthe criteria are proven, attach sanitized evidence using the action's declared\ninput and execute its base argv. It restores the same owner and keeps the full\nblocker audit.\n\n# sp-design: Design System Workflow\n\nYou are running `sp-design`. This is a design-system workflow, not an implementation workflow.\n\n## Objective\n\nProduce, refine, synthesize, or audit the project's root `DESIGN.md` design-system contract so downstream UI work has a stable visual and interaction system before implementation starts.\n\n## Process\n\nFollow the phase lock, intake, synthesis, review, and closeout steps below. Keep the work design-only unless the user explicitly starts a downstream implementation workflow after reviewing the design output.\n\n## Workflow Phase Lock\n\n- Create or resume `.specify\u002Fdesign\u002Fdesign-state.md` before substantial design synthesis.\n- Set durable state with:\n  - `active_command: sp-design`\n  - `phase_mode: design-only`\n  - `current_stage: context-intake`\n  - `allowed_writes: DESIGN.md, .specify\u002Fdesign\u002Fdesign-state.md, .specify\u002Fdesign\u002Freferences.md, .specify\u002Fdesign\u002Foptions.md, .specify\u002Fdesign\u002Freview.md, .specify\u002Fmemory\u002Fproject-rules.md`\n  - `forbidden_actions: edit source code, edit tests, write CSS\u002Ftheme implementation files, create UI components, create feature specs, create plan artifacts, create task artifacts`\n- When resuming after compaction, read `.specify\u002Fdesign\u002Fdesign-state.md` before continuing.\n\n## Allowed Writes\n\n- `DESIGN.md`\n- `.specify\u002Fdesign\u002Fdesign-state.md`\n- `.specify\u002Fdesign\u002Freferences.md`\n- `.specify\u002Fdesign\u002Foptions.md`\n- `.specify\u002Fdesign\u002Freview.md`\n- stable design rules in `.specify\u002Fmemory\u002Fproject-rules.md` when they should become shared project defaults\n\n## Forbidden Writes\n\n- source code\n- UI components\n- CSS or theme implementation files\n- tests\n- business feature specs\n- plan or task artifacts outside the active design workflow\n\n## Modes\n\nInfer the mode from the user's request:\n\n- `create`: generate a new project design system from product context.\n- `synthesize`: transform references into an original design system.\n- `refine`: update an existing `DESIGN.md`.\n- `audit`: inspect whether the current design system is enough for upcoming UI work.\n\nIf the mode is ambiguous, choose the smallest safe mode and state the assumption.\n\n## Intake\n\n1. Read `DESIGN.md` if it exists.\n   If it declares `design_system.status: bootstrap`, treat it as a starter to\n   replace, not an approved constraint or evidence that design work is done.\n2. Read `.specify\u002Fdesign\u002Freferences.md`, `.specify\u002Fdesign\u002Foptions.md`, and `.specify\u002Fdesign\u002Freview.md` if they exist.\n3. Read `README.md`, project handbook files, existing UI surfaces, and existing design files. Use the command's shared Learning intake for project rules and reusable lessons.\n4. Use project cognition to locate likely UI entry points, token\u002Ftheme owners,\n   reusable component owners, responsive\u002Fstate patterns, visual or accessibility\n   tests, and design assets; verify every selected route in live files before it\n   becomes design evidence.\n5. Classify the experience separately by work type, surface type (`landing`,\n   `product-workspace`, `hybrid`, or `existing-pattern-maintenance`), and\n   platform (`web`, `mobile`, `desktop`, `tui`, or `cli`).\n6. If references are supplied as URLs, screenshots, text notes, existing design files, or imported summaries, assign each an explicit intent: `exact`, `preserve-structure`, `inspiration`, `extract-tokens`, or `do-not-copy`.\n7. When built-in presets help, read one of the shipped preset files such as `.specify\u002Ftemplates\u002Fdesign-library\u002Fworkbench-precision.md` or `.specify\u002Ftemplates\u002Fdesign-library\u002Fworkbench-precision.md` and treat it as inspiration, not as a forced brand.\n\n## Synthesis Rules\n\n- Write the project's own `DESIGN.md` as the final output.\n- Present two or three project-specific design directions when creating or synthesizing a design system.\n- Before proposing them, name the product subject, audience, and single user job.\n- Each direction must state a visual thesis, content thesis, interaction thesis,\n  signature element, platform fit, state strategy, safe system choices, and any\n  deliberate creative risk with its gain and cost.\n- Give every direction an inspectable visual artifact such as a moodboard,\n  rendered static composition, or screenshot. Ask the user to approve the\n  visual direction before writing or replacing `DESIGN.md`; a prose label alone\n  is not approval.\n- Ask the user to approve a direction; approval refers to its inspectable visual\n  artifact and recorded tradeoffs, not only its name.\n- Preserve existing project rules unless the user approves a design-system change that supersedes them.\n- Do not copy external brand names, protected visual identity, proprietary token names, or third-party file text into the final design system.\n- Normalize approved direction into `spec-kit-design-v1` YAML front matter plus readable Markdown guidance.\n- Set `design_system.status: approved` and record\n  `design_system.approval.status`, the selected direction, and concrete product\n  or repository `source_refs`, plus `approval.visual_refs`. Record\n  `product_context` and `direction_contract`. Remove unresolved placeholders and generic\n  starter choices that are not justified by those sources.\n\n## Output Contract\n\nThe workflow output is a root `DESIGN.md` contract plus supporting `.specify\u002Fdesign\u002F*` state, references, options, and review artifacts when relevant.\n\n## Required DESIGN.md Shape\n\n`DESIGN.md` must contain:\n\n- YAML front matter with `design_system.schema: spec-kit-design-v1`\n- `design_system.status: approved` plus approval direction and source refs\n- product subject, audience, single job, and approved visual reference\n- visual, content, and interaction theses plus one signature element\n- `design_system.name`\n- `design_system.version`\n- `design_system.platforms`\n- token categories for `color`, `spacing`, `radius`, and `typography`\n- component required states and token references\n- accessibility intent\n- Markdown sections for `Product Feel`, `Platforms`, `Component Rules`, `Anti-Patterns`, `UI QA Checklist`, and `Design Change Policy`\n\n## Review\n\nBefore closeout:\n\n1. Run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@6fbbf08a0b6833bb783ec6b418d567776b197ae4 specify design lint --level ready` when the CLI helper is available.\n2. Write `.specify\u002Fdesign\u002Freview.md` with:\n   - selected mode\n   - inputs read\n   - approved direction\n   - approved visual reference\n   - platforms covered\n   - design-system risks\n   - lint result\n   - recommended next workflow\n3. Ask the user to review the written design before downstream workflows consume it as locked input.\n\n## Closeout\n\nClose with the design-system status, changed files, lint result, and exactly one recommended next command.\n\n## Guardrails\n\n- Do not edit source code, tests, CSS\u002Ftheme implementation files, UI components, feature specs, plan artifacts, or task artifacts from this command.\n- Do not clone protected brands or copy third-party design files into `DESIGN.md`; synthesize project-owned design principles and tokens.\n- Do not let downstream workflows treat an unaudited or contradictory `DESIGN.md` as locked input.\n\n## Project Learning\n\nThe CLI is the only agent-facing Learning read surface:\n\n1. Run `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@6fbbf08a0b6833bb783ec6b418d567776b197ae4 specify learning start --command '\u003Cclassic-command-name>' --format json` before deeper non-trivial work.\n2. Select summaries by applicability and triggers; use `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@6fbbf08a0b6833bb783ec6b418d567776b197ae4 specify learning list --command '\u003Cclassic-command-name>' --format json` only to filter or page.\n3. Execute one matching card's `show_argv`. Do not parse Learning storage.\n\nAfter minimal live inspection identifies a reused operation or changed entry point, rerun targeted recall with current code, tests, and task\u002Fcontract evidence, for example `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@6fbbf08a0b6833bb783ec6b418d567776b197ae4 specify learning list --command '\u003Cclassic-command-name>' --context 'operation_owner=\u003Cowner>' --context 'consumer_owner=\u003Cconsumer>' --context 'outcome=\u003Cresult-family>' --format json`. Do not derive these facets from archived specifications. An exact operation-owner match may surface a cross-command candidate even when the new consumer differs; treat it as a candidate, expand one `show_argv`, verify it against live evidence, and do not auto-apply it.\n\nWhen the entrypoint outcome audit is triggered, persist the live facets as `learning_context`, the contextual invocation as `learning_search_refs`, and returned refs as `learning_candidate_refs`. Record exactly one `applied`, `not_applicable`, or `deferred` item in `learning_dispositions` for every candidate. Do not silently ignore a candidate: applied Learning traces to requirement\u002Fconsequence refs, not-applicable needs current evidence, and deferred needs an explicit deferral ref.\n\n`start`, `list`, and `show` are read-only. Current repository evidence,\n`.specify\u002Fmemory\u002Fconstitution.md`, and explicit user direction override stale or\ncandidate Learning.\n\nAt closeout, corrections, retries, route changes, recovery, false leads, hidden\ndependencies, validation\u002Ftooling\u002Fstate\u002Fcognition gaps, constraints, and near\nmisses are capture signals. Prefer `uvx --from git+https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Fspec-kit-plus.git@6fbbf08a0b6833bb783ec6b418d567776b197ae4 specify learning capture-auto`\nfrom owning state; manual capture includes summary, problem, action, triggers,\nsuccess criteria, avoid items, exceptions, and evidence.\n\n- `fast`: skip unless the task escalates.\n- `accept`, `analyze`, `ask`, `auto`, `constitution`, `explain`,\n  `implement-teams`, `taskstoissues`, and `team`: consume-only; do not violate\n  their write boundaries to capture.\n- Other non-trivial workflows: consume before deeper work; capture reusable\n  signals at closeout or record a no-learning decision.\n\nThe `policy` returned by the CLI is authoritative when prompt wording drifts.\n\n[AGENT] For project-cognition-backed semantic intake, routing, audit, resume, or final-claim gates, read `references\u002Fsemantic-work-contract.md`.\n\n## Detailed References\n\nRead [Reference index](references\u002FINDEX.md) before applying shared semantic contracts.\n\n- [semantic work contract](references\u002Fsemantic-work-contract.md)\n\n## Adaptive Artifact-Phase Execution\n\nThis partial governs artifact-producing adaptive phases such as `sp-design`, `sp-plan`, and `sp-tasks`. `sp-implement` has its own task-level adaptive controller; debug, map, PRD, and other workflows keep their command-specific execution contracts.\n\nSelect the execution mode before dispatch:\n\n- `light`: low-risk, single-lane artifact work that is safe for leader-inline synthesis.\n- `standard`: bounded planning or task-generation work where native subagents should be used when available.\n- `heavy`: safety-critical, cross-boundary, high-risk, or hard-to-packetize work that requires safe native delegation before synthesis continues.\n\nRecord the adaptive decision fields exactly:\n\n- `execution_model: adaptive`\n- `execution_mode: light | standard | heavy`\n- `workflow_status: ready | blocked`\n- `dispatch_shape: leader-inline | one-subagent | parallel-subagents | subagent-blocked`\n- `execution_surface: leader-inline | native-subagents | none`\n- `capability_degraded: false | true`\n- `blocked_reason: required when blocked`\n\nUse `choose_subagent_dispatch(command_name=\"plan\" | \"tasks\", snapshot, workload_shape)` as the shared policy contract. Derive `workload_shape.lightweight_safe` from workload shape and risk keys; do not invent a separate template-only boolean.\n\nDispatch rules:\n\n- Light mode records `dispatch_shape: leader-inline`, `execution_surface: leader-inline`, `workflow_status: ready`, and `capability_degraded: false`.\n- Standard mode uses native subagents when available: one validated lane records `one-subagent`; two or more isolated lanes record `parallel-subagents`.\n- Standard mode may degrade to leader-inline only when native subagents are unavailable and no high-risk trigger is present; record `capability_degraded: true`.\n- Heavy mode must use native subagents with safely packetized lanes. If native subagents are unavailable, or if the work cannot be packetized safely, record `workflow_status: blocked`, `dispatch_shape: subagent-blocked`, `execution_surface: none`, and `blocked_reason`.\n\nArtifact-writing delegated lanes must use writable, execution-capable native subagents. If the runtime exposes role, sandbox, or permission choices, select a role\u002Fsandbox that can write the declared handoff file. Do not dispatch a read-only explorer, reviewer, or diagnostic lane when the lane must write a filesystem handoff; read-only lanes may provide supplemental evidence, but they do not satisfy `one-subagent` or `parallel-subagents` handoff requirements. The lane contract's allowed write scope must include the exact expected handoff path and must forbid unrelated writes unless the command explicitly assigns an additional generated artifact. If a delegated lane returns prose, idle state, or an unwritten handoff, stop or re-dispatch with a writable lane and the valid handoff path.\n\nDelegated lanes still require structured handoffs before synthesis. If delegated lanes were used, consume the one lane manifest and every accepted lane result before final output; do not duplicate the same events into evidence-index and checkpoint logs. If no lanes were delegated, report the delegated-lane field as `none`.\n\nManaged-team fallback is not part of adaptive plan\u002Ftasks dispatch. Do not route blocked adaptive planning or task generation to `sp-teams`, managed-team lifecycle language, or a durable team fallback from this command.\n\n## Codex Subagent Capability Discovery\n\n- Execution model: preserve the workflow's existing `subagent-mandatory`, `subagents-first`, `adaptive`, or `subagent-assisted` policy.\n- Dispatch shape: preserve the workflow's existing dispatch shape; use `subagent-blocked` only after the discovery step below fails or is unsafe.\n- Execution surface: prefer `native-subagents` when the current runtime supports it; use `none` only after recording the unavailable or unsafe surface.\n- Native subagent capability discovery: Before recording `subagent-blocked`, confirm the current runtime exposes `spawn_agent`, `wait_agent`, and `close_agent`; if they are not visible, use the active tool discovery mechanism for multi-agent or subagent tools first.\n- Do not record `subagent-blocked` until this capability discovery step is complete and the exact unavailable or unsafe surface is recorded.\n- Native subagent dispatch: Dispatch bounded subagents through `spawn_agent`.\n- Join behavior: Rejoin with `wait_agent`, integrate, then `close_agent`.\n- Preserve this workflow's existing packet, handoff, artifact, and result schema; this section only governs capability discovery before dispatch or blocked-state recording.\n",{"name":5,"metadata":24,"description":7,"compatibility":27},{"author":25,"source":26},"github-spec-kit","templates\u002Fcommands\u002Fdesign.md","Requires spec-kit project structure with .specify\u002F directory","main","021f5cbe02157229460a577e9a585f2da6d78cb0",".codex\u002Fskills\u002Fsp-design","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck","https:\u002F\u002Fgithub.com\u002Fchenziyang110","2026-08-07 18:10:54",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add chenziyang110\u002Flaunchdeck --skill sp-design",{"tool":40,"command":41},"bunx","bunx skills add chenziyang110\u002Flaunchdeck --skill sp-design",{"tool":43,"command":44},"pnpm","pnpm dlx skills add chenziyang110\u002Flaunchdeck --skill sp-design","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fsp-design\u002FSKILL.md",true,[48,54],{"path":49,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":52,"sourceHtmlUrl":53},"references\u002FINDEX.md","REFERENCE","参考文档",601,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fsp-design\u002Freferences\u002FINDEX.md",{"path":55,"resourceType":50,"resourceTypeDesc":51,"sizeBytes":56,"sourceHtmlUrl":57},"references\u002Fsemantic-work-contract.md",32434,"https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.codex\u002Fskills\u002Fsp-design\u002Freferences\u002Fsemantic-work-contract.md",[59,66,72,78,85,94],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":19},"01M7875F3HQ1GF5F6BR36KY3JE","launchdeck-agent","Codex host adapter contract fixture for Launchdeck.","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002Ftest\u002Ffixtures\u002Fagent-hosts\u002Fcodex\u002Fskill\u002FSKILL.md",[],[],{"skillNo":67,"name":61,"nameZh":6,"description":68,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":69,"categories":70,"keywords":71,"publishedAt":19},"01M7875DV2DQR33K1NFJHKAMZP","Claude host adapter contract fixture for Launchdeck.","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002Ftest\u002Ffixtures\u002Fagent-hosts\u002Fclaude\u002Fskill\u002FSKILL.md",[],[],{"skillNo":73,"name":61,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"01M78759JQ7A6FQ8KDQTNYS3X9","Use this skill aggressively for local project lifecycle operations even when the user does not mention Launchdeck: start this project, run the dev server, dev, build, test, restart service, stop service, show logs, inspect ports, port is occupied, clean cache; and when the user explicitly asks to configure this local project for Launchdeck or create or generate a project-adapted `.launchdeck.yml`, including 为这个项目生成 Launchdeck 配置. Do not use for ordinary code edits, docs-only work, general explanations, API design discussion, or production deployment unless the user also asks to operate or configure a local project or service.","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002Fagent\u002Finstaller-payload\u002Fskill\u002Flaunchdeck-agent\u002FSKILL.md",[],[],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":19},"01M78753ZJQ7G2CZT1W1G8WRJV","zig-testing","Use ONLY when user explicitly requests Zig test code, built-in test runner configuration,\ntest failure diagnosis, or coverage for Zig projects.\n\nTriggers: \"write test zig\", \"zig test\", \"testing.allocator\", \"zig coverage\",\n\"comptime test\", \"zig expectError\", \"zig snapshot test\", \"zig fuzz\".\n\nDo NOT activate for: general Zig coding without test context, build.zig configuration\nfor non-test targets, Zig compiler errors, or Zig build system setup.","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.specify\u002Ftemplates\u002Fpassive-skills\u002Fzig-testing\u002FSKILL.md",[],[],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":89,"licenseFileUrl":90,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":19},"01M78750JXY4Z5D5W1EX3PQ31Z","webapp-testing","Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.specify\u002Ftemplates\u002Fpassive-skills\u002Fwebapp-testing\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.specify\u002Ftemplates\u002Fpassive-skills\u002Fwebapp-testing\u002FSKILL.md",[],[],{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":19},"01M7874X2T83EQQFRCEY5SJJVC","verification-before-completion","Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always","https:\u002F\u002Fgithub.com\u002Fchenziyang110\u002Flaunchdeck\u002Fblob\u002Fmain\u002F.specify\u002Ftemplates\u002Fpassive-skills\u002Fverification-before-completion\u002FSKILL.md",[],[]]