[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71HF9DBHWTG3R9SHSAC4ZVQ":3,"skill-same:01M71HF9DBHWTG3R9SHSAC4ZVQ":79},{"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":52,"commitSha":53,"skillDirectory":54,"forksCount":55,"repositoryHtmlUrl":56,"repositoryHomepageUrl":6,"ownerHtmlUrl":57,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":58,"install":59,"resources":72},"01M71HF9DBHWTG3R9SHSAC4ZVQ","loop-learn",null,"Appends phase outcomes to Flywheel memory so future phases learn from past work. Adapter over spec-driven's lessons layer and memory-management's flat-append format. Writes decisions (kept phases) to decisions.md and distilled failures to lessons.md, rooted at .flywheel\u002Fmemory\u002F. EN triggers: \u002Floop-learn, record this outcome, save what we learned, log decision, capture lesson. PT triggers: \u002Floop-learn, registrar resultado, salvar aprendizado, registrar decisão, capturar lição. Do NOT use for: spec-driven's own .specs\u002FSTATE.md or LESSONS.md (separate system), Guild projects (use guild-commit-learning), or writing the phase contract itself (use loop-contract).","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-learn\u002FSKILL.md",[17,22],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000039","教师与教育",[26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45],"learn","loop learn","loop","distilled","past","at","outcome","learned","work","log","phase","commit","writing","spec-driven","decision","pt","memory","projects","registrar","lesson","2026-11-10 10:12:30",false,"---\nname: loop-learn\ndescription: >\n  Appends phase outcomes to Flywheel memory so future phases learn from past work.\n  Adapter over spec-driven's lessons layer and memory-management's flat-append format.\n  Writes decisions (kept phases) to decisions.md and distilled failures to lessons.md,\n  rooted at .flywheel\u002Fmemory\u002F. EN triggers: \u002Floop-learn, record this outcome,\n  save what we learned, log decision, capture lesson. PT triggers: \u002Floop-learn,\n  registrar resultado, salvar aprendizado, registrar decisão, capturar lição.\n  Do NOT use for: spec-driven's own .specs\u002FSTATE.md or LESSONS.md (separate system),\n  Guild projects (use guild-commit-learning), or writing the phase contract itself\n  (use loop-contract).\nlicense: CC-BY-4.0\n---\n\n# loop-learn\n\nThin adapter that records Flywheel phase outcomes to persistent memory. Reuses **spec-driven's lessons distillation** (failure → reusable guidance) and **memory-management's flat-append format** — this skill is a disciplined writer of two files, not a new memory engine.\n\n```\nJUDGE VERDICT → CLASSIFY → FORMAT → APPEND TO CORRECT FILE\n```\n\n---\n\n## Overview\n\nFlywheel's loop produces a judge verdict after every phase iteration. `loop-learn` takes that verdict and writes it to the right place in `.flywheel\u002Fmemory\u002F` so future phases (and future sessions) can consult past decisions and avoid repeating known failures.\n\nTwo files, one directory:\n\n```\n.flywheel\u002Fmemory\u002F\n├── decisions.md    # what-we-chose ledger (every kept phase)\n└── lessons.md      # what-to-avoid ledger (only grounded failures)\n```\n\n**Why two files:** `decisions.md` grows with every kept phase — the full audit trail of settled choices. `lessons.md` grows only on grounded failure — high-density, actionable guidance. Keeping them separate means `loop-contract` can load prior decisions cheaply without wading through failure narratives, and the failure signal stays sharp.\n\n---\n\n## When to Use\n\nWrite to `.flywheel\u002Fmemory\u002F` when:\n\n- A phase completes with status `DONE` or `DONE_WITH_CONCERNS` — record the decision\n- A phase fails with a grounded, concrete reason (gate failure, surviving sensor mutant, `BLOCKED`) — distill a lesson\n- `loop-run` invokes you automatically after a judge verdict (the normal path)\n\nDo **not** write when:\n\n- The phase is still in-flight (no verdict yet — wait for the judge)\n- The phase outcome is `NEEDS_CONTEXT` (pause, not a final outcome — no record)\n- A clean `DONE` — records a **decision only**, never a lesson (no ceremony for successes, matches spec-driven's rule)\n\n---\n\n## Process\n\n### Step 1: Classify the Verdict\n\nRead the judge verdict from the current phase's run-log (`runs\u002F\u003Cphase-id>.md`). Classify:\n\n| Verdict | Action |\n|---------|--------|\n| `DONE` | Write a decision entry. Write **nothing** to lessons.md. |\n| `DONE_WITH_CONCERNS` | Write a decision entry **with the concern field**. Write **nothing** to lessons.md. |\n| Grounded failure (gate fail, surviving sensor mutant, `BLOCKED`) | Write a decision entry (status reflects the outcome). **Also** write a lesson entry. |\n| `NEEDS_CONTEXT` | Do nothing — not a final outcome. |\n\n### Step 2: Format the Decision Entry\n\nAppend to `.flywheel\u002Fmemory\u002Fdecisions.md` at the bottom (newest last). Use this exact format:\n\n```markdown\n## \u003Cphase-id> — \u003Cshort title>\n- date: \u003CISO date>\n- decision: \u003Cwhat was chosen or what happened>\n- rationale: \u003Cwhy — one or two lines>\n- evidence: \u003Cfile:line | command output | judge rationale>\n- status: DONE | DONE_WITH_CONCERNS | BLOCKED\n- concern: \u003Conly if DONE_WITH_CONCERNS — what to watch>\n```\n\n**Rules for good decisions:**\n- **phase-id** matches the contract file name (e.g., `m1-p1`).\n- **date** is ISO 8601 (e.g., `2026-07-25`).\n- **decision** states the outcome concretely: \"Implemented user auth with JWT + refresh tokens\" not \"Finished auth\".\n- **rationale** explains why this approach, not another one. An entry without rationale is just a log line.\n- **evidence** is cited — never \"seems right.\" Point at a file:line, a command exit code, or the judge's rubric output. If no evidence can be cited, flag it.\n- **concern** only appears for `DONE_WITH_CONCERNS`. Be specific about what to watch (e.g., \"token refresh not tested under network partition\").\n\n### Step 3: Distill a Lesson (only for grounded failures)\n\nA **grounded failure** is: a gate that failed for a real reason, a surviving discrimination-sensor mutant, a `BLOCKED` outcome with a concrete blocker. These become reusable guidance in `.flywheel\u002Fmemory\u002Flessons.md`.\n\nAppend at the bottom using this exact format:\n\n```markdown\n## \u003Cphase-id> — \u003Cwhat went wrong>\n- trigger: \u003Cthe concrete failure — e.g., \"gate passed but sensor mutant survived\">\n- root-cause: \u003Cwhy it happened>\n- guidance: \u003Cthe reusable rule — \"when X, do Y \u002F avoid Z\">\n- evidence: \u003Ccited source>\n```\n\n**Rules for good lessons:**\n- **trigger** is the observable failure, not the symptom. \"Database migration ran but 3 of 12 tables were empty\" beats \"Migration failed\".\n- **root-cause** traces the failure to its source. If the root cause is unclear, say \"unknown — hypothesis: \u003Cbest guess>\" and flag it.\n- **guidance** is a reusable, imperative rule for future phases. \"When running SQLite migrations, verify row counts per table before marking DONE\" beats \"Be more careful with migrations\".\n- **evidence** ties the lesson to ground truth — a file:line, a command output, a judge rationale.\n- **Only write lessons for grounded failures.** A clean `DONE` records nothing here. A `DONE_WITH_CONCERNS` records the concern in the decision entry, not as a lesson (unless the concern later materializes into a real failure).\n\nThis mirrors spec-driven's lessons distillation: `scripts\u002Flessons.py` turns verification failures into reusable rules; `loop-learn` does the same at the roadmap-phase level.\n\n### Step 4: Create Files on First Use\n\nIf `.flywheel\u002Fmemory\u002F` does not exist, create it and both files:\n\n```bash\nmkdir -p .flywheel\u002Fmemory\n[ ! -f .flywheel\u002Fmemory\u002Fdecisions.md ] && echo \"# Decisions\\n\" > .flywheel\u002Fmemory\u002Fdecisions.md\n[ ! -f .flywheel\u002Fmemory\u002Flessons.md ] && echo \"# Lessons\\n\" > .flywheel\u002Fmemory\u002Flessons.md\n```\n\nRoot output at `.flywheel\u002Fmemory\u002F`, never at `.agent-memory\u002F` or `.specs\u002F`.\n\n### Step 5: Verify the Write\n\nAfter appending:\n\n- Read the entry back from the file to confirm it was written correctly\n- Confirm the entry has all required fields (date, decision, rationale, evidence, status)\n- Confirm a `DONE_WITH_CONCERNS` entry includes the `concern` field\n- Confirm no lesson was written for a clean `DONE`\n- Confirm no secrets, tokens, or credentials in the entry\n\n---\n\n## Adapter Contract\n\nThis skill is an **adapter**, not an engine. It does not:\n\n- Run verification (that's `loop-judge`, which reuses spec-driven's verifier + discrimination sensor)\n- Manage the run-log (that's `loop-run`)\n- Re-implement memory management (that's `memory-management` — this skill reuses its flat-append format)\n- Re-implement lesson distillation (that's spec-driven's `scripts\u002Flessons.py` — this skill reuses the concept at phase granularity)\n\nIt **does**:\n\n- Read the judge verdict from `runs\u002F\u003Cphase-id>.md`\n- Write disciplined entries to `.flywheel\u002Fmemory\u002Fdecisions.md` and `.flywheel\u002Fmemory\u002Flessons.md`\n- Enforce the rule: clean success → decision only; failure → decision + lesson\n- Ensure every entry carries cited evidence\n\n---\n\n## Example\n\n### Input (from run-log)\n\n```\n## Outcome\nphase: DONE_WITH_CONCERNS (after 2\u002F3 iterations)\nverdict: KEEP\nevidence: judge scored 85\u002F100; AC-3 edge case not tested (file: src\u002Fauth.test.ts:42)\n```\n\n### Output (decision entry)\n\n```markdown\n## m1-p2 — JWT auth with refresh tokens\n- date: 2026-07-25\n- decision: Implemented JWT-based authentication with rotating refresh tokens. Gate passed at 85\u002F100 (LLM-judge).\n- rationale: Chose RS256 over HS256 so external services can verify tokens without sharing the secret. Refresh rotation prevents stolen-token replay.\n- evidence: judge scored 85\u002F100 against AC-1..AC-4; src\u002Fauth.test.ts:42 — AC-3 (token expiry edge case) not exercised\n- status: DONE_WITH_CONCERNS\n- concern: Refresh-token rotation not tested under network partition; add as a follow-up phase if token theft is in threat model.\n```\n\n### Output (no lesson)\n\nA `DONE_WITH_CONCERNS` is **not** a grounded failure — it records the concern in the decision entry and advances. No lesson is written unless the concern materializes into a real failure in a later phase.\n\n### Input (grounded failure)\n\n```\n## Outcome\nphase: BLOCKED (after 1\u002F3 iterations)\nreason: database migration deadlocked under concurrent writes; rollback applied\nevidence: WAL checkpoint timed out at 30s (migrations\u002F003.sql:12)\n```\n\n### Output (decision entry + lesson entry)\n\n```markdown\n## m2-p3 — Add notifications table\n- date: 2026-07-25\n- decision: Migration BLOCKED — WAL checkpoint deadlocked under concurrent writes. Rolled back.\n- rationale: SQLite serializes writes; the migration ran while production traffic was active. Must drain writes before schema changes.\n- evidence: WAL checkpoint timeout at migrations\u002F003.sql:12\n- status: BLOCKED\n```\n\n```markdown\n## m2-p3 — Migration deadlocked under concurrent writes\n- trigger: Migration ran while production writes were active; WAL checkpoint timed out at 30s\n- root-cause: SQLite serializes write transactions. The migration held an exclusive lock while concurrent write requests queued, exhausting the WAL checkpoint timeout.\n- guidance: When running SQLite migrations in production, drain external writes first (or use `BEGIN EXCLUSIVE` with a short timeout and retry). Verify zero concurrent writers before running DDL.\n- evidence: migrations\u002F003.sql:12; WAL checkpoint timeout log\n```\n\n---\n\n## See Also\n\n- `spec-driven` — Feature workflow with lessons layer (`scripts\u002Flessons.py`) that this skill adapts to phase granularity\n- `memory-management` — Flat-append format that this skill reuses for both decisions and lessons\n- `loop-judge` — Produces the verdicts this skill records\n- `loop-run` — Orchestrator that invokes this skill after each judge verdict\n- `loop-contract` — Reads past decisions from `.flywheel\u002Fmemory\u002Fdecisions.md` to avoid re-litigating settled choices\n","# loop-learn\n\nThin adapter that records Flywheel phase outcomes to persistent memory. Reuses **spec-driven's lessons distillation** (failure → reusable guidance) and **memory-management's flat-append format** — this skill is a disciplined writer of two files, not a new memory engine.\n\n```\nJUDGE VERDICT → CLASSIFY → FORMAT → APPEND TO CORRECT FILE\n```\n\n---\n\n## Overview\n\nFlywheel's loop produces a judge verdict after every phase iteration. `loop-learn` takes that verdict and writes it to the right place in `.flywheel\u002Fmemory\u002F` so future phases (and future sessions) can consult past decisions and avoid repeating known failures.\n\nTwo files, one directory:\n\n```\n.flywheel\u002Fmemory\u002F\n├── decisions.md    # what-we-chose ledger (every kept phase)\n└── lessons.md      # what-to-avoid ledger (only grounded failures)\n```\n\n**Why two files:** `decisions.md` grows with every kept phase — the full audit trail of settled choices. `lessons.md` grows only on grounded failure — high-density, actionable guidance. Keeping them separate means `loop-contract` can load prior decisions cheaply without wading through failure narratives, and the failure signal stays sharp.\n\n---\n\n## When to Use\n\nWrite to `.flywheel\u002Fmemory\u002F` when:\n\n- A phase completes with status `DONE` or `DONE_WITH_CONCERNS` — record the decision\n- A phase fails with a grounded, concrete reason (gate failure, surviving sensor mutant, `BLOCKED`) — distill a lesson\n- `loop-run` invokes you automatically after a judge verdict (the normal path)\n\nDo **not** write when:\n\n- The phase is still in-flight (no verdict yet — wait for the judge)\n- The phase outcome is `NEEDS_CONTEXT` (pause, not a final outcome — no record)\n- A clean `DONE` — records a **decision only**, never a lesson (no ceremony for successes, matches spec-driven's rule)\n\n---\n\n## Process\n\n### Step 1: Classify the Verdict\n\nRead the judge verdict from the current phase's run-log (`runs\u002F\u003Cphase-id>.md`). Classify:\n\n| Verdict | Action |\n|---------|--------|\n| `DONE` | Write a decision entry. Write **nothing** to lessons.md. |\n| `DONE_WITH_CONCERNS` | Write a decision entry **with the concern field**. Write **nothing** to lessons.md. |\n| Grounded failure (gate fail, surviving sensor mutant, `BLOCKED`) | Write a decision entry (status reflects the outcome). **Also** write a lesson entry. |\n| `NEEDS_CONTEXT` | Do nothing — not a final outcome. |\n\n### Step 2: Format the Decision Entry\n\nAppend to `.flywheel\u002Fmemory\u002Fdecisions.md` at the bottom (newest last). Use this exact format:\n\n```markdown\n## \u003Cphase-id> — \u003Cshort title>\n- date: \u003CISO date>\n- decision: \u003Cwhat was chosen or what happened>\n- rationale: \u003Cwhy — one or two lines>\n- evidence: \u003Cfile:line | command output | judge rationale>\n- status: DONE | DONE_WITH_CONCERNS | BLOCKED\n- concern: \u003Conly if DONE_WITH_CONCERNS — what to watch>\n```\n\n**Rules for good decisions:**\n- **phase-id** matches the contract file name (e.g., `m1-p1`).\n- **date** is ISO 8601 (e.g., `2026-07-25`).\n- **decision** states the outcome concretely: \"Implemented user auth with JWT + refresh tokens\" not \"Finished auth\".\n- **rationale** explains why this approach, not another one. An entry without rationale is just a log line.\n- **evidence** is cited — never \"seems right.\" Point at a file:line, a command exit code, or the judge's rubric output. If no evidence can be cited, flag it.\n- **concern** only appears for `DONE_WITH_CONCERNS`. Be specific about what to watch (e.g., \"token refresh not tested under network partition\").\n\n### Step 3: Distill a Lesson (only for grounded failures)\n\nA **grounded failure** is: a gate that failed for a real reason, a surviving discrimination-sensor mutant, a `BLOCKED` outcome with a concrete blocker. These become reusable guidance in `.flywheel\u002Fmemory\u002Flessons.md`.\n\nAppend at the bottom using this exact format:\n\n```markdown\n## \u003Cphase-id> — \u003Cwhat went wrong>\n- trigger: \u003Cthe concrete failure — e.g., \"gate passed but sensor mutant survived\">\n- root-cause: \u003Cwhy it happened>\n- guidance: \u003Cthe reusable rule — \"when X, do Y \u002F avoid Z\">\n- evidence: \u003Ccited source>\n```\n\n**Rules for good lessons:**\n- **trigger** is the observable failure, not the symptom. \"Database migration ran but 3 of 12 tables were empty\" beats \"Migration failed\".\n- **root-cause** traces the failure to its source. If the root cause is unclear, say \"unknown — hypothesis: \u003Cbest guess>\" and flag it.\n- **guidance** is a reusable, imperative rule for future phases. \"When running SQLite migrations, verify row counts per table before marking DONE\" beats \"Be more careful with migrations\".\n- **evidence** ties the lesson to ground truth — a file:line, a command output, a judge rationale.\n- **Only write lessons for grounded failures.** A clean `DONE` records nothing here. A `DONE_WITH_CONCERNS` records the concern in the decision entry, not as a lesson (unless the concern later materializes into a real failure).\n\nThis mirrors spec-driven's lessons distillation: `scripts\u002Flessons.py` turns verification failures into reusable rules; `loop-learn` does the same at the roadmap-phase level.\n\n### Step 4: Create Files on First Use\n\nIf `.flywheel\u002Fmemory\u002F` does not exist, create it and both files:\n\n```bash\nmkdir -p .flywheel\u002Fmemory\n[ ! -f .flywheel\u002Fmemory\u002Fdecisions.md ] && echo \"# Decisions\\n\" > .flywheel\u002Fmemory\u002Fdecisions.md\n[ ! -f .flywheel\u002Fmemory\u002Flessons.md ] && echo \"# Lessons\\n\" > .flywheel\u002Fmemory\u002Flessons.md\n```\n\nRoot output at `.flywheel\u002Fmemory\u002F`, never at `.agent-memory\u002F` or `.specs\u002F`.\n\n### Step 5: Verify the Write\n\nAfter appending:\n\n- Read the entry back from the file to confirm it was written correctly\n- Confirm the entry has all required fields (date, decision, rationale, evidence, status)\n- Confirm a `DONE_WITH_CONCERNS` entry includes the `concern` field\n- Confirm no lesson was written for a clean `DONE`\n- Confirm no secrets, tokens, or credentials in the entry\n\n---\n\n## Adapter Contract\n\nThis skill is an **adapter**, not an engine. It does not:\n\n- Run verification (that's `loop-judge`, which reuses spec-driven's verifier + discrimination sensor)\n- Manage the run-log (that's `loop-run`)\n- Re-implement memory management (that's `memory-management` — this skill reuses its flat-append format)\n- Re-implement lesson distillation (that's spec-driven's `scripts\u002Flessons.py` — this skill reuses the concept at phase granularity)\n\nIt **does**:\n\n- Read the judge verdict from `runs\u002F\u003Cphase-id>.md`\n- Write disciplined entries to `.flywheel\u002Fmemory\u002Fdecisions.md` and `.flywheel\u002Fmemory\u002Flessons.md`\n- Enforce the rule: clean success → decision only; failure → decision + lesson\n- Ensure every entry carries cited evidence\n\n---\n\n## Example\n\n### Input (from run-log)\n\n```\n## Outcome\nphase: DONE_WITH_CONCERNS (after 2\u002F3 iterations)\nverdict: KEEP\nevidence: judge scored 85\u002F100; AC-3 edge case not tested (file: src\u002Fauth.test.ts:42)\n```\n\n### Output (decision entry)\n\n```markdown\n## m1-p2 — JWT auth with refresh tokens\n- date: 2026-07-25\n- decision: Implemented JWT-based authentication with rotating refresh tokens. Gate passed at 85\u002F100 (LLM-judge).\n- rationale: Chose RS256 over HS256 so external services can verify tokens without sharing the secret. Refresh rotation prevents stolen-token replay.\n- evidence: judge scored 85\u002F100 against AC-1..AC-4; src\u002Fauth.test.ts:42 — AC-3 (token expiry edge case) not exercised\n- status: DONE_WITH_CONCERNS\n- concern: Refresh-token rotation not tested under network partition; add as a follow-up phase if token theft is in threat model.\n```\n\n### Output (no lesson)\n\nA `DONE_WITH_CONCERNS` is **not** a grounded failure — it records the concern in the decision entry and advances. No lesson is written unless the concern materializes into a real failure in a later phase.\n\n### Input (grounded failure)\n\n```\n## Outcome\nphase: BLOCKED (after 1\u002F3 iterations)\nreason: database migration deadlocked under concurrent writes; rollback applied\nevidence: WAL checkpoint timed out at 30s (migrations\u002F003.sql:12)\n```\n\n### Output (decision entry + lesson entry)\n\n```markdown\n## m2-p3 — Add notifications table\n- date: 2026-07-25\n- decision: Migration BLOCKED — WAL checkpoint deadlocked under concurrent writes. Rolled back.\n- rationale: SQLite serializes writes; the migration ran while production traffic was active. Must drain writes before schema changes.\n- evidence: WAL checkpoint timeout at migrations\u002F003.sql:12\n- status: BLOCKED\n```\n\n```markdown\n## m2-p3 — Migration deadlocked under concurrent writes\n- trigger: Migration ran while production writes were active; WAL checkpoint timed out at 30s\n- root-cause: SQLite serializes write transactions. The migration held an exclusive lock while concurrent write requests queued, exhausting the WAL checkpoint timeout.\n- guidance: When running SQLite migrations in production, drain external writes first (or use `BEGIN EXCLUSIVE` with a short timeout and retry). Verify zero concurrent writers before running DDL.\n- evidence: migrations\u002F003.sql:12; WAL checkpoint timeout log\n```\n\n---\n\n## See Also\n\n- `spec-driven` — Feature workflow with lessons layer (`scripts\u002Flessons.py`) that this skill adapts to phase granularity\n- `memory-management` — Flat-append format that this skill reuses for both decisions and lessons\n- `loop-judge` — Produces the verdicts this skill records\n- `loop-run` — Orchestrator that invokes this skill after each judge verdict\n- `loop-contract` — Reads past decisions from `.flywheel\u002Fmemory\u002Fdecisions.md` to avoid re-litigating settled choices\n",{"name":5,"license":14,"description":51},"Appends phase outcomes to Flywheel memory so future phases learn from past work. Adapter over spec-driven's lessons layer and memory-management's flat-append format. Writes decisions (kept phases) to decisions.md and distilled failures to lessons.md, rooted at .flywheel\u002Fmemory\u002F. EN triggers: \u002Floop-learn, record this outcome, save what we learned, log decision, capture lesson. PT triggers: \u002Floop-learn, registrar resultado, salvar aprendizado, registrar decisão, capturar lição. Do NOT use for: spec-driven's own .specs\u002FSTATE.md or LESSONS.md (separate system), Guild projects (use guild-commit-learning), or writing the phase contract itself (use loop-contract).\n","main","33b040feb49e126600394272a8e321a3cd279e8b","packages\u002Fspells\u002Fskills\u002Floop-learn",0,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum","https:\u002F\u002Fgithub.com\u002Frunecraftai","2026-07-29 22:08:52",{"source":8,"skillName":5,"commands":60,"prompt":70,"zipAvailable":71},[61,64,67],{"tool":62,"command":63},"npx","npx skills add runecraftai\u002Farcanum --skill loop-learn",{"tool":65,"command":66},"bunx","bunx skills add runecraftai\u002Farcanum --skill loop-learn",{"tool":68,"command":69},"pnpm","pnpm dlx skills add runecraftai\u002Farcanum --skill loop-learn","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-learn\u002FSKILL.md",true,[73],{"path":74,"resourceType":75,"resourceTypeDesc":76,"sizeBytes":77,"sourceHtmlUrl":78},"README.md","REFERENCE","参考文档",800,"https:\u002F\u002Fgithub.com\u002Frunecraftai\u002Farcanum\u002Fblob\u002Fmain\u002Fpackages\u002Fspells\u002Fskills\u002Floop-learn\u002FREADME.md",[80,110,134,160,179,203],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":91,"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",[86],{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[92,93,94,41,95,96,97,98,99,100,101,102,103,34,104,105,106,107,108,109],"using agent skills","standalone","which","pick","Meta","when","workflow","you","code","tasks","skill discovery","route","unrelated","opencode","request","paths","a skill","ambiguous",{"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":116,"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",[],[117,118,119,120,43,121,41,122,123,124,125,126,127,128,129,130,131,132,100,133],"typescript","patterns","typescript patterns","do","for","runtime","project","performance","en","maintainable code","triggers","only","use","assertions","Rules","best practices","common",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":146,"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",[140,143],{"categoryNo":141,"categoryName":142,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":144,"categoryName":145,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000008","测试与质量",[147,148,149,150,41,151,152,153,128,97,154,155,156,157,158,120,121,125,127,159],"test driven development","development","test","driven","incident","implementing","write tests","write","bug","refactor","behavioral","make","tests",{"skillNo":161,"name":39,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"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",[],[166,167,150,168,169,170,171,41,123,40,152,172,173,174,175,176,97,177,101,178],"spec driven","spec","coverage","complexity","task breakdown","scope","local","design","self-improving","auto","atomic commits","analysis","architecture",{"skillNo":180,"name":181,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":189,"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",[185,188],{"categoryNo":186,"categoryName":187,"taxonomyType":89,"taxonomyTypeDesc":90},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":87,"categoryName":88,"taxonomyType":89,"taxonomyTypeDesc":90},[190,191,192,94,193,194,41,195,96,196,197,173,178,198,199,154,200,108,201,202],"forge","skill forge","deliver","new agent","feature implementation","packaging","improve","open","create","de","software","new skill","full",{"skillNo":204,"name":205,"nameZh":6,"description":206,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":207,"categories":208,"keywords":209,"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",[],[210,211,212,41,213,214,97,215,216,217,218,34,219,220,221,222,199,223,224,225],"shipping and launch","shipping","launch","time","beta","rollout","rollback plan","monitoring","rollback strategy","plan","change","exposure","plano","ship","Tools","pre-launch"]