[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CYBV5B9Z5EMBB3Q115SWRV":3,"skill-same:01M6CYBV5B9Z5EMBB3Q115SWRV":119},{"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":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":64,"commitSha":65,"skillDirectory":66,"forksCount":67,"repositoryHtmlUrl":68,"repositoryHomepageUrl":6,"ownerHtmlUrl":69,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":70,"install":71,"resources":84},"01M6CYBV5B9Z5EMBB3Q115SWRV","sdd-workflow",null,"Runs a Kiro-inspired Spec-Driven Development workflow with Requirements-First, Design-First, Quick Plan, and Bugfix modes before implementation. Creates numbered, versioned artifacts under sdd-specs\u002F and executes approved tasks with traceability and verification. Use only when the user explicitly asks for SDD, a Kiro-style spec, spec-driven development, avoiding vibe coding, writing a spec, or planning before implementation. Do not auto-apply to ordinary feature, refactor, or bug requests that do not ask for a spec workflow.","jotafurtado\u002Fdev-skills","jotafurtado","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F748350?v=4","01M6CYB1G1JTWWSNR948H19TG1","Jota Furtado","01M6CYB1N5BPYA6DGRMZM2BR69",1,"MIT","https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsdd-workflow\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"sdd workflow","workflow","sdd","use","requirements","kiro","windsurf","do","only","auto","vibe coding","design","ask","artifacts","planning","code","development","tasks","copilot","writing","2026-11-10 10:12:30",false,"---\nname: sdd-workflow\ndescription: \"Runs a Kiro-inspired Spec-Driven Development workflow with Requirements-First, Design-First, Quick Plan, and Bugfix modes before implementation. Creates numbered, versioned artifacts under sdd-specs\u002F and executes approved tasks with traceability and verification. Use only when the user explicitly asks for SDD, a Kiro-style spec, spec-driven development, avoiding vibe coding, writing a spec, or planning before implementation. Do not auto-apply to ordinary feature, refactor, or bug requests that do not ask for a spec workflow.\"\nlicense: MIT\ncompatibility: \"Designed for Claude Code, Cursor, Windsurf, and Copilot.\"\nmetadata:\n  tags: \"spec-driven-development, sdd, kiro, planning, requirements, design, bugfix, workflow\"\n  author: jotafurtado\n  version: \"2.0.1\"\n  domain: workflow\n  role: specialist\n  scope: planning-and-implementation\n  output-format: markdown+code\n---\n\n# SDD Workflow — Kiro-Inspired Spec-Driven Development\n\n## Purpose and official basis\n\nTurn an explicitly requested spec workflow into durable artifacts, then execute\nonly from the resulting task plan. The semantic model follows the official Kiro\ndocumentation:\n\n- [Specs](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002F)\n- [Feature Specs](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002Ffeature-specs\u002F)\n- [Bugfix Specs](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002Fbugfix-specs\u002F)\n- [Quick Plan](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002Fquick-plan\u002F)\n- [Analyze Requirements](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002Fanalyze-requirements\u002F)\n- [Correctness](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002Fcorrectness\u002F)\n\nThis is a portable Agent Skill, not an implementation of Kiro's UI. Kiro-specific\nfeatures such as `.kiro\u002Fspecs\u002F`, `#spec`, Sync Files, and UI approval state are\nadapted to files under `sdd-specs\u002F`.\n\n## Host precedence and invocation\n\nCurrent user instructions and the host agent's modes, permissions, safety rules,\nand approval requirements always take precedence. This skill does not authorize\nsource edits, commands, commits, pushes, or destructive operations.\n\nApply automatically only when the request explicitly mentions SDD, Kiro specs,\nspec-driven development, avoiding vibe coding, writing a spec, or planning\nbefore implementation. Otherwise, do not impose this workflow on an ordinary\nfeature, refactor, or bug request.\n\nManual invocation with `\u002Fsdd-workflow` is always explicit opt-in.\n\nUse the user's language for artifacts and approval prompts unless the project\ndocuments another language.\n\n## Spec location and mandatory numbering\n\nEvery spec lives in:\n\n```text\nsdd-specs\u002F{sequence}-{slug}\u002F\n```\n\nExample:\n\n```text\nsdd-specs\u002F001-user-authentication\u002F\n├── spec.yaml\n├── requirements.md   # Feature modes and Quick Plan; absent for Bugfix\n├── bugfix.md          # Bugfix only; absent for Feature and Quick Plan\n├── design.md\n└── tasks.md\n```\n\nBefore creating a new spec:\n\n1. Create the `sdd-specs\u002F` root if it does not exist, then inspect only its\n   immediate child directories whose names match\n   `^[0-9]+-`.\n2. Parse each numeric prefix as base 10. The next sequence is the maximum plus\n   one, or `1` if no matching directory exists.\n3. Format with at least three digits: `001` through `999`; `1000` remains\n   `1000`.\n4. Create a kebab-case slug and combine it with the sequence, for example\n   `007-payment-reconciliation`.\n5. Re-scan immediately before creating the directory. If the identifier now\n   exists, calculate again.\n\nNever reuse, rename, or close a numbering gap. Ignore non-matching directories.\nPersist the immutable `sequence`, `slug`, and full `spec_id` in `spec.yaml`.\n\nBefore allocating a new number, check whether the user intends to resume an\nexisting spec. Resume by full `spec_id`; if only a slug is supplied and more\nthan one spec matches, ask which one. If a same-purpose spec exists, ask whether\nto resume it or create a new numbered spec.\n\nImmediately after creating the directory, instantiate `spec.yaml` from\n`references\u002Fspec-state-template.yaml` before writing another artifact. Fill the\nimmutable identifiers, type, mode, ISO 8601 timestamps, initial phase, and this\nmode-specific graph:\n\n- `requirements-first`: requirements → design → tasks; initial phase\n  `requirements`.\n- `design-first-hld` or `design-first-lld`: design → requirements → tasks;\n  initial phase `design`.\n- `quick-plan`: requirements → design → tasks; initial phase `requirements`;\n  requirements\u002Fdesign approval is not required.\n- `bugfix`: bugfix → design → tasks; initial phase `bugfix`; requirements is not\n  applicable.\n\nDo not leave the Requirements-First defaults in place for another mode.\n\n## Select one workflow mode\n\nIf the user has not made the mode clear, ask one focused question. Persist the\nselected mode. If the user later changes it, reconcile artifact dependencies and\napprovals; create a new spec only when the goal itself is a separate body of\nwork.\n\n### Feature — Requirements-First\n\nUse when desired behavior is known but architecture remains open:\n\n1. `requirements.md` — generate, review, and obtain explicit approval.\n2. `design.md` — generate from approved requirements, review, and obtain\n   explicit approval.\n3. `tasks.md` — generate executable tasks and wait for an explicit command to\n   run one task or all required tasks, unless implementation was already\n   authorized in the current request.\n\n### Feature — Design-First\n\nUse when architecture, stack, constraints, or algorithms are the starting point:\n\n1. Ask whether the design level is HLD or LLD.\n2. `design.md` — generate, review, and obtain explicit approval.\n3. `requirements.md` — derive feasible requirements from the approved design,\n   review, and obtain explicit approval.\n4. `tasks.md` — generate executable tasks, then follow the same execution\n   authorization rule as Requirements-First.\n\n### Quick Plan\n\nUse only for well-understood, low-ambiguity work:\n\n1. Ask all blocking clarification questions up front.\n2. Generate `requirements.md`, `design.md`, and `tasks.md` continuously without\n   intermediate approval gates.\n3. Present the complete plan. Do not edit source code unless the current request\n   already authorizes implementation; otherwise wait for a run command.\n\nFor complex, regulated, security-sensitive, or highly ambiguous work, recommend\na gated Feature mode instead. Offer an optional requirements analysis before\ndesign when it can expose ambiguity, conflicts, assumptions, or missing cases.\n\n### Bugfix Spec\n\nUse for a defect requiring structured diagnosis:\n\n1. `bugfix.md` — capture reproduction, current behavior, expected behavior,\n   behavior that must remain unchanged, evidence, and root-cause status; obtain\n   explicit approval.\n2. Before and during `design.md`, inspect the affected code paths and reproduce\n   or trace the defect where possible. Confirm or refine the root cause, then\n   define the smallest safe correction and regression strategy; obtain explicit\n   approval.\n3. `tasks.md` — generate fix and regression tasks, then wait for execution\n   authorization unless it was already granted.\n\nDo not force a bug into the feature `requirements.md` template.\n\n## Persistent state, approval, and resumption\n\nRead `references\u002Fspec-state-template.yaml` before creating or resuming a spec.\n`spec.yaml` is a portable extension of this skill; it stores workflow state that\nKiro normally manages in its product UI.\n\nFor each applicable artifact, persist:\n\n- path, revision, status, and dependencies;\n- whether approval is required;\n- approver and approval timestamp;\n- deterministic whole-file content hash when it becomes approved, generated, or\n  ready for the next phase.\n\nPrefer `git hash-object \u003Cpath>` in a Git repository. Record the hash algorithm.\nIf no deterministic hash tool is available, set the hash to `null` and require\nexplicit reapproval when external edits cannot be ruled out.\n\nIncrement an artifact's revision for every accepted content change. Update its\nhash after each agent-controlled change, including task checkbox\u002Fevidence\nupdates, so later resumption can distinguish known progress from external edits.\n\nUse these transitions consistently:\n\n1. On first creation, set the artifact revision to `1` and status to `draft`.\n   Missing artifacts remain revision `0`.\n2. When a gated artifact is ready for review, set its status and the spec status\n   to `awaiting-approval`.\n3. On explicit approval, set artifact status to `approved`, approval status to\n   `approved`, `approved_by` to `user`, `approved_at` to the current timestamp,\n   and store its hash. Advance `current_phase` to the next artifact and set the\n   spec status to `draft`.\n4. In Quick Plan, store hashes and mark requirements\u002Fdesign as `generated`.\n   After any mode generates tasks, mark tasks `ready`, store its hash, set\n   `current_phase: tasks`, and set spec status to `ready`.\n5. Update `updated_at` on every transition. Set `created_at` only once.\n\nBefore any phase or execution:\n\n1. Read `spec.yaml` and every existing artifact.\n2. Recompute every non-null artifact hash.\n3. If content differs from persisted state, mark it `draft`; clear approval when\n   required and reconcile the change before proceeding.\n4. Apply downstream invalidation rules.\n5. Inspect `tasks.md` and relevant code\u002Ftests. Never mark an existing task\n   complete without concrete evidence.\n6. Resume at the first applicable artifact that is missing, draft, stale, or\n   awaiting approval. If upstream artifacts are `approved` or `generated` and\n   tasks is `ready`, offer execution. If tasks is `in-progress` or the spec is\n   `blocked`, reconcile recorded evidence and resume the eligible task.\n\nArtifact existence is not approval. Never overwrite an approved artifact\nsilently.\n\n## Invalidation and synchronization\n\nUse a living-spec model during active work and follow the selected mode's\ndependency direction:\n\n- Requirements-First and Quick Plan:\n  `requirements.md → design.md → tasks.md`.\n- Design-First: `design.md → requirements.md → tasks.md`. A requirements change\n  invalidates tasks; it invalidates design too only when it contradicts or\n  materially expands the approved design.\n- Bugfix: `bugfix.md → design.md → tasks.md`.\n- Changing any artifact invalidates all of its descendants in that graph.\n- Changing `tasks.md` requires reconciliation with execution progress but does\n  not invalidate upstream artifacts.\n- A material implementation discovery updates the appropriate upstream\n  artifact, clears its approval, invalidates descendants, and stops execution\n  until the required gate is passed again.\n\nPersist invalidation rather than merely reporting it. Mark each descendant\nartifact `stale`, reset any required approval to `pending`, and clear its\napprover\u002Ftimestamp. Preserve its file, revision, and previous hash until\nreconciliation. When reconciled content is accepted, increment its revision,\nstore the new hash, and pass its gate again when required.\n\nMaterial changes include behavior, public contracts, data models, security or\nprivacy assumptions, external dependencies, architecture, or acceptance\ncriteria. Minor in-scope implementation details may proceed when they do not\nchange approved behavior or design; record them as task evidence or a design\nnote.\n\nNever regenerate stale files by erasing human edits. Reconcile deliberately and\nsummarize what changed.\n\n## Task execution\n\nRead `references\u002Ftasks-template.md` before generating or running tasks.\n\nThe user may request one task by ID or all required incomplete tasks. Before\nrunning a task, confirm:\n\n- upstream artifacts are approved or valid for Quick Plan;\n- the task is incomplete and all dependencies are complete;\n- the task is authorized by the current user request;\n- no host safety rule or unrelated work blocks it.\n\nWhen execution is authorized, persist `execution.authorization: granted`,\n`authorized_at`, `current_phase: execution`, tasks status `in-progress`, and\nspec status `in-progress`.\nAuthorization remains subject to the current host and user instructions; set it\nto `revoked` if the user withdraws permission.\n\nFor each task:\n\n1. Add its ID to `execution.active_tasks`.\n2. Implement only its approved scope.\n3. Run the narrowest relevant tests, linters, static analysis, or manual checks\n   that the host and project support.\n4. Compare the result with the task outcome and linked acceptance criteria.\n5. Record concise evidence in `tasks.md`.\n6. Mark `- [x]` only after verification passes, remove it from `active_tasks`,\n   increment the tasks revision, update its hash, and update `updated_at`. On\n   failure, leave it incomplete, record the blocker, increment the tasks\n   revision, clear it from `active_tasks`, update its hash, set spec status to\n   `blocked`, and stop or retry within the authorized scope.\n\nFor “run all”, build dependency waves from required incomplete tasks. Execute\nindependent tasks in parallel only when the host supports it and their files,\nstate, migrations, or external effects cannot conflict. Run waves sequentially.\nOptional tasks are never included unless explicitly requested.\n\nGenerate exactly one required final convergence task, conventionally `T900`,\nwhich depends on all required implementation tasks. It is the sole convergence\nrun and appears as the last dependency wave in “run all”. When it starts, set\n`current_phase: convergence`. That task must:\n\n1. Map every acceptance criterion or bugfix expected\u002Funchanged behavior to\n   implementation and verification evidence.\n2. Run broader relevant checks.\n3. Reconcile code and artifacts without hiding deviations.\n4. On success, mark T900 checked, tasks status `complete`,\n\n[Showing lines 1-300 of 320. Use :301 to continue]","# SDD Workflow — Kiro-Inspired Spec-Driven Development\n\n## Purpose and official basis\n\nTurn an explicitly requested spec workflow into durable artifacts, then execute\nonly from the resulting task plan. The semantic model follows the official Kiro\ndocumentation:\n\n- [Specs](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002F)\n- [Feature Specs](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002Ffeature-specs\u002F)\n- [Bugfix Specs](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002Fbugfix-specs\u002F)\n- [Quick Plan](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002Fquick-plan\u002F)\n- [Analyze Requirements](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002Fanalyze-requirements\u002F)\n- [Correctness](https:\u002F\u002Fkiro.dev\u002Fdocs\u002Fspecs\u002Fcorrectness\u002F)\n\nThis is a portable Agent Skill, not an implementation of Kiro's UI. Kiro-specific\nfeatures such as `.kiro\u002Fspecs\u002F`, `#spec`, Sync Files, and UI approval state are\nadapted to files under `sdd-specs\u002F`.\n\n## Host precedence and invocation\n\nCurrent user instructions and the host agent's modes, permissions, safety rules,\nand approval requirements always take precedence. This skill does not authorize\nsource edits, commands, commits, pushes, or destructive operations.\n\nApply automatically only when the request explicitly mentions SDD, Kiro specs,\nspec-driven development, avoiding vibe coding, writing a spec, or planning\nbefore implementation. Otherwise, do not impose this workflow on an ordinary\nfeature, refactor, or bug request.\n\nManual invocation with `\u002Fsdd-workflow` is always explicit opt-in.\n\nUse the user's language for artifacts and approval prompts unless the project\ndocuments another language.\n\n## Spec location and mandatory numbering\n\nEvery spec lives in:\n\n```text\nsdd-specs\u002F{sequence}-{slug}\u002F\n```\n\nExample:\n\n```text\nsdd-specs\u002F001-user-authentication\u002F\n├── spec.yaml\n├── requirements.md   # Feature modes and Quick Plan; absent for Bugfix\n├── bugfix.md          # Bugfix only; absent for Feature and Quick Plan\n├── design.md\n└── tasks.md\n```\n\nBefore creating a new spec:\n\n1. Create the `sdd-specs\u002F` root if it does not exist, then inspect only its\n   immediate child directories whose names match\n   `^[0-9]+-`.\n2. Parse each numeric prefix as base 10. The next sequence is the maximum plus\n   one, or `1` if no matching directory exists.\n3. Format with at least three digits: `001` through `999`; `1000` remains\n   `1000`.\n4. Create a kebab-case slug and combine it with the sequence, for example\n   `007-payment-reconciliation`.\n5. Re-scan immediately before creating the directory. If the identifier now\n   exists, calculate again.\n\nNever reuse, rename, or close a numbering gap. Ignore non-matching directories.\nPersist the immutable `sequence`, `slug`, and full `spec_id` in `spec.yaml`.\n\nBefore allocating a new number, check whether the user intends to resume an\nexisting spec. Resume by full `spec_id`; if only a slug is supplied and more\nthan one spec matches, ask which one. If a same-purpose spec exists, ask whether\nto resume it or create a new numbered spec.\n\nImmediately after creating the directory, instantiate `spec.yaml` from\n`references\u002Fspec-state-template.yaml` before writing another artifact. Fill the\nimmutable identifiers, type, mode, ISO 8601 timestamps, initial phase, and this\nmode-specific graph:\n\n- `requirements-first`: requirements → design → tasks; initial phase\n  `requirements`.\n- `design-first-hld` or `design-first-lld`: design → requirements → tasks;\n  initial phase `design`.\n- `quick-plan`: requirements → design → tasks; initial phase `requirements`;\n  requirements\u002Fdesign approval is not required.\n- `bugfix`: bugfix → design → tasks; initial phase `bugfix`; requirements is not\n  applicable.\n\nDo not leave the Requirements-First defaults in place for another mode.\n\n## Select one workflow mode\n\nIf the user has not made the mode clear, ask one focused question. Persist the\nselected mode. If the user later changes it, reconcile artifact dependencies and\napprovals; create a new spec only when the goal itself is a separate body of\nwork.\n\n### Feature — Requirements-First\n\nUse when desired behavior is known but architecture remains open:\n\n1. `requirements.md` — generate, review, and obtain explicit approval.\n2. `design.md` — generate from approved requirements, review, and obtain\n   explicit approval.\n3. `tasks.md` — generate executable tasks and wait for an explicit command to\n   run one task or all required tasks, unless implementation was already\n   authorized in the current request.\n\n### Feature — Design-First\n\nUse when architecture, stack, constraints, or algorithms are the starting point:\n\n1. Ask whether the design level is HLD or LLD.\n2. `design.md` — generate, review, and obtain explicit approval.\n3. `requirements.md` — derive feasible requirements from the approved design,\n   review, and obtain explicit approval.\n4. `tasks.md` — generate executable tasks, then follow the same execution\n   authorization rule as Requirements-First.\n\n### Quick Plan\n\nUse only for well-understood, low-ambiguity work:\n\n1. Ask all blocking clarification questions up front.\n2. Generate `requirements.md`, `design.md`, and `tasks.md` continuously without\n   intermediate approval gates.\n3. Present the complete plan. Do not edit source code unless the current request\n   already authorizes implementation; otherwise wait for a run command.\n\nFor complex, regulated, security-sensitive, or highly ambiguous work, recommend\na gated Feature mode instead. Offer an optional requirements analysis before\ndesign when it can expose ambiguity, conflicts, assumptions, or missing cases.\n\n### Bugfix Spec\n\nUse for a defect requiring structured diagnosis:\n\n1. `bugfix.md` — capture reproduction, current behavior, expected behavior,\n   behavior that must remain unchanged, evidence, and root-cause status; obtain\n   explicit approval.\n2. Before and during `design.md`, inspect the affected code paths and reproduce\n   or trace the defect where possible. Confirm or refine the root cause, then\n   define the smallest safe correction and regression strategy; obtain explicit\n   approval.\n3. `tasks.md` — generate fix and regression tasks, then wait for execution\n   authorization unless it was already granted.\n\nDo not force a bug into the feature `requirements.md` template.\n\n## Persistent state, approval, and resumption\n\nRead `references\u002Fspec-state-template.yaml` before creating or resuming a spec.\n`spec.yaml` is a portable extension of this skill; it stores workflow state that\nKiro normally manages in its product UI.\n\nFor each applicable artifact, persist:\n\n- path, revision, status, and dependencies;\n- whether approval is required;\n- approver and approval timestamp;\n- deterministic whole-file content hash when it becomes approved, generated, or\n  ready for the next phase.\n\nPrefer `git hash-object \u003Cpath>` in a Git repository. Record the hash algorithm.\nIf no deterministic hash tool is available, set the hash to `null` and require\nexplicit reapproval when external edits cannot be ruled out.\n\nIncrement an artifact's revision for every accepted content change. Update its\nhash after each agent-controlled change, including task checkbox\u002Fevidence\nupdates, so later resumption can distinguish known progress from external edits.\n\nUse these transitions consistently:\n\n1. On first creation, set the artifact revision to `1` and status to `draft`.\n   Missing artifacts remain revision `0`.\n2. When a gated artifact is ready for review, set its status and the spec status\n   to `awaiting-approval`.\n3. On explicit approval, set artifact status to `approved`, approval status to\n   `approved`, `approved_by` to `user`, `approved_at` to the current timestamp,\n   and store its hash. Advance `current_phase` to the next artifact and set the\n   spec status to `draft`.\n4. In Quick Plan, store hashes and mark requirements\u002Fdesign as `generated`.\n   After any mode generates tasks, mark tasks `ready`, store its hash, set\n   `current_phase: tasks`, and set spec status to `ready`.\n5. Update `updated_at` on every transition. Set `created_at` only once.\n\nBefore any phase or execution:\n\n1. Read `spec.yaml` and every existing artifact.\n2. Recompute every non-null artifact hash.\n3. If content differs from persisted state, mark it `draft`; clear approval when\n   required and reconcile the change before proceeding.\n4. Apply downstream invalidation rules.\n5. Inspect `tasks.md` and relevant code\u002Ftests. Never mark an existing task\n   complete without concrete evidence.\n6. Resume at the first applicable artifact that is missing, draft, stale, or\n   awaiting approval. If upstream artifacts are `approved` or `generated` and\n   tasks is `ready`, offer execution. If tasks is `in-progress` or the spec is\n   `blocked`, reconcile recorded evidence and resume the eligible task.\n\nArtifact existence is not approval. Never overwrite an approved artifact\nsilently.\n\n## Invalidation and synchronization\n\nUse a living-spec model during active work and follow the selected mode's\ndependency direction:\n\n- Requirements-First and Quick Plan:\n  `requirements.md → design.md → tasks.md`.\n- Design-First: `design.md → requirements.md → tasks.md`. A requirements change\n  invalidates tasks; it invalidates design too only when it contradicts or\n  materially expands the approved design.\n- Bugfix: `bugfix.md → design.md → tasks.md`.\n- Changing any artifact invalidates all of its descendants in that graph.\n- Changing `tasks.md` requires reconciliation with execution progress but does\n  not invalidate upstream artifacts.\n- A material implementation discovery updates the appropriate upstream\n  artifact, clears its approval, invalidates descendants, and stops execution\n  until the required gate is passed again.\n\nPersist invalidation rather than merely reporting it. Mark each descendant\nartifact `stale`, reset any required approval to `pending`, and clear its\napprover\u002Ftimestamp. Preserve its file, revision, and previous hash until\nreconciliation. When reconciled content is accepted, increment its revision,\nstore the new hash, and pass its gate again when required.\n\nMaterial changes include behavior, public contracts, data models, security or\nprivacy assumptions, external dependencies, architecture, or acceptance\ncriteria. Minor in-scope implementation details may proceed when they do not\nchange approved behavior or design; record them as task evidence or a design\nnote.\n\nNever regenerate stale files by erasing human edits. Reconcile deliberately and\nsummarize what changed.\n\n## Task execution\n\nRead `references\u002Ftasks-template.md` before generating or running tasks.\n\nThe user may request one task by ID or all required incomplete tasks. Before\nrunning a task, confirm:\n\n- upstream artifacts are approved or valid for Quick Plan;\n- the task is incomplete and all dependencies are complete;\n- the task is authorized by the current user request;\n- no host safety rule or unrelated work blocks it.\n\nWhen execution is authorized, persist `execution.authorization: granted`,\n`authorized_at`, `current_phase: execution`, tasks status `in-progress`, and\nspec status `in-progress`.\nAuthorization remains subject to the current host and user instructions; set it\nto `revoked` if the user withdraws permission.\n\nFor each task:\n\n1. Add its ID to `execution.active_tasks`.\n2. Implement only its approved scope.\n3. Run the narrowest relevant tests, linters, static analysis, or manual checks\n   that the host and project support.\n4. Compare the result with the task outcome and linked acceptance criteria.\n5. Record concise evidence in `tasks.md`.\n6. Mark `- [x]` only after verification passes, remove it from `active_tasks`,\n   increment the tasks revision, update its hash, and update `updated_at`. On\n   failure, leave it incomplete, record the blocker, increment the tasks\n   revision, clear it from `active_tasks`, update its hash, set spec status to\n   `blocked`, and stop or retry within the authorized scope.\n\nFor “run all”, build dependency waves from required incomplete tasks. Execute\nindependent tasks in parallel only when the host supports it and their files,\nstate, migrations, or external effects cannot conflict. Run waves sequentially.\nOptional tasks are never included unless explicitly requested.\n\nGenerate exactly one required final convergence task, conventionally `T900`,\nwhich depends on all required implementation tasks. It is the sole convergence\nrun and appears as the last dependency wave in “run all”. When it starts, set\n`current_phase: convergence`. That task must:\n\n1. Map every acceptance criterion or bugfix expected\u002Funchanged behavior to\n   implementation and verification evidence.\n2. Run broader relevant checks.\n3. Reconcile code and artifacts without hiding deviations.\n4. On success, mark T900 checked, tasks status `complete`,\n\n[Showing lines 1-300 of 320. Use :301 to continue]",{"name":5,"license":15,"metadata":57,"description":7,"compatibility":63},{"role":58,"tags":59,"scope":60,"author":9,"domain":33,"version":61,"output-format":62},"specialist","spec-driven-development, sdd, kiro, planning, requirements, design, bugfix, workflow","planning-and-implementation","2.0.1","markdown+code","Designed for Claude Code, Cursor, Windsurf, and Copilot.","main","8d0e3c567f2dff8ffe3abdf5386d7f6e9ba82893","skills\u002Fsdd-workflow",0,"https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills","https:\u002F\u002Fgithub.com\u002Fjotafurtado","2026-10-20 12:26:03",{"source":8,"skillName":5,"commands":72,"prompt":82,"zipAvailable":83},[73,76,79],{"tool":74,"command":75},"npx","npx skills add jotafurtado\u002Fdev-skills --skill sdd-workflow",{"tool":77,"command":78},"bunx","bunx skills add jotafurtado\u002Fdev-skills --skill sdd-workflow",{"tool":80,"command":81},"pnpm","pnpm dlx skills add jotafurtado\u002Fdev-skills --skill sdd-workflow","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsdd-workflow\u002FSKILL.md",true,[85,91,95,99,103,107,111,115],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"evals\u002Feval_queries.json","REFERENCE","参考文档",2685,"https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsdd-workflow\u002Fevals\u002Feval_queries.json",{"path":92,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":93,"sourceHtmlUrl":94},"evals\u002Fevals.json",2275,"https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsdd-workflow\u002Fevals\u002Fevals.json",{"path":96,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":97,"sourceHtmlUrl":98},"README.md",4541,"https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsdd-workflow\u002FREADME.md",{"path":100,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fbugfix-template.md",2321,"https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsdd-workflow\u002Freferences\u002Fbugfix-template.md",{"path":104,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fdesign-template.md",4048,"https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsdd-workflow\u002Freferences\u002Fdesign-template.md",{"path":108,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Frequirements-template.md",3296,"https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsdd-workflow\u002Freferences\u002Frequirements-template.md",{"path":112,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":113,"sourceHtmlUrl":114},"references\u002Fspec-state-template.yaml",3816,"https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsdd-workflow\u002Freferences\u002Fspec-state-template.yaml",{"path":116,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":117,"sourceHtmlUrl":118},"references\u002Ftasks-template.md",4383,"https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Fskills\u002Fsdd-workflow\u002Freferences\u002Ftasks-template.md",[120,135,147,156,164,173],{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":129,"publishedAt":52},"01M6CYCCP610F3QV9XF1N2SJWG","valid-minimal","Use when testing a valid minimal skill.","https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fvalid-minimal\u002FSKILL.md",[126],{"categoryNo":127,"categoryName":128,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[130,131,132,35,133,134],"minimal","valid minimal","valid","minimal skill","testing",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":142,"publishedAt":52},"01M6CYCAAJ9KADYZCRW24PJR8C","valid-compatibility","Use when testing compatibility metadata.","https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fvalid-compatibility\u002FSKILL.md",[141],{"categoryNo":127,"categoryName":128,"taxonomyType":21,"taxonomyTypeDesc":22},[132,143,144,35,145,146,134],"valid compatibility","compatibility","metadata","git",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":154,"publishedAt":52},"01M6CYC8JV2MBHEDNZYM8YF0RY","unknown-key","Use when testing unknown keys.","https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Funknown-key\u002FSKILL.md",[153],{"categoryNo":127,"categoryName":128,"taxonomyType":21,"taxonomyTypeDesc":22},[155,35,134],"Unknown key",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":52},"01M6CYC5EFX2WMVMSF6AWASWVF","overlimit-description","xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Foverlimit-description\u002FSKILL.md",[],[163],"overlimit description",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":171,"publishedAt":52},"01M6CYC2RVDX296BMTG856JM6Q","overlimit-compatibility","Use when testing compatibility length.","https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Foverlimit-compatibility\u002FSKILL.md",[170],{"categoryNo":127,"categoryName":128,"taxonomyType":21,"taxonomyTypeDesc":22},[172,144,134,35],"overlimit compatibility",{"skillNo":174,"name":175,"nameZh":6,"description":176,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":177,"categories":178,"keywords":180,"publishedAt":52},"01M6CYC0WMJFA34FT7NNTKD3J5","different-name","Use when testing mismatch handling.","https:\u002F\u002Fgithub.com\u002Fjotafurtado\u002Fdev-skills\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fmismatched-directory\u002FSKILL.md",[179],{"categoryNo":127,"categoryName":128,"taxonomyType":21,"taxonomyTypeDesc":22},[181,35,134],"different name"]