[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KWDVXNF6T2JTMV23RJGAF6":3,"skill-same:01M6KWDVXNF6T2JTMV23RJGAF6":68},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":14,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":52,"updatedAt":53,"install":54,"resources":67},"01M6KWDVXNF6T2JTMV23RJGAF6","spec-driven-development",null,"Manages the full lifecycle of a feature specification — from collaborative drafting to enforcement during implementation and testing.","rafsanulhasan\u002FHypermediaEngine","rafsanulhasan","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2341142?v=4","01M6KW2HWPTZWK051N7B0HTBVG","Rafsanul Hasan","01M6KW2J0N3613382MF5DRN79H",0,"GPL-3.0","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspec-driven-development\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"spec","spec driven development","development","spec driven","driven","feature specification","testing","sonnet","feature","full","analyst","specification","implementation","enforcement","edit","write","read","grep","Bash","lifecycle","2026-11-10 10:12:30",false,"---\nname: spec-driven-development\ndescription: Manages the full lifecycle of a feature specification — from collaborative drafting to enforcement during implementation and testing.\ninvoker: requirement-analyst\nmodel: claude-sonnet-4-6\ntools: Read, Write, Edit, Glob, Grep, Bash, TodoWrite\n---\n\nManages the full lifecycle of a feature specification: collaborative drafting with architect and engineer review, finalization to a persistent spec file, and enforcement handoff to software-engineer and sqa-engineer. Only the `requirement-analyst` agent may invoke this skill.\n\n---\n\n## Phase 0 — Guard\n\n1. Verify the caller is `requirement-analyst`. If not, halt immediately and output:\n   > \"This skill may only be invoked by the requirement-analyst agent.\"\n2. Read `.claude\\CLAUDE.md`\n3. Invoke `Skill(\"manage-memory\", args: \"requirement-analyst\")` to load persistent memory\n4. Read relevant source files and any existing specs under `docs\u002Fspecs\u002F` identified from memory or task input\n\n---\n\n## Phase 1 — Spec Drafting (Collaborative)\n\n1. `requirement-analyst` drafts the initial specification from previously elicited requirements.\n2. Consult `software-architect` to review the draft spec for:\n   - Architectural alignment with the existing system\n   - Technical feasibility\n   - Clear and correct component boundary assignments\n3. Consult `system-engineer` to review the draft spec for:\n   - Low-level design concerns\n   - SOLID, DRY, and YAGNI compliance\n   - Data shape conformance — all request\u002Fresponse shapes must use `{ data, error }`\n4. Collect all feedback from both reviewers and revise the spec.\n5. Repeat consultation rounds until both `software-architect` and `system-engineer` explicitly sign off.\n\n---\n\n## Phase 2 — Spec Finalization\n\n1. Derive the `\u003Cfeature-slug>` from the feature name in kebab-case (e.g., `user-registration`).\n2. Write the finalized spec to `docs\u002Fspecs\u002F\u003Cfeature-slug>.spec.md`.\n3. The spec file MUST include all of the following sections:\n\n   ### Overview\n   What the feature does and why it is being built.\n\n   ### Acceptance Criteria\n   Numbered, testable criteria. Each AC must be independently verifiable.\n   Example format:\n   ```\n   AC-1: Given X, when Y, then Z.\n   AC-2: ...\n   ```\n\n   ### Component Boundaries\n   Which component, service, or module owns each part of the feature. Describe ownership explicitly — do not leave ambiguity.\n\n   ### Data Shapes\n   All request and response data shapes. Every shape must use the `{ data, error }` envelope:\n   ```json\n   {\n     \"data\": { ... },\n     \"error\": null\n   }\n   ```\n\n   ### Out of Scope\n   Explicit list of things that will NOT be addressed by this feature. Required — cannot be omitted.\n\n   ### Open Questions\n   Any unresolved questions that remain after the review cycle. May be empty if none remain, but the section must be present.\n\n4. Validate the written file is readable and well-formed before proceeding.\n\n---\n\n## Phase 3 — Enforcement Handoff\n\nOutput the following summary block. `software-engineer` and `sqa-engineer` MUST reference this before beginning any work:\n\n```\n--- SPEC ENFORCEMENT HANDOFF ---\n\nSpec file: docs\u002Fspecs\u002F\u003Cfeature-slug>.spec.md\n\nAcceptance Criteria IDs:\n  AC-1, AC-2, ... (list all IDs from the finalized spec)\n\nIMPORTANT: All implementation and tests must trace to an AC in this spec.\nDo not implement anything not covered by the spec.\nAny deviation from the spec requires re-invoking `spec-driven-development`\nto update the spec first — do not diverge silently.\n\n--- END HANDOFF ---\n```\n\n---\n\n## Adherence Rules (for software-engineer and sqa-engineer)\n\nThese rules are enforced by the handoff block and must be followed by downstream agents:\n\n- **Before writing any code**, `software-engineer` must read the spec at `docs\u002Fspecs\u002F\u003Cfeature-slug>.spec.md`.\n- Every implemented behavior must map to a numbered AC. If an AC has no corresponding implementation, flag it explicitly.\n- **Before writing any test**, `sqa-engineer` must read the spec and trace each test case to an AC ID in the test's comments or description.\n- Any deviation from the spec — whether discovered during implementation or testing — requires re-invoking `spec-driven-development` to update the spec first. Silent divergence is not permitted.\n","Manages the full lifecycle of a feature specification: collaborative drafting with architect and engineer review, finalization to a persistent spec file, and enforcement handoff to software-engineer and sqa-engineer. Only the `requirement-analyst` agent may invoke this skill.\n\n---\n\n## Phase 0 — Guard\n\n1. Verify the caller is `requirement-analyst`. If not, halt immediately and output:\n   > \"This skill may only be invoked by the requirement-analyst agent.\"\n2. Read `.claude\\CLAUDE.md`\n3. Invoke `Skill(\"manage-memory\", args: \"requirement-analyst\")` to load persistent memory\n4. Read relevant source files and any existing specs under `docs\u002Fspecs\u002F` identified from memory or task input\n\n---\n\n## Phase 1 — Spec Drafting (Collaborative)\n\n1. `requirement-analyst` drafts the initial specification from previously elicited requirements.\n2. Consult `software-architect` to review the draft spec for:\n   - Architectural alignment with the existing system\n   - Technical feasibility\n   - Clear and correct component boundary assignments\n3. Consult `system-engineer` to review the draft spec for:\n   - Low-level design concerns\n   - SOLID, DRY, and YAGNI compliance\n   - Data shape conformance — all request\u002Fresponse shapes must use `{ data, error }`\n4. Collect all feedback from both reviewers and revise the spec.\n5. Repeat consultation rounds until both `software-architect` and `system-engineer` explicitly sign off.\n\n---\n\n## Phase 2 — Spec Finalization\n\n1. Derive the `\u003Cfeature-slug>` from the feature name in kebab-case (e.g., `user-registration`).\n2. Write the finalized spec to `docs\u002Fspecs\u002F\u003Cfeature-slug>.spec.md`.\n3. The spec file MUST include all of the following sections:\n\n   ### Overview\n   What the feature does and why it is being built.\n\n   ### Acceptance Criteria\n   Numbered, testable criteria. Each AC must be independently verifiable.\n   Example format:\n   ```\n   AC-1: Given X, when Y, then Z.\n   AC-2: ...\n   ```\n\n   ### Component Boundaries\n   Which component, service, or module owns each part of the feature. Describe ownership explicitly — do not leave ambiguity.\n\n   ### Data Shapes\n   All request and response data shapes. Every shape must use the `{ data, error }` envelope:\n   ```json\n   {\n     \"data\": { ... },\n     \"error\": null\n   }\n   ```\n\n   ### Out of Scope\n   Explicit list of things that will NOT be addressed by this feature. Required — cannot be omitted.\n\n   ### Open Questions\n   Any unresolved questions that remain after the review cycle. May be empty if none remain, but the section must be present.\n\n4. Validate the written file is readable and well-formed before proceeding.\n\n---\n\n## Phase 3 — Enforcement Handoff\n\nOutput the following summary block. `software-engineer` and `sqa-engineer` MUST reference this before beginning any work:\n\n```\n--- SPEC ENFORCEMENT HANDOFF ---\n\nSpec file: docs\u002Fspecs\u002F\u003Cfeature-slug>.spec.md\n\nAcceptance Criteria IDs:\n  AC-1, AC-2, ... (list all IDs from the finalized spec)\n\nIMPORTANT: All implementation and tests must trace to an AC in this spec.\nDo not implement anything not covered by the spec.\nAny deviation from the spec requires re-invoking `spec-driven-development`\nto update the spec first — do not diverge silently.\n\n--- END HANDOFF ---\n```\n\n---\n\n## Adherence Rules (for software-engineer and sqa-engineer)\n\nThese rules are enforced by the handoff block and must be followed by downstream agents:\n\n- **Before writing any code**, `software-engineer` must read the spec at `docs\u002Fspecs\u002F\u003Cfeature-slug>.spec.md`.\n- Every implemented behavior must map to a numbered AC. If an AC has no corresponding implementation, flag it explicitly.\n- **Before writing any test**, `sqa-engineer` must read the spec and trace each test case to an AC ID in the test's comments or description.\n- Any deviation from the spec — whether discovered during implementation or testing — requires re-invoking `spec-driven-development` to update the spec first. Silent divergence is not permitted.\n",{"name":5,"model":44,"tools":45,"invoker":46,"description":7},"claude-sonnet-4-6","Read, Write, Edit, Glob, Grep, Bash, TodoWrite","requirement-analyst","main","00b2c68281930728ee390bb16cec32b88d2caac7",".github\u002Fskills\u002Fspec-driven-development","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine","https:\u002F\u002Fgithub.com\u002Frafsanulhasan","\r\n    MCSD || A-CSD || Software Architect\r\n\r\n","2026-06-06 07:47:06",{"source":8,"skillName":5,"commands":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add rafsanulhasan\u002FHypermediaEngine --skill spec-driven-development",{"tool":60,"command":61},"bunx","bunx skills add rafsanulhasan\u002FHypermediaEngine --skill spec-driven-development",{"tool":63,"command":64},"pnpm","pnpm dlx skills add rafsanulhasan\u002FHypermediaEngine --skill spec-driven-development","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspec-driven-development\u002FSKILL.md",true,[],[69,96,116,134,162,185],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":80,"publishedAt":39},"01M6KWEJD606FG3DBBRM0W4DKW","write-tests","Test implementation skill for HypermediaEngine. Takes a confirmed test plan from design-test-cases and produces compilable, runnable xUnit tests following project conventions. Validates coverage quality through mutation testing. Invoked by the sqa-engineer agent after the test plan is approved.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-tests\u002FSKILL.md",[75],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[81,34,82,25,83,84,85,86,37,87,88,89,35,33,90,91,92,93,94,95],"write tests","tests","design","test","project conventions","test plan","plan","quality","xunit","coverage","engineer","mutation testing","project","mutation","for",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":39},"01M6KWEF2XQ00C1Y6QCK7YHZ1H","write-documentation","Structured documentation writing workflow for HypermediaEngine. Writes or updates README.md files at the repo root and in each project directory (src\u002F, tests\u002F, samples\u002F, etc.) based on current implementation, ADRs, and architecture decisions.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-documentation\u002FSKILL.md",[],[103,34,104,105,106,107,108,37,109,110,111,112,35,33,113,93,82,114,115,95],"documentation","write documentation","writing","directory","workflow","architecture","src","repo","decisions","README","files","updates","at",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":39},"01M6KWEBDXTXAVPQ3BHS3YYYNT","write-adr","Writes a numbered Architecture Decision Record (ADR) for a significant architectural choice in the HypermediaEngine project. Invoked by the software-architect agent whenever a consequential design decision is made or ratified. Saves the ADR to docs\u002Farchitecture\u002Fdecisions\u002F.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-adr\u002FSKILL.md",[],[123,34,124,83,125,108,126,127,128,36,111,35,129,130,93,131,132,95,133],"adr","write adr","docs","architect","decision","choice","architecture decision record","record","software","opus","architecture decision",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":146,"publishedAt":39},"01M6KWE76TM3QHGQ08PEB3KY6D","tunit-playwright-ui-testing","Comprehensive guidance for writing coded end-to-end UI tests in C# using TUnit.Playwright. Tests inherit from PageTest — the base class manages all browser lifecycle. Covers NuGet setup, PageTest inheritance, Page Object Model, browser configuration, parallelism limiting, and CI integration. Based on the official TUnit docs at https:\u002F\u002Ftunit.dev\u002Fdocs\u002Fexamples\u002Fplaywright.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftunit-playwright-ui-testing\u002FSKILL.md",[140,141],{"categoryNo":76,"categoryName":77,"taxonomyType":78,"taxonomyTypeDesc":79},{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[25,147,148,149,150,151,152,105,153,154,155,156,38,157,158,159,82,160,161,95],"playwright","ui","playwright ui testing","ui testing","tunit","tunit playwright ui testing","official","dev","examples","ci","model","page","inheritance","end","object",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":171,"publishedAt":39},"01M6KWE44A738GDK65QS02XJBG","triage","Task classification, decomposition, dependency mapping, and routing skill. Invoked by the triage-agent to break any user request into discrete, independently-routable work items with assigned priorities and agent chains.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Ftriage\u002FSKILL.md",[168],{"categoryNo":169,"categoryName":170,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000023","Skill与智能体开发",[164,172,173,174,175,176,177,178,179,180,181,182,183,184],"routing","classification","work","user","dependency","task","priorities","decomposition","user request","mapping","with","break","request",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":195,"publishedAt":39},"01M6KWDZ3W9ZKPR7FTTTSX8H2K","system-design","Expert system design skill. Use PROACTIVELY to design systems, review architectures, and assist software engineers in learning design principles and implementing them in the code with design patterns.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fsystem-design\u002FSKILL.md",[191,194],{"categoryNo":192,"categoryName":193,"taxonomyType":78,"taxonomyTypeDesc":79},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},[83,196,197,198,199,200,201,36,35,202,203,204,205,206,207,131,208,209,182,210],"system","system design","web","design systems","learning","haiku","use","design patterns","design principles","expert","patterns","systems","architectures","principles","implementing"]