[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71KCWDK28P8WB942FMQBN43":3,"skill-same:01M71KCWDK28P8WB942FMQBN43":81},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M71KCWDK28P8WB942FMQBN43","interview-framework",null,"Use when curdx-flow needs user decisions after codebase facts are discovered.","mugsun\u002Fcurdx-flow","mugsun","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F100790155?v=4","01M6KJSAN2W4WRPDFBKTJTDDQ2","Mugsun","01M71K65VJXA4C1KPJAHZ6ZVHC",4,"MIT","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Finterview-framework\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],"framework","interview","interview framework","design","false","when","tasks","flow","use","decisions","requirements","facts","research","codebase","triage","user","2026-11-10 10:12:30",false,"---\nname: interview-framework\ndescription: Use when curdx-flow needs user decisions after codebase facts are discovered.\nwhen_to_use: Use before research, requirements, design, tasks, or triage when user decisions are needed and codebase facts must be discovered before asking.\nversion: 0.2.0\nuser-invocable: false\n---\n\n# Interview Framework\n\nAdaptive brainstorming dialogue algorithm for all spec phases. Each phase command provides its own exploration territory (phase-specific areas to probe).\n\n## Option Limit Rule\n\nEach question must have 2-4 options (max 4). Keep the most relevant options, combine similar ones.\n\n## Recommendation Format\n\nEvery question asked via `AskUserQuestion` in Phase 1 leads with the recommended option (except when options are symmetric, in which case `[Recommended]` may be omitted):\n\n```yaml\nAskUserQuestion:\n  question: \"[Context-aware question referencing prior answers]. [One sentence rationale for the recommendation.]\"\n  options:\n    - \"[Recommended] [Option text -- the AI's suggested answer]\"\n    - \"[Alternative 1]\"\n    - \"[Alternative 2 if needed]\"\n    - \"Other\"\n```\n\nRules:\n- `[Recommended]` is a label prefix on the first option only.\n- The rationale sits in the question text, not the option label.\n- Option count still 2-4 max (Option Limit Rule preserved).\n- If there is no meaningful recommendation (truly symmetric choice), omit the `[Recommended]` label rather than placing it arbitrarily.\n\nExample:\n\n```yaml\nAskUserQuestion:\n  question: \"Where should the spec live? You only have one specs directory configured, so the default is fine unless you want to reorganize.\"\n  options:\n    - \"[Recommended] .\u002Fspecs\u002F (default)\"\n    - \"Let me configure a different path\"\n    - \"Other\"\n```\n\n## Parallel Codebase-First Discovery\n\nBefore asking ANY question, determine whether the answer is a **codebase fact**, a **prior-memory fact**, a **current-docs fact**, or a **user decision**:\n\n- **Codebase fact**: discoverable by reading code, config, or existing specs (e.g., which framework is used, whether an interface already exists, what a file currently does). Delegate to an `Explore` subagent. Never ask the user.\n- **Prior-memory fact**: discoverable by querying the user's claude-mem history (e.g., \"did we already decide on Postgres for this product?\", \"what stack did we pick last quarter?\"). Delegate to a `general-purpose` subagent invoking `mcp__plugin_claude-mem_mcp-search__*` tools. Never ask the user.\n- **Current-docs fact**: discoverable from official docs of a named library\u002Fframework\u002FSDK\u002FAPI (e.g., \"does node-pty support Windows?\", \"is OAuth-PKCE required for this provider?\"). Delegate to a `research-analyst` subagent (preferring Context7 MCP via its tool surface). Never ask the user.\n- **User decision**: a preference, priority, trade-off, or constraint that only the user can answer (e.g., which of two viable approaches, what the success criteria are, what's in scope). Ask via `AskUserQuestion`.\n\n### Discover in parallel BEFORE the first question\n\n\u003Cmandatory>\nBefore asking the FIRST interview question, the coordinator MUST fan out all discoverable facts in ONE message:\n\n- One `Explore` agent per orthogonal codebase concern\n- One `general-purpose` agent (claude-mem search) if the project has prior history\n- One `research-analyst` agent per named candidate library\u002Fframework\n\u003C\u002Fmandatory>\n\nAsking the user before exhausting parallel discovery is the **Question-before-discovery** anti-pattern (see `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fbounded-parallel-dispatch.md` Discovery domain, anti-pattern #14). The interview becomes lower-leverage when its `[Recommended]` options aren't grounded in evidence.\n\n### Synthesis → interview\n\nAfter parallel discovery returns:\n\n1. Mark each pre-identified question as **answered by discovery** (drop from interview) or **still needs user decision** (keep).\n2. For kept questions, derive `[Recommended]` from synthesis findings; never fabricate a recommendation without evidence.\n3. Run the interview in a single tight pass. Re-discover only if a user answer materially changes the search space.\n\nOnly ask what you cannot discover yourself.\n\n## Completion Signal Detection\n\nAfter each response, check for early completion signals using token-based matching:\n\n```text\ncompletionSignals = [\"done\", \"proceed\", \"skip\", \"enough\", \"that's all\", \"continue\", \"next\"]\n\ntokens = tokenize(userResponse.lower())  # split on whitespace\u002Fpunctuation\nfor signal in completionSignals:\n  if signal in tokens:  # exact token match, not substring\n    -> SKIP remaining questions, move to PROPOSE APPROACHES\n```\n\n## 3-Phase Overview\n\n### Phase 1: UNDERSTAND (Decision-Tree)\n\nRead all available context (.progress.md, prior artifacts, goal text). Build a question tree from the exploration territory with dependency ordering. Traverse the tree: auto-resolve codebase facts via exploration, ask user only about decisions. Each question leads with `[Recommended]` answer. No fixed question caps. Exit when all nodes resolved or user signals completion.\n\nSee `references\u002Falgorithm.md` for full pseudocode.\n\n### Phase 2: PROPOSE APPROACHES\n\nSynthesize dialogue into 2-3 distinct approaches. Each includes: name, description, trade-offs. Lead with recommendation. Present via AskUserQuestion. Maximum 3 approaches (more causes decision fatigue). Trade-offs must be honest. No straw-man alternatives.\n\nSee `references\u002Falgorithm.md` for full pseudocode.\n\n### Phase 3: CONFIRM & STORE\n\nBrief recap to user of key decisions and chosen approach. If user corrects something, update before storing. Store in .progress.md under Context Accumulator pattern.\n\nSee `references\u002Falgorithm.md` for full pseudocode.\n\n## Adaptive Depth (Other Responses)\n\nWhen user selects \"Other\": ask a context-specific follow-up (never generic \"elaborate\"). Reference what the user typed. Continue until clarity or 5 rounds. Do not increment askedCount for follow-ups.\n\nSee `references\u002Fexamples.md` for example follow-up patterns.\n\n## Context Accumulator Pattern\n\nAfter each interview, update `.progress.md`: read existing content, append new section under \"## Interview Responses\" with descriptive keys reflecting what was discussed. Include the chosen approach.\n\nSee `references\u002Fexamples.md` for storage format.\n\n## References\n\n- **`references\u002Falgorithm.md`** -- Full 3-phase pseudocode (UNDERSTAND decision-tree, PROPOSE APPROACHES, CONFIRM & STORE)\n- **`references\u002Fexamples.md`** -- Example interview questions, \"Other\" response handling, context storage format\n","# Interview Framework\n\nAdaptive brainstorming dialogue algorithm for all spec phases. Each phase command provides its own exploration territory (phase-specific areas to probe).\n\n## Option Limit Rule\n\nEach question must have 2-4 options (max 4). Keep the most relevant options, combine similar ones.\n\n## Recommendation Format\n\nEvery question asked via `AskUserQuestion` in Phase 1 leads with the recommended option (except when options are symmetric, in which case `[Recommended]` may be omitted):\n\n```yaml\nAskUserQuestion:\n  question: \"[Context-aware question referencing prior answers]. [One sentence rationale for the recommendation.]\"\n  options:\n    - \"[Recommended] [Option text -- the AI's suggested answer]\"\n    - \"[Alternative 1]\"\n    - \"[Alternative 2 if needed]\"\n    - \"Other\"\n```\n\nRules:\n- `[Recommended]` is a label prefix on the first option only.\n- The rationale sits in the question text, not the option label.\n- Option count still 2-4 max (Option Limit Rule preserved).\n- If there is no meaningful recommendation (truly symmetric choice), omit the `[Recommended]` label rather than placing it arbitrarily.\n\nExample:\n\n```yaml\nAskUserQuestion:\n  question: \"Where should the spec live? You only have one specs directory configured, so the default is fine unless you want to reorganize.\"\n  options:\n    - \"[Recommended] .\u002Fspecs\u002F (default)\"\n    - \"Let me configure a different path\"\n    - \"Other\"\n```\n\n## Parallel Codebase-First Discovery\n\nBefore asking ANY question, determine whether the answer is a **codebase fact**, a **prior-memory fact**, a **current-docs fact**, or a **user decision**:\n\n- **Codebase fact**: discoverable by reading code, config, or existing specs (e.g., which framework is used, whether an interface already exists, what a file currently does). Delegate to an `Explore` subagent. Never ask the user.\n- **Prior-memory fact**: discoverable by querying the user's claude-mem history (e.g., \"did we already decide on Postgres for this product?\", \"what stack did we pick last quarter?\"). Delegate to a `general-purpose` subagent invoking `mcp__plugin_claude-mem_mcp-search__*` tools. Never ask the user.\n- **Current-docs fact**: discoverable from official docs of a named library\u002Fframework\u002FSDK\u002FAPI (e.g., \"does node-pty support Windows?\", \"is OAuth-PKCE required for this provider?\"). Delegate to a `research-analyst` subagent (preferring Context7 MCP via its tool surface). Never ask the user.\n- **User decision**: a preference, priority, trade-off, or constraint that only the user can answer (e.g., which of two viable approaches, what the success criteria are, what's in scope). Ask via `AskUserQuestion`.\n\n### Discover in parallel BEFORE the first question\n\n\u003Cmandatory>\nBefore asking the FIRST interview question, the coordinator MUST fan out all discoverable facts in ONE message:\n\n- One `Explore` agent per orthogonal codebase concern\n- One `general-purpose` agent (claude-mem search) if the project has prior history\n- One `research-analyst` agent per named candidate library\u002Fframework\n\u003C\u002Fmandatory>\n\nAsking the user before exhausting parallel discovery is the **Question-before-discovery** anti-pattern (see `${CLAUDE_PLUGIN_ROOT}\u002Freferences\u002Fbounded-parallel-dispatch.md` Discovery domain, anti-pattern #14). The interview becomes lower-leverage when its `[Recommended]` options aren't grounded in evidence.\n\n### Synthesis → interview\n\nAfter parallel discovery returns:\n\n1. Mark each pre-identified question as **answered by discovery** (drop from interview) or **still needs user decision** (keep).\n2. For kept questions, derive `[Recommended]` from synthesis findings; never fabricate a recommendation without evidence.\n3. Run the interview in a single tight pass. Re-discover only if a user answer materially changes the search space.\n\nOnly ask what you cannot discover yourself.\n\n## Completion Signal Detection\n\nAfter each response, check for early completion signals using token-based matching:\n\n```text\ncompletionSignals = [\"done\", \"proceed\", \"skip\", \"enough\", \"that's all\", \"continue\", \"next\"]\n\ntokens = tokenize(userResponse.lower())  # split on whitespace\u002Fpunctuation\nfor signal in completionSignals:\n  if signal in tokens:  # exact token match, not substring\n    -> SKIP remaining questions, move to PROPOSE APPROACHES\n```\n\n## 3-Phase Overview\n\n### Phase 1: UNDERSTAND (Decision-Tree)\n\nRead all available context (.progress.md, prior artifacts, goal text). Build a question tree from the exploration territory with dependency ordering. Traverse the tree: auto-resolve codebase facts via exploration, ask user only about decisions. Each question leads with `[Recommended]` answer. No fixed question caps. Exit when all nodes resolved or user signals completion.\n\nSee `references\u002Falgorithm.md` for full pseudocode.\n\n### Phase 2: PROPOSE APPROACHES\n\nSynthesize dialogue into 2-3 distinct approaches. Each includes: name, description, trade-offs. Lead with recommendation. Present via AskUserQuestion. Maximum 3 approaches (more causes decision fatigue). Trade-offs must be honest. No straw-man alternatives.\n\nSee `references\u002Falgorithm.md` for full pseudocode.\n\n### Phase 3: CONFIRM & STORE\n\nBrief recap to user of key decisions and chosen approach. If user corrects something, update before storing. Store in .progress.md under Context Accumulator pattern.\n\nSee `references\u002Falgorithm.md` for full pseudocode.\n\n## Adaptive Depth (Other Responses)\n\nWhen user selects \"Other\": ask a context-specific follow-up (never generic \"elaborate\"). Reference what the user typed. Continue until clarity or 5 rounds. Do not increment askedCount for follow-ups.\n\nSee `references\u002Fexamples.md` for example follow-up patterns.\n\n## Context Accumulator Pattern\n\nAfter each interview, update `.progress.md`: read existing content, append new section under \"## Interview Responses\" with descriptive keys reflecting what was discussed. Include the chosen approach.\n\nSee `references\u002Fexamples.md` for storage format.\n\n## References\n\n- **`references\u002Falgorithm.md`** -- Full 3-phase pseudocode (UNDERSTAND decision-tree, PROPOSE APPROACHES, CONFIRM & STORE)\n- **`references\u002Fexamples.md`** -- Example interview questions, \"Other\" response handling, context storage format\n",{"name":5,"version":45,"description":7,"when_to_use":46,"user-invocable":41},"0.2.0","Use before research, requirements, design, tasks, or triage when user decisions are needed and codebase facts must be discovered before asking.","main","7357746802ae7a84cafa93b9dbffd138817b0290","plugins\u002Fcurdx-flow\u002Fskills\u002Finterview-framework",0,"https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow","https:\u002F\u002Fcurdx.org","https:\u002F\u002Fgithub.com\u002Fmugsun","📮 bydongxin@gmail.com","🧑‍💻 AI Builder & Software Engineer\r\n🚀 Turning ideas into software.          \r\n\r\n","2026-08-19 15:19:29",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add mugsun\u002Fcurdx-flow --skill interview-framework",{"tool":63,"command":64},"bunx","bunx skills add mugsun\u002Fcurdx-flow --skill interview-framework",{"tool":66,"command":67},"pnpm","pnpm dlx skills add mugsun\u002Fcurdx-flow --skill interview-framework","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Finterview-framework\u002FSKILL.md",true,[71,77],{"path":72,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Falgorithm.md","REFERENCE","参考文档",4396,"https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Finterview-framework\u002Freferences\u002Falgorithm.md",{"path":78,"resourceType":73,"resourceTypeDesc":74,"sizeBytes":79,"sourceHtmlUrl":80},"references\u002Fexamples.md",1886,"https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Finterview-framework\u002Freferences\u002Fexamples.md",[82,95,111,127,140,151],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":93,"publishedAt":40},"01M71KDR5EJP6G4VWFCHNJ35PT","help","Fixture help skill","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fruntime-readiness\u002Fclaude-code-plugin-like\u002Fskills\u002Fhelp\u002FSKILL.md",[88],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[84,94],"fixture",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":40},"01M71KDNAVB000W3MZB1W7CMD8","verification-before-completion","Use when checking fixes, phase exits, completion evidence, or mock-heavy tests before claiming success.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Fverification-before-completion\u002FSKILL.md",[],[102,103,104,28,29,30,105,106,107,108,32,109,110],"verification","verification before completion","only","phase","evidence","fixes","tests","mock","state",{"skillNo":112,"name":38,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":117,"publishedAt":40},"01M71KDKFE975GFYRDC21H1NEE","Use when a large feature should be decomposed into dependency-aware specs.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Ftriage\u002FSKILL.md",[116],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[38,118,119,120,121,122,123,124,125,29,32,126],"goal","true","feature","write","read","dependency","name","Bash","EPIC",{"skillNo":128,"name":30,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":133,"publishedAt":40},"01M71KDH7XFQJPKYZ0H9JDNSA5","Use when a spec has design.md and needs implementation tasks.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Ftasks\u002FSKILL.md",[132],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[30,134,135,124,136,32,137,27,138,29,125,122,121,139,119],"implementation","spec","task","standard","auto","edit",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":147,"publishedAt":40},"01M71KDEV9G51MCXDQWPJH7QST","switch","Use when changing the active spec by name or path.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Fswitch\u002FSKILL.md",[146],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[142,125,148,119,32,29,149,124,122,135,121,150],"by name","active","path",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":158,"publishedAt":40},"01M71KDDJFRV09YZ08B3WJ39SC","status","Use when inspecting curdx-flow specs, active state, progress, or index status.","https:\u002F\u002Fgithub.com\u002Fmugsun\u002Fcurdx-flow\u002Fblob\u002Fmain\u002Fplugins\u002Fcurdx-flow\u002Fskills\u002Fstatus\u002FSKILL.md",[157],{"categoryNo":89,"categoryName":90,"taxonomyType":91,"taxonomyTypeDesc":92},[153,119,32,29,125,110,159,149,160,122,31,161],"progress","update","index"]