[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KWEBDXTXAVPQ3BHS3YYYNT":3,"skill-same:01M6KWEBDXTXAVPQ3BHS3YYYNT":66},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":14,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6KWEBDXTXAVPQ3BHS3YYYNT","write-adr",null,"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.","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\u002Fwrite-adr\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"adr","write adr","write","read","architecture decision","for","opus","software","project","record","architecture decision record","design","decisions","grep","choice","decision","architect","architecture","docs","2026-11-10 10:12:30",false,"---\nname: write-adr\ndescription: 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.\nmodel: claude-opus-4-7\ntools: Read, Grep, Glob, Write\n---\n\nYou are executing the `write-adr` skill on behalf of the software-architect agent. Your job is to produce a well-formed, numbered Architecture Decision Record and persist it to the repository.\n\n## Input\n\nThe calling agent will pass:\n- **Decision title** — a short phrase naming the decision (e.g. \"Use Result\u003CT> for all service return types\")\n- **Context and decision** — a summary of what was decided and why (may come from an `architecture-design` output or a post-implementation `architecture-review`)\n- Optionally: specific files, components, or requirements that motivated the decision\n\n## Process\n\n### Step 1 — Discover Existing ADRs\n\n1. Use **Glob** to list all files matching `docs\u002Farchitecture\u002Fdecisions\u002FADR-*.md`\n2. Find the highest existing ADR number; the new ADR number = highest + 1 (start at `ADR-0001` if none exist)\n3. Use **Read** on the two most recent ADRs (if any) to absorb the established tone and any cross-references\n\n### Step 2 — Ground the Decision in the Codebase\n\nUse **Grep** and **Read** to locate the concrete artifacts this decision affects:\n- Files, classes, or interfaces that implement or will implement the decision\n- Existing usages of the pattern being decided on (or the pattern being superseded)\n- Any related ADRs that this decision builds on or contradicts (mark those as Superseded in Step 4 if needed)\n\n### Step 3 — Draft the ADR\n\nProduce the record using this structure:\n\n---\n\n# ADR-{NNNN}: {Title}\n\n**Date**: {YYYY-MM-DD}\n**Status**: Accepted\n**Deciders**: software-architect\n\n## Context\n\nWhat situation, requirement, or constraint forced this decision? Describe the problem space in 3–6 sentences. Reference specific project constraints where relevant (e.g. middleware pipeline, `{ data, error }` return shape, DI-only instantiation, async disposal).\n\n## Decision\n\nState the decision in one clear sentence beginning with \"We will…\".\n\nThen explain the chosen approach with enough detail that a new engineer understands what to do and why. Include:\n- The specific pattern, component structure, or constraint being adopted\n- How it integrates with the existing middleware \u002F DI \u002F filter architecture\n- Any naming conventions or file placement rules it implies\n\n## Alternatives Considered\n\nFor each rejected option:\n- **Option**: Name of the alternative\n- **Why rejected**: One or two sentences — be specific, not vague\n\n## Consequences\n\n### Positive\n- Bullet list of concrete benefits\n\n### Negative \u002F Trade-offs\n- Bullet list of known costs or constraints introduced\n\n### Neutral\n- Bullet list of things that change but are neither good nor bad (migration steps, tooling changes, etc.)\n\n## Compliance Checklist\n\n- [ ] All affected components identified and listed above\n- [ ] Related ADRs cross-referenced (or \"None\" if first)\n- [ ] Return shape `{ data, error }` preserved where applicable\n- [ ] No stack traces exposed\n- [ ] DI registration approach specified (if new components introduced)\n- [ ] Superseded ADRs updated with `**Status**: Superseded by ADR-{NNNN}`\n\n---\n\n### Step 4 — Update Superseded ADRs\n\nIf this decision supersedes an existing one:\n1. **Read** the superseded ADR file\n2. Change its `**Status**` line to `**Status**: Superseded by ADR-{NNNN}`\n3. **Write** the updated file back\n\n### Step 5 — Save the ADR\n\n1. Ensure the directory `docs\u002Farchitecture\u002Fdecisions\u002F` exists (create it via Write if absent)\n2. Write the file as `docs\u002Farchitecture\u002Fdecisions\u002FADR-{NNNN}-{kebab-case-title}.md`\n3. Report the saved path and ADR number to the calling agent\n\n## Output\n\nReturn:\n- The full ADR text\n- The saved file path (e.g. `docs\u002Farchitecture\u002Fdecisions\u002FADR-0003-use-result-t-for-service-returns.md`)\n- A one-line summary: **ADR-{NNNN}** recorded: {title}\n","You are executing the `write-adr` skill on behalf of the software-architect agent. Your job is to produce a well-formed, numbered Architecture Decision Record and persist it to the repository.\n\n## Input\n\nThe calling agent will pass:\n- **Decision title** — a short phrase naming the decision (e.g. \"Use Result\u003CT> for all service return types\")\n- **Context and decision** — a summary of what was decided and why (may come from an `architecture-design` output or a post-implementation `architecture-review`)\n- Optionally: specific files, components, or requirements that motivated the decision\n\n## Process\n\n### Step 1 — Discover Existing ADRs\n\n1. Use **Glob** to list all files matching `docs\u002Farchitecture\u002Fdecisions\u002FADR-*.md`\n2. Find the highest existing ADR number; the new ADR number = highest + 1 (start at `ADR-0001` if none exist)\n3. Use **Read** on the two most recent ADRs (if any) to absorb the established tone and any cross-references\n\n### Step 2 — Ground the Decision in the Codebase\n\nUse **Grep** and **Read** to locate the concrete artifacts this decision affects:\n- Files, classes, or interfaces that implement or will implement the decision\n- Existing usages of the pattern being decided on (or the pattern being superseded)\n- Any related ADRs that this decision builds on or contradicts (mark those as Superseded in Step 4 if needed)\n\n### Step 3 — Draft the ADR\n\nProduce the record using this structure:\n\n---\n\n# ADR-{NNNN}: {Title}\n\n**Date**: {YYYY-MM-DD}\n**Status**: Accepted\n**Deciders**: software-architect\n\n## Context\n\nWhat situation, requirement, or constraint forced this decision? Describe the problem space in 3–6 sentences. Reference specific project constraints where relevant (e.g. middleware pipeline, `{ data, error }` return shape, DI-only instantiation, async disposal).\n\n## Decision\n\nState the decision in one clear sentence beginning with \"We will…\".\n\nThen explain the chosen approach with enough detail that a new engineer understands what to do and why. Include:\n- The specific pattern, component structure, or constraint being adopted\n- How it integrates with the existing middleware \u002F DI \u002F filter architecture\n- Any naming conventions or file placement rules it implies\n\n## Alternatives Considered\n\nFor each rejected option:\n- **Option**: Name of the alternative\n- **Why rejected**: One or two sentences — be specific, not vague\n\n## Consequences\n\n### Positive\n- Bullet list of concrete benefits\n\n### Negative \u002F Trade-offs\n- Bullet list of known costs or constraints introduced\n\n### Neutral\n- Bullet list of things that change but are neither good nor bad (migration steps, tooling changes, etc.)\n\n## Compliance Checklist\n\n- [ ] All affected components identified and listed above\n- [ ] Related ADRs cross-referenced (or \"None\" if first)\n- [ ] Return shape `{ data, error }` preserved where applicable\n- [ ] No stack traces exposed\n- [ ] DI registration approach specified (if new components introduced)\n- [ ] Superseded ADRs updated with `**Status**: Superseded by ADR-{NNNN}`\n\n---\n\n### Step 4 — Update Superseded ADRs\n\nIf this decision supersedes an existing one:\n1. **Read** the superseded ADR file\n2. Change its `**Status**` line to `**Status**: Superseded by ADR-{NNNN}`\n3. **Write** the updated file back\n\n### Step 5 — Save the ADR\n\n1. Ensure the directory `docs\u002Farchitecture\u002Fdecisions\u002F` exists (create it via Write if absent)\n2. Write the file as `docs\u002Farchitecture\u002Fdecisions\u002FADR-{NNNN}-{kebab-case-title}.md`\n3. Report the saved path and ADR number to the calling agent\n\n## Output\n\nReturn:\n- The full ADR text\n- The saved file path (e.g. `docs\u002Farchitecture\u002Fdecisions\u002FADR-0003-use-result-t-for-service-returns.md`)\n- A one-line summary: **ADR-{NNNN}** recorded: {title}\n",{"name":5,"model":43,"tools":44,"description":7},"claude-opus-4-7","Read, Grep, Glob, Write","main","00b2c68281930728ee390bb16cec32b88d2caac7",".github\u002Fskills\u002Fwrite-adr","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":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add rafsanulhasan\u002FHypermediaEngine --skill write-adr",{"tool":58,"command":59},"bunx","bunx skills add rafsanulhasan\u002FHypermediaEngine --skill write-adr",{"tool":61,"command":62},"pnpm","pnpm dlx skills add rafsanulhasan\u002FHypermediaEngine --skill write-adr","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fwrite-adr\u002FSKILL.md",true,[],[67,94,112,141,164,190],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":78,"publishedAt":38},"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",[73],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[79,21,80,81,30,82,83,84,85,86,87,88,22,89,90,91,92,27,93,24],"write tests","tests","testing","test","project conventions","test plan","Bash","plan","quality","xunit","edit","coverage","engineer","mutation testing","mutation",{"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":38},"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",[],[101,21,102,103,104,105,36,85,106,107,31,108,22,89,109,27,80,110,111,24],"documentation","write documentation","writing","directory","workflow","src","repo","README","files","updates","at",{"skillNo":113,"name":114,"nameZh":6,"description":115,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":116,"categories":117,"keywords":124,"publishedAt":38},"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",[118,119],{"categoryNo":74,"categoryName":75,"taxonomyType":76,"taxonomyTypeDesc":77},{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[81,125,126,127,128,129,130,103,131,132,133,134,135,136,137,138,80,139,140,24],"playwright","ui","playwright ui testing","ui testing","tunit","tunit playwright ui testing","official","dev","examples","ci","lifecycle","model","page","inheritance","end","object",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":150,"publishedAt":38},"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",[147],{"categoryNo":148,"categoryName":149,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000023","Skill与智能体开发",[143,151,152,153,154,155,156,157,158,159,160,161,162,163],"routing","classification","work","user","dependency","task","priorities","decomposition","user request","mapping","with","break","request",{"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":174,"publishedAt":38},"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",[170,173],{"categoryNo":171,"categoryName":172,"taxonomyType":76,"taxonomyTypeDesc":77},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},[30,175,176,177,178,179,180,32,22,181,182,183,184,185,186,26,187,188,161,189],"system","system design","web","design systems","learning","haiku","use","design patterns","design principles","expert","patterns","systems","architectures","principles","implementing",{"skillNo":191,"name":192,"nameZh":6,"description":193,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":194,"categories":195,"keywords":196,"publishedAt":38},"01M6KWDVXNF6T2JTMV23RJGAF6","spec-driven-development","Manages the full lifecycle of a feature specification — from collaborative drafting to enforcement during implementation and testing.","https:\u002F\u002Fgithub.com\u002Frafsanulhasan\u002FHypermediaEngine\u002Fblob\u002Fmain\u002F.github\u002Fskills\u002Fspec-driven-development\u002FSKILL.md",[],[197,198,199,200,201,81,135,85,32,22,21,89,202,203,204,205,206,207,208,209],"spec","spec driven development","development","spec driven","driven","enforcement","implementation","specification","analyst","full","feature","sonnet","feature specification"]