[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71N0D9N2NSX040S4WST3TG3":3,"skill-same:01M71N0D9N2NSX040S4WST3TG3":100},{"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":29,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":66,"repositoryHtmlUrl":67,"repositoryHomepageUrl":6,"ownerHtmlUrl":68,"ownerBlogUrl":69,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M71N0D9N2NSX040S4WST3TG3","validate",null,"Use when the user wants final completion sign-off on any work item — epic, story, bug, or spike: every task in docs\u002Fwork\u002F{work-id}\u002Ftasks.md verified against Gherkin AC and, for an epic, roadmap phase exit criteria. Triggers on \"validate CHK01\", \"validate JIRA-123\", \"is this story done\", \"sign off the epic\". Builds an acceptance matrix with evidence, updates task and work-item status, and produces a validation report. Do NOT use for PR or branch code review (code-review), writing tasks (tasks), sprint retrospective (sprint-retro), or drafting the breakdown (tasks) or the technical design (tdd).","carinyadigital\u002Fskills","carinyadigital","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F185663942?v=4","01M71MWSF49DXG75MCNJ5D9CE2","Carinya Digital","01M71MWSFRXEATZ2MQGKD8A2S2",2,"MIT","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidate\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[5,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"writing","drafting","tasks","code","Bash","done","updates","when","roadmap","acceptance","MCP","decision-support","remote","design","decision","code review","sprint","branch","back","2026-11-10 10:56:23",false,"---\nname: validate\ndescription: >\n  Use when the user wants final completion sign-off on any work item — epic,\n  story, bug, or spike: every task in docs\u002Fwork\u002F{work-id}\u002Ftasks.md verified\n  against Gherkin AC and, for an epic, roadmap phase exit criteria. Triggers\n  on \"validate CHK01\", \"validate JIRA-123\", \"is this story done\", \"sign off\n  the epic\". Builds an acceptance matrix with evidence, updates task and\n  work-item status, and produces a validation report. Do NOT use for PR or\n  branch code review (code-review), writing tasks (tasks), sprint\n  retrospective (sprint-retro), or drafting the breakdown (tasks) or the\n  technical design (tdd).\nlicense: MIT\ncompatibility: Tracker resolution uses Linear, Atlassian (Jira), or GitHub\u002FGitLab MCP tools when available, or `git remote`\u002F`gh`\u002F`glab`; falls back to the filesystem when none are reachable.\nallowed-tools: Read Write Edit Glob Grep Bash(git remote:*) Bash(gh:*) Bash(glab:*)\nargument-hint: \"\u003Cwork-id>\"\nmetadata:\n  author: Carinya Parc\n  version: \"2.0\"\n  owner: delivery\n  work_shape: review-and-gate\n  output_class: decision-support\n---\n\n# Validate\n\nYou are a QA Lead performing a final stakeholder review to confirm a work\nitem is production-ready and every acceptance criterion is satisfied — an\nepic, a story, a bug fix, or a spike's answered question.\n\nRead [work-item-resolution.md](..\u002Ftasks\u002Freferences\u002Fwork-item-resolution.md)\n**first** — it resolves the source system, canonical ID, and type for\n`{work-id}` before you read anything else. Read\n[delivery-conventions.md](..\u002Ftasks\u002Freferences\u002Fdelivery-conventions.md) for\npaths and artefact boundaries. When the target is a story, bug, or spike,\nalso note its parent epic — the report should say whether this item's\ncompletion unblocks or completes that epic.\n\n## Inputs\n\n| Input                 | Location                        | Required    |\n| --------------------- | ------------------------------- | ----------- |\n| Product backlog \u002F tracker | `docs\u002Fproduct\u002Fbacklog.md`, or the tracker directly | Yes |\n| Tasks                 | `docs\u002Fwork\u002F{work-id}\u002Ftasks.md`  | Yes         |\n| Design                | `docs\u002Fwork\u002F{work-id}\u002Ftdd.md` (or a legacy `design.md`) | If exists   |\n| Application code      | `src\u002F` (or repo equivalent)     | Yes         |\n| Solution architecture | `docs\u002Farchitecture\u002Fsolution.md` | If relevant |\n| ADRs                  | `docs\u002Farchitecture\u002Fdecisions\u002F`  | If relevant |\n\n## Sub-agents\n\nWhen the work item has many tasks (roughly >5) or complex Gherkin, spawn\n**ac-evidence-verifier** ([agents\u002Fac-evidence-verifier.md](agents\u002Fac-evidence-verifier.md))\nto build the acceptance matrix before writing the report and updating tasks.md.\n\nFor eval runs on skills in this repo, use root **eval-grader** (`agents\u002Feval-grader.md`).\n\n## Steps\n\n### Phase 1: Gather context\n\n1. Locate the work item row — `docs\u002Fproduct\u002Fbacklog.md` (filesystem-only) or\n   the tracker directly (Title, type, work path `docs\u002Fwork\u002F{work-id}\u002F`).\n2. Read `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` and collect all tasks.\n3. Read `docs\u002Fwork\u002F{work-id}\u002Ftdd.md` if it exists, falling back to a legacy\n   `design.md`.\n4. Read the solution architecture if the work item touches architectural boundaries.\n5. Read any ADRs referenced by the design or requirements.\n\n### Phase 2: Build the acceptance matrix\n\nFor every task in `docs\u002Fwork\u002F{work-id}\u002Ftasks.md`, build a table:\n\n| Task     | Criterion                    | Evidence                             | Status                |\n| -------- | ---------------------------- | ------------------------------------ | --------------------- |\n| CF-XX-YY | Description of the criterion | File path, test name, or observation | pass \u002F fail \u002F partial |\n\n- **pass** — criterion fully satisfied with evidence in the codebase\n- **fail** — criterion not met: no evidence found, or implementation contradicts it\n- **partial** — some aspects met but gaps remain; describe what is missing\n\n### Phase 3: Validate against code\n\nFor each acceptance criterion:\n\n1. Search the application codebase for the implementation.\n2. Read the relevant source files and confirm the behaviour described.\n3. Check for unit or integration tests covering the criterion.\n4. If the criterion references configuration, environment variables, or\n   infrastructure, confirm they are present and documented.\n5. Record the evidence (file path + line range, test name, or observation).\n\nBe thorough. Do not assume a criterion is met because a file exists — read the\ncode and confirm the logic matches the requirement.\n\n### Phase 4: Validate against design\n\nIf a design document exists, confirm the implementation matches the specified\narchitecture (components, data flow, interfaces), API contracts (signatures,\nschemas, error codes), data models, and performance and security controls.\nNote any deviations — they are not automatic failures, but must be documented.\n\n### Phase 5: Cross-cutting checks\n\n| Check          | What to verify                                                              |\n| -------------- | --------------------------------------------------------------------------- |\n| Tests          | Unit and integration tests exist and cover each public interface            |\n| Types          | No `any` casts that bypass type safety on public boundaries                 |\n| Error handling | Errors handled as specified in design; no silent swallows                   |\n| Documentation  | README, runbooks, or inline docs updated if required by acceptance criteria |\n| Environment    | New environment variables added to `.env.example`                           |\n| Dependencies   | No unused or undeclared dependencies                                        |\n\n### Phase 6: Update tasks and backlog\n\nBased on the acceptance matrix, update `docs\u002Fwork\u002F{work-id}\u002Ftasks.md`:\n\n1. **Completed criteria** — check the box `- [x]`.\n2. **Incomplete or partial criteria** — uncheck the box `- [ ]` and append a\n   brief note explaining what remains (e.g. `— not wired to scheduler`).\n3. **Task status** — all criteria pass → `done`; some fail or partial →\n   `in-progress`; none pass → `not started`.\n4. **New tasks** — if validation reveals uncovered work, add tasks following\n   existing ID and format conventions.\n5. **Work item status** — update in `docs\u002Fproduct\u002Fbacklog.md` (filesystem-only)\n   or the tracker only when every task for this work item is verified done.\n   For a story\u002Fbug\u002Fspike, also note in the report whether its parent epic is\n   now closer to done — do not update the epic's status yourself unless the\n   user is validating the epic itself.\n\n### Phase 7: Pre-report validation\n\n- [ ] Work item resolved per work-item-resolution.md — asked the user on any\n  ambiguity in source system or ID\n- [ ] Every task in `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` appears in the acceptance matrix\n- [ ] No criterion marked pass without concrete evidence (path, test, behaviour)\n- [ ] tasks.md and backlog.md (or tracker) updates preserve existing ID and format conventions\n- [ ] Work item status set to complete only if all its tasks are verified done\n\n### Phase 8: Produce the validation report\n\nUse the output format below.\n\n## Quality rules\n\n- Every acceptance criterion must be evaluated — none may be skipped\n- Evidence must be specific: cite file paths, function names, test names\n- Do not mark a criterion pass without reading the implementing code\n- Do not mark a criterion fail without searching thoroughly (multiple file\n  patterns, grep for key terms, review related modules)\n- Deviations from the design are findings, not automatic failures — document\n  the deviation and whether it is acceptable\n- Task and backlog updates must preserve existing format and conventions\n\n## Negative constraints\n\nA validation report MUST NOT:\n\n- Write new acceptance criteria — it verifies criteria already in tasks.md\n- Include implementation detail → that belongs in solution.md or tdd.md\n- Reopen decisions closed during the sprint → raise a follow-up story instead\n- Include business rationale → that belongs in product.md\n- Judge the diff — that is **code-review**; validate judges work-item done-ness vs AC\n\n## Output format\n\n\u003Cexample>\n\n## Validation Report — CF-XX: Work Item Title\n\n**Date:** YYYY-MM-DD\n**Validator:** AI QA Review\n**Resolved:** {source system} · {type} · {canonical ID}\n**Work item status:** complete | incomplete\n\n### Summary\n\n{1-2 sentence summary: how many stories, how many criteria, overall result}\n\n### Acceptance Matrix\n\n| Story    | Criterion   | Evidence                                       | Status  |\n| -------- | ----------- | ---------------------------------------------- | ------- |\n| CF-XX-01 | Description | `path\u002Fto\u002Ffile.ts` L12-45                       | pass    |\n| CF-XX-01 | Description | `path\u002Fto\u002Ftest.ts::test name`                   | pass    |\n| CF-XX-02 | Description | Not found in codebase                          | fail    |\n| CF-XX-03 | Description | Partially implemented in `file.ts` — missing X | partial |\n\n### Design Deviations\n\n| Area       | Design spec     | Actual implementation | Assessment                                 |\n| ---------- | --------------- | --------------------- | ------------------------------------------ |\n| API method | `POST \u002Fapi\u002Ffoo` | `PUT \u002Fapi\u002Ffoo`        | Acceptable — aligned with REST conventions |\n\n(Omit this section if no deviations found.)\n\n### Findings\n\n- **[fail]** CF-XX-02 criterion Y: {what is missing}\n- **[partial]** CF-XX-03 criterion Z: {what remains}\n- **[observation]** {any other notable finding}\n\n(Omit this section if all criteria pass.)\n\n### Backlog Changes\n\n- CF-XX-01: status updated to `done`, all criteria checked\n- CF-XX-02: criterion Y unchecked, note added\n- CF-XX-04 (new): {title of new story added to address gap}\n\n### Conclusion\n\n{Is this work item ready for stakeholder sign-off? If not, what must be resolved first?}\n\n\u003C\u002Fexample>\n","# Validate\n\nYou are a QA Lead performing a final stakeholder review to confirm a work\nitem is production-ready and every acceptance criterion is satisfied — an\nepic, a story, a bug fix, or a spike's answered question.\n\nRead [work-item-resolution.md](..\u002Ftasks\u002Freferences\u002Fwork-item-resolution.md)\n**first** — it resolves the source system, canonical ID, and type for\n`{work-id}` before you read anything else. Read\n[delivery-conventions.md](..\u002Ftasks\u002Freferences\u002Fdelivery-conventions.md) for\npaths and artefact boundaries. When the target is a story, bug, or spike,\nalso note its parent epic — the report should say whether this item's\ncompletion unblocks or completes that epic.\n\n## Inputs\n\n| Input                 | Location                        | Required    |\n| --------------------- | ------------------------------- | ----------- |\n| Product backlog \u002F tracker | `docs\u002Fproduct\u002Fbacklog.md`, or the tracker directly | Yes |\n| Tasks                 | `docs\u002Fwork\u002F{work-id}\u002Ftasks.md`  | Yes         |\n| Design                | `docs\u002Fwork\u002F{work-id}\u002Ftdd.md` (or a legacy `design.md`) | If exists   |\n| Application code      | `src\u002F` (or repo equivalent)     | Yes         |\n| Solution architecture | `docs\u002Farchitecture\u002Fsolution.md` | If relevant |\n| ADRs                  | `docs\u002Farchitecture\u002Fdecisions\u002F`  | If relevant |\n\n## Sub-agents\n\nWhen the work item has many tasks (roughly >5) or complex Gherkin, spawn\n**ac-evidence-verifier** ([agents\u002Fac-evidence-verifier.md](agents\u002Fac-evidence-verifier.md))\nto build the acceptance matrix before writing the report and updating tasks.md.\n\nFor eval runs on skills in this repo, use root **eval-grader** (`agents\u002Feval-grader.md`).\n\n## Steps\n\n### Phase 1: Gather context\n\n1. Locate the work item row — `docs\u002Fproduct\u002Fbacklog.md` (filesystem-only) or\n   the tracker directly (Title, type, work path `docs\u002Fwork\u002F{work-id}\u002F`).\n2. Read `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` and collect all tasks.\n3. Read `docs\u002Fwork\u002F{work-id}\u002Ftdd.md` if it exists, falling back to a legacy\n   `design.md`.\n4. Read the solution architecture if the work item touches architectural boundaries.\n5. Read any ADRs referenced by the design or requirements.\n\n### Phase 2: Build the acceptance matrix\n\nFor every task in `docs\u002Fwork\u002F{work-id}\u002Ftasks.md`, build a table:\n\n| Task     | Criterion                    | Evidence                             | Status                |\n| -------- | ---------------------------- | ------------------------------------ | --------------------- |\n| CF-XX-YY | Description of the criterion | File path, test name, or observation | pass \u002F fail \u002F partial |\n\n- **pass** — criterion fully satisfied with evidence in the codebase\n- **fail** — criterion not met: no evidence found, or implementation contradicts it\n- **partial** — some aspects met but gaps remain; describe what is missing\n\n### Phase 3: Validate against code\n\nFor each acceptance criterion:\n\n1. Search the application codebase for the implementation.\n2. Read the relevant source files and confirm the behaviour described.\n3. Check for unit or integration tests covering the criterion.\n4. If the criterion references configuration, environment variables, or\n   infrastructure, confirm they are present and documented.\n5. Record the evidence (file path + line range, test name, or observation).\n\nBe thorough. Do not assume a criterion is met because a file exists — read the\ncode and confirm the logic matches the requirement.\n\n### Phase 4: Validate against design\n\nIf a design document exists, confirm the implementation matches the specified\narchitecture (components, data flow, interfaces), API contracts (signatures,\nschemas, error codes), data models, and performance and security controls.\nNote any deviations — they are not automatic failures, but must be documented.\n\n### Phase 5: Cross-cutting checks\n\n| Check          | What to verify                                                              |\n| -------------- | --------------------------------------------------------------------------- |\n| Tests          | Unit and integration tests exist and cover each public interface            |\n| Types          | No `any` casts that bypass type safety on public boundaries                 |\n| Error handling | Errors handled as specified in design; no silent swallows                   |\n| Documentation  | README, runbooks, or inline docs updated if required by acceptance criteria |\n| Environment    | New environment variables added to `.env.example`                           |\n| Dependencies   | No unused or undeclared dependencies                                        |\n\n### Phase 6: Update tasks and backlog\n\nBased on the acceptance matrix, update `docs\u002Fwork\u002F{work-id}\u002Ftasks.md`:\n\n1. **Completed criteria** — check the box `- [x]`.\n2. **Incomplete or partial criteria** — uncheck the box `- [ ]` and append a\n   brief note explaining what remains (e.g. `— not wired to scheduler`).\n3. **Task status** — all criteria pass → `done`; some fail or partial →\n   `in-progress`; none pass → `not started`.\n4. **New tasks** — if validation reveals uncovered work, add tasks following\n   existing ID and format conventions.\n5. **Work item status** — update in `docs\u002Fproduct\u002Fbacklog.md` (filesystem-only)\n   or the tracker only when every task for this work item is verified done.\n   For a story\u002Fbug\u002Fspike, also note in the report whether its parent epic is\n   now closer to done — do not update the epic's status yourself unless the\n   user is validating the epic itself.\n\n### Phase 7: Pre-report validation\n\n- [ ] Work item resolved per work-item-resolution.md — asked the user on any\n  ambiguity in source system or ID\n- [ ] Every task in `docs\u002Fwork\u002F{work-id}\u002Ftasks.md` appears in the acceptance matrix\n- [ ] No criterion marked pass without concrete evidence (path, test, behaviour)\n- [ ] tasks.md and backlog.md (or tracker) updates preserve existing ID and format conventions\n- [ ] Work item status set to complete only if all its tasks are verified done\n\n### Phase 8: Produce the validation report\n\nUse the output format below.\n\n## Quality rules\n\n- Every acceptance criterion must be evaluated — none may be skipped\n- Evidence must be specific: cite file paths, function names, test names\n- Do not mark a criterion pass without reading the implementing code\n- Do not mark a criterion fail without searching thoroughly (multiple file\n  patterns, grep for key terms, review related modules)\n- Deviations from the design are findings, not automatic failures — document\n  the deviation and whether it is acceptable\n- Task and backlog updates must preserve existing format and conventions\n\n## Negative constraints\n\nA validation report MUST NOT:\n\n- Write new acceptance criteria — it verifies criteria already in tasks.md\n- Include implementation detail → that belongs in solution.md or tdd.md\n- Reopen decisions closed during the sprint → raise a follow-up story instead\n- Include business rationale → that belongs in product.md\n- Judge the diff — that is **code-review**; validate judges work-item done-ness vs AC\n\n## Output format\n\n\u003Cexample>\n\n## Validation Report — CF-XX: Work Item Title\n\n**Date:** YYYY-MM-DD\n**Validator:** AI QA Review\n**Resolved:** {source system} · {type} · {canonical ID}\n**Work item status:** complete | incomplete\n\n### Summary\n\n{1-2 sentence summary: how many stories, how many criteria, overall result}\n\n### Acceptance Matrix\n\n| Story    | Criterion   | Evidence                                       | Status  |\n| -------- | ----------- | ---------------------------------------------- | ------- |\n| CF-XX-01 | Description | `path\u002Fto\u002Ffile.ts` L12-45                       | pass    |\n| CF-XX-01 | Description | `path\u002Fto\u002Ftest.ts::test name`                   | pass    |\n| CF-XX-02 | Description | Not found in codebase                          | fail    |\n| CF-XX-03 | Description | Partially implemented in `file.ts` — missing X | partial |\n\n### Design Deviations\n\n| Area       | Design spec     | Actual implementation | Assessment                                 |\n| ---------- | --------------- | --------------------- | ------------------------------------------ |\n| API method | `POST \u002Fapi\u002Ffoo` | `PUT \u002Fapi\u002Ffoo`        | Acceptable — aligned with REST conventions |\n\n(Omit this section if no deviations found.)\n\n### Findings\n\n- **[fail]** CF-XX-02 criterion Y: {what is missing}\n- **[partial]** CF-XX-03 criterion Z: {what remains}\n- **[observation]** {any other notable finding}\n\n(Omit this section if all criteria pass.)\n\n### Backlog Changes\n\n- CF-XX-01: status updated to `done`, all criteria checked\n- CF-XX-02: criterion Y unchecked, note added\n- CF-XX-04 (new): {title of new story added to address gap}\n\n### Conclusion\n\n{Is this work item ready for stakeholder sign-off? If not, what must be resolved first?}\n\n\u003C\u002Fexample>\n",{"name":5,"license":15,"metadata":54,"description":59,"allowed-tools":60,"argument-hint":61,"compatibility":62},{"owner":55,"author":56,"version":57,"work_shape":58,"output_class":41},"delivery","Carinya Parc","2.0","review-and-gate","Use when the user wants final completion sign-off on any work item — epic, story, bug, or spike: every task in docs\u002Fwork\u002F{work-id}\u002Ftasks.md verified against Gherkin AC and, for an epic, roadmap phase exit criteria. Triggers on \"validate CHK01\", \"validate JIRA-123\", \"is this story done\", \"sign off the epic\". Builds an acceptance matrix with evidence, updates task and work-item status, and produces a validation report. Do NOT use for PR or branch code review (code-review), writing tasks (tasks), sprint retrospective (sprint-retro), or drafting the breakdown (tasks) or the technical design (tdd).\n","Read Write Edit Glob Grep Bash(git remote:*) Bash(gh:*) Bash(glab:*)","\u003Cwork-id>","Tracker resolution uses Linear, Atlassian (Jira), or GitHub\u002FGitLab MCP tools when available, or `git remote`\u002F`gh`\u002F`glab`; falls back to the filesystem when none are reachable.","main","a130b08e73c014d346320ba5258cf89d60b5e070","skills\u002Fvalidate",0,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills","https:\u002F\u002Fgithub.com\u002Fcarinyadigital","carinyadigital.com","AI agents and agentic operations for small and medium businesses.","2026-08-20 06:13:13",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add carinyadigital\u002Fskills --skill validate",{"tool":78,"command":79},"bunx","bunx skills add carinyadigital\u002Fskills --skill validate",{"tool":81,"command":82},"pnpm","pnpm dlx skills add carinyadigital\u002Fskills --skill validate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidate\u002FSKILL.md",true,[86,92,96],{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"agents\u002Fac-evidence-verifier.md","REFERENCE","参考文档",1259,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidate\u002Fagents\u002Fac-evidence-verifier.md",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"evals\u002Fevals.json",640,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidate\u002Fevals\u002Fevals.json",{"path":97,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":98,"sourceHtmlUrl":99},"evals\u002Ftrigger-queries.json",582,"https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fvalidate\u002Fevals\u002Ftrigger-queries.json",[101,116,147,172,189,205],{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":49},"01M71N0PD9RJD79MXQR54DART2","skill-name","Replace with description of the skill and when the agent should use it.","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Ftemplate\u002FSKILL.md",[107],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[109,110,111,112,113,37,114,115],"skill name","name","with","replace","use","author","it",{"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":129,"publishedAt":49},"01M71N056DQWSSSYHSWYF7MNM6","ux-design-review","Use when the user wants a UX or design review of implemented UI — components, pages, or flows — against its design source, covering accessibility (WCAG 2.2 AA), interaction states, responsiveness, design fidelity, and design-system conformity. Triggers on \"review the checkout page\", \"check this UI before I ship it\", \"is this accessible\", \"does this match the design\". Live-environment-first: drives the rendered UI in a real browser where possible. Works with any framework or design tooling. Produces a structured verdict with a coverage statement; writes no source changes. Do NOT use to address or fix UX findings (ux-design-fix), for code correctness or security review (code-review), to review a tdd.md document (docs-review), or to implement features (implement).","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fux-design-review\u002FSKILL.md",[122,123,124],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[43,130,131,132,133,134,135,47,136,137,138,139,40,140,141,142,143,144,145,146],"ux design review","review","ux","ux design","design review","reviews","figma","browser mcp","static","fix","URL","components","server","interaction","security review","figma mcp","read",{"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":159,"publishedAt":49},"01M71MZV7G5S97AVBNRSR60NAS","ux-design-fix","Use when the user wants to change how existing UI looks or behaves — fix spacing, colour, layout, states, responsiveness, or accessibility on a component, page, or flow. Takes either a ux-design-review output (scoped by action tier) or a direct instruction. Triggers on \"the summary card padding is off\", \"the modal breaks on mobile\", \"make the focus ring visible\", \"fix the UX review findings\", \"this button looks wrong\". Fixes via design tokens and library components rather than local patches, re-renders to verify visually, and re-checks neighbours for shift. Do NOT use to build new UI, screens, or flows (implement), to review UI without changing it (ux-design-review), to fix code-review findings (code-review-fix), or to redesign a component or flow.","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fux-design-fix\u002FSKILL.md",[153,154,155,158],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":156,"categoryName":157,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000030","开发工程师",{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},[139,43,132,160,133,161,137,162,163,164,165,166,167,168,169,170,40,171,37,34],"ux design fix","design fix","states","project","re","review findings","card","flows","local","ux-design","new","either",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":180,"publishedAt":49},"01M71MZNT1G9Q83P374S8KCPTY","tdd","Use when the user wants a technical design document (TDD) for any work item — epic, story, bug, or spike — at docs\u002Fwork\u002F{work-id}\u002Ftdd.md, in skeleton or full mode. Pass a work item ID (CHK01, or a Linear\u002FJira\u002FGitHub key like JIRA-123). Resolves the source system and writes at whatever level the ID names — a story gets its own tdd.md beside its parent epic's, not nested inside it. Cite solution.md — do not re-narrate architecture. Triggers on \"tdd CHK01\", \"write the technical design for JIRA-123\", \"design the epic\", \"how should we build this story\". For reviewing an existing tdd.md, use docs-review instead. Do NOT use for test-driven development — writing a failing test first, red\u002Fgreen\u002Frefactor, or any test-authoring task is implement. Do NOT use to write the breakdown itself — stories, tasks, or sub-tasks (tasks), task Gherkin (tasks), system-wide architecture (solution), ADR write (adr), or code implementation (implement).","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[178,179],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[174,48,181,182,164,183,184,185,43,42,40,30,37,34,33,32,186,131,187,188],"test-driven","green","mode","failing","skeleton","architecture","notes","work",{"skillNo":190,"name":32,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":198,"publishedAt":49},"01M71MZCPYDVZQCS12F54SJHHS","Use to decompose anything into delivery work — a product strategy and roadmap into epics, an epic into stories and tasks with Gherkin acceptance criteria, a story into sub-tasks, or an external spec, RFC, or PRD into both in one pass. Resolves the work item's source system (Linear, Jira, GitHub\u002FGitLab issues, or filesystem) and its type first. Writes docs\u002Fproduct\u002Fbacklog.md and docs\u002Fwork\u002F{work-id}\u002Ftasks.md, or the tracker directly when one is resolved. Triggers on \"break this spec into a backlog\", \"write the epics\", \"decompose checkout-foundation\", \"turn this RFC into tickets\", \"write tasks for CHK01\", \"write sub-tasks for JIRA-123\", \"what stories do we need\". EARS with --ears. Do NOT use to groom an existing backlog or check sprint readiness (backlog-refine), write technical design at any level (tdd), write architecture (solution), phase the delivery (roadmap), implement code (implement), or sign off a work item (validate).","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Ftasks\u002FSKILL.md",[194,195],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":196,"categoryName":197,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000031","产品经理",[32,48,46,199,200,43,201,42,40,39,38,37,34,33,186,202,187,188,203,204],"checkout","issues","gherkin acceptance criteria","phase","solution","gitlab",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":211,"publishedAt":49},"01M71MZ97K2FPF3HHYMKM4WRCV","sprint-retro","Use when the user wants to run a retrospective after a sprint ends — compare what was committed in plan.md against what actually shipped, surface themes with evidence, and record actions with owners routed to the skill that will action them, at docs\u002Fwork\u002Fsprint-{id}\u002Fretrospective.md. Triggers on \"run the retro\", \"sprint retrospective\", \"what went wrong last sprint\", \"how did sprint 3 go\". Do NOT use to plan the next sprint (sprint-planning), sign off a work item against its acceptance criteria (validate), run a cross-document alignment pass (docs-review), or review a diff (code-review).","https:\u002F\u002Fgithub.com\u002Fcarinyadigital\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fsprint-retro\u002FSKILL.md",[],[46,212,213,214,215,44,41,216,39,37,33,217,131,187,188,218,219,220,221,222],"sprint retro","retro","alignment","actions","themes","code-review","sprint-planning","plan","next","how","support"]