[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6PVCZCZAPMEMM32BBQRDFA2":3,"skill-same:01M6PVCZCZAPMEMM32BBQRDFA2":70},{"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":23,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":49,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6PVCZCZAPMEMM32BBQRDFA2","requirements-interview",null,"The Requirements stage of the plan-gate — fills plan.md's Requirements section via structured Q&A where the agent proposes a cited best-guess per question and the supervisor reviews. Reached through plan-gate (which owns the brainstorm→plan entry), not as an independent trigger.","muratovv\u002Fai-hats","muratovv","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F7502801?v=4","01M6JGCBN4KEJX012GPJVSH04T","Fedor Muratov","01M6JGCBSNMN7CW3RGTPPE0MN2",3,"MIT","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Frequirements-interview\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41],"requirements interview","interview","requirements","as","section","entry","which","q&a","reviews","via","trigger","plan","stage","structured","gate","question","brainstorm","supervisor","2026-11-10 10:12:30",false,"---\nname: requirements-interview\ndescription: >-\n  The Requirements stage of the plan-gate — fills plan.md's Requirements\n  section via structured Q&A where the agent proposes a cited best-guess\n  per question and the supervisor reviews. Reached through plan-gate\n  (which owns the brainstorm→plan entry), not as an independent trigger.\nlicense: MIT\nai_hats:\n  schema_version: 1\n  type: skill\n---\n\n# Requirements Interview\n\nThe **Requirements stage of `plan-gate`**: structured Q&A that fills the\n`Requirements` section of `plan.md` before a task leaves brainstorm.\n**The interview is review-shaped, not interrogation-shaped:** for every\nquestion, the agent proposes a best-guess answer grounded in the\ncodebase\u002Fdocs and the supervisor confirms or overrides.\n\n## When to Use\n\nReach this stage through `plan-gate`, not as a standalone brainstorm→plan\ntrigger — `plan-gate` is the single entry point and routes here to fill the\n`Requirements` section.\n\n- Run it when that section is empty and the request leaves >2 independent assumptions about user intent.\n- Skip when requirements are already unambiguous from the request — fill the section directly.\n- Sibling stage: `design-minimalism` owns the adjacent `Scope & Out-of-scope` section — don't do scope-justification here.\n- Next stage: once you've stated the value (Q1 \"Goal & user value\"), `devils-advocate` challenges it in `Approach & counter` — *is it needed? did we miss anything? another way?* Loop with it until the value settles, then hand off to scope.\n\n## Checklist\n\nWalk through these with the user. Skip any that are already unambiguous from\nthe request. Ask in order; stop when you have enough to plan.\n\n### Procedure for each question — collect, propose, review\n\nBefore voicing any question from the list below:\n\n1. **Collect context.** Read \u002F Glob \u002F Grep relevant files (existing\n   patterns, similar tasks in the backlog, docs\u002F, ADRs, task.yaml of\n   related cards). One targeted pass — not a full codebase tour.\n2. **Propose a best-guess answer with a source citation.** Format:\n   *\"My current best guess: \u003Canswer>, because `\u003Cpath>:\u003Cline>` shows\n   `\u003Cverbatim or paraphrase>`.\"* If the source is a prior task or HYP,\n   cite the ID. If context is genuinely silent, say *\"context silent\n   on this — please supply\"* and only then ask the open question.\n3. **Supervisor reviews.** Supervisor confirms, corrects, or overrides.\n   The interview becomes a one-turn review per question, not a\n   multi-round interrogation.\n\n**Without step 1, the recommended answer is hallucination.** A\nbest-guess pulled from training-data prior is exactly what we are\ntrying to replace with grounded review.\n\n### Questions\n\n1. **Goal & user value** — Who is this for, and what changes for them when it's done?\n2. **Acceptance criteria** — How will we know it's done? List 2-4 concrete checks.\n3. **Edge cases & failure modes** — What should happen on errors, empty inputs,\n   concurrency, or partial state?\n4. **Non-functional requirements** — Performance, reliability, compatibility,\n   observability needs?\n5. **Constraints & non-goals** — What is explicitly out of scope? What must NOT change?\n6. **Dependencies & blockers** — Anything we're waiting on (other tasks, systems, people)?\n7. **Kill criteria** — Under what condition should we abandon the task instead of\n   shipping a partial version?\n\n## Output\n\nAfter the interview, update the task description so a fresh agent can pick it\nup without re-asking:\n\n```bash\nrack transition \u003CID> --set description=\"\u003Canswers organized by section>\"\n```\n\nMirror the question headings (Goal, Acceptance, Edge cases, etc.) so future\nreaders see what was confirmed vs left N\u002FA. **Each non-N\u002FA answer carries\neither a source citation (`path:line`, task ID, ADR ID) or an explicit\n\"supervisor override: \u003Creason>\"** — so the next agent can audit the\nprovenance of each line.\n\n## Completion\n\n- Task description has answers (or explicit `N\u002FA — \u003Creason>`) for questions 1-3 minimum\n- Every non-N\u002FA answer carries a source citation OR a \"supervisor override\" tag\n- All user-mentioned constraints captured (cross-check with **scope-guard**)\n- Plan can be drafted without material assumptions about user intent\n\n## Anti-Patterns\n\n- **Asking a question whose answer is visible in the code\u002Fdocs.** Read\n  first; ask only when context is silent or ambiguous. Cheap exploration\n  costs less than a supervisor turn.\n- **Recommended answer without a source citation.** A best-guess\n  unanchored to `path:line` \u002F task-ID \u002F ADR is a hallucination dressed\n  as review. The whole point of the citation is that supervisor can\n  jump to the source in one click.\n- **Citing a source that doesn't actually say what you claim.** Worse\n  than no citation — it's a false anchor. Read the file you're citing.\n- Asking all 7 questions when only 1-2 are unclear — wastes the user's time\n- Accepting vague answers (\"make it good\") without a follow-up\n- Skipping the interview on tasks described in one sentence — that's exactly\n  when ambiguity is highest\n- Deferring questions until plan\u002Fexecute — a misaligned plan costs more to redo\n  than a 2-minute interview\n","# Requirements Interview\n\nThe **Requirements stage of `plan-gate`**: structured Q&A that fills the\n`Requirements` section of `plan.md` before a task leaves brainstorm.\n**The interview is review-shaped, not interrogation-shaped:** for every\nquestion, the agent proposes a best-guess answer grounded in the\ncodebase\u002Fdocs and the supervisor confirms or overrides.\n\n## When to Use\n\nReach this stage through `plan-gate`, not as a standalone brainstorm→plan\ntrigger — `plan-gate` is the single entry point and routes here to fill the\n`Requirements` section.\n\n- Run it when that section is empty and the request leaves >2 independent assumptions about user intent.\n- Skip when requirements are already unambiguous from the request — fill the section directly.\n- Sibling stage: `design-minimalism` owns the adjacent `Scope & Out-of-scope` section — don't do scope-justification here.\n- Next stage: once you've stated the value (Q1 \"Goal & user value\"), `devils-advocate` challenges it in `Approach & counter` — *is it needed? did we miss anything? another way?* Loop with it until the value settles, then hand off to scope.\n\n## Checklist\n\nWalk through these with the user. Skip any that are already unambiguous from\nthe request. Ask in order; stop when you have enough to plan.\n\n### Procedure for each question — collect, propose, review\n\nBefore voicing any question from the list below:\n\n1. **Collect context.** Read \u002F Glob \u002F Grep relevant files (existing\n   patterns, similar tasks in the backlog, docs\u002F, ADRs, task.yaml of\n   related cards). One targeted pass — not a full codebase tour.\n2. **Propose a best-guess answer with a source citation.** Format:\n   *\"My current best guess: \u003Canswer>, because `\u003Cpath>:\u003Cline>` shows\n   `\u003Cverbatim or paraphrase>`.\"* If the source is a prior task or HYP,\n   cite the ID. If context is genuinely silent, say *\"context silent\n   on this — please supply\"* and only then ask the open question.\n3. **Supervisor reviews.** Supervisor confirms, corrects, or overrides.\n   The interview becomes a one-turn review per question, not a\n   multi-round interrogation.\n\n**Without step 1, the recommended answer is hallucination.** A\nbest-guess pulled from training-data prior is exactly what we are\ntrying to replace with grounded review.\n\n### Questions\n\n1. **Goal & user value** — Who is this for, and what changes for them when it's done?\n2. **Acceptance criteria** — How will we know it's done? List 2-4 concrete checks.\n3. **Edge cases & failure modes** — What should happen on errors, empty inputs,\n   concurrency, or partial state?\n4. **Non-functional requirements** — Performance, reliability, compatibility,\n   observability needs?\n5. **Constraints & non-goals** — What is explicitly out of scope? What must NOT change?\n6. **Dependencies & blockers** — Anything we're waiting on (other tasks, systems, people)?\n7. **Kill criteria** — Under what condition should we abandon the task instead of\n   shipping a partial version?\n\n## Output\n\nAfter the interview, update the task description so a fresh agent can pick it\nup without re-asking:\n\n```bash\nrack transition \u003CID> --set description=\"\u003Canswers organized by section>\"\n```\n\nMirror the question headings (Goal, Acceptance, Edge cases, etc.) so future\nreaders see what was confirmed vs left N\u002FA. **Each non-N\u002FA answer carries\neither a source citation (`path:line`, task ID, ADR ID) or an explicit\n\"supervisor override: \u003Creason>\"** — so the next agent can audit the\nprovenance of each line.\n\n## Completion\n\n- Task description has answers (or explicit `N\u002FA — \u003Creason>`) for questions 1-3 minimum\n- Every non-N\u002FA answer carries a source citation OR a \"supervisor override\" tag\n- All user-mentioned constraints captured (cross-check with **scope-guard**)\n- Plan can be drafted without material assumptions about user intent\n\n## Anti-Patterns\n\n- **Asking a question whose answer is visible in the code\u002Fdocs.** Read\n  first; ask only when context is silent or ambiguous. Cheap exploration\n  costs less than a supervisor turn.\n- **Recommended answer without a source citation.** A best-guess\n  unanchored to `path:line` \u002F task-ID \u002F ADR is a hallucination dressed\n  as review. The whole point of the citation is that supervisor can\n  jump to the source in one click.\n- **Citing a source that doesn't actually say what you claim.** Worse\n  than no citation — it's a false anchor. Read the file you're citing.\n- Asking all 7 questions when only 1-2 are unclear — wastes the user's time\n- Accepting vague answers (\"make it good\") without a follow-up\n- Skipping the interview on tasks described in one sentence — that's exactly\n  when ambiguity is highest\n- Deferring questions until plan\u002Fexecute — a misaligned plan costs more to redo\n  than a 2-minute interview\n",{"name":5,"ai_hats":47,"license":15,"description":7},{"type":48,"schema_version":49},"skill",1,"master","f922a7f627276366873d546942d9ad899a86f71a","packages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Frequirements-interview","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats","https:\u002F\u002Fgithub.com\u002Fmuratovv","2026-11-05 20:59:10",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add muratovv\u002Fai-hats --skill requirements-interview",{"tool":62,"command":63},"bunx","bunx skills add muratovv\u002Fai-hats --skill requirements-interview",{"tool":65,"command":66},"pnpm","pnpm dlx skills add muratovv\u002Fai-hats --skill requirements-interview","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fcore\u002Fskills\u002Frequirements-interview\u002FSKILL.md",true,[],[71,98,123,145,169,182],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":42},"01M6PVFB1SM738R2SRSRSF7CY6","tool-evaluation-protocol","Time-bounded protocol for evaluating new tools, libraries, or methodologies before adoption. Use when evaluating a candidate dependency for the project, researching a methodology (e.g. ML\u002FLLM frameworks, testing approaches), or following up on a hype-driven recommendation.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Ftool-evaluation-protocol\u002FSKILL.md",[],[78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97],"protocol","Evaluation","tool","tool evaluation protocol","testing","ml","libraries","adoption","methodology","Tools","use","dependency","up","frameworks","time","project","recommendation","for","bounded","candidate",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":104,"publishedAt":42},"01M6PVF7HATBEX1G7N50E2QT57","systematic-debugging","4-phase bug-fix protocol (evidence, pattern, hypothesis, verify). Use when investigating any error, failure, or unexpected behavior, handling bug reports from users or monitoring, or diagnosing test failures with non-obvious causes.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fsystematic-debugging\u002FSKILL.md",[],[105,106,107,108,78,109,110,111,112,113,88,114,115,116,117,118,119,120,121,122],"systematic debugging","debugging","systematic","test","monitoring","hypothesis","verify","behavior","fix","evidence","bug","reports","pattern","users","error","with","bug-fix","phase",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":134,"publishedAt":42},"01M6PVF3MTQN3RPF73AN34856J","skill-template","Canonical template and validation guide for ai-hats skills. Use when creating a new skill, reviewing an existing one for structural compliance, or deciding which pattern fits a new behavior.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fskill-template\u002FSKILL.md",[129],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[135,136,137,138,139,112,140,88,141,117,142,143,30,95,144],"template","skill template","validation","compliance","hats","guide","new skill","structural","canonical","Existing",{"skillNo":146,"name":147,"nameZh":6,"description":148,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":149,"categories":150,"keywords":152,"publishedAt":42},"01M6PVF06SCV28QARM5MQPANC9","skill-optimization","Audit and refactor library components to eliminate redundancy and staleness. Use during periodic library maintenance, after adding multiple new skills or rules, when a role's token budget is too high, or after retrospectives identify component issues.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fskill-optimization\u002FSKILL.md",[151],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},[153,154,155,156,157,158,159,160,161,162,88,163,164,165,166,167,168],"Optimization","skill optimization","components","component","issues","library","audit","refactor","Budget","Rules","periodic","maintenance","token","token budget","role","high",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":175,"publishedAt":42},"01M6PVEXM9717016T9MW82HDCT","silent-fallback-gate","PreToolUse hook — refuses an Edit or Write that adds an inert broad except. Use when a Python edit was blocked for a silent fallback.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fsilent-fallback-gate\u002FSKILL.md",[],[38,176,177,178,179,180,88,181,95],"fallback","silent fallback gate","python","write","edit","hook",{"skillNo":183,"name":184,"nameZh":6,"description":185,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":186,"categories":187,"keywords":189,"publishedAt":42},"01M6PVESM49C5NT7SB7N3F76VS","retro-to-framework","Convert an observation about agent behavior — from a retrospective or from a single incident — into a framework-level change (hook, rule, skill, skill update). Use after a retrospective identifies problems that are not project-specific, after an incident where an agent misapplied a component it had read, when CLAUDE.md band-aids accumulate (more than 3 per-project rules that could be generic), or when the same problem recurs across multiple projects.","https:\u002F\u002Fgithub.com\u002Fmuratovv\u002Fai-hats\u002Fblob\u002Fmaster\u002Fpackages\u002Fai-hats-library\u002Fsrc\u002Fai_hats_library\u002Fexperimental\u002Fusage\u002Fskills\u002Fretro-to-framework\u002FSKILL.md",[188],{"categoryNo":130,"categoryName":131,"taxonomyType":132,"taxonomyTypeDesc":133},[190,191,192,193,156,194,195,196,162,112,88,197,198,93,199,200,201,202,203,204],"framework","retro","retro to framework","change","retrospective","projects","convert","incident","across","problem","about","more","skill update","single","generic"]