[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HEZPTTR99NTWQKHNEVR0K":3,"skill-same:01M71HEZPTTR99NTWQKHNEVR0K":82},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M71HEZPTTR99NTWQKHNEVR0K","loop-contract",null,"Read the next pending phase from `.flywheel\u002Froadmap.md` and produce a scoped `.flywheel\u002Fcontracts\u002F{phase-id}.md` contract matching the `program.md` template. The contract is the single source of truth the loop obeys for one phase — it declares allowed files, BDD acceptance criteria, verify method, risk class, mandatory sub-steps, impact level, and budget. Triggers (EN): `\u002Floop-contract`, \"create phase contract\", \"scope this phase\". Triggers (PT): `\u002Floop-contract`, \"criar contrato da fase\", \"escopo da fase\". Do NOT use for roadmap generation (use loop-roadmap) or phase execution (use loop-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-contract\u002FSKILL.md",[17,22,25],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000037","律师与法务",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000040","财务",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"loop contract","contract","loop","flywheel","steps","source","Budget","read","run","template","next","create","phase","program","roadmap","acceptance","impact","files","pt","scope","2026-11-10 10:12:30",false,"---\nname: loop-contract\ndescription: >\n  Read the next pending phase from `.flywheel\u002Froadmap.md` and produce a scoped\n  `.flywheel\u002Fcontracts\u002F{phase-id}.md` contract matching the `program.md` template.\n  The contract is the single source of truth the loop obeys for one phase — it declares\n  allowed files, BDD acceptance criteria, verify method, risk class, mandatory sub-steps,\n  impact level, and budget. Triggers (EN): `\u002Floop-contract`, \"create phase contract\",\n  \"scope this phase\". Triggers (PT): `\u002Floop-contract`, \"criar contrato da fase\",\n  \"escopo da fase\". Do NOT use for roadmap generation (use loop-roadmap) or phase\n  execution (use loop-run).\nlicense: CC-BY-4.0\n---\n\n# loop-contract\n\nTurn the next roadmap phase into a scoped, machine-readable contract that the loop obeys.\n\n```\n┌──────────┐     ┌───────────┐     ┌──────────┐\n│ READ     │ ──► │ AUTHOR    │ ──► │ WRITE    │\n│ roadmap  │     │ contract  │     │ contract │\n└──────────┘     └───────────┘     └──────────┘\n```\n\n## What It Does\n\n`loop-contract` reads `.flywheel\u002Froadmap.md`, selects the next pending phase (first unchecked phase in milestone order), and writes a scoped `.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md` file. The contract is the **single source of truth** the loop-run engine obeys for one phase — every guardrail (scope, acceptance, gate, impact, budget) lives in plain markdown the user or agent can read and edit.\n\n## When to Use\n\n- After `loop-roadmap` has produced or loaded a roadmap\n- Before `loop-run` executes a phase — the contract must exist first\n- When the user wants to review or tighten the scope of a specific phase before execution\n- When re-scoping is needed after a BLOCKED or ESCALATED outcome\n\n## Process\n\n### 1. Read the Roadmap\n\nOpen `.flywheel\u002Froadmap.md`. Find the first unchecked phase (`- [ ] P\u003CN>`) in milestone order. Extract:\n\n- `phase-id` (e.g., `m1-p1`)\n- `title`\n- `risk` class declared on the phase line (e.g., `risk: standard`)\n\nIf no unchecked phase remains, report that the roadmap is complete and stop.\n\n### 2. Infer Risk Class\n\nThe `risk` field on the phase line in `roadmap.md` is authoritative. If absent, infer from context:\n\n- **tiny-fix** — single file, no new abstractions, no API change, no data model change\n- **standard** — multiple files, new modules or patterns, measurable acceptance criteria\n- **risky** — architectural change, user-facing behavior, business-facing logic, data migration, external dependencies\n\nWhen `impact` is `user-facing` or `business-facing`, force `risk: risky` regardless of the roadmap declaration.\n\n### 3. Author the Contract\n\nWrite `.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md` with these sections:\n\n#### Risk Class\n\nThe `risk` class governs which sub-steps are mandatory during execution (§13.4):\n\n| Risk class | Mandatory sub-steps |\n|---|---|\n| **tiny-fix** | apply → measure → judge |\n| **standard** | contract → apply → measure → judge → learn |\n| **risky** | contract → apply → measure → judge (sensor forced) → learn → human sign-off |\n\n#### Objective\n\nOne sentence describing what this phase must achieve. Concrete and measurable.\n\n#### Scope (Allowed Files)\n\nA glob or path list. `loop-run` may **only** edit files matching these patterns. Anything else is out of scope. Be explicit: prefer paths over globs when the set is small; use globs when a well-known directory structure applies.\n\nExample:\n```\n- src\u002Fcommands\u002Floop-contract.ts\n- packages\u002Fspells\u002Fskills\u002Floop-contract\u002F**\n- tests\u002Floop-contract.test.ts\n```\n\n#### Out of Scope\n\nExplicit files, directories, or concerns the phase must **never** touch. This is the guardrail that prevents scope creep.\n\n#### Acceptance Criteria (BDD)\n\nWritten in Given\u002FWhen\u002FThen format, numbered AC-1, AC-2, ... per §13.2. Each criterion must be observable and checkable — no \"seems right\" outcomes.\n\nExample:\n```\n- AC-1:\n    Given a roadmap with at least one unchecked phase\n    When  loop-contract runs\n    Then  the next pending phase is selected in milestone order\n- AC-2:\n    Given a selected phase with risk class and impact\n    When  the contract is authored\n    Then  all mandatory sub-steps for that risk class are written into the contract\n```\n\n#### Verify Method\n\nDeclares how the gate measures success:\n\n- **kind**: `programmatic` or `llm-judge`\n- **command** (when kind=programmatic): a shell command that exits 0 for pass, non-zero for fail, or prints a numeric result\n- **judge_rubric** (when kind=llm-judge): rubric text; score 0–100 against AC-1..N; specify the PASS threshold\n- **sensor**: `on` (discrimination sensor from spec-driven — anti-self-approval; forces at least `on` for risky phases)\n\n#### Impact\n\nOne of: `internal` | `user-facing` | `business-facing`.\n\nNon-internal impact forces `risk: risky` and forced HITL (human-in-the-loop). This gates autonomy — autonomous mode is only allowed for `internal` phases.\n\n#### Mandatory Sub-Steps\n\nExpanded from the risk class (§13.4). Written as an explicit checklist so `loop-run` knows exactly which steps to execute.\n\n#### Budget & Stop\n\n- **max_iterations**: default 3 from roadmap's `budget_per_phase`; override if the phase warrants fewer or more\n- **stop_criterion**: when to stop even if not perfect (e.g., \"no further measurable improvement after 3 iterations\", \"human sign-off required regardless of score\")\n\n### 4. Contract Template\n\nThe output file follows this exact shape:\n\n```markdown\n# Phase Contract: \u003Cphase-id> — \u003Ctitle>\n\nrisk: \u003Ctiny-fix | standard | risky>\n\n## Objective\n\u003Cone sentence>\n\n## Scope (allowed files)\n- \u003Cglob or path>\n\n## Out of Scope\n- \u003Cexplicit exclusion>\n\n## Acceptance Criteria (BDD)\n- AC-1:\n    Given \u003Cprecondition>\n    When  \u003Caction>\n    Then  \u003Cobservable outcome>\n- AC-2:\n    Given \u003Cprecondition>\n    When  \u003Caction>\n    Then  \u003Cobservable outcome>\n\n## Verify Method\nkind: \u003Cprogrammatic | llm-judge>\ncommand: \"\u003Ccmd>\"                                    # when kind=programmatic\njudge_rubric: |                                     # when kind=llm-judge\n  score 0–100 against AC-1..N; PASS threshold: \u003Cn>\nsensor: \u003Con | off>\n\n## Impact\nimpact: \u003Cinternal | user-facing | business-facing>\n\n## Mandatory Sub-Steps\n- [ ] contract\n- [ ] apply\n- [ ] measure\n- [ ] judge\n- [ ] learn\n- [ ] human sign-off  # only for risky\n\n## Budget & Stop\nmax_iterations: \u003Cn>\nstop_criterion: \"\u003Ccriterion>\"\n```\n\n## Edge Cases\n\n- **No unchecked phase**: report \"roadmap complete\" and exit — do not create a contract\n- **Missing risk in roadmap**: infer from phase context; if ambiguous, default to `standard`\n- **Non-internal impact declared**: force `risk: risky` and flag in the contract output\n- **Phase with no title**: derive a title from the phase-id and surrounding milestone context\n- **Roadmap not found**: report that `loop-roadmap` must run first — do not fabricate a roadmap\n\n## Context Loading Strategy\n\nLoad only what is needed for the current contract:\n- `.flywheel\u002Froadmap.md` — the phase list\n- `.flywheel\u002Fstate.md` — current position and autonomy mode\n- `.flywheel\u002Fmemory\u002Fdecisions.md` — prior kept choices to avoid re-litigating settled decisions\n- Target: keep context under 20k tokens for contract authoring\n","# loop-contract\n\nTurn the next roadmap phase into a scoped, machine-readable contract that the loop obeys.\n\n```\n┌──────────┐     ┌───────────┐     ┌──────────┐\n│ READ     │ ──► │ AUTHOR    │ ──► │ WRITE    │\n│ roadmap  │     │ contract  │     │ contract │\n└──────────┘     └───────────┘     └──────────┘\n```\n\n## What It Does\n\n`loop-contract` reads `.flywheel\u002Froadmap.md`, selects the next pending phase (first unchecked phase in milestone order), and writes a scoped `.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md` file. The contract is the **single source of truth** the loop-run engine obeys for one phase — every guardrail (scope, acceptance, gate, impact, budget) lives in plain markdown the user or agent can read and edit.\n\n## When to Use\n\n- After `loop-roadmap` has produced or loaded a roadmap\n- Before `loop-run` executes a phase — the contract must exist first\n- When the user wants to review or tighten the scope of a specific phase before execution\n- When re-scoping is needed after a BLOCKED or ESCALATED outcome\n\n## Process\n\n### 1. Read the Roadmap\n\nOpen `.flywheel\u002Froadmap.md`. Find the first unchecked phase (`- [ ] P\u003CN>`) in milestone order. Extract:\n\n- `phase-id` (e.g., `m1-p1`)\n- `title`\n- `risk` class declared on the phase line (e.g., `risk: standard`)\n\nIf no unchecked phase remains, report that the roadmap is complete and stop.\n\n### 2. Infer Risk Class\n\nThe `risk` field on the phase line in `roadmap.md` is authoritative. If absent, infer from context:\n\n- **tiny-fix** — single file, no new abstractions, no API change, no data model change\n- **standard** — multiple files, new modules or patterns, measurable acceptance criteria\n- **risky** — architectural change, user-facing behavior, business-facing logic, data migration, external dependencies\n\nWhen `impact` is `user-facing` or `business-facing`, force `risk: risky` regardless of the roadmap declaration.\n\n### 3. Author the Contract\n\nWrite `.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md` with these sections:\n\n#### Risk Class\n\nThe `risk` class governs which sub-steps are mandatory during execution (§13.4):\n\n| Risk class | Mandatory sub-steps |\n|---|---|\n| **tiny-fix** | apply → measure → judge |\n| **standard** | contract → apply → measure → judge → learn |\n| **risky** | contract → apply → measure → judge (sensor forced) → learn → human sign-off |\n\n#### Objective\n\nOne sentence describing what this phase must achieve. Concrete and measurable.\n\n#### Scope (Allowed Files)\n\nA glob or path list. `loop-run` may **only** edit files matching these patterns. Anything else is out of scope. Be explicit: prefer paths over globs when the set is small; use globs when a well-known directory structure applies.\n\nExample:\n```\n- src\u002Fcommands\u002Floop-contract.ts\n- packages\u002Fspells\u002Fskills\u002Floop-contract\u002F**\n- tests\u002Floop-contract.test.ts\n```\n\n#### Out of Scope\n\nExplicit files, directories, or concerns the phase must **never** touch. This is the guardrail that prevents scope creep.\n\n#### Acceptance Criteria (BDD)\n\nWritten in Given\u002FWhen\u002FThen format, numbered AC-1, AC-2, ... per §13.2. Each criterion must be observable and checkable — no \"seems right\" outcomes.\n\nExample:\n```\n- AC-1:\n    Given a roadmap with at least one unchecked phase\n    When  loop-contract runs\n    Then  the next pending phase is selected in milestone order\n- AC-2:\n    Given a selected phase with risk class and impact\n    When  the contract is authored\n    Then  all mandatory sub-steps for that risk class are written into the contract\n```\n\n#### Verify Method\n\nDeclares how the gate measures success:\n\n- **kind**: `programmatic` or `llm-judge`\n- **command** (when kind=programmatic): a shell command that exits 0 for pass, non-zero for fail, or prints a numeric result\n- **judge_rubric** (when kind=llm-judge): rubric text; score 0–100 against AC-1..N; specify the PASS threshold\n- **sensor**: `on` (discrimination sensor from spec-driven — anti-self-approval; forces at least `on` for risky phases)\n\n#### Impact\n\nOne of: `internal` | `user-facing` | `business-facing`.\n\nNon-internal impact forces `risk: risky` and forced HITL (human-in-the-loop). This gates autonomy — autonomous mode is only allowed for `internal` phases.\n\n#### Mandatory Sub-Steps\n\nExpanded from the risk class (§13.4). Written as an explicit checklist so `loop-run` knows exactly which steps to execute.\n\n#### Budget & Stop\n\n- **max_iterations**: default 3 from roadmap's `budget_per_phase`; override if the phase warrants fewer or more\n- **stop_criterion**: when to stop even if not perfect (e.g., \"no further measurable improvement after 3 iterations\", \"human sign-off required regardless of score\")\n\n### 4. Contract Template\n\nThe output file follows this exact shape:\n\n```markdown\n# Phase Contract: \u003Cphase-id> — \u003Ctitle>\n\nrisk: \u003Ctiny-fix | standard | risky>\n\n## Objective\n\u003Cone sentence>\n\n## Scope (allowed files)\n- \u003Cglob or path>\n\n## Out of Scope\n- \u003Cexplicit exclusion>\n\n## Acceptance Criteria (BDD)\n- AC-1:\n    Given \u003Cprecondition>\n    When  \u003Caction>\n    Then  \u003Cobservable outcome>\n- AC-2:\n    Given \u003Cprecondition>\n    When  \u003Caction>\n    Then  \u003Cobservable outcome>\n\n## Verify Method\nkind: \u003Cprogrammatic | llm-judge>\ncommand: \"\u003Ccmd>\"                                    # when kind=programmatic\njudge_rubric: |                                     # when kind=llm-judge\n  score 0–100 against AC-1..N; PASS threshold: \u003Cn>\nsensor: \u003Con | off>\n\n## Impact\nimpact: \u003Cinternal | user-facing | business-facing>\n\n## Mandatory Sub-Steps\n- [ ] contract\n- [ ] apply\n- [ ] measure\n- [ ] judge\n- [ ] learn\n- [ ] human sign-off  # only for risky\n\n## Budget & Stop\nmax_iterations: \u003Cn>\nstop_criterion: \"\u003Ccriterion>\"\n```\n\n## Edge Cases\n\n- **No unchecked phase**: report \"roadmap complete\" and exit — do not create a contract\n- **Missing risk in roadmap**: infer from phase context; if ambiguous, default to `standard`\n- **Non-internal impact declared**: force `risk: risky` and flag in the contract output\n- **Phase with no title**: derive a title from the phase-id and surrounding milestone context\n- **Roadmap not found**: report that `loop-roadmap` must run first — do not fabricate a roadmap\n\n## Context Loading Strategy\n\nLoad only what is needed for the current contract:\n- `.flywheel\u002Froadmap.md` — the phase list\n- `.flywheel\u002Fstate.md` — current position and autonomy mode\n- `.flywheel\u002Fmemory\u002Fdecisions.md` — prior kept choices to avoid re-litigating settled decisions\n- Target: keep context under 20k tokens for contract authoring\n",{"name":5,"license":14,"description":54},"Read the next pending phase from `.flywheel\u002Froadmap.md` and produce a scoped `.flywheel\u002Fcontracts\u002F{phase-id}.md` contract matching the `program.md` template. The contract is the single source of truth the loop obeys for one phase — it declares allowed files, BDD acceptance criteria, verify method, risk class, mandatory sub-steps, impact level, and budget. Triggers (EN): `\u002Floop-contract`, \"create phase contract\", \"scope this phase\". Triggers (PT): `\u002Floop-contract`, \"criar contrato da fase\", \"escopo da fase\". Do NOT use for roadmap generation (use loop-roadmap) or phase execution (use loop-run).\n","main","33b040feb49e126600394272a8e321a3cd279e8b","packages\u002Fspells\u002Fskills\u002Floop-contract",0,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum","https:\u002F\u002Fgithub.com\u002Frunecraftai","2026-07-29 22:08:52",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add runecraftai\u002Farcanum --skill loop-contract",{"tool":68,"command":69},"bunx","bunx skills add runecraftai\u002Farcanum --skill loop-contract",{"tool":71,"command":72},"pnpm","pnpm dlx skills add runecraftai\u002Farcanum --skill loop-contract","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-contract\u002FSKILL.md",true,[76],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"README.md","REFERENCE","参考文档",280,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-contract\u002FREADME.md",[83,114,139,165,185,208],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":94,"publishedAt":49},"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",[89],{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[95,96,97,47,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113],"using agent skills","standalone","which","pick","Meta","when","workflow","you","code","tasks","skill discovery","route","work","unrelated","opencode","request","paths","a skill","ambiguous",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":49},"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",[],[121,122,123,124,125,126,47,127,128,129,130,131,132,133,134,135,136,137,103,138],"typescript","patterns","typescript patterns","do","projects","for","runtime","project","performance","en","maintainable code","triggers","only","use","assertions","Rules","best practices","common",{"skillNo":140,"name":141,"nameZh":6,"description":142,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":143,"categories":144,"keywords":151,"publishedAt":49},"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",[145,148],{"categoryNo":146,"categoryName":147,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":149,"categoryName":150,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000008","测试与质量",[152,153,154,155,47,156,157,158,133,100,159,160,161,162,163,124,126,130,132,164],"test driven development","development","test","driven","incident","implementing","write tests","write","bug","refactor","behavioral","make","tests",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"publishedAt":49},"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",[],[172,173,155,174,175,176,48,47,128,177,157,178,179,180,181,182,100,183,104,184],"spec driven","spec","coverage","complexity","task breakdown","decision","local","design","self-improving","auto","atomic commits","analysis","architecture",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":195,"publishedAt":49},"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",[191,194],{"categoryNo":192,"categoryName":193,"taxonomyType":92,"taxonomyTypeDesc":93},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":90,"categoryName":91,"taxonomyType":92,"taxonomyTypeDesc":93},[196,197,198,97,199,200,47,201,99,202,203,179,184,40,204,159,205,112,206,207],"forge","skill forge","deliver","new agent","feature implementation","packaging","improve","open","de","software","new skill","full",{"skillNo":209,"name":210,"nameZh":6,"description":211,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":212,"categories":213,"keywords":214,"publishedAt":49},"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",[],[215,216,217,47,218,219,100,220,221,222,223,107,224,225,226,227,204,228,229,230],"shipping and launch","shipping","launch","time","beta","rollout","rollback plan","monitoring","rollback strategy","plan","change","exposure","plano","ship","Tools","pre-launch"]