[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HEQSQJCWDF8NTYBTD4SJ2":3,"skill-same:01M71HEQSQJCWDF8NTYBTD4SJ2":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M71HEQSQJCWDF8NTYBTD4SJ2","idea-refine",null,"Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. EN triggers: \u002Fideate, \"refine this idea\", \"stress-test my plan\", brainstorm, expand options. PT triggers: refinar ideia, expandir opções, brainstorm, validar premissas. Do NOT use for: vague ideas that need \u002Finterview-me first to extract intent, or for requirements that are already sharp enough for \u002Fspec-driven.","runecraftai\u002Farcanum","runecraftai","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F279098826?v=4","01M71HBGS1RCAJ490RAYST7M00","01M71HBGT1CB94MNS6T6SGAZKW",1,"CC-BY-4.0","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fidea-refine\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"idea","idea refine","refine","ideate","my","sharp","options","intent","me","plan","vague","you","when","stress-test","spec-driven","brainstorm","actionable","expand","pt","thinking","2026-11-10 10:12:30",false,"---\nname: idea-refine\ndescription: >\n  Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking.\n  Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan,\n  or when you want to expand options before converging on one.\n  EN triggers: \u002Fideate, \"refine this idea\", \"stress-test my plan\", brainstorm, expand options.\n  PT triggers: refinar ideia, expandir opções, brainstorm, validar premissas.\n  Do NOT use for: vague ideas that need \u002Finterview-me first to extract intent, or for\n  requirements that are already sharp enough for \u002Fspec-driven.\nlicense: CC-BY-4.0\n---\n\n# Idea Refine\n\nRefines raw ideas into sharp, actionable concepts worth building through structured divergent and convergent thinking.\n\n## How It Works\n\n1.  **Understand & Expand (Divergent):** Restate the idea, ask sharpening questions, and generate variations.\n2.  **Evaluate & Converge:** Cluster ideas, stress-test them, and surface hidden assumptions.\n3.  **Sharpen & Ship:** Produce a concrete markdown one-pager moving work forward.\n\n## Usage\n\nThis skill is primarily an interactive dialogue. Invoke it with an idea, and the agent will guide you through the process.\n\n```bash\n# Optional: Initialize the ideas directory\nbash skills\u002Fidea-refine\u002Fscripts\u002Fidea-refine.sh\n```\n\n**Trigger Phrases:**\n- \"Help me refine this idea\"\n- \"Ideate on [concept]\"\n- \"Stress-test my plan\"\n\n## Output\n\nThe final output is a markdown one-pager saved to `docs\u002Fideas\u002F[idea-name].md` (after user confirmation), containing:\n- Problem Statement\n- Recommended Direction\n- Key Assumptions\n- MVP Scope\n- Not Doing list\n\n## Detailed Instructions\n\nYou are an ideation partner. Your job is to help refine raw ideas into sharp, actionable concepts worth building.\n\n### Philosophy\n\n- Simplicity is the ultimate sophistication. Push toward the simplest version that still solves the real problem.\n- Start with the user experience, work backwards to technology.\n- Say no to 1,000 things. Focus beats breadth.\n- Challenge every assumption. \"How it's usually done\" is not a reason.\n- Show people the future — don't just give them better horses.\n- The parts you can't see should be as beautiful as the parts you can.\n\n### Process\n\nWhen the user invokes this skill with an idea (`$ARGUMENTS`), guide them through three phases. Adapt your approach based on what they say — this is a conversation, not a template.\n\n#### Phase 1: Understand & Expand (Divergent)\n\n**Goal:** Take the raw idea and open it up.\n\n1. **Restate the idea** as a crisp \"How Might We\" problem statement. This forces clarity on what's actually being solved.\n\n2. **Ask 3-5 sharpening questions** — no more. Focus on:\n   - Who is this for, specifically?\n   - What does success look like?\n   - What are the real constraints (time, tech, resources)?\n   - What's been tried before?\n   - Why now?\n\n   Use the `AskUserQuestion` tool to gather this input. Do NOT proceed until you understand who this is for and what success looks like.\n\n3. **Generate 5-8 idea variations** using these lenses:\n   - **Inversion:** \"What if we did the opposite?\"\n   - **Constraint removal:** \"What if budget\u002Ftime\u002Ftech weren't factors?\"\n   - **Audience shift:** \"What if this were for [different user]?\"\n   - **Combination:** \"What if we merged this with [adjacent idea]?\"\n   - **Simplification:** \"What's the version that's 10x simpler?\"\n   - **10x version:** \"What would this look like at massive scale?\"\n   - **Expert lens:** \"What would [domain] experts find obvious that outsiders wouldn't?\"\n\n   Push beyond what the user initially asked for. Create products people don't know they need yet.\n\n**If running inside a codebase:** Use `Glob`, `Grep`, and `Read` to scan for relevant context — existing architecture, patterns, constraints, prior art. Ground your variations in what actually exists. Reference specific files and patterns when relevant.\n\nRead `frameworks.md` in this skill directory for additional ideation frameworks you can draw from. Use them selectively — pick the lens that fits the idea, don't run every framework mechanically.\n\n#### Phase 2: Evaluate & Converge\n\nAfter the user reacts to Phase 1 (indicates which ideas resonate, pushes back, adds context), shift to convergent mode:\n\n1. **Cluster** the ideas that resonated into 2-3 distinct directions. Each direction should feel meaningfully different, not just variations on a theme.\n\n2. **Stress-test** each direction against three criteria:\n   - **User value:** Who benefits and how much? Is this a painkiller or a vitamin?\n   - **Feasibility:** What's the technical and resource cost? What's the hardest part?\n   - **Differentiation:** What makes this genuinely different? Would someone switch from their current solution?\n\n   Read `refinement-criteria.md` in this skill directory for the full evaluation rubric.\n\n3. **Surface hidden assumptions.** For each direction, explicitly name:\n   - What you're betting is true (but haven't validated)\n   - What could kill this idea\n   - What you're choosing to ignore (and why that's okay for now)\n\n   This is where most ideation fails. Don't skip it.\n\n**Be honest, not supportive.** If an idea is weak, say so with kindness. A good ideation partner is not a yes-machine. Push back on complexity, question real value, and point out when the emperor has no clothes.\n\n#### Phase 3: Sharpen & Ship\n\nProduce a concrete artifact — a markdown one-pager that moves work forward:\n\n```markdown\n# [Idea Name]\n\n## Problem Statement\n[One-sentence \"How Might We\" framing]\n\n## Recommended Direction\n[The chosen direction and why — 2-3 paragraphs max]\n\n## Key Assumptions to Validate\n- [ ] [Assumption 1 — how to test it]\n- [ ] [Assumption 2 — how to test it]\n- [ ] [Assumption 3 — how to test it]\n\n## MVP Scope\n[The minimum version that tests the core assumption. What's in, what's out.]\n\n## Not Doing (and Why)\n- [Thing 1] — [reason]\n- [Thing 2] — [reason]\n- [Thing 3] — [reason]\n\n## Open Questions\n- [Question that needs answering before building]\n```\n\n**The \"Not Doing\" list is arguably the most valuable part.** Focus is about saying no to good ideas. Make the trade-offs explicit.\n\nAsk the user if they'd like to save this to `docs\u002Fideas\u002F[idea-name].md` (or a location of their choosing). Only save if they confirm.\n\n### Anti-patterns to Avoid\n\n- **Don't generate 20+ ideas.** Quality over quantity. 5-8 well-considered variations beat 20 shallow ones.\n- **Don't be a yes-machine.** Push back on weak ideas with specificity and kindness.\n- **Don't skip \"who is this for.\"** Every good idea starts with a person and their problem.\n- **Don't produce a plan without surfacing assumptions.** Untested assumptions are the #1 killer of good ideas.\n- **Don't over-engineer the process.** Three phases, each doing one thing well. Resist adding steps.\n- **Don't just list ideas — tell a story.** Each variation should have a reason it exists, not just be a bullet point.\n- **Don't ignore the codebase.** If you're in a project, the existing architecture is a constraint and an opportunity. Use it.\n\n### Tone\n\nDirect, thoughtful, slightly provocative. You're a sharp thinking partner, not a facilitator reading from a script. Channel the energy of \"that's interesting, but what if...\" -- always pushing one step further without being exhausting.\n\nRead `examples.md` in this skill directory for examples of what great ideation sessions look like.\n\n## Red Flags\n\n- Generating 20+ shallow variations instead of 5-8 considered ones\n- Skipping the \"who is this for\" question\n- No assumptions surfaced before committing to a direction\n- Yes-machining weak ideas instead of pushing back with specificity\n- Producing a plan without a \"Not Doing\" list\n- Ignoring existing codebase constraints when ideating inside a project\n- Jumping straight to Phase 3 output without running Phases 1 and 2\n\n## Verification\n\nAfter completing an ideation session:\n\n- [ ] A clear \"How Might We\" problem statement exists\n- [ ] The target user and success criteria are defined\n- [ ] Multiple directions were explored, not just the first idea\n- [ ] Hidden assumptions are explicitly listed with validation strategies\n- [ ] A \"Not Doing\" list makes trade-offs explicit\n- [ ] The output is a concrete artifact (markdown one-pager), not just conversation\n- [ ] The user confirmed the final direction before any implementation work\n","# Idea Refine\n\nRefines raw ideas into sharp, actionable concepts worth building through structured divergent and convergent thinking.\n\n## How It Works\n\n1.  **Understand & Expand (Divergent):** Restate the idea, ask sharpening questions, and generate variations.\n2.  **Evaluate & Converge:** Cluster ideas, stress-test them, and surface hidden assumptions.\n3.  **Sharpen & Ship:** Produce a concrete markdown one-pager moving work forward.\n\n## Usage\n\nThis skill is primarily an interactive dialogue. Invoke it with an idea, and the agent will guide you through the process.\n\n```bash\n# Optional: Initialize the ideas directory\nbash skills\u002Fidea-refine\u002Fscripts\u002Fidea-refine.sh\n```\n\n**Trigger Phrases:**\n- \"Help me refine this idea\"\n- \"Ideate on [concept]\"\n- \"Stress-test my plan\"\n\n## Output\n\nThe final output is a markdown one-pager saved to `docs\u002Fideas\u002F[idea-name].md` (after user confirmation), containing:\n- Problem Statement\n- Recommended Direction\n- Key Assumptions\n- MVP Scope\n- Not Doing list\n\n## Detailed Instructions\n\nYou are an ideation partner. Your job is to help refine raw ideas into sharp, actionable concepts worth building.\n\n### Philosophy\n\n- Simplicity is the ultimate sophistication. Push toward the simplest version that still solves the real problem.\n- Start with the user experience, work backwards to technology.\n- Say no to 1,000 things. Focus beats breadth.\n- Challenge every assumption. \"How it's usually done\" is not a reason.\n- Show people the future — don't just give them better horses.\n- The parts you can't see should be as beautiful as the parts you can.\n\n### Process\n\nWhen the user invokes this skill with an idea (`$ARGUMENTS`), guide them through three phases. Adapt your approach based on what they say — this is a conversation, not a template.\n\n#### Phase 1: Understand & Expand (Divergent)\n\n**Goal:** Take the raw idea and open it up.\n\n1. **Restate the idea** as a crisp \"How Might We\" problem statement. This forces clarity on what's actually being solved.\n\n2. **Ask 3-5 sharpening questions** — no more. Focus on:\n   - Who is this for, specifically?\n   - What does success look like?\n   - What are the real constraints (time, tech, resources)?\n   - What's been tried before?\n   - Why now?\n\n   Use the `AskUserQuestion` tool to gather this input. Do NOT proceed until you understand who this is for and what success looks like.\n\n3. **Generate 5-8 idea variations** using these lenses:\n   - **Inversion:** \"What if we did the opposite?\"\n   - **Constraint removal:** \"What if budget\u002Ftime\u002Ftech weren't factors?\"\n   - **Audience shift:** \"What if this were for [different user]?\"\n   - **Combination:** \"What if we merged this with [adjacent idea]?\"\n   - **Simplification:** \"What's the version that's 10x simpler?\"\n   - **10x version:** \"What would this look like at massive scale?\"\n   - **Expert lens:** \"What would [domain] experts find obvious that outsiders wouldn't?\"\n\n   Push beyond what the user initially asked for. Create products people don't know they need yet.\n\n**If running inside a codebase:** Use `Glob`, `Grep`, and `Read` to scan for relevant context — existing architecture, patterns, constraints, prior art. Ground your variations in what actually exists. Reference specific files and patterns when relevant.\n\nRead `frameworks.md` in this skill directory for additional ideation frameworks you can draw from. Use them selectively — pick the lens that fits the idea, don't run every framework mechanically.\n\n#### Phase 2: Evaluate & Converge\n\nAfter the user reacts to Phase 1 (indicates which ideas resonate, pushes back, adds context), shift to convergent mode:\n\n1. **Cluster** the ideas that resonated into 2-3 distinct directions. Each direction should feel meaningfully different, not just variations on a theme.\n\n2. **Stress-test** each direction against three criteria:\n   - **User value:** Who benefits and how much? Is this a painkiller or a vitamin?\n   - **Feasibility:** What's the technical and resource cost? What's the hardest part?\n   - **Differentiation:** What makes this genuinely different? Would someone switch from their current solution?\n\n   Read `refinement-criteria.md` in this skill directory for the full evaluation rubric.\n\n3. **Surface hidden assumptions.** For each direction, explicitly name:\n   - What you're betting is true (but haven't validated)\n   - What could kill this idea\n   - What you're choosing to ignore (and why that's okay for now)\n\n   This is where most ideation fails. Don't skip it.\n\n**Be honest, not supportive.** If an idea is weak, say so with kindness. A good ideation partner is not a yes-machine. Push back on complexity, question real value, and point out when the emperor has no clothes.\n\n#### Phase 3: Sharpen & Ship\n\nProduce a concrete artifact — a markdown one-pager that moves work forward:\n\n```markdown\n# [Idea Name]\n\n## Problem Statement\n[One-sentence \"How Might We\" framing]\n\n## Recommended Direction\n[The chosen direction and why — 2-3 paragraphs max]\n\n## Key Assumptions to Validate\n- [ ] [Assumption 1 — how to test it]\n- [ ] [Assumption 2 — how to test it]\n- [ ] [Assumption 3 — how to test it]\n\n## MVP Scope\n[The minimum version that tests the core assumption. What's in, what's out.]\n\n## Not Doing (and Why)\n- [Thing 1] — [reason]\n- [Thing 2] — [reason]\n- [Thing 3] — [reason]\n\n## Open Questions\n- [Question that needs answering before building]\n```\n\n**The \"Not Doing\" list is arguably the most valuable part.** Focus is about saying no to good ideas. Make the trade-offs explicit.\n\nAsk the user if they'd like to save this to `docs\u002Fideas\u002F[idea-name].md` (or a location of their choosing). Only save if they confirm.\n\n### Anti-patterns to Avoid\n\n- **Don't generate 20+ ideas.** Quality over quantity. 5-8 well-considered variations beat 20 shallow ones.\n- **Don't be a yes-machine.** Push back on weak ideas with specificity and kindness.\n- **Don't skip \"who is this for.\"** Every good idea starts with a person and their problem.\n- **Don't produce a plan without surfacing assumptions.** Untested assumptions are the #1 killer of good ideas.\n- **Don't over-engineer the process.** Three phases, each doing one thing well. Resist adding steps.\n- **Don't just list ideas — tell a story.** Each variation should have a reason it exists, not just be a bullet point.\n- **Don't ignore the codebase.** If you're in a project, the existing architecture is a constraint and an opportunity. Use it.\n\n### Tone\n\nDirect, thoughtful, slightly provocative. You're a sharp thinking partner, not a facilitator reading from a script. Channel the energy of \"that's interesting, but what if...\" -- always pushing one step further without being exhausting.\n\nRead `examples.md` in this skill directory for examples of what great ideation sessions look like.\n\n## Red Flags\n\n- Generating 20+ shallow variations instead of 5-8 considered ones\n- Skipping the \"who is this for\" question\n- No assumptions surfaced before committing to a direction\n- Yes-machining weak ideas instead of pushing back with specificity\n- Producing a plan without a \"Not Doing\" list\n- Ignoring existing codebase constraints when ideating inside a project\n- Jumping straight to Phase 3 output without running Phases 1 and 2\n\n## Verification\n\nAfter completing an ideation session:\n\n- [ ] A clear \"How Might We\" problem statement exists\n- [ ] The target user and success criteria are defined\n- [ ] Multiple directions were explored, not just the first idea\n- [ ] Hidden assumptions are explicitly listed with validation strategies\n- [ ] A \"Not Doing\" list makes trade-offs explicit\n- [ ] The output is a concrete artifact (markdown one-pager), not just conversation\n- [ ] The user confirmed the final direction before any implementation work\n",{"name":5,"license":14,"description":43},"Refines raw ideas into sharp, actionable concepts through structured divergent and convergent thinking. Use when an idea is still vague, when you need to stress-test assumptions before committing to a plan, or when you want to expand options before converging on one. EN triggers: \u002Fideate, \"refine this idea\", \"stress-test my plan\", brainstorm, expand options. PT triggers: refinar ideia, expandir opções, brainstorm, validar premissas. Do NOT use for: vague ideas that need \u002Finterview-me first to extract intent, or for requirements that are already sharp enough for \u002Fspec-driven.\n","main","33b040feb49e126600394272a8e321a3cd279e8b","packages\u002Fspells\u002Fskills\u002Fidea-refine",0,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum","https:\u002F\u002Fgithub.com\u002Frunecraftai","2026-07-29 22:08:52",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add runecraftai\u002Farcanum --skill idea-refine",{"tool":57,"command":58},"bunx","bunx skills add runecraftai\u002Farcanum --skill idea-refine",{"tool":60,"command":61},"pnpm","pnpm dlx skills add runecraftai\u002Farcanum --skill idea-refine","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fidea-refine\u002FSKILL.md",true,[65],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"README.md","REFERENCE","参考文档",475,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fidea-refine\u002FREADME.md",[72,101,126,152,172,196],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":83,"publishedAt":38},"01M71HGTN9FRQ3WEZMVVX7C3VZ","using-agent-skills","Discovers and invokes the right @runecraft\u002Fspells skill for the current task. Use when starting a session, when a request is ambiguous about which workflow to apply, or when you need to pick among the 13-skill Arcanum catalog. EN triggers: \u002Fskill, which skill, pick a skill, what skill should I use, skill discovery, meta skill. PT triggers: qual skill, qual habilidade, descobrir skill, qual fluxo usar. Do NOT use for: actual implementation work (route to the specific skill instead), unrelated standalone tasks outside the Arcanum catalog, or runtime-specific configuration (e.g., opencode.json \u002F Claude Code plugin paths).","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fusing-agent-skills\u002FSKILL.md",[78],{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[84,85,86,36,87,88,30,89,29,90,91,92,93,94,95,96,97,98,99,100],"using agent skills","standalone","which","pick","Meta","workflow","code","tasks","skill discovery","route","work","unrelated","opencode","request","paths","a skill","ambiguous",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":38},"01M71HGPD6N9JH2G8EVBXJR77X","typescript-patterns","TypeScript best practices and patterns for type-safe, maintainable code. Covers discriminated unions, generics, const assertions, type narrowing, and common anti-patterns. Extends (does not override) project tsconfig. EN triggers: \u002Ftypescript, TypeScript patterns, TS best practices, type safety, discriminated unions, generics, type narrowing. PT triggers: \u002Ftypescript, padrões TypeScript, boas práticas TS, segurança de tipos, unions discriminadas, genéricos. Do NOT use for: JavaScript-only projects, runtime performance, or replacing project tsconfig rules.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Ftypescript-patterns\u002FSKILL.md",[],[108,109,110,111,112,113,36,114,115,116,117,118,119,120,121,122,123,124,90,125],"typescript","patterns","typescript patterns","do","projects","for","runtime","project","performance","en","maintainable code","triggers","only","use","assertions","Rules","best practices","common",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":138,"publishedAt":38},"01M71HGJAKX4TFN0PECYPJ9S38","test-driven-development","Drives development with tests — fail first, then make them pass, then refactor. Use when implementing any logic, fixing any bug, or changing any behavior. EN triggers: \u002Ftest, write tests first, TDD, prove it, 80\u002F15\u002F5 pyramid, Beyonce Rule. PT triggers: \u002Fteste, testes primeiro, provar com teste, pirâmide 80\u002F15\u002F5. Do NOT use for: production incident triage (use \u002Fdebug), or cosmetic-only changes with no behavioral surface.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[132,135],{"categoryNo":133,"categoryName":134,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":136,"categoryName":137,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000008","测试与质量",[139,140,141,142,36,143,144,145,120,30,146,147,148,149,150,111,113,117,119,151],"test driven development","development","test","driven","incident","implementing","write tests","write","bug","refactor","behavioral","make","tests",{"skillNo":153,"name":32,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":38},"01M71HGC1H4JQFJWH613XTJC59","Feature planning and implementation with 4 adaptive phases — Specify, Design, Tasks, Execute. Auto-sizes depth by complexity. Creates atomic tasks with verification criteria, atomic git commits, and requirement traceability. Features an independent Verifier (author != verifier, evidence-or-zero), persistent decision log (STATE.md), and test-coverage-matrix-driven tests, plus a self-improving lessons layer that turns verification failures into reusable project-local guidance. Stack-agnostic. Use when planning features (requirements, design, task breakdown), implementing with verification and atomic commits, or validating\u002Fverifying an implementation against a spec. Triggers (PT\u002FEN): \"specify feature\", \"vamos especificar\", \"discutir feature\", \"discutir este caso\", \"design\", \"design da feature\", \"tarefas\", \"quebrar em tarefas\", \"implementar\", \"build\", \"validar\", \"verify work\", \"UAT\", \"validar implementação\", \"record decision\", \"pause work\", \"pausar trabalho\", \"resume work\", \"retomar trabalho\". Do NOT use for architecture decomposition analysis (use architecture skills) or technical design docs (treat as Complex scope: discuss gray areas + architecture-focused design).","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fspec-driven\u002FSKILL.md",[],[158,159,142,160,161,162,163,36,115,164,144,165,166,167,168,169,30,170,91,171],"spec driven","spec","coverage","complexity","task breakdown","scope","decision","local","design","self-improving","auto","atomic commits","analysis","architecture",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":182,"publishedAt":38},"01M71HG5CSP04F29HRAG7XVYKG","skill-forge","Designs, authors, validates, and optimizes new Agent Skills from scratch. Use when creating a new skill, packaging a workflow as a skill, improving a skill's triggering accuracy, or evaluating whether a skill improves output quality. Covers the full lifecycle: DISCOVER, DESIGN, AUTHOR, VALIDATE, OPTIMIZE, DELIVER. Produces skills that follow the open SKILL.md format (YAML frontmatter + Markdown body, progressive disclosure, validation loops). EN triggers: \u002Fforge, create a skill, write a skill, build a skill, new skill, author a skill, package this as a skill, validate a skill, improve skill triggering, optimize skill description, evaluate skill quality. PT triggers: \u002Fforge, criar uma skill, escrever uma skill, construir uma skill, nova skill, empacotar como skill, validar skill, melhorar disparo, otimizar descrição de skill. Do NOT use for: discovering which existing skill to apply (use a dispatch\u002Fmeta skill), planning feature implementation, or designing software architecture.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fskill-forge\u002FSKILL.md",[178,181],{"categoryNo":179,"categoryName":180,"taxonomyType":81,"taxonomyTypeDesc":82},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":79,"categoryName":80,"taxonomyType":81,"taxonomyTypeDesc":82},[183,184,185,86,186,187,36,188,88,189,190,166,171,191,192,146,193,99,194,195],"forge","skill forge","deliver","new agent","feature implementation","packaging","improve","open","create","de","software","new skill","full",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":202,"publishedAt":38},"01M71HG1RAQY3GXX0Q5TMW0XD6","shipping-and-launch","Prepares production launches with a pre-launch checklist, staged rollout, monitoring, and a rollback strategy — plus feature flag lifecycle (off → internal → beta → GA). Use when deploying a feature to production for the first time, releasing a significant change, or planning a rollout. EN triggers: \u002Fship, pre-launch checklist, staged rollout, feature flag, rollback plan, monitoring. PT triggers: \u002Fshippar, checklist pré-lançamento, rollout gradual, feature flag, plano de rollback. Do NOT use for: pre-production development work, or one-off internal tools with no user exposure.","https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Fshipping-and-launch\u002FSKILL.md",[],[203,204,205,36,206,207,30,208,209,210,211,94,27,212,213,214,192,215,216,217],"shipping and launch","shipping","launch","time","beta","rollout","rollback plan","monitoring","rollback strategy","change","exposure","plano","ship","Tools","pre-launch"]