[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CWJNMB8PM1D7ACXJD8SHMJ":3,"skill-same:01M6CWJNMB8PM1D7ACXJD8SHMJ":109},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6CWJNMB8PM1D7ACXJD8SHMJ","spec-strategy",null,"Create or update STRATEGY.md. Use when starting a product, changing direction or roadmap, or when spec-ideate, spec-brainstorm, or spec-plan need upstream product grounding.","leo-kuang-ai\u002Fspec-first","leo-kuang-ai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F8476392?v=4","01M6CWDM2YRT5M8C3G3QC3YGR5","leokuang","01M6CWDM6X46EFBXT1M1GDB5XC",111,"MIT","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36],"spec","strategy","spec strategy","create","update","product","metrics","ideate","plan","brainstorm","use","roadmap","upstream","2026-11-10 10:12:30",false,"---\nname: spec-strategy\ndescription: \"Create or update STRATEGY.md. Use when starting a product, changing direction or roadmap, or when spec-ideate, spec-brainstorm, or spec-plan need upstream product grounding.\"\nargument-hint: \"[optional: section to revisit, e.g. 'metrics' or 'approach']\"\n---\n\n# Product Strategy\n\nNote: Use the current date from the active host context. Use this when weighting external sources and dating artifacts.\n\n`spec-strategy` produces and maintains `STRATEGY.md` - a short, durable anchor document that captures what the product is, who it serves, how it succeeds, and where the team is investing. It lives at the repo root as a canonical, well-known file (peer of `README.md`). Downstream skills (`spec-ideate`, `spec-brainstorm`, `spec-plan`) read it as grounding when it exists.\n\nThe document is short and structured on purpose. Good answers to a handful of sharp questions produce a better strategy than any amount of prose. This skill asks those questions, pushes back on weak answers, and writes the doc.\n\n## Interaction Method\n\nDefault to the platform's blocking question tool: `AskUserQuestion` in Claude Code (call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded), `request_user_input` in Codex. Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.\n\nAsk one question at a time. Prefer free-form responses for the substantive sections (problem, approach, persona); reserve single-select for routing decisions (which section to revisit). Each option label must be self-contained.\n\n## Focus Hint\n\nInterpret the user's current request as an optional focus: a section name to revisit (`metrics`, `approach`, `tracks`) or a scope hint. With no focus, proceed open-ended and let the file state decide the path.\n\n## Core Principles\n\n1. **Anchor, not plan.** Strategy is what the product is and why. Features belong in `spec-brainstorm`; schedules belong in the issue tracker. Do not let either creep into the doc. When declining such creep, name the destination explicitly (`spec-brainstorm` for features, the issue tracker for schedules) — a bare refusal or a generic \"put it elsewhere\" leaves the owner without a route.\n2. **Rigor in the questions, not the headings.** The section headers are plain English. The interview questions enforce strategy discipline.\n3. **Short is a feature.** The template is constrained. Adding sections costs more than it looks like. Push back on expansion.\n4. **Durable across runs.** This skill is rerunnable. On a second run it updates in place, preserves what is working, and only challenges sections that look stale or weak.\n\n## Execution Flow\n\n### Phase 0: Route by File State\n\nRead `STRATEGY.md` using the native file-read tool.\n\n- **File does not exist** -> First run. Go to Phase 1.\n- **File exists and argument names a specific section** -> Targeted update. Go to Phase 2.\n- **File exists, no argument** -> Ask which section(s) to revisit, then Phase 2.\n\nAnnounce the path in one line: \"Strategy doc not found - let's write it.\" or \"Found existing strategy - let's review and update.\"\n\n### Phase 1: First-Run Interview\n\nRead `references\u002Finterview.md`. This load is non-optional - the pushback rules, anti-pattern examples, and quality bar for each section live there. Improvising from memory produces a passive transcription instead of a strategy doc.\n\nRun the interview in the section order of the final document:\n\n1. Target problem\n2. Our approach\n3. Who it's for\n4. Key metrics\n5. Tracks\n6. Milestones (optional)\n7. Not working on (optional)\n8. Marketing (optional)\n\nFor each section, ask the opening question, apply the pushback rules, and capture the final answer in the user's own language. Do not skip the pushback step - it is the core of the skill. Two rounds of pushback per section maximum; capture what the user has given after that and note the section is worth revisiting on the next run.\n\nWhen all required sections (1-5) are captured, read `references\u002Fstrategy-template.md`, fill it in, and present the full draft in chat before writing. Offer one round of edits. Then write to `STRATEGY.md`.\n\n### Phase 2: Update Run\n\nRead the existing `STRATEGY.md` thoroughly. Summarize current state in 3-5 lines so the user sees what is on file.\n\nIf the argument named a specific section, jump to that section in `references\u002Finterview.md`. Preserve all other sections exactly. Apply pushback as if this were a first run - do not rubber-stamp existing weak content just because it is already written.\n\nIf no specific target, ask the user which section to revisit using the blocking question tool. Options:\n\n- \"Target problem\"\n- \"Our approach\"\n- \"Who it's for\"\n- \"Metrics, tracks, or other\"\n\nFor each revisited section, re-interview with full pushback. For sections the user confirms are still accurate, leave them untouched. Update the `last_updated` value in the YAML frontmatter to today's ISO date.\n\nWrite the updated doc back to `STRATEGY.md`.\n\n### Phase 3: Downstream Handoff\n\nAfter writing, note in one line where the file lives and that `spec-ideate`, `spec-brainstorm`, and `spec-plan` will pick it up as grounding on their next run.\n\nIf no downstream skill has run yet on this repo, suggest `spec-ideate` or `spec-brainstorm` skills as a next step.\n\n## What This Skill Does Not Do\n\n- Does not update the issue tracker or reconcile in-flight work. Strategy is the doc; execution lives elsewhere.\n- Does not prioritize the backlog. Prioritization is a separate workflow.\n- Does not write product requirements or implementation plans - those are `spec-brainstorm` and `spec-plan`.\n- Does not compute metric values. It records which metrics matter and where they live, not what they read today.\n\n## Learn More\n\nThe \"Target problem \u002F Our approach \u002F Tracks\" structure is informed by Richard Rumelt's *Good Strategy Bad Strategy* - specifically his kernel of diagnosis, guiding policy, and coherent action. The interview questions in `references\u002Finterview.md` are designed to push past the patterns he calls \"bad strategy\": fluff, goals dressed up as strategy, and feature lists in place of a guiding choice. The book is the recommended follow-up reading if the distinction between a slogan and a strategy is not yet sharp.\n","# Product Strategy\n\nNote: Use the current date from the active host context. Use this when weighting external sources and dating artifacts.\n\n`spec-strategy` produces and maintains `STRATEGY.md` - a short, durable anchor document that captures what the product is, who it serves, how it succeeds, and where the team is investing. It lives at the repo root as a canonical, well-known file (peer of `README.md`). Downstream skills (`spec-ideate`, `spec-brainstorm`, `spec-plan`) read it as grounding when it exists.\n\nThe document is short and structured on purpose. Good answers to a handful of sharp questions produce a better strategy than any amount of prose. This skill asks those questions, pushes back on weak answers, and writes the doc.\n\n## Interaction Method\n\nDefault to the platform's blocking question tool: `AskUserQuestion` in Claude Code (call `ToolSearch` with `select:AskUserQuestion` first if its schema isn't loaded), `request_user_input` in Codex. Fall back to numbered options in chat only when no blocking tool exists in the harness or the call errors (e.g., Codex edit modes) — not because a schema load is required. Never silently skip the question.\n\nAsk one question at a time. Prefer free-form responses for the substantive sections (problem, approach, persona); reserve single-select for routing decisions (which section to revisit). Each option label must be self-contained.\n\n## Focus Hint\n\nInterpret the user's current request as an optional focus: a section name to revisit (`metrics`, `approach`, `tracks`) or a scope hint. With no focus, proceed open-ended and let the file state decide the path.\n\n## Core Principles\n\n1. **Anchor, not plan.** Strategy is what the product is and why. Features belong in `spec-brainstorm`; schedules belong in the issue tracker. Do not let either creep into the doc. When declining such creep, name the destination explicitly (`spec-brainstorm` for features, the issue tracker for schedules) — a bare refusal or a generic \"put it elsewhere\" leaves the owner without a route.\n2. **Rigor in the questions, not the headings.** The section headers are plain English. The interview questions enforce strategy discipline.\n3. **Short is a feature.** The template is constrained. Adding sections costs more than it looks like. Push back on expansion.\n4. **Durable across runs.** This skill is rerunnable. On a second run it updates in place, preserves what is working, and only challenges sections that look stale or weak.\n\n## Execution Flow\n\n### Phase 0: Route by File State\n\nRead `STRATEGY.md` using the native file-read tool.\n\n- **File does not exist** -> First run. Go to Phase 1.\n- **File exists and argument names a specific section** -> Targeted update. Go to Phase 2.\n- **File exists, no argument** -> Ask which section(s) to revisit, then Phase 2.\n\nAnnounce the path in one line: \"Strategy doc not found - let's write it.\" or \"Found existing strategy - let's review and update.\"\n\n### Phase 1: First-Run Interview\n\nRead `references\u002Finterview.md`. This load is non-optional - the pushback rules, anti-pattern examples, and quality bar for each section live there. Improvising from memory produces a passive transcription instead of a strategy doc.\n\nRun the interview in the section order of the final document:\n\n1. Target problem\n2. Our approach\n3. Who it's for\n4. Key metrics\n5. Tracks\n6. Milestones (optional)\n7. Not working on (optional)\n8. Marketing (optional)\n\nFor each section, ask the opening question, apply the pushback rules, and capture the final answer in the user's own language. Do not skip the pushback step - it is the core of the skill. Two rounds of pushback per section maximum; capture what the user has given after that and note the section is worth revisiting on the next run.\n\nWhen all required sections (1-5) are captured, read `references\u002Fstrategy-template.md`, fill it in, and present the full draft in chat before writing. Offer one round of edits. Then write to `STRATEGY.md`.\n\n### Phase 2: Update Run\n\nRead the existing `STRATEGY.md` thoroughly. Summarize current state in 3-5 lines so the user sees what is on file.\n\nIf the argument named a specific section, jump to that section in `references\u002Finterview.md`. Preserve all other sections exactly. Apply pushback as if this were a first run - do not rubber-stamp existing weak content just because it is already written.\n\nIf no specific target, ask the user which section to revisit using the blocking question tool. Options:\n\n- \"Target problem\"\n- \"Our approach\"\n- \"Who it's for\"\n- \"Metrics, tracks, or other\"\n\nFor each revisited section, re-interview with full pushback. For sections the user confirms are still accurate, leave them untouched. Update the `last_updated` value in the YAML frontmatter to today's ISO date.\n\nWrite the updated doc back to `STRATEGY.md`.\n\n### Phase 3: Downstream Handoff\n\nAfter writing, note in one line where the file lives and that `spec-ideate`, `spec-brainstorm`, and `spec-plan` will pick it up as grounding on their next run.\n\nIf no downstream skill has run yet on this repo, suggest `spec-ideate` or `spec-brainstorm` skills as a next step.\n\n## What This Skill Does Not Do\n\n- Does not update the issue tracker or reconcile in-flight work. Strategy is the doc; execution lives elsewhere.\n- Does not prioritize the backlog. Prioritization is a separate workflow.\n- Does not write product requirements or implementation plans - those are `spec-brainstorm` and `spec-plan`.\n- Does not compute metric values. It records which metrics matter and where they live, not what they read today.\n\n## Learn More\n\nThe \"Target problem \u002F Our approach \u002F Tracks\" structure is informed by Richard Rumelt's *Good Strategy Bad Strategy* - specifically his kernel of diagnosis, guiding policy, and coherent action. The interview questions in `references\u002Finterview.md` are designed to push past the patterns he calls \"bad strategy\": fluff, goals dressed up as strategy, and feature lists in place of a guiding choice. The book is the recommended follow-up reading if the distinction between a slogan and a strategy is not yet sharp.\n",{"name":5,"description":7,"argument-hint":42},"[optional: section to revisit, e.g. 'metrics' or 'approach']","master","74655dc86b1270bb52239e0f8bc9517de7a7071c","skills\u002Fspec-strategy",13,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first","http:\u002F\u002Fspec-first.cn\u002F","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai","作为一个初学者或者进阶者，这并没有什么错。当一个有能力的程序员而不是领导者，这也没有什么错。真正的错误是，当你知道应该如何去提高时仍然选择做一名初学者。","2026-11-05 13:30:55",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add leo-kuang-ai\u002Fspec-first --skill spec-strategy",{"tool":58,"command":59},"bunx","bunx skills add leo-kuang-ai\u002Fspec-first --skill spec-strategy",{"tool":61,"command":62},"pnpm","pnpm dlx skills add leo-kuang-ai\u002Fspec-first --skill spec-strategy","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002FSKILL.md",true,[66,72,76,80,84,87,91,95,101,105],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"evals\u002Fcases\u002Fexisting-asks-which-section.yaml","REFERENCE","参考文档",703,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002Fevals\u002Fcases\u002Fexisting-asks-which-section.yaml",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":74,"sourceHtmlUrl":75},"evals\u002Fcases\u002Ffeatures-route-to-brainstorm.yaml",757,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002Fevals\u002Fcases\u002Ffeatures-route-to-brainstorm.yaml",{"path":77,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":78,"sourceHtmlUrl":79},"evals\u002Fcases\u002Ffirst-run-interview-asks.yaml",569,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002Fevals\u002Fcases\u002Ffirst-run-interview-asks.yaml",{"path":81,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":82,"sourceHtmlUrl":83},"evals\u002Fcases\u002Ftargeted-update-metrics.yaml",708,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002Fevals\u002Fcases\u002Ftargeted-update-metrics.yaml",{"path":85,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":82,"sourceHtmlUrl":86},"evals\u002Fcases\u002Fupdate-reads-existing-doc.yaml","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002Fevals\u002Fcases\u002Fupdate-reads-existing-doc.yaml",{"path":88,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":89,"sourceHtmlUrl":90},"evals\u002Feval.yaml",520,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002Fevals\u002Feval.yaml",{"path":92,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":93,"sourceHtmlUrl":94},"evals\u002Ffixtures\u002Frepos\u002Fexisting-strategy\u002FSTRATEGY.md",470,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002Fevals\u002Ffixtures\u002Frepos\u002Fexisting-strategy\u002FSTRATEGY.md",{"path":96,"resourceType":97,"resourceTypeDesc":98,"sizeBytes":99,"sourceHtmlUrl":100},"evals\u002Ffixtures\u002Fscripts\u002Fasks-a-question.sh","SCRIPT","脚本",1232,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002Fevals\u002Ffixtures\u002Fscripts\u002Fasks-a-question.sh",{"path":102,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Finterview.md",10729,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002Freferences\u002Finterview.md",{"path":106,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fstrategy-template.md",3038,"https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-strategy\u002Freferences\u002Fstrategy-template.md",[110,143,164,178,192,212],{"skillNo":111,"name":112,"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":124,"publishedAt":37},"01M6CWKQCYJXDCW4MEF3FSJE26","using-spec-first","Standalone entry governor for spec-first. Use before substantial work in a spec-first repo or when the user asks what to run next; choose one public `spec-*` workflow, standalone skill, terminal command, or Direct Lane. Do not use to reroute active public workflows or bounded workers, or for lightweight facts, current-context explanations, narrow lookups, user-supplied single-document cleanup, or clearly scoped low-risk edits.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fusing-spec-first\u002FSKILL.md",[116,121],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000030","开发工程师",[24,125,126,127,128,129,130,131,34,132,133,134,135,136,137,138,139,140,141,142],"first","using spec first","terminal","work","active","next","do","context","command","repo","choose","direct","risk","lane","run","cleanup","workflows","workflow",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":150,"publishedAt":37},"01M6CWKK43ZJKQXKVJB3BWWPR1","spec-write-tasks","Public workflow entrypoint (spec-write-tasks): compile a settled local spec-plan into an optional derived task pack for spec-work, or validate an existing local task pack before execution. Use for explicit plan-splitting\u002Ftask-doc requests or high-complexity work suitability; do not use for plan authoring, implementation execution, unresolved scope, small low-risk plans, progress\u002Fapproval state, remote\u002Fgeneric task lists, or generated runtime mirror edits. Keep the plan as single source of truth; tasks are derived and optional.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-tasks\u002FSKILL.md",[149],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},[24,151,152,153,154,155,131,156,157,34,158,128,32,159,137,160,161,162,142,163],"tasks","write","spec write tasks","local","task","complexity","plan authoring","generated","doc","execution","compile","validate","state",{"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":171,"publishedAt":37},"01M6CWKEK6CVPQW8EMCNSDPHBJ","spec-write-skill","公开 workflow：创建、修改或迁移项目拥有的 Agent Skill package，或对现有\u002F外部 package 做用户明确要求、零执行的只读验证与 readiness 报告时使用；也用于按已接受的 audit finding 修复 source skill。不要用于一次性回答、解释\u002F总结\u002F翻译、普通代码 review、第三方 Skill 纯安装或导入、跨仓批量修改，或直接修补 generated runtime mirrors。","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-write-skill\u002FSKILL.md",[170],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},[172,24,152,173,174,158,175,176,142,177],"spec write skill","write skill","audit","翻译","package","review",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":184,"publishedAt":37},"01M6CWKBDEZ7QFF1ZH3DP52SHA","spec-worktree","Internal helper for caller-owned git worktree isolation. Governed callers are spec-dogfood and spec-work; every caller must provide the forward invocation and intake contract.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-worktree\u002FSKILL.md",[],[24,185,186,187,188,189,190,128,191],"worktree","spec worktree","intake","git","Bash","dogfood","git worktree",{"skillNo":193,"name":194,"nameZh":6,"description":195,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":196,"categories":197,"keywords":199,"publishedAt":37},"01M6CWK5W4VREMNXGQQKXXSQ3N","spec-work","Execute a settled plan, validated task pack, spec path, or concrete implementation request end-to-end. Use spec-debug for open-ended bugs; stop when target repo, scope, source ownership, or required authorization is unresolved. Not for explicitly requested GitHub PR-review-feedback handling — route those to spec-resolve-pr-feedback.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-work\u002FSKILL.md",[198],{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},[128,200,24,201,202,203,204,205,155,206,207,208,34,134,209,210,32,211,159,177],"spec work","stop","github","to spec","debug","route","github pr","implementation","auto","pr","feedback","open",{"skillNo":213,"name":214,"nameZh":6,"description":215,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":216,"categories":217,"keywords":223,"publishedAt":37},"01M6CWK1MFTSNV9MYD4C8WGB8B","spec-test-xcode","Build and test iOS apps on simulator using XcodeBuildMCP. Use after making iOS code changes, before creating a PR, or when verifying app behavior and checking for crashes on simulator.","https:\u002F\u002Fgithub.com\u002Fleo-kuang-ai\u002Fspec-first\u002Fblob\u002Fmaster\u002Fskills\u002Fspec-test-xcode\u002FSKILL.md",[218,221,222],{"categoryNo":219,"categoryName":220,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},{"categoryNo":122,"categoryName":123,"taxonomyType":21,"taxonomyTypeDesc":22},[24,224,225,209,226,227,228,229,34,230,231],"test","spec test xcode","code","ios","build and test","behavior","default","build"]