[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HFE8ZW483E6TT46CEKRE4":3,"skill-same:01M71HFE8ZW483E6TT46CEKRE4":116},{"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":22,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M71HFE8ZW483E6TT46CEKRE4","loop-roadmap",null,"Type-aware roadmap generation from a raw idea or validation of an existing roadmap. Loads project-type guides (application, workflow, client, utility, campaign) to adapt interview rigor, then produces .flywheel\u002Froadmap.md + .flywheel\u002Fstate.md ready for the loop engine. The persona is a coach — brainstorm alongside the user, push to decision when ready, never interrogate. EN triggers: \u002Floop-roadmap, \"create a roadmap\", \"generate roadmap\", \"what should I build\". PT triggers: \u002Floop-roadmap, \"criar roadmap\", \"gerar roadmap\". Do NOT use for: pure information requests, mechanical operations, or when the user already has a fully-loaded roadmap and only needs execution (use \u002Floop-run).","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\u002Floop-roadmap\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"roadmap","loop roadmap","loop","generate","create","guides","workflow","when","information","utility","persona","only","campaign","mechanical","decision","brainstorm","project","pt","never","ready","2026-11-10 10:12:30",false,"---\nname: loop-roadmap\ndescription: >\n  Type-aware roadmap generation from a raw idea or validation of an existing roadmap.\n  Loads project-type guides (application, workflow, client, utility, campaign) to adapt\n  interview rigor, then produces .flywheel\u002Froadmap.md + .flywheel\u002Fstate.md ready for the\n  loop engine. The persona is a coach — brainstorm alongside the user, push to decision\n  when ready, never interrogate.\n  EN triggers: \u002Floop-roadmap, \"create a roadmap\", \"generate roadmap\", \"what should I build\".\n  PT triggers: \u002Floop-roadmap, \"criar roadmap\", \"gerar roadmap\".\n  Do NOT use for: pure information requests, mechanical operations, or when the user already\n  has a fully-loaded roadmap and only needs execution (use \u002Floop-run).\nlicense: CC-BY-4.0\n---\n\n# Loop Roadmap\n\n## Overview\n\nMost ideas stall because nobody writes down what \"done\" looks like. Not a spec — a roadmap. One page that says: here's the shape of the work, here's what we're building, here's what we're explicitly not building, and here's the order we'll tackle it.\n\nThis skill produces that page. It adapts to the *type* of work — a throwaway utility gets a tight 3-section interview; a full application gets a thorough architecture walkthrough — and writes a `roadmap.md` that the Flywheel loop engine can execute phase by phase.\n\nThe persona is a **coach**, not an interrogator. You brainstorm alongside the user. You suggest when they stall. You push to a decision when it's time. No quiz-show tone, no waterfall ceremony. The artifact matters; the conversation gets you there.\n\n## When to Use\n\nApply this skill when:\n\n- The user has a raw idea (\"I want to build X\") but no written plan\n- The user has an existing roadmap and wants it validated or loaded into the loop engine\n- The user explicitly invokes `\u002Floop-roadmap` or one of its triggers\n- The user says \"what should I build?\" and needs structure to think through it\n\n**When NOT to use:**\n\n- The user already has a fully-loaded `.flywheel\u002Froadmap.md` and only needs execution — route to `loop-run`\n- The ask is a pure information request or mechanical operation\n- The user needs intent extraction before they have an idea — route to `interview-me` first\n- The user needs to refine an idea into concrete variations — route to `idea-refine` first\n\n## The Process\n\n### Step 1: Identify or confirm the project type\n\nBefore asking anything else, determine which project-type bucket this work falls into.\nPresent the five types with a one-line description each, and ask the user to pick or confirm your best guess:\n\n| Type | Description | Rigor |\n|------|-------------|-------|\n| **application** | Software with UI, data model, and API surface | deep |\n| **workflow** | Commands, hooks, skills, automations | standard |\n| **client** | Client site — business context, audience, conversion | standard |\n| **utility** | Small single-purpose tool | tight |\n| **campaign** | Content or marketing — timeline-driven, goal-anchored | creative |\n\nTypes are extensible. Dropping a new `\u003Ctype>\u002F` directory into `references\u002Fproject-types\u002F` adds a type without changing the skill. If the user's work doesn't fit any type, default to `application` (deep rigor, safe) and note the mismatch.\n\n### Step 2: Load the type's config and guide\n\nFrom the skill's own `references\u002Fproject-types\u002F\u003Ctype>\u002F` directory, load:\n\n- **`config.md`** — sets `rigor` (tight | standard | deep | creative), `required_sections`, and `default_phase_risk`\n- **`guide.md`** — holds the interview sections, each with `Explore:` (questions) and `Suggest:` (options when the user stalls)\n\nThe `rigor` value adapts behavior:\n- **tight** — moves fast, resists scope creep, runs only required sections\n- **standard** — balanced, runs required sections at a normal pace\n- **deep** — thorough, runs all sections, architecture matters\n- **creative** — generative, always anchored to a measurable goal\n\nThe `required_sections` list determines which guide sections are mandatory. Skip optional sections unless the user brings them up.\n\n### Step 3: Run the interview — one section at a time\n\nWork through each `required_sections` entry from `config.md`, using the corresponding `## Section:` block from `guide.md`.\n\nFor each section:\n\n1. **Explore** — ask one `Explore:` question at a time. Attach your best guess of the answer (the coach move from `interview-me` — reacting is faster than generating from scratch).\n2. **Suggest** — only when the user stalls. Offer one `Suggest:` option with its tradeoff. Don't list all options at once; pick the one that fits the context.\n3. **Capture** — distill the answer into a tight summary (1–3 sentences). Write it down before moving to the next question.\n4. **Gate** — when the section has enough to fill its part of the roadmap, move on. Don't over-interview; the roadmap is a plan, not a spec.\n\nKeep the tone conversational. You're a coach helping someone think through their project, not a checklist-ticking auditor. If a section is clearly irrelevant despite being \"required\" (e.g., `deployment` for a local-only tool), note the skip and why.\n\n### Step 4: Generate the roadmap\n\nWhen all required sections are covered, synthesize the captured answers into `.flywheel\u002Froadmap.md`.\n\nThe roadmap format:\n\n```markdown\n# \u003CProject> Roadmap\n\ntype: application          # from Step 1\nrigor: deep                # from config.md\n\n## Vision\n\u003Cone paragraph: what \"done\" looks like, distilled from the problem section>\n\n## Out of Scope\n- \u003Cexplicit non-goals — the scope guardrail>\n\n## Milestones\n### M1: \u003Cmilestone name>\n- [ ] P1 — \u003Cphase title>  · id: m1-p1  · risk: standard\n- [ ] P2 — \u003Cphase title>  · id: m1-p2  · risk: risky\n### M2: \u003Cmilestone name>\n- [ ] P3 — \u003Cphase title>  · id: m2-p3  · risk: tiny-fix\n\n## Autonomy\nmode: hitl                 # default; only change if user explicitly opts into autonomous\nbudget_per_phase: 3        # max iterations before escalating (mirrors spec-driven bound)\n```\n\n**Phase construction rules:**\n- Each section's output becomes one or more phases inside a milestone\n- Group related phases into named milestones (M1: Foundation, M2: Core, M3: Polish)\n- Default phase risk is `standard` (from `config.md.default_phase_risk`); promote to `risky` for auth, payments, data migration, or anything user\u002Fbusiness-facing; demote to `tiny-fix` for straightforward crud\u002Fplumbing\n- Assign unique, stable phase IDs (`m1-p1`, `m1-p2`, ...) — these are the contract keys the loop engine uses\n- Max 5–7 phases total. If the interview surfaced more, group the smallest ones or defer to a later milestone\n\n**When the user provides an existing roadmap:**\nIf the user has a roadmap file they want to load, validate it against the contract:\n1. Does it have `type:` and `rigor:` fields?\n2. Does every phase have an `id:` and `risk:` annotation?\n3. Are phases grouped into milestones?\n\nIf valid, adopt it (write to `.flywheel\u002Froadmap.md`). If invalid, point out what's missing and offer to fix it via a shortened interview (run only the missing sections).\n\n### Step 5: Write the initial state\n\nCreate `.flywheel\u002Fstate.md`:\n\n```markdown\n# Flywheel State\n\nroadmap: roadmap.md\nstatus: active\ncurrent_phase: null        # set by loop-run when execution begins\nphases_completed: 0\nphases_total: \u003CN>\nmode: hitl\nbudget_remaining: 3\nlast_updated: \u003CISO date>\n```\n\nThis is the boot file. `loop-run` reads it to know where to start.\n\n### Step 6: Confirm and hand off\n\nPresent the roadmap to the user:\n\n```\nHere's the roadmap I've drafted:\n\n\u003Csummary: vision + milestone count + phase count>\n\nThe full roadmap is at .flywheel\u002Froadmap.md. State is at .flywheel\u002Fstate.md.\n\nReady to start the first phase? Run \u002Floop-run to begin the loop.\n```\n\nWait for an explicit confirmation before considering the task done. If the user wants changes, iterate on the specific sections — don't redo the whole interview.\n\n## When to Route Upstream\n\n`loop-roadmap` assumes the user has an idea to work with. If they don't, route them upstream:\n\n- **No idea at all** → `interview-me` — extract what they actually want before a roadmap makes sense\n- **Idea is fuzzy or has competing directions** → `idea-refine` — generate concrete variations\n- **Need a formal spec before building** → `spec-driven` — write acceptance criteria and verification\n\nReturn to `loop-roadmap` when there's a concrete idea to roadmap-ify.\n\n## Coaching Principles\n\n- **One question at a time.** Batch questions kill momentum and encourage skim-answers. The third question often depends on the answer to the first.\n- **Attach a guess.** The user reacts faster to a wrong guess than they generate from scratch. Be visibly willing to be wrong.\n- **Push to decision.** When the user has been circling a section, offer a concrete choice with a recommendation. A coach doesn't let the player stall indefinitely.\n- **Suggest, don't prescribe.** Offer options framed as tradeoffs. \"Option A gets you shipped faster but skips auth; Option B is more complete but adds a phase.\" Let the user decide.\n- **Respect the scope guardrail.** When the user starts describing features that don't fit the type or belong in v2, gently capture them in Out of Scope. \"That sounds like a great Phase 2 candidate — let's write it down so we don't lose it.\"\n\n## Verification\n\nAfter applying loop-roadmap:\n\n- [ ] The project type was confirmed with the user before the interview began\n- [ ] The correct `config.md` and `guide.md` were loaded for that type\n- [ ] Each `required_sections` section was covered (or explicitly skipped with a reason)\n- [ ] `.flywheel\u002Froadmap.md` exists with `type:`, `rigor:`, `## Vision`, `## Out of Scope`, `## Milestones` (with phase IDs and risk classes), and `## Autonomy`\n- [ ] Every phase has a unique `id:` and a `risk:` annotation\n- [ ] `.flywheel\u002Fstate.md` exists with `status:`, `current_phase:`, `phases_completed:`, `phases_total:`, `mode:`, and `budget_remaining:`\n- [ ] The user confirmed the roadmap before the skill considered itself done\n- [ ] No phase count exceeds 7 without explicit justification\n","# Loop Roadmap\n\n## Overview\n\nMost ideas stall because nobody writes down what \"done\" looks like. Not a spec — a roadmap. One page that says: here's the shape of the work, here's what we're building, here's what we're explicitly not building, and here's the order we'll tackle it.\n\nThis skill produces that page. It adapts to the *type* of work — a throwaway utility gets a tight 3-section interview; a full application gets a thorough architecture walkthrough — and writes a `roadmap.md` that the Flywheel loop engine can execute phase by phase.\n\nThe persona is a **coach**, not an interrogator. You brainstorm alongside the user. You suggest when they stall. You push to a decision when it's time. No quiz-show tone, no waterfall ceremony. The artifact matters; the conversation gets you there.\n\n## When to Use\n\nApply this skill when:\n\n- The user has a raw idea (\"I want to build X\") but no written plan\n- The user has an existing roadmap and wants it validated or loaded into the loop engine\n- The user explicitly invokes `\u002Floop-roadmap` or one of its triggers\n- The user says \"what should I build?\" and needs structure to think through it\n\n**When NOT to use:**\n\n- The user already has a fully-loaded `.flywheel\u002Froadmap.md` and only needs execution — route to `loop-run`\n- The ask is a pure information request or mechanical operation\n- The user needs intent extraction before they have an idea — route to `interview-me` first\n- The user needs to refine an idea into concrete variations — route to `idea-refine` first\n\n## The Process\n\n### Step 1: Identify or confirm the project type\n\nBefore asking anything else, determine which project-type bucket this work falls into.\nPresent the five types with a one-line description each, and ask the user to pick or confirm your best guess:\n\n| Type | Description | Rigor |\n|------|-------------|-------|\n| **application** | Software with UI, data model, and API surface | deep |\n| **workflow** | Commands, hooks, skills, automations | standard |\n| **client** | Client site — business context, audience, conversion | standard |\n| **utility** | Small single-purpose tool | tight |\n| **campaign** | Content or marketing — timeline-driven, goal-anchored | creative |\n\nTypes are extensible. Dropping a new `\u003Ctype>\u002F` directory into `references\u002Fproject-types\u002F` adds a type without changing the skill. If the user's work doesn't fit any type, default to `application` (deep rigor, safe) and note the mismatch.\n\n### Step 2: Load the type's config and guide\n\nFrom the skill's own `references\u002Fproject-types\u002F\u003Ctype>\u002F` directory, load:\n\n- **`config.md`** — sets `rigor` (tight | standard | deep | creative), `required_sections`, and `default_phase_risk`\n- **`guide.md`** — holds the interview sections, each with `Explore:` (questions) and `Suggest:` (options when the user stalls)\n\nThe `rigor` value adapts behavior:\n- **tight** — moves fast, resists scope creep, runs only required sections\n- **standard** — balanced, runs required sections at a normal pace\n- **deep** — thorough, runs all sections, architecture matters\n- **creative** — generative, always anchored to a measurable goal\n\nThe `required_sections` list determines which guide sections are mandatory. Skip optional sections unless the user brings them up.\n\n### Step 3: Run the interview — one section at a time\n\nWork through each `required_sections` entry from `config.md`, using the corresponding `## Section:` block from `guide.md`.\n\nFor each section:\n\n1. **Explore** — ask one `Explore:` question at a time. Attach your best guess of the answer (the coach move from `interview-me` — reacting is faster than generating from scratch).\n2. **Suggest** — only when the user stalls. Offer one `Suggest:` option with its tradeoff. Don't list all options at once; pick the one that fits the context.\n3. **Capture** — distill the answer into a tight summary (1–3 sentences). Write it down before moving to the next question.\n4. **Gate** — when the section has enough to fill its part of the roadmap, move on. Don't over-interview; the roadmap is a plan, not a spec.\n\nKeep the tone conversational. You're a coach helping someone think through their project, not a checklist-ticking auditor. If a section is clearly irrelevant despite being \"required\" (e.g., `deployment` for a local-only tool), note the skip and why.\n\n### Step 4: Generate the roadmap\n\nWhen all required sections are covered, synthesize the captured answers into `.flywheel\u002Froadmap.md`.\n\nThe roadmap format:\n\n```markdown\n# \u003CProject> Roadmap\n\ntype: application          # from Step 1\nrigor: deep                # from config.md\n\n## Vision\n\u003Cone paragraph: what \"done\" looks like, distilled from the problem section>\n\n## Out of Scope\n- \u003Cexplicit non-goals — the scope guardrail>\n\n## Milestones\n### M1: \u003Cmilestone name>\n- [ ] P1 — \u003Cphase title>  · id: m1-p1  · risk: standard\n- [ ] P2 — \u003Cphase title>  · id: m1-p2  · risk: risky\n### M2: \u003Cmilestone name>\n- [ ] P3 — \u003Cphase title>  · id: m2-p3  · risk: tiny-fix\n\n## Autonomy\nmode: hitl                 # default; only change if user explicitly opts into autonomous\nbudget_per_phase: 3        # max iterations before escalating (mirrors spec-driven bound)\n```\n\n**Phase construction rules:**\n- Each section's output becomes one or more phases inside a milestone\n- Group related phases into named milestones (M1: Foundation, M2: Core, M3: Polish)\n- Default phase risk is `standard` (from `config.md.default_phase_risk`); promote to `risky` for auth, payments, data migration, or anything user\u002Fbusiness-facing; demote to `tiny-fix` for straightforward crud\u002Fplumbing\n- Assign unique, stable phase IDs (`m1-p1`, `m1-p2`, ...) — these are the contract keys the loop engine uses\n- Max 5–7 phases total. If the interview surfaced more, group the smallest ones or defer to a later milestone\n\n**When the user provides an existing roadmap:**\nIf the user has a roadmap file they want to load, validate it against the contract:\n1. Does it have `type:` and `rigor:` fields?\n2. Does every phase have an `id:` and `risk:` annotation?\n3. Are phases grouped into milestones?\n\nIf valid, adopt it (write to `.flywheel\u002Froadmap.md`). If invalid, point out what's missing and offer to fix it via a shortened interview (run only the missing sections).\n\n### Step 5: Write the initial state\n\nCreate `.flywheel\u002Fstate.md`:\n\n```markdown\n# Flywheel State\n\nroadmap: roadmap.md\nstatus: active\ncurrent_phase: null        # set by loop-run when execution begins\nphases_completed: 0\nphases_total: \u003CN>\nmode: hitl\nbudget_remaining: 3\nlast_updated: \u003CISO date>\n```\n\nThis is the boot file. `loop-run` reads it to know where to start.\n\n### Step 6: Confirm and hand off\n\nPresent the roadmap to the user:\n\n```\nHere's the roadmap I've drafted:\n\n\u003Csummary: vision + milestone count + phase count>\n\nThe full roadmap is at .flywheel\u002Froadmap.md. State is at .flywheel\u002Fstate.md.\n\nReady to start the first phase? Run \u002Floop-run to begin the loop.\n```\n\nWait for an explicit confirmation before considering the task done. If the user wants changes, iterate on the specific sections — don't redo the whole interview.\n\n## When to Route Upstream\n\n`loop-roadmap` assumes the user has an idea to work with. If they don't, route them upstream:\n\n- **No idea at all** → `interview-me` — extract what they actually want before a roadmap makes sense\n- **Idea is fuzzy or has competing directions** → `idea-refine` — generate concrete variations\n- **Need a formal spec before building** → `spec-driven` — write acceptance criteria and verification\n\nReturn to `loop-roadmap` when there's a concrete idea to roadmap-ify.\n\n## Coaching Principles\n\n- **One question at a time.** Batch questions kill momentum and encourage skim-answers. The third question often depends on the answer to the first.\n- **Attach a guess.** The user reacts faster to a wrong guess than they generate from scratch. Be visibly willing to be wrong.\n- **Push to decision.** When the user has been circling a section, offer a concrete choice with a recommendation. A coach doesn't let the player stall indefinitely.\n- **Suggest, don't prescribe.** Offer options framed as tradeoffs. \"Option A gets you shipped faster but skips auth; Option B is more complete but adds a phase.\" Let the user decide.\n- **Respect the scope guardrail.** When the user starts describing features that don't fit the type or belong in v2, gently capture them in Out of Scope. \"That sounds like a great Phase 2 candidate — let's write it down so we don't lose it.\"\n\n## Verification\n\nAfter applying loop-roadmap:\n\n- [ ] The project type was confirmed with the user before the interview began\n- [ ] The correct `config.md` and `guide.md` were loaded for that type\n- [ ] Each `required_sections` section was covered (or explicitly skipped with a reason)\n- [ ] `.flywheel\u002Froadmap.md` exists with `type:`, `rigor:`, `## Vision`, `## Out of Scope`, `## Milestones` (with phase IDs and risk classes), and `## Autonomy`\n- [ ] Every phase has a unique `id:` and a `risk:` annotation\n- [ ] `.flywheel\u002Fstate.md` exists with `status:`, `current_phase:`, `phases_completed:`, `phases_total:`, `mode:`, and `budget_remaining:`\n- [ ] The user confirmed the roadmap before the skill considered itself done\n- [ ] No phase count exceeds 7 without explicit justification\n",{"name":5,"license":14,"description":48},"Type-aware roadmap generation from a raw idea or validation of an existing roadmap. Loads project-type guides (application, workflow, client, utility, campaign) to adapt interview rigor, then produces .flywheel\u002Froadmap.md + .flywheel\u002Fstate.md ready for the loop engine. The persona is a coach — brainstorm alongside the user, push to decision when ready, never interrogate. EN triggers: \u002Floop-roadmap, \"create a roadmap\", \"generate roadmap\", \"what should I build\". PT triggers: \u002Floop-roadmap, \"criar roadmap\", \"gerar roadmap\". Do NOT use for: pure information requests, mechanical operations, or when the user already has a fully-loaded roadmap and only needs execution (use \u002Floop-run).\n","main","33b040feb49e126600394272a8e321a3cd279e8b","packages\u002Fspells\u002Fskills\u002Floop-roadmap",0,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum","https:\u002F\u002Fgithub.com\u002Frunecraftai","2026-07-29 22:08:52",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add runecraftai\u002Farcanum --skill loop-roadmap",{"tool":62,"command":63},"bunx","bunx skills add runecraftai\u002Farcanum --skill loop-roadmap",{"tool":65,"command":66},"pnpm","pnpm dlx skills add runecraftai\u002Farcanum --skill loop-roadmap","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002FSKILL.md",true,[70,76,80,84,88,92,96,100,104,108,112],{"path":71,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":74,"sourceHtmlUrl":75},"README.md","REFERENCE","参考文档",669,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002FREADME.md",{"path":77,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fproject-types\u002Fapplication\u002Fconfig.md",142,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002Freferences\u002Fproject-types\u002Fapplication\u002Fconfig.md",{"path":81,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fproject-types\u002Fapplication\u002Fguide.md",1562,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002Freferences\u002Fproject-types\u002Fapplication\u002Fguide.md",{"path":85,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fproject-types\u002Fcampaign\u002Fconfig.md",115,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002Freferences\u002Fproject-types\u002Fcampaign\u002Fconfig.md",{"path":89,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002Fproject-types\u002Fcampaign\u002Fguide.md",1461,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002Freferences\u002Fproject-types\u002Fcampaign\u002Fguide.md",{"path":93,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002Fproject-types\u002Fclient\u002Fconfig.md",126,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002Freferences\u002Fproject-types\u002Fclient\u002Fconfig.md",{"path":97,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":98,"sourceHtmlUrl":99},"references\u002Fproject-types\u002Fclient\u002Fguide.md",1481,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002Freferences\u002Fproject-types\u002Fclient\u002Fguide.md",{"path":101,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":102,"sourceHtmlUrl":103},"references\u002Fproject-types\u002Futility\u002Fconfig.md",100,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002Freferences\u002Fproject-types\u002Futility\u002Fconfig.md",{"path":105,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":106,"sourceHtmlUrl":107},"references\u002Fproject-types\u002Futility\u002Fguide.md",1079,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002Freferences\u002Fproject-types\u002Futility\u002Fguide.md",{"path":109,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":110,"sourceHtmlUrl":111},"references\u002Fproject-types\u002Fworkflow\u002Fconfig.md",129,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002Freferences\u002Fproject-types\u002Fworkflow\u002Fconfig.md",{"path":113,"resourceType":72,"resourceTypeDesc":73,"sizeBytes":114,"sourceHtmlUrl":115},"references\u002Fproject-types\u002Fworkflow\u002Fguide.md",1219,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-roadmap\u002Freferences\u002Fproject-types\u002Fworkflow\u002Fguide.md",[117,146,169,195,215,238],{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":128,"publishedAt":43},"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",[123],{"categoryNo":124,"categoryName":125,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[129,130,131,40,132,133,30,29,134,135,136,137,138,139,140,141,142,143,144,145],"using agent skills","standalone","which","pick","Meta","you","code","tasks","skill discovery","route","work","unrelated","opencode","request","paths","a skill","ambiguous",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":43},"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",[],[153,154,155,156,157,158,40,159,39,160,161,162,163,34,164,165,166,167,135,168],"typescript","patterns","typescript patterns","do","projects","for","runtime","performance","en","maintainable code","triggers","use","assertions","Rules","best practices","common",{"skillNo":170,"name":171,"nameZh":6,"description":172,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":173,"categories":174,"keywords":181,"publishedAt":43},"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",[175,178],{"categoryNo":176,"categoryName":177,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":179,"categoryName":180,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000008","测试与质量",[182,183,184,185,40,186,187,188,34,30,189,190,191,192,193,156,158,161,163,194],"test driven development","development","test","driven","incident","implementing","write tests","write","bug","refactor","behavioral","make","tests",{"skillNo":196,"name":197,"nameZh":6,"description":198,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":199,"categories":200,"keywords":201,"publishedAt":43},"01M71HGC1H4JQFJWH613XTJC59","spec-driven","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",[],[202,203,185,204,205,206,207,40,39,37,187,208,209,210,211,212,30,213,136,214],"spec driven","spec","coverage","complexity","task breakdown","scope","local","design","self-improving","auto","atomic commits","analysis","architecture",{"skillNo":216,"name":217,"nameZh":6,"description":218,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":219,"categories":220,"keywords":225,"publishedAt":43},"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",[221,224],{"categoryNo":222,"categoryName":223,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":124,"categoryName":125,"taxonomyType":126,"taxonomyTypeDesc":127},[226,227,228,131,229,230,40,231,133,232,233,209,214,27,234,189,235,144,236,237],"forge","skill forge","deliver","new agent","feature implementation","packaging","improve","open","de","software","new skill","full",{"skillNo":239,"name":240,"nameZh":6,"description":241,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":242,"categories":243,"keywords":244,"publishedAt":43},"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",[],[245,246,247,40,248,249,30,250,251,252,253,139,254,255,256,257,234,258,259,260],"shipping and launch","shipping","launch","time","beta","rollout","rollback plan","monitoring","rollback strategy","plan","change","exposure","plano","ship","Tools","pre-launch"]