[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HFJYJ9WBVFDYN49CBZ164":3,"skill-same:01M71HFJYJ9WBVFDYN49CBZ164":109},{"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":25,"publishedAt":46,"linkOnly":47,"markdownContent":48,"markdownBody":49,"frontMatter":50,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":60,"install":61,"resources":74},"01M71HFJYJ9WBVFDYN49CBZ164","loop-run",null,"The Flywheel loop orchestrator — wires SELECT→APPLY→MEASURE→JUDGE→UNIFY, driving a roadmap to completion phase-by-phase per the contract's risk class, autonomy mode, and budget. Applies changes in-session (subagents are for discovery only), supports pause\u002Fresume across sessions and hosts via .flywheel\u002Fstate.md, defaults to HITL confirmation each iteration (autonomous only for internal-impact phases), and reacts deterministically to each judge escalation status per the plan's decision flow. Use when running the loop engine, advancing roadmap phases, or resuming a paused loop. Triggers (EN): \u002Floop-run, \"run the next phase\", \"execute roadmap phase\", \"start the loop\", \"resume loop\", \"pause loop\". Triggers (PT): \u002Floop-run, \"executar próxima fase\", \"rodar loop\", \"retomar loop\", \"pausar loop\". Do NOT use for: generating roadmaps (loop-roadmap), writing contracts (loop-contract), judging work (loop-judge — author≠verifier), recording memory (loop-learn), or spec-level task execution (spec-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\u002Floop-run\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000038","人力资源",[26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"loop run","run","loop","roadmap","when","phase","mode","pt","spec-driven","recording","impact","iteration","writing","only","autonomous","confirmation","decision","select","learn","memory","2026-11-10 10:12:30",false,"---\nname: loop-run\ndescription: >\n  The Flywheel loop orchestrator — wires SELECT→APPLY→MEASURE→JUDGE→UNIFY, driving a roadmap\n  to completion phase-by-phase per the contract's risk class, autonomy mode, and budget.\n  Applies changes in-session (subagents are for discovery only), supports pause\u002Fresume across\n  sessions and hosts via .flywheel\u002Fstate.md, defaults to HITL confirmation each iteration\n  (autonomous only for internal-impact phases), and reacts deterministically to each judge\n  escalation status per the plan's decision flow.\n  Use when running the loop engine, advancing roadmap phases, or resuming a paused loop.\n  Triggers (EN): \u002Floop-run, \"run the next phase\", \"execute roadmap phase\", \"start the loop\",\n  \"resume loop\", \"pause loop\". Triggers (PT): \u002Floop-run, \"executar próxima fase\",\n  \"rodar loop\", \"retomar loop\", \"pausar loop\".\n  Do NOT use for: generating roadmaps (loop-roadmap), writing contracts (loop-contract),\n  judging work (loop-judge — author≠verifier), recording memory (loop-learn), or spec-level\n  task execution (spec-driven).\nlicense: CC-BY-4.0\nmetadata:\n  version: 1.0.0\n---\n\n# loop-run\n\nThe Flywheel loop orchestrator. This is the **engine** that wires SELECT → APPLY → MEASURE → JUDGE → UNIFY, driving a roadmap to completion phase-by-phase. It is the conductor — it invokes the other `loop-*` skills, but does not itself generate roadmaps, write contracts, judge work, or record memory. Those are separate skills invoked at the right point in the loop.\n\n```\nSELECT phase → CONTRACT (if needed) → APPLY (in-session) → MEASURE → JUDGE → UNIFY\n                                                                             │\n                                                            ┌────────────────┘\n                                                            ▼\n                                              loop-learn → update state → advance or escalate\n```\n\n## Overview\n\n`loop-run` reads a roadmap from `.flywheel\u002Froadmap.md`, selects the next pending phase, ensures a contract exists (invoking `loop-contract` if needed), then executes the loop: apply the change, measure against the gate, submit to the independent judge, and unify the outcome into memory and state. It respects the phase's risk class to determine which sub-steps are mandatory, honors autonomy mode (default HITL, opt-in autonomous for internal-impact phases), and reacts deterministically to each judge escalation status.\n\nThe loop runs in-session for implementation work; subagents are reserved for discovery\u002Fresearch only. Pause and resume are pure file operations via `.flywheel\u002Fstate.md`, enabling continuity across sessions and hosts.\n\n## When to Use\n\n| Trigger | Language |\n|---------|----------|\n| `\u002Floop-run` | EN, PT |\n| `run the next phase`, `execute roadmap phase`, `start the loop`, `resume loop`, `pause loop` | EN |\n| `executar próxima fase`, `rodar loop`, `retomar loop`, `pausar loop` | PT |\n\n**Do NOT use for:**\n- Generating roadmaps (use `loop-roadmap`)\n- Writing phase contracts (use `loop-contract` — `loop-run` invokes it only when a contract is missing)\n- Judging\u002Fverifying work (use `loop-judge` — author≠verifier must be a fresh pass)\n- Recording decisions or lessons (use `loop-learn`)\n- Spec-level task execution or verification (use `spec-driven` directly)\n\n## Prerequisites\n\nBefore invoking `loop-run`, confirm:\n\n- `.flywheel\u002Froadmap.md` exists with at least one pending phase\n- `.flywheel\u002Fstate.md` exists (or will be created on first run)\n- The host environment has access to `loop-contract`, `loop-judge`, and `loop-learn` (installed as companion skills or available as slash commands)\n- The host can read\u002Fwrite files in `.flywheel\u002F`\n\n## Reference Files\n\nLoad these only when the step at hand needs them — do not read all of them up front:\n\n- **`references\u002Fprogram.md`** — the exact phase-contract file shape. Read when authoring a contract (Step 2) or when a contract's structure looks malformed.\n- **`references\u002Fmetrics.md`** — baseline-comparison mechanics for both gate kinds. Read during Step 4 (MEASURE) when defining or interpreting the gate's baseline.\n- **`references\u002Frun-log.md`** — the run-log entry format. Read when appending an iteration (Step 5, Step 5.1-5.3) so field names match what `loop-judge` and `loop-learn` expect.\n- **`references\u002Fverifier.md`** — full discrimination-sensor mechanics (mutation strategy, scratch-state isolation). Read before invoking `loop-judge` on a phase with `sensor: on`.\n- **`references\u002Fexample-run.md`** — a complete worked example of a two-phase loop run end-to-end. Read when unsure how the pieces fit together, or when onboarding a new host\u002Fagent to the loop.\n\n## Process\n\n### Step 1 — SELECT: Pick the Next Phase\n\n1. Read `.flywheel\u002Froadmap.md`. Identify the next **pending** phase (checkbox `[ ]` in the milestones section, ordered top-to-bottom within each milestone, milestone-by-milestone).\n2. Read `.flywheel\u002Fstate.md` to confirm the active phase (if resuming) or set it (if starting fresh).\n3. If no pending phases remain, the roadmap is complete. Report completion and stop.\n\n### Step 2 — CONTRACT: Ensure a Phase Contract Exists\n\nCheck for `.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md`:\n\n- **Exists and well-formed**: proceed to Step 3.\n- **Missing or malformed**: invoke `loop-contract` to generate one from the phase's entry in the roadmap. Wait until the contract is written and valid before continuing.\n- **Ambiguous scope or acceptance**: invoke `loop-contract` with the gap described; do not guess.\n\nThe contract declares the phase's risk class, scope (allowed files), BDD acceptance criteria, verify-method (programmatic or LLM-judge), impact, budget, and mandatory sub-steps. `loop-run` obeys every field — it does not override the contract.\n\n### Step 3 — APPLY: Execute the Phase (In-Session)\n\nImplement the change **in-session** with managed context. This is the implementation step; `loop-run` or the agent it delegates to edits only the files listed in the contract's **Scope (allowed files)**. Any file outside this list is out of scope and must not be touched.\n\n**Subagents are reserved for discovery\u002Fresearch only (§13.3).** Do not use subagents for applying changes. Implementation work always runs in-session to avoid context rot and ~70%-quality subagent output that needs cleanup. Subagents may only be used in Step 5.2 (NEEDS_CONTEXT → discovery subagent) to gather information — not to write code.\n\n**Risk-scaled mandatory sub-steps (§13.4):** the phase's risk class governs which steps are mandatory. The loop must always include at least the steps declared for the risk class:\n\n| Risk class | Mandatory sub-steps | Skippable |\n|------------|---------------------|-----------|\n| **tiny-fix** | apply → measure → judge | contract, learn |\n| **standard** | contract → apply → measure → judge → learn | — |\n| **risky** | contract → apply → measure → judge (sensor forced) → learn → human sign-off | — |\n\n`Impact != internal` ⇒ risk class `risky` ⇒ forced HITL regardless of autonomy mode. Respect this rule: non-internal impact forces human-in-the-loop.\n\n### Step 4 — MEASURE: Run the Gate\n\nRun the verification gate declared in the contract:\n\n- **Programmatic gate** (`kind: programmatic`): execute the contract's `command`, capture exit code and output, compare against baseline.\n- **LLM-judge gate** (`kind: llm-judge`): delegate to `loop-judge` for a rubric-based score against the BDD acceptance criteria.\n\nThe measurement (number, score, exit code) is recorded in the run-log for the judge to act on. `loop-run` initiates the gate but the final verdict comes from the judge.\n\n### Step 5 — JUDGE: Invoke the Independent Verifier\n\nInvoke `loop-judge` as a **fresh, independent pass** (author≠verifier). The agent that ran APPLY must not run JUDGE — this is non-negotiable.\n\n`loop-judge` reads the contract, runs the gate (programmatic or LLM-judge), activates the discrimination sensor when declared, and emits one of four escalation statuses with a verdict (KEEP\u002FREVERT) and cited evidence. The status is written to `.flywheel\u002Fruns\u002F\u003Cphase-id>.md`.\n\n### Step 5.1 — Decision Flow: React to Judge Status\n\nEach iteration produces exactly **one** judge status. `loop-run` reacts deterministically:\n\n| Judge status | Verdict | `loop-run` action | Consumes budget? |\n|--------------|---------|-------------------|-------------------|\n| **DONE** | KEEP | Invoke `loop-learn` (record decision). Mark phase complete in `roadmap.md` and `state.md`. **If risk class is `risky`**: require human sign-off before advancing. Otherwise, advance to next phase. | No |\n| **DONE_WITH_CONCERNS** | KEEP | Invoke `loop-learn` (records the concern as a lesson). Mark phase complete, advance to next phase. In `hitl` mode: show the concern to the human before advancing. | No |\n| **NEEDS_CONTEXT** | (no verdict) | **Pause the phase.** Invoke a **discovery subagent** (§13.3) to gather missing context. Append findings to the run-log. Retry the iteration with added context. Does **not** revert. | Yes |\n| **BLOCKED** | REVERT | **Revert the change.** Write a `BLOCKED` outcome to the run-log with the cited blocker. **Escalate to human immediately** regardless of autonomy mode. Loop stops for this phase. | Yes |\n\n**Plain gate-fail REVERT** (not BLOCKED): the change simply failed the gate — retry within `max_iterations` budget. When the budget is exhausted without a KEEP, the phase outcome becomes `ESCALATED` and control returns to the human. The loop never silently gives up and never loops forever.\n\n**Risk gate before advance:** for a `risky` phase, even a `DONE` requires **human sign-off** before `loop-run` advances. The machine verdict is necessary but not sufficient when impact is user\u002Fbusiness-facing.\n\n### Step 5.2 — NEEDS_CONTEXT: Discovery Subagent\n\nWhen the judge returns `NEEDS_CONTEXT`, the phase is paused (does not advance, does not revert). `loop-run` gathers missing context via a **discovery subagent** — not in-session implementation — and appends findings to the run-log. The iteration retries with the added context, consuming one budget unit.\n\nDiscovery subagents may search the codebase, research external APIs, read documentation, or fetch missing requirements — but they do not modify code.\n\n### Step 5.3 — BLOCKED: Immediate Escalation\n\nWhen the judge returns `BLOCKED`, the phase is halted:\n\n1. Revert the applied change to the pre-iteration state.\n2. Write the BLOCKED outcome (with status, blocker, and cited evidence) to the run-log.\n3. **Escalate to the human immediately** — regardless of autonomy mode. The loop stops for this phase.\n4. Update `state.md` to reflect: phase is blocked, no further iterations are attempted.\n\n### Step 6 — UNIFY: Record and Advance\n\nAfter a KEEP verdict (DONE or DONE_WITH_CONCERNS):\n\n1. **Invoke `loop-learn`** to append the outcome to `.flywheel\u002Fmemory\u002Fdecisions.md` (and `.flywheel\u002Fmemory\u002Flessons.md` if a grounded failure).\n2. **Update state**: mark the phase checkbox `[x]` in `roadmap.md`, update `.flywheel\u002Fstate.md` with the new position (next phase, or \"roadmap complete\").\n3. **Advance**: select the next pending phase (return to Step 1).\n\nAfter a `BLOCKED` or `ESCALATED` outcome: stop the loop for this phase. Update `state.md` with the escalation reason. Do not advance.\n\n## Autonomy Modes\n\n`loop-run` respects the autonomy mode declared in `roadmap.md`:\n\n| Mode | Behavior |\n|------|----------|\n| **hitl** (default) | Confirm each iteration with the human before proceeding. Show DONE_WITH_CONCERNS concerns before advancing. |\n| **autonomous** | Run within budget without per-iteration confirmation. **Force HITL** when the phase contract declares `impact: user-facing` or `impact: business-facing` (see Step 3). |\n\nThe per-phase budget comes from the contract's `max_iterations` field (default 3, mirrors `spec-driven`'s bounded loop). Autonomous mode does not mean unlimited — when budget is exhausted, the phase escalates.\n\n## Pause and Resume (§15)\n\nPause and resume are **pure file operations** — not a runtime feature.\n\n### Pause\n\nTriggered by `\u002Floop-run pause` or context-window pressure:\n\n1. Write the current position to `state.md`:\n   - Active `phase-id`\n   - Current iteration number\n   - Autonomy mode\n   - Budget remaining\n2. Ensure the run-log for the active phase is flushed.\n3. Any in-flight, unjudged change is either committed as a checkpoint or reverted — never left ambiguous.\n\nPause writes no new runtime state; the `.flywheel\u002F` directory is the only source of truth.\n\n### Resume\n\nTriggered by `\u002Floop-run resume` (in the same or a different session\u002Fhost):\n\n1. Read `.flywheel\u002Fstate.md` for the active `phase-id`, iteration, mode, and budget.\n2. Read `.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md` for the phase contract.\n3. Read `.flywheel\u002Fruns\u002F\u003Cphase-id>.md` for the iteration history.\n4. Reconstruct position: continue from the next un-started iteration within the phase.\n5. Resume works across **different hosts** (pause in Cursor, resume in Claude Code) because state lives entirely in `.flywheel\u002F`.\n\n### Source of Truth on Conflict\n\nIf `state.md` and the run-log disagree (e.g., crash mid-write):\n\n- **Run-log is authoritative for history.** Trust the run-log's last complete iteration.\n- **Rewind `state.md`** to match the run-log's actual position.\n- `loop-run` must detect the mismatch, log it, and repair before continuing.\n\n## Loop Orchestration Summary\n\n```\n┌──────────────────────────────────────────────────────────────────┐\n│                    loop-run orchestration                         │\n│                                                                   │\n│  SELECT → CONTRACT → APPLY → MEASURE → JUDGE → UNIFY             │\n│    │         │         │        │         │        │              │\n│    │     invoke       in-     run     invoke    invoke            │\n│    │     loop-      session   gate    loop-    loop-              │\n│    │    contract              per     judge    learn              │\n│    │                          contract                            │\n│    │                                                              │\n│    └─ JUDGE STATUS → DECISION FLOW (§14)                          │\n│         ├─ DONE ────────────────► learn ─► [risky? sign-off] ─► advance\n│         ├─ DONE_WITH_CONCERNS ──► learn(+concern) ─► advance      │\n│         ├─ NEEDS_CONTEXT ───────► discovery subagent ─► retry     │\n│         └─ BLOCKED ─────────────► revert ─► escalate (stop)       │\n│                (plain gate-fail REVERT ─► retry ─► else ESCALATED)│\n└──────────────────────────────────────────────────────────────────┘\n```\n\n## Files Touched\n\n| File | Read\u002FWrite | Purpose |\n|------|-----------|---------|\n| `.flywheel\u002Froadmap.md` | Read + Write | Select pending phase, mark complete |\n| `.flywheel\u002Fstate.md` | Read + Write | Track position, mode, budget; pause\u002Fresume |\n| `.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md` | Read | Phase scope, acceptance, gate, risk, budget |\n| `.flywheel\u002Fruns\u002F\u003Cphase-id>.md` | Append | Iteration history (judge verdicts, evidence) |\n| `.flywheel\u002Fmemory\u002Fdecisions.md` | Append (via loop-learn) | Kept decisions |\n| `.flywheel\u002Fmemory\u002Flessons.md` | Append (via loop-learn) | Distilled failures |\n\n## Reuse\n\n| Capability | Source |\n|------------|--------|\n| Phase contract generation | `loop-contract` (invoked when contract is missing) |\n| Independent verifier + discrimination sensor | `loop-judge` (invoked as fresh pass, author≠verifier) |\n| Memory recording (decisions + lessons) | `loop-learn` (invoked after KEEP verdict) |\n| Roadmap creation | `loop-roadmap` (invoked before loop-run if no roadmap exists) |\n| Bounded loop budget (default 3 iterations) | `spec-driven`'s fix→re-verify loop pattern |\n| Decision flow + escalation statuses | Flywheel plan (§14) |\n| Pause\u002Fresume contract | `.flywheel\u002Fstate.md` + run-log (§15) |\n| Risk sub-steps | Flywheel plan (§13.4) |\n\nThis skill is the **orchestrator** — it does not implement judging, learning, contracting, or roadmap generation. It delegates those responsibilities to the appropriate skills and enforces the decision flow, autonomy rules, and pause\u002Fresume contract.\n","# loop-run\n\nThe Flywheel loop orchestrator. This is the **engine** that wires SELECT → APPLY → MEASURE → JUDGE → UNIFY, driving a roadmap to completion phase-by-phase. It is the conductor — it invokes the other `loop-*` skills, but does not itself generate roadmaps, write contracts, judge work, or record memory. Those are separate skills invoked at the right point in the loop.\n\n```\nSELECT phase → CONTRACT (if needed) → APPLY (in-session) → MEASURE → JUDGE → UNIFY\n                                                                             │\n                                                            ┌────────────────┘\n                                                            ▼\n                                              loop-learn → update state → advance or escalate\n```\n\n## Overview\n\n`loop-run` reads a roadmap from `.flywheel\u002Froadmap.md`, selects the next pending phase, ensures a contract exists (invoking `loop-contract` if needed), then executes the loop: apply the change, measure against the gate, submit to the independent judge, and unify the outcome into memory and state. It respects the phase's risk class to determine which sub-steps are mandatory, honors autonomy mode (default HITL, opt-in autonomous for internal-impact phases), and reacts deterministically to each judge escalation status.\n\nThe loop runs in-session for implementation work; subagents are reserved for discovery\u002Fresearch only. Pause and resume are pure file operations via `.flywheel\u002Fstate.md`, enabling continuity across sessions and hosts.\n\n## When to Use\n\n| Trigger | Language |\n|---------|----------|\n| `\u002Floop-run` | EN, PT |\n| `run the next phase`, `execute roadmap phase`, `start the loop`, `resume loop`, `pause loop` | EN |\n| `executar próxima fase`, `rodar loop`, `retomar loop`, `pausar loop` | PT |\n\n**Do NOT use for:**\n- Generating roadmaps (use `loop-roadmap`)\n- Writing phase contracts (use `loop-contract` — `loop-run` invokes it only when a contract is missing)\n- Judging\u002Fverifying work (use `loop-judge` — author≠verifier must be a fresh pass)\n- Recording decisions or lessons (use `loop-learn`)\n- Spec-level task execution or verification (use `spec-driven` directly)\n\n## Prerequisites\n\nBefore invoking `loop-run`, confirm:\n\n- `.flywheel\u002Froadmap.md` exists with at least one pending phase\n- `.flywheel\u002Fstate.md` exists (or will be created on first run)\n- The host environment has access to `loop-contract`, `loop-judge`, and `loop-learn` (installed as companion skills or available as slash commands)\n- The host can read\u002Fwrite files in `.flywheel\u002F`\n\n## Reference Files\n\nLoad these only when the step at hand needs them — do not read all of them up front:\n\n- **`references\u002Fprogram.md`** — the exact phase-contract file shape. Read when authoring a contract (Step 2) or when a contract's structure looks malformed.\n- **`references\u002Fmetrics.md`** — baseline-comparison mechanics for both gate kinds. Read during Step 4 (MEASURE) when defining or interpreting the gate's baseline.\n- **`references\u002Frun-log.md`** — the run-log entry format. Read when appending an iteration (Step 5, Step 5.1-5.3) so field names match what `loop-judge` and `loop-learn` expect.\n- **`references\u002Fverifier.md`** — full discrimination-sensor mechanics (mutation strategy, scratch-state isolation). Read before invoking `loop-judge` on a phase with `sensor: on`.\n- **`references\u002Fexample-run.md`** — a complete worked example of a two-phase loop run end-to-end. Read when unsure how the pieces fit together, or when onboarding a new host\u002Fagent to the loop.\n\n## Process\n\n### Step 1 — SELECT: Pick the Next Phase\n\n1. Read `.flywheel\u002Froadmap.md`. Identify the next **pending** phase (checkbox `[ ]` in the milestones section, ordered top-to-bottom within each milestone, milestone-by-milestone).\n2. Read `.flywheel\u002Fstate.md` to confirm the active phase (if resuming) or set it (if starting fresh).\n3. If no pending phases remain, the roadmap is complete. Report completion and stop.\n\n### Step 2 — CONTRACT: Ensure a Phase Contract Exists\n\nCheck for `.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md`:\n\n- **Exists and well-formed**: proceed to Step 3.\n- **Missing or malformed**: invoke `loop-contract` to generate one from the phase's entry in the roadmap. Wait until the contract is written and valid before continuing.\n- **Ambiguous scope or acceptance**: invoke `loop-contract` with the gap described; do not guess.\n\nThe contract declares the phase's risk class, scope (allowed files), BDD acceptance criteria, verify-method (programmatic or LLM-judge), impact, budget, and mandatory sub-steps. `loop-run` obeys every field — it does not override the contract.\n\n### Step 3 — APPLY: Execute the Phase (In-Session)\n\nImplement the change **in-session** with managed context. This is the implementation step; `loop-run` or the agent it delegates to edits only the files listed in the contract's **Scope (allowed files)**. Any file outside this list is out of scope and must not be touched.\n\n**Subagents are reserved for discovery\u002Fresearch only (§13.3).** Do not use subagents for applying changes. Implementation work always runs in-session to avoid context rot and ~70%-quality subagent output that needs cleanup. Subagents may only be used in Step 5.2 (NEEDS_CONTEXT → discovery subagent) to gather information — not to write code.\n\n**Risk-scaled mandatory sub-steps (§13.4):** the phase's risk class governs which steps are mandatory. The loop must always include at least the steps declared for the risk class:\n\n| Risk class | Mandatory sub-steps | Skippable |\n|------------|---------------------|-----------|\n| **tiny-fix** | apply → measure → judge | contract, learn |\n| **standard** | contract → apply → measure → judge → learn | — |\n| **risky** | contract → apply → measure → judge (sensor forced) → learn → human sign-off | — |\n\n`Impact != internal` ⇒ risk class `risky` ⇒ forced HITL regardless of autonomy mode. Respect this rule: non-internal impact forces human-in-the-loop.\n\n### Step 4 — MEASURE: Run the Gate\n\nRun the verification gate declared in the contract:\n\n- **Programmatic gate** (`kind: programmatic`): execute the contract's `command`, capture exit code and output, compare against baseline.\n- **LLM-judge gate** (`kind: llm-judge`): delegate to `loop-judge` for a rubric-based score against the BDD acceptance criteria.\n\nThe measurement (number, score, exit code) is recorded in the run-log for the judge to act on. `loop-run` initiates the gate but the final verdict comes from the judge.\n\n### Step 5 — JUDGE: Invoke the Independent Verifier\n\nInvoke `loop-judge` as a **fresh, independent pass** (author≠verifier). The agent that ran APPLY must not run JUDGE — this is non-negotiable.\n\n`loop-judge` reads the contract, runs the gate (programmatic or LLM-judge), activates the discrimination sensor when declared, and emits one of four escalation statuses with a verdict (KEEP\u002FREVERT) and cited evidence. The status is written to `.flywheel\u002Fruns\u002F\u003Cphase-id>.md`.\n\n### Step 5.1 — Decision Flow: React to Judge Status\n\nEach iteration produces exactly **one** judge status. `loop-run` reacts deterministically:\n\n| Judge status | Verdict | `loop-run` action | Consumes budget? |\n|--------------|---------|-------------------|-------------------|\n| **DONE** | KEEP | Invoke `loop-learn` (record decision). Mark phase complete in `roadmap.md` and `state.md`. **If risk class is `risky`**: require human sign-off before advancing. Otherwise, advance to next phase. | No |\n| **DONE_WITH_CONCERNS** | KEEP | Invoke `loop-learn` (records the concern as a lesson). Mark phase complete, advance to next phase. In `hitl` mode: show the concern to the human before advancing. | No |\n| **NEEDS_CONTEXT** | (no verdict) | **Pause the phase.** Invoke a **discovery subagent** (§13.3) to gather missing context. Append findings to the run-log. Retry the iteration with added context. Does **not** revert. | Yes |\n| **BLOCKED** | REVERT | **Revert the change.** Write a `BLOCKED` outcome to the run-log with the cited blocker. **Escalate to human immediately** regardless of autonomy mode. Loop stops for this phase. | Yes |\n\n**Plain gate-fail REVERT** (not BLOCKED): the change simply failed the gate — retry within `max_iterations` budget. When the budget is exhausted without a KEEP, the phase outcome becomes `ESCALATED` and control returns to the human. The loop never silently gives up and never loops forever.\n\n**Risk gate before advance:** for a `risky` phase, even a `DONE` requires **human sign-off** before `loop-run` advances. The machine verdict is necessary but not sufficient when impact is user\u002Fbusiness-facing.\n\n### Step 5.2 — NEEDS_CONTEXT: Discovery Subagent\n\nWhen the judge returns `NEEDS_CONTEXT`, the phase is paused (does not advance, does not revert). `loop-run` gathers missing context via a **discovery subagent** — not in-session implementation — and appends findings to the run-log. The iteration retries with the added context, consuming one budget unit.\n\nDiscovery subagents may search the codebase, research external APIs, read documentation, or fetch missing requirements — but they do not modify code.\n\n### Step 5.3 — BLOCKED: Immediate Escalation\n\nWhen the judge returns `BLOCKED`, the phase is halted:\n\n1. Revert the applied change to the pre-iteration state.\n2. Write the BLOCKED outcome (with status, blocker, and cited evidence) to the run-log.\n3. **Escalate to the human immediately** — regardless of autonomy mode. The loop stops for this phase.\n4. Update `state.md` to reflect: phase is blocked, no further iterations are attempted.\n\n### Step 6 — UNIFY: Record and Advance\n\nAfter a KEEP verdict (DONE or DONE_WITH_CONCERNS):\n\n1. **Invoke `loop-learn`** to append the outcome to `.flywheel\u002Fmemory\u002Fdecisions.md` (and `.flywheel\u002Fmemory\u002Flessons.md` if a grounded failure).\n2. **Update state**: mark the phase checkbox `[x]` in `roadmap.md`, update `.flywheel\u002Fstate.md` with the new position (next phase, or \"roadmap complete\").\n3. **Advance**: select the next pending phase (return to Step 1).\n\nAfter a `BLOCKED` or `ESCALATED` outcome: stop the loop for this phase. Update `state.md` with the escalation reason. Do not advance.\n\n## Autonomy Modes\n\n`loop-run` respects the autonomy mode declared in `roadmap.md`:\n\n| Mode | Behavior |\n|------|----------|\n| **hitl** (default) | Confirm each iteration with the human before proceeding. Show DONE_WITH_CONCERNS concerns before advancing. |\n| **autonomous** | Run within budget without per-iteration confirmation. **Force HITL** when the phase contract declares `impact: user-facing` or `impact: business-facing` (see Step 3). |\n\nThe per-phase budget comes from the contract's `max_iterations` field (default 3, mirrors `spec-driven`'s bounded loop). Autonomous mode does not mean unlimited — when budget is exhausted, the phase escalates.\n\n## Pause and Resume (§15)\n\nPause and resume are **pure file operations** — not a runtime feature.\n\n### Pause\n\nTriggered by `\u002Floop-run pause` or context-window pressure:\n\n1. Write the current position to `state.md`:\n   - Active `phase-id`\n   - Current iteration number\n   - Autonomy mode\n   - Budget remaining\n2. Ensure the run-log for the active phase is flushed.\n3. Any in-flight, unjudged change is either committed as a checkpoint or reverted — never left ambiguous.\n\nPause writes no new runtime state; the `.flywheel\u002F` directory is the only source of truth.\n\n### Resume\n\nTriggered by `\u002Floop-run resume` (in the same or a different session\u002Fhost):\n\n1. Read `.flywheel\u002Fstate.md` for the active `phase-id`, iteration, mode, and budget.\n2. Read `.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md` for the phase contract.\n3. Read `.flywheel\u002Fruns\u002F\u003Cphase-id>.md` for the iteration history.\n4. Reconstruct position: continue from the next un-started iteration within the phase.\n5. Resume works across **different hosts** (pause in Cursor, resume in Claude Code) because state lives entirely in `.flywheel\u002F`.\n\n### Source of Truth on Conflict\n\nIf `state.md` and the run-log disagree (e.g., crash mid-write):\n\n- **Run-log is authoritative for history.** Trust the run-log's last complete iteration.\n- **Rewind `state.md`** to match the run-log's actual position.\n- `loop-run` must detect the mismatch, log it, and repair before continuing.\n\n## Loop Orchestration Summary\n\n```\n┌──────────────────────────────────────────────────────────────────┐\n│                    loop-run orchestration                         │\n│                                                                   │\n│  SELECT → CONTRACT → APPLY → MEASURE → JUDGE → UNIFY             │\n│    │         │         │        │         │        │              │\n│    │     invoke       in-     run     invoke    invoke            │\n│    │     loop-      session   gate    loop-    loop-              │\n│    │    contract              per     judge    learn              │\n│    │                          contract                            │\n│    │                                                              │\n│    └─ JUDGE STATUS → DECISION FLOW (§14)                          │\n│         ├─ DONE ────────────────► learn ─► [risky? sign-off] ─► advance\n│         ├─ DONE_WITH_CONCERNS ──► learn(+concern) ─► advance      │\n│         ├─ NEEDS_CONTEXT ───────► discovery subagent ─► retry     │\n│         └─ BLOCKED ─────────────► revert ─► escalate (stop)       │\n│                (plain gate-fail REVERT ─► retry ─► else ESCALATED)│\n└──────────────────────────────────────────────────────────────────┘\n```\n\n## Files Touched\n\n| File | Read\u002FWrite | Purpose |\n|------|-----------|---------|\n| `.flywheel\u002Froadmap.md` | Read + Write | Select pending phase, mark complete |\n| `.flywheel\u002Fstate.md` | Read + Write | Track position, mode, budget; pause\u002Fresume |\n| `.flywheel\u002Fcontracts\u002F\u003Cphase-id>.md` | Read | Phase scope, acceptance, gate, risk, budget |\n| `.flywheel\u002Fruns\u002F\u003Cphase-id>.md` | Append | Iteration history (judge verdicts, evidence) |\n| `.flywheel\u002Fmemory\u002Fdecisions.md` | Append (via loop-learn) | Kept decisions |\n| `.flywheel\u002Fmemory\u002Flessons.md` | Append (via loop-learn) | Distilled failures |\n\n## Reuse\n\n| Capability | Source |\n|------------|--------|\n| Phase contract generation | `loop-contract` (invoked when contract is missing) |\n| Independent verifier + discrimination sensor | `loop-judge` (invoked as fresh pass, author≠verifier) |\n| Memory recording (decisions + lessons) | `loop-learn` (invoked after KEEP verdict) |\n| Roadmap creation | `loop-roadmap` (invoked before loop-run if no roadmap exists) |\n| Bounded loop budget (default 3 iterations) | `spec-driven`'s fix→re-verify loop pattern |\n| Decision flow + escalation statuses | Flywheel plan (§14) |\n| Pause\u002Fresume contract | `.flywheel\u002Fstate.md` + run-log (§15) |\n| Risk sub-steps | Flywheel plan (§13.4) |\n\nThis skill is the **orchestrator** — it does not implement judging, learning, contracting, or roadmap generation. It delegates those responsibilities to the appropriate skills and enforces the decision flow, autonomy rules, and pause\u002Fresume contract.\n",{"name":5,"license":14,"metadata":51,"description":53},{"version":52},"1.0.0","The Flywheel loop orchestrator — wires SELECT→APPLY→MEASURE→JUDGE→UNIFY, driving a roadmap to completion phase-by-phase per the contract's risk class, autonomy mode, and budget. Applies changes in-session (subagents are for discovery only), supports pause\u002Fresume across sessions and hosts via .flywheel\u002Fstate.md, defaults to HITL confirmation each iteration (autonomous only for internal-impact phases), and reacts deterministically to each judge escalation status per the plan's decision flow. Use when running the loop engine, advancing roadmap phases, or resuming a paused loop. Triggers (EN): \u002Floop-run, \"run the next phase\", \"execute roadmap phase\", \"start the loop\", \"resume loop\", \"pause loop\". Triggers (PT): \u002Floop-run, \"executar próxima fase\", \"rodar loop\", \"retomar loop\", \"pausar loop\". Do NOT use for: generating roadmaps (loop-roadmap), writing contracts (loop-contract), judging work (loop-judge — author≠verifier), recording memory (loop-learn), or spec-level task execution (spec-driven).\n","main","33b040feb49e126600394272a8e321a3cd279e8b","packages\u002Fspells\u002Fskills\u002Floop-run",0,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum","https:\u002F\u002Fgithub.com\u002Frunecraftai","2026-07-29 22:08:52",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add runecraftai\u002Farcanum --skill loop-run",{"tool":67,"command":68},"bunx","bunx skills add runecraftai\u002Farcanum --skill loop-run",{"tool":70,"command":71},"pnpm","pnpm dlx skills add runecraftai\u002Farcanum --skill loop-run","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-run\u002FSKILL.md",true,[75,81,85,89,93,97,101,105],{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"README.md","REFERENCE","参考文档",809,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-run\u002FREADME.md",{"path":82,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":83,"sourceHtmlUrl":84},"references\u002Fexample-run.md",28870,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-run\u002Freferences\u002Fexample-run.md",{"path":86,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fmetrics.md",1991,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-run\u002Freferences\u002Fmetrics.md",{"path":90,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":91,"sourceHtmlUrl":92},"references\u002Fprogram.md",728,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-run\u002Freferences\u002Fprogram.md",{"path":94,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":95,"sourceHtmlUrl":96},"references\u002Froadmap.md",459,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-run\u002Freferences\u002Froadmap.md",{"path":98,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":99,"sourceHtmlUrl":100},"references\u002Frun-log.md",677,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-run\u002Freferences\u002Frun-log.md",{"path":102,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":103,"sourceHtmlUrl":104},"references\u002Fstate.md",217,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-run\u002Freferences\u002Fstate.md",{"path":106,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":107,"sourceHtmlUrl":108},"references\u002Fverifier.md",2294,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-run\u002Freferences\u002Fverifier.md",[110,140,164,190,209,233],{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":121,"publishedAt":46},"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",[116],{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[122,123,124,33,125,126,30,127,128,129,130,131,132,133,134,135,136,137,138,139],"using agent skills","standalone","which","pick","Meta","workflow","you","code","tasks","skill discovery","route","work","unrelated","opencode","request","paths","a skill","ambiguous",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":46},"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",[],[147,148,149,150,151,152,33,153,154,155,156,157,158,39,159,160,161,162,129,163],"typescript","patterns","typescript patterns","do","projects","for","runtime","project","performance","en","maintainable code","triggers","use","assertions","Rules","best practices","common",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":176,"publishedAt":46},"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",[170,173],{"categoryNo":171,"categoryName":172,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":174,"categoryName":175,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000008","测试与质量",[177,178,179,180,33,181,182,183,39,30,184,185,186,187,188,150,152,156,158,189],"test driven development","development","test","driven","incident","implementing","write tests","write","bug","refactor","behavioral","make","tests",{"skillNo":191,"name":34,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":195,"publishedAt":46},"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",[],[196,197,180,198,199,200,201,33,154,42,182,202,203,204,205,206,30,207,130,208],"spec driven","spec","coverage","complexity","task breakdown","scope","local","design","self-improving","auto","atomic commits","analysis","architecture",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":219,"publishedAt":46},"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",[215,218],{"categoryNo":216,"categoryName":217,"taxonomyType":119,"taxonomyTypeDesc":120},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":117,"categoryName":118,"taxonomyType":119,"taxonomyTypeDesc":120},[220,221,222,124,223,224,33,225,126,226,227,203,208,228,229,184,230,138,231,232],"forge","skill forge","deliver","new agent","feature implementation","packaging","improve","open","create","de","software","new skill","full",{"skillNo":234,"name":235,"nameZh":6,"description":236,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":237,"categories":238,"keywords":239,"publishedAt":46},"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",[],[240,241,242,33,243,244,30,245,246,247,248,133,249,250,251,252,229,253,254,255],"shipping and launch","shipping","launch","time","beta","rollout","rollback plan","monitoring","rollback strategy","plan","change","exposure","plano","ship","Tools","pre-launch"]