[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6NVD148JZK0V2CSS22MKC36":3,"skill-same:01M6NVD148JZK0V2CSS22MKC36":75},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":43,"linkOnly":44,"markdownContent":45,"markdownBody":46,"frontMatter":47,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":56,"ownerHtmlUrl":57,"ownerBlogUrl":58,"ownerDescription":59,"updatedAt":60,"install":61,"resources":74},"01M6NVD148JZK0V2CSS22MKC36","retrospective",null,"Structured retrospective after completing a delivery increment or diamond. Captures learning for continuous improvement.","haabe\u002Fmycelium","haabe","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F2988921?v=4","01M6NTRKFVVHQG4RF09EB5FRB4","Håvard Bartnes","01M6NTRKKSM94X8BRYCYE2D80Y",52,"MIT","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Fplugins\u002Fmycelium\u002Fskills\u002Fretrospective\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42],"continuous improvement","improvement","for","standalone","gates","mycelium","delivery","use","install","behavior","canvas","learning","https","harness","framework","state","run","plugin","github","2026-11-10 10:12:30",false,"---\nname: retrospective\ndescription: \"Structured retrospective after completing a delivery increment or diamond. Captures learning for continuous improvement.\"\nmetadata:\n  instruction_budget: \"58\"\n  framework_dependency: \"mycelium\"\n  framework_dependency_note: \"This skill is designed to run within the Mycelium framework (https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: \u002Fplugin install mycelium@haabe-mycelium.\"\n---\n\n# Retrospective\n\nRun after every completed **cycle**: a solution leaf reaching a terminal state (launched, archived, killed), or a framework-development arc that shipped. Not only after a diamond completes — a diamond at L0 to L2 can stay open for months while cycles close under it weekly. Measured on the dogfood repo (2026-08-30): 17 cycles in 116 days, median 3.5 days apart, while every diamond stayed open the whole time; the earlier wording (\"after every completed delivery diamond or significant milestone\") named two units forty times apart and the load-bearing one was the vague one. Source: Forsgren (learning culture).\n\n## Preflight: Read target canvas file(s) before any Write\u002FEdit\n\n**Hard rule.** Before issuing `Write` or `Edit` against any `.claude\u002Fcanvas\u002F*.yml`, use the **Read tool** on that file in this session. Claude Code's Read-before-Write check requires the `Read` tool specifically — `cat`\u002F`head`\u002F`grep` via Bash do NOT satisfy it.\n\n**Edit vs Write — different cost profiles** (verified 2026-05-14):\n- **`Edit`** (exact-string replacement): `Read` with `limit: 1` satisfies the check at ~50 tokens. State-tracking is per-file, not per-byte — subsequent `Edit` calls work anywhere in the file. Use this for partial updates against large canvas files (e.g., `purpose.yml` at 800+ lines).\n- **`Write`** (full replacement): do a **full Read** first. Write obliterates the file; you should see what you're about to replace. The `limit:1` shortcut is *not* appropriate here.\n\n**ID-bearing entries — scan the ID space before assigning** (added 2026-05-15, v0.23.19): When adding a new component, opportunity, solution, or any other ID-bearing entry to a canvas file, run a Bash grep first to confirm the next ID in your prefix sequence is actually free:\n\n```\ngrep -o \"\u003Cprefix>-[0-9][0-9]*\" .claude\u002Fcanvas\u002F\u003Cfile>.yml | sort -u -t- -k2 -n | tail -3\n```\n\nReplace `\u003Cprefix>` with the canvas's ID prefix (`comp` for landscape, `opp` for opportunities, `sol` for solutions, `ht` for human-tasks, etc.). Then pick the next free integer, **matching the zero-padding already used in that file**. The sort is NUMERIC (`-t- -k2 -n`) rather than lexical, and that is not pedantry: a plain `sort -u` orders `ht-1` after `ht-080`, so on a canvas with inconsistent padding it reports the wrong maximum and the next ID collides. Verified on the dogfood repo 2026-08-13, where lexical sort returned `ht-1` as the highest human-task ID against an actual `ht-080`. `grep -o` is also deliberate: it matches IDs wherever they appear, including cross-references and prose, so an ID that was promised somewhere but not yet defined is not handed out twice. `validate_canvas.py` has a per-file duplicate-ID check (it reports `duplicate id '\u003Cid>'`) that catches the failure on CI, but a duplicate can persist in the working tree for days if CI isn't run between edit and discovery; that happened on 2026-05-15, when a duplicate ID was created in `landscape.yml`.\n\nOriginal failure mode: anti-pattern #7 instance #5, 2026-05-09 — agent conflated Bash `head` with the Read tool, lost ~14k tokens to a Write-fail → remedial-full-Read → re-Write loop. The `limit:1` discipline (graduated 2026-05-14, v0.23.18) prevents the second-order cost where the agent *correctly* follows the rule but full-Reads every time. The ID-scan discipline (graduated 2026-05-15, v0.23.19) prevents the related class where the agent reads enough of the file to satisfy the Edit check but not enough to see existing ID assignments — kin to anti-pattern #8 (Stale State Read).\n\nIf this skill writes to multiple canvas files, register each one first (limit:1 for Edit-only paths; full Read for Write paths) AND ID-scan any prefix you intend to assign.\n\nSee `${CLAUDE_PLUGIN_ROOT}\u002Fengine\u002Fagent-operating-contract.md` *Canvas writes — Read before Write* for the canonical rule.\n\n## Workflow\n\nRun these steps IN ORDER. Do not skip any step. **Step 1 (cycle recording) MUST be completed FIRST — before any reflective analysis.**\n\n### Step 1. Record Cycle in `.claude\u002Fcanvas\u002Fcycle-history.yml` AND Decision Log (MANDATORY — DO THIS FIRST)\n\n**This step is critical.** Without it, the learning metabolism has no data. You MUST do BOTH parts (5a and 5b).\n\n#### Step 5a. Write cycle record to `.claude\u002Fcanvas\u002Fcycle-history.yml`\n\nFind the leaf_id and opportunity_id for the delivered solution (from `.claude\u002Fcanvas\u002Fopportunities.yml` or `.claude\u002Fcanvas\u002Fgist.yml`). Then write a cycle record:\n\n```yaml\n- cycle_id: cycle-NNN\n  leaf_id: \"opp-XXX-sol-X\"         # From opportunities.yml\n  opportunity_id: \"opp-XXX\"         # Parent opportunity\n  diamond_id: \"d-XXX\"               # From .claude\u002Fdiamonds\u002Factive.yml\n  completed_at: \"YYYY-MM-DDTHH:MM:SSZ\"\n  outcome: shipped | partial | failed | discarded\n  cycle_class: product-leaf | meta-dogfood | observation  # REQUIRED — see engine\u002Fcycle-learning.md#cycle-class\n  predicted:\n    ice_score: {i: X, c: X.XX, e: X, total: X}  # total = i x c x e (Gilad's ICE; c from his Confidence Meter). REQUIRED recorded when cycle_class=product-leaf; permitted all-zero for meta-dogfood\u002Fobservation (state why in notes)\n    feasibility_risk: low | medium | high        # From four_risks\n    effort_estimate: \"X days\u002Fweeks\"              # Original estimate\n  actual:\n    effort: \"X days\u002Fweeks\"                       # How long it actually took\n    dora:                                        # From \u002Fmycelium:dora-check or known metrics\n      deploy_frequency: \"...\"\n      lead_time: \"...\"\n      change_failure_rate: \"...\"\n      mttr: \"...\"\n  calibration:\n    ice_accuracy: \"predicted XXX vs actual [outcome description]\"\n    effort_accuracy: \"predicted X days vs actual X days (delta: +\u002F-X)\"\n    risk_accuracy: \"feasibility was [predicted] — actual was [description]\"\n  demand_type: value                             # value | failure — WHY this cycle exists (Seddon)\n  demand_origin: \"\"                              # required when failure: the earlier work that caused it\n  demand_cost_class: null                        # optional: prevention|appraisal|internal-failure|external-failure\n  gates_fired:                                   # which theory gates fired; result pass|fail (fail = caught a real gap)\n    - {gate: \"\u003Cgate name>\", result: pass, caught: \"\"}\n  regressions:                                   # in-cycle phase regressions (NOT post-delivery rework)\n    in_cycle_count: 0\n    from_phase: null\n    to_phase: null\n    trigger: \"\"\n  learnings: \"Key learning from this cycle\"\n```\n\n**`demand_type` is the one field you should already know before the retrospective starts.** Ask why\nthe cycle existed: did a user, a goal or a deliberate bet ask for it (`value`), or did it exist\nbecause earlier work was wrong, missing or incomplete (`failure`)? **If you are reconstructing the\nanswer now, say so** — set `reconstructed_post_hoc: true`, because Seddon's method classifies demand\nas it ARRIVES and a type assigned weeks later reports on the assessor. **`failure` requires\n`demand_origin`**: a failure cycle that cannot name the earlier work that caused it is usually\nmis-classed as failure when it is value, or hiding the real cause. **Do not route this through\n`rework`** — that block is post-delivery defects in a 14-day window; work begun because earlier work\nwas incomplete is not a post-delivery regression, it is the reason the cycle exists.\n\n**Populate `gates_fired` and `regressions` from the analysis you already do below** (Step \"Where did the theory gates catch a real problem?\" → `gates_fired`; \"How many regressions occurred?\" → split: mid-cycle phase regressions go to `regressions.in_cycle_count`\u002F`from_phase`\u002F`to_phase`\u002F`trigger`, post-launch defects stay in `rework.post_delivery_regressions`). If no gate fired and no regression occurred, write the empty\u002Fzero forms explicitly — absence recorded is a measurement; a missing field is not (anti-pattern #9, Fail-Open on Absent Input).\n\nUpdate `calibration_summary.total_cycles` count. If total_cycles reaches a multiple of 5, prompt: \"5 cycles since last review. Run `\u002Fmycelium:framework-health` to check calibration?\"\n\n**Hard gate on `cycle_class: product-leaf`**: if the cycle being closed shipped an OST solution leaf, `predicted.ice_score` must be a recorded score. Recorded means: `total` is not zero, or `total` is zero and the three factors are there with at least one of them above zero (an Impact of 0 is legal in Gilad's ICE and totals 0; changed 0.319.0, until then the rule was \"`total` must be non-zero\"). `{i: 0, c: 0, e: 0, total: 0}` is not a score. Copy the score as it stood when the cycle opened, whichever arithmetic it was written under; do not recompute an older average or product into the current form. If no score is recorded, do NOT write the record yet — stop and ask: \"This cycle shipped a product leaf but has no recorded ICE prediction. Was `\u002Fmycelium:ice-score` run before the cycle opened? If yes, copy the score from `opportunities.yml`. If no, this is a Check 38 violation — class the cycle as `meta-dogfood` if no design tradeoff was actually scored, or backfill the ICE score with an honest reconstruction noted as `reconstructed_post_hoc: true`.\" Reconstructed scores are excluded from calibration aggregates but preserved for the audit trail.\n\n#### Step 5b. Log cycle calibration summary in .claude\u002Fharness\u002Fdecision-log.md\n\nWrite a decision log entry titled \"Cycle calibration record\" that includes ALL of the following (use these exact words):\n\n- **cycle** number and diamond ID\n- **predicted** ICE score and effort estimate (from the original canvas)\n- **actual** outcome and effort (from what really happened)\n- **calibration** assessment: was the prediction accurate?\n- **effort** delta: if the estimate was an **underestimate** or overestimate, state the **accuracy** gap (e.g., \"effort accuracy: predicted 5 days vs actual 7 days, 40% underestimate\")\n- Risk dimension accuracy (e.g., \"feasibility was predicted medium — actual confirmed, analytics pipeline was indeed the hardest part\")\n\nThis decision log entry ensures the calibration data is auditable alongside other decisions, not just buried in cycle-history.yml.\n\n### Step 2. What Went Well?\n- Which patterns from patterns.md were reused successfully?\n- What new approaches worked?\n- Where did the theory gates catch a real problem?\n\n### Step 3. What Didn't Go Well?\n- What mistakes were made? (Add to corrections.md)\n- Where did we skip a guardrail and regret it?\n- What took longer than expected and why?\n\n### Step 4. What Should Change?\n- New corrections to add\n- New patterns to capture\n- Process improvements\n- Guardrail adjustments\n- ADR review (if `docs\u002Fadr\u002F` exists): did implementation follow the decided approach? Any consequences that turned out differently than expected? Mark superseded ADRs.\n\n### Step 5. BVSSH Dimension Check\n- **Better**: Did quality improve or degrade?\n- **Value**: Did we deliver actual user value?\n- **Sooner**: Was our flow efficient?\n- **Safer**: Did we maintain security and trust?\n- **Happier**: How is team satisfaction? Customer advocacy? Societal impact? Was compute usage proportionate to value (not wasteful)?\n\n### Step 6. Rework Follow-Up (14-day window)\n\nIf this retrospective is for a cycle completed more than 14 days ago, check:\n- How many corrections were logged against this delivery since completion? → `rework.post_delivery_corrections`\n- How many regressions occurred? → `rework.post_delivery_regressions`\n- Days to first regression? → `rework.days_to_first_regression`\n\nUpdate the cycle record in `.claude\u002Fcanvas\u002Fcycle-history.yml` with the rework fields. This is the denominator — the hidden cost of delivery that velocity metrics miss.\n\nIf this retrospective is for a just-completed cycle, prompt: \"Set a reminder to check rework in 14 days. Run `\u002Fmycelium:retrospective rework-check [cycle-id]` after that.\"\n\n*Source: Paddo (the denominator problem — 43% of AI-assisted code requires post-delivery debugging). Forsgren (change failure rate as a trailing indicator).*\n\n## Root Cause Analysis (when \"What Didn't Go Well\" surfaces a significant problem)\n\nUse these two complementary techniques. Fishbone gives breadth (all possible causes). 5 Whys gives depth (one cause traced to its root).\n\n### Fishbone Diagram (Ishikawa)\n\nMap all potential causes before investigating any. Structure:\n\n```\n                        ┌─ People (skills, handoffs, communication)\n                        ├─ Process (gates, cadence, workflow)\nProblem ◄───────────────├─ Product (canvas, evidence, assumptions)\n(effect)                ├─ Platform (tools, infra, dependencies)\n                        ├─ Principles (which theory\u002Fguardrail failed?)\n                        └─ Pressures (deadlines, scope, external)\n```\n\n1. Write the specific problem at the head\n2. Brainstorm causes in each category — add as branches\n3. Drill into sub-causes until you reach actionable items\n4. Vote\u002Frank the most likely root causes for investigation\n\nIshikawa's original 6M manufacturing categories: Man (Manpower), Machine, Method, Material, Measurement, Mother Nature (Environment). Adapted for product development as: Man→People, Machine→Platform, Method→Process, Material→Product (inputs to the work), Measurement→Principles (what we measure against), Mother Nature→Pressures (external forces).\n\n### 5 Whys (Toyoda)\n\nFor the top-ranked cause from the fishbone, ask \"why?\" five times:\n\n1. Why did this happen? → [first-level cause]\n2. Why did that happen? → [second-level cause]\n3. Why? → [deeper]\n4. Why? → [deeper]\n5. Why? → [root cause — usually systemic]\n\n**Stop rule**: Stop when ANY of these conditions are met:\n- You reach something you can **change systemically** (a guardrail, gate, or process step)\n- Asking \"why\" again would require **speculation** rather than verifiable fact\n- You reach a cause **outside your sphere of influence** (an escalation point, not a dead end)\n- The answer would be **the same regardless** of asking \"why\" (you've hit bedrock)\n\n**Anti-pattern**: Stopping at \"human error\" — that's never the root cause. Ask why the system allowed the error.\n\n*Source: Ishikawa (cause-and-effect diagrams), Toyoda\u002FOhno (5 Whys), adapted for agentic product development.*\n\n### Waste Identification (Ohno — 7 Wastes \u002F TIMWOOD)\n\n\"Eliminating waste is the foundation of lean.\" (Ohno)\n\nBefore root cause analysis, identify which waste category the problem falls into:\n\n| Waste | Product Development Form | Detection |\n|---|---|---|\n| **T**ransportation | Handoffs between people\u002Fteams, between discovery and delivery | Count handoffs in the value stream |\n| **I**nventory | WIP, unshipped code, unfinished features, unmerged branches, open PRs | Check WIP limits, branch age |\n| **M**otion | Context switching between tasks, tools, codebases | Track focus time vs fragmented time |\n| **W**aiting | Blocked tasks, review queues, approval bottlenecks, blocked dependencies | Measure wait-to-work ratio |\n| **O**verproduction | Building features nobody uses, YAGNI violations | Compare shipped features to validated needs |\n| **O**verprocessing | Gold-plating, unnecessary abstraction, premature optimization | \"Would removing this step reduce value?\" |\n| **D**efects | Bugs, rework, corrections, failed deployments | Track defect escape rate |\n\nAlso watch for: **Muri** (overburden → BVSSH Happier \u002F sustainable pace) and **Mura** (unevenness → delivery cadence variation).\n\n*Source: Taiichi Ohno, Sakichi Toyoda (Toyota Production System). Mapped to product development via Poppendieck (Lean Software Development).*\n\n## Blameless Post-Mortem Format (SRE)\n\nFor incidents or significant failures, use the SRE blameless post-mortem:\n1. **Timeline**: What happened, when, in what order\n2. **Impact**: Who was affected, how severely, for how long\n3. **Contributing factors**: What conditions led to this (NOT \"who caused it\")\n4. **Root cause**: The systemic issue, not the human action (use fishbone + 5 Whys above)\n5. **Action items**: Specific, assigned, time-bound improvements\n6. **What went well**: What prevented it from being worse\n\nRule: No blame. Focus on the system, not the person. *Source: Beyer et al. (SRE)*\n\n## Refactoring Prompt\n\nAfter delivery retrospective, always ask:\n- \"Are there refactoring opportunities? Duplicated logic (DRY)? Unnecessary complexity (KISS)?\"\n*Source: Beck (XP), Fowler (Refactoring)*\n\n## Output\n1. Update `.claude\u002Fmemory\u002Fcorrections.md` with new corrections\n2. Update `.claude\u002Fmemory\u002Fpatterns.md` with new patterns\n3. Update `.claude\u002Fmemory\u002Fdelivery-journal.md` with retrospective entry\n4. Update .claude\u002Fcanvas\u002Fbvssh-health.yml if dimensions changed\n5. Log in .claude\u002Fharness\u002Fdecision-log.md\n6. Record cycle in `.claude\u002Fcanvas\u002Fcycle-history.yml` (see Cycle History Recording above)\n7. **Doctrine retrospective, when it is due** — see below.\n\n## The doctrine retrospective, and its firing condition (v0.230.0)\n\nDoctrine is the one register with a named producer and, until this release, **no trigger**.\n*\"Learn these continuously\"* is not a trigger, and an un-triggered retrospective is the shape that\nhas failed repeatedly in this project — a mechanism that runs when someone remembers is a mechanism\nthat reads green while doing nothing.\n\n**IT IS DUE WHEN**: `.claude\u002Fcanvas\u002Fdoctrine.yml#last_reviewed` is **absent**, or **earlier than the\nnewest `completed_at` in `diamonds\u002Factive.yml#completed_diamonds`** — or a climate prediction is\npast its `horizon` with no `outcome`. That is the trigger — an event that already gets recorded,\nnot a calendar someone has to keep. It became checkable only in this same release, when completion\nstopped being conflated with archival and got a writer; before that there was no event to hang it on.\n\n**YOU DO NOT HAVE TO REMEMBER TO ASK.** `scripts\u002Fcheck_doctrine_due.py` evaluates the condition and\n`session-start` relays its line, so a due retrospective arrives unprompted. Run it directly any time:\n\n```bash\npython3 \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fcheck_doctrine_due.py\" --project-dir .\n```\n\n*v0.231.0 shipped this condition with no evaluator — it lived only as the paragraph you are reading,\nso it fired when someone happened to open this skill. That is the \"runs when a person remembers\"\nshape the condition was written to replace, and **a condition nothing computes reads as satisfied**.\nThe evaluator landed in v0.231.2. Note what it will NOT say: with no diamond in `completed_diamonds`\nit reports that the trigger cannot fire, explicitly not that doctrine is current.*\n\nWhen it is due, ask Wardley's question — *\"look for what has changed and always ask why?\"* — and\nwrite to `.claude\u002Fcanvas\u002Fdoctrine.yml`:\n\n- **Doctrine**: did something we learned turn out to apply *universally* to our own work? Add it with\n  the incident it came from. **`learned_from` is required**, because a principle with no incident\n  behind it was imported rather than learned. Doctrine **grows and never completes** — *\"the more you\n  play the game then the more forms of doctrine you'll discover\"* — so **do not compute coverage\n  against a total.** There is no total. That is what made the 2026-04 audit's ratios unscoreable.\n- **Climate**: score any prediction whose horizon has passed — `held`, `failed`, or `unclear`.\n  **`unclear` is a real answer** and beats forcing a verdict; leaving it `unscored` is also honest,\n  but `unscored` must never be reported as `held`. Add new predictions **dated**, because a\n  prediction that cannot go stale cannot be scored.\n\nThen stamp `last_reviewed`. **An empty doctrine register after a review is a legitimate outcome** —\nwrite the stamp anyway, or the trigger fires forever and the nudge gets muted.\n\n## Counter-Argument Check (Bias Mitigation)\n\nBefore finalizing the retrospective, draft a one-line counter-argument for each major claim: *\"What's the strongest case that this 'went well' was actually luck? That this 'went wrong' was actually unavoidable? That this 'pattern' is actually noise?\"* If you can't articulate counter-cases, run `\u002Fmycelium:devils-advocate` before locking in the corrections\u002Fpatterns.\n\nThis addresses the bias cluster documented in corrections.md (L5 sycophancy 2026-04-20, eval overfitting 2026-04-30, sharper-framing-isn't-righter 2026-05-03). Retrospectives are particularly bias-prone — narrative coherence is rewarded, the agent is incentivized to find tidy patterns, and post-hoc rationalization is the natural mode. Counter-arguments break that gravity.\n\n### Hindsight Bias Check\n\nRetrospectives are the natural home of *hindsight bias* — the \"I knew it all along\" effect that rewrites uncertainty as foreknowledge. For every claim of the form \"we should have seen X coming,\" ask: *would I have predicted X with the evidence available BEFORE the outcome?* If the honest answer is \"no, that evidence only became diagnostic in retrospect,\" log it as a learning about evidence interpretation, not as a missed signal. This protects future retrospectives from manufacturing false should-have-knowns that distort confidence calibration.\n\n*Source: Fischhoff, \"Hindsight ≠ Foresight: The Effect of Outcome Knowledge on Judgment Under Uncertainty\" (1975).*\n\nEspecially important when proposing graduation candidates (recurring corrections → guardrails) — make sure the recurrence is real, not 3 instances of pattern-matching by the agent itself.\n\n## Postflight: Verify-After-Write (claim matches state)\n\n**Hard rule** (per the operating contract's Communication Rules, anti-pattern #7 *write-narration-verification* — mechanism Check 42, graduated v0.39.18; enforced surface expanded to this skill v0.44.0). This skill mandates multi-field canvas updates. Before narrating \"updated \u002F wrote \u002F refreshed [canvas]\" in any user-facing summary, RE-READ the value fields this skill's MANDATORY says to update and confirm they actually changed — not just `_meta.last_validated` or a freshness stamp. Each field you claim to have updated must reflect its new value. The symmetric half of the Read-before-Write Preflight: that one protects what gets read before a write; this one protects that the write matches the claim. Worked failures: 2026-06-05 #18 (`\u002Fdora-check` narrated \"updated\" with value fields unchanged) + #19 (`\u002Fretrospective` left a cycle-history aggregate un-propagated).\n","# Retrospective\n\nRun after every completed **cycle**: a solution leaf reaching a terminal state (launched, archived, killed), or a framework-development arc that shipped. Not only after a diamond completes — a diamond at L0 to L2 can stay open for months while cycles close under it weekly. Measured on the dogfood repo (2026-08-30): 17 cycles in 116 days, median 3.5 days apart, while every diamond stayed open the whole time; the earlier wording (\"after every completed delivery diamond or significant milestone\") named two units forty times apart and the load-bearing one was the vague one. Source: Forsgren (learning culture).\n\n## Preflight: Read target canvas file(s) before any Write\u002FEdit\n\n**Hard rule.** Before issuing `Write` or `Edit` against any `.claude\u002Fcanvas\u002F*.yml`, use the **Read tool** on that file in this session. Claude Code's Read-before-Write check requires the `Read` tool specifically — `cat`\u002F`head`\u002F`grep` via Bash do NOT satisfy it.\n\n**Edit vs Write — different cost profiles** (verified 2026-05-14):\n- **`Edit`** (exact-string replacement): `Read` with `limit: 1` satisfies the check at ~50 tokens. State-tracking is per-file, not per-byte — subsequent `Edit` calls work anywhere in the file. Use this for partial updates against large canvas files (e.g., `purpose.yml` at 800+ lines).\n- **`Write`** (full replacement): do a **full Read** first. Write obliterates the file; you should see what you're about to replace. The `limit:1` shortcut is *not* appropriate here.\n\n**ID-bearing entries — scan the ID space before assigning** (added 2026-05-15, v0.23.19): When adding a new component, opportunity, solution, or any other ID-bearing entry to a canvas file, run a Bash grep first to confirm the next ID in your prefix sequence is actually free:\n\n```\ngrep -o \"\u003Cprefix>-[0-9][0-9]*\" .claude\u002Fcanvas\u002F\u003Cfile>.yml | sort -u -t- -k2 -n | tail -3\n```\n\nReplace `\u003Cprefix>` with the canvas's ID prefix (`comp` for landscape, `opp` for opportunities, `sol` for solutions, `ht` for human-tasks, etc.). Then pick the next free integer, **matching the zero-padding already used in that file**. The sort is NUMERIC (`-t- -k2 -n`) rather than lexical, and that is not pedantry: a plain `sort -u` orders `ht-1` after `ht-080`, so on a canvas with inconsistent padding it reports the wrong maximum and the next ID collides. Verified on the dogfood repo 2026-08-13, where lexical sort returned `ht-1` as the highest human-task ID against an actual `ht-080`. `grep -o` is also deliberate: it matches IDs wherever they appear, including cross-references and prose, so an ID that was promised somewhere but not yet defined is not handed out twice. `validate_canvas.py` has a per-file duplicate-ID check (it reports `duplicate id '\u003Cid>'`) that catches the failure on CI, but a duplicate can persist in the working tree for days if CI isn't run between edit and discovery; that happened on 2026-05-15, when a duplicate ID was created in `landscape.yml`.\n\nOriginal failure mode: anti-pattern #7 instance #5, 2026-05-09 — agent conflated Bash `head` with the Read tool, lost ~14k tokens to a Write-fail → remedial-full-Read → re-Write loop. The `limit:1` discipline (graduated 2026-05-14, v0.23.18) prevents the second-order cost where the agent *correctly* follows the rule but full-Reads every time. The ID-scan discipline (graduated 2026-05-15, v0.23.19) prevents the related class where the agent reads enough of the file to satisfy the Edit check but not enough to see existing ID assignments — kin to anti-pattern #8 (Stale State Read).\n\nIf this skill writes to multiple canvas files, register each one first (limit:1 for Edit-only paths; full Read for Write paths) AND ID-scan any prefix you intend to assign.\n\nSee `${CLAUDE_PLUGIN_ROOT}\u002Fengine\u002Fagent-operating-contract.md` *Canvas writes — Read before Write* for the canonical rule.\n\n## Workflow\n\nRun these steps IN ORDER. Do not skip any step. **Step 1 (cycle recording) MUST be completed FIRST — before any reflective analysis.**\n\n### Step 1. Record Cycle in `.claude\u002Fcanvas\u002Fcycle-history.yml` AND Decision Log (MANDATORY — DO THIS FIRST)\n\n**This step is critical.** Without it, the learning metabolism has no data. You MUST do BOTH parts (5a and 5b).\n\n#### Step 5a. Write cycle record to `.claude\u002Fcanvas\u002Fcycle-history.yml`\n\nFind the leaf_id and opportunity_id for the delivered solution (from `.claude\u002Fcanvas\u002Fopportunities.yml` or `.claude\u002Fcanvas\u002Fgist.yml`). Then write a cycle record:\n\n```yaml\n- cycle_id: cycle-NNN\n  leaf_id: \"opp-XXX-sol-X\"         # From opportunities.yml\n  opportunity_id: \"opp-XXX\"         # Parent opportunity\n  diamond_id: \"d-XXX\"               # From .claude\u002Fdiamonds\u002Factive.yml\n  completed_at: \"YYYY-MM-DDTHH:MM:SSZ\"\n  outcome: shipped | partial | failed | discarded\n  cycle_class: product-leaf | meta-dogfood | observation  # REQUIRED — see engine\u002Fcycle-learning.md#cycle-class\n  predicted:\n    ice_score: {i: X, c: X.XX, e: X, total: X}  # total = i x c x e (Gilad's ICE; c from his Confidence Meter). REQUIRED recorded when cycle_class=product-leaf; permitted all-zero for meta-dogfood\u002Fobservation (state why in notes)\n    feasibility_risk: low | medium | high        # From four_risks\n    effort_estimate: \"X days\u002Fweeks\"              # Original estimate\n  actual:\n    effort: \"X days\u002Fweeks\"                       # How long it actually took\n    dora:                                        # From \u002Fmycelium:dora-check or known metrics\n      deploy_frequency: \"...\"\n      lead_time: \"...\"\n      change_failure_rate: \"...\"\n      mttr: \"...\"\n  calibration:\n    ice_accuracy: \"predicted XXX vs actual [outcome description]\"\n    effort_accuracy: \"predicted X days vs actual X days (delta: +\u002F-X)\"\n    risk_accuracy: \"feasibility was [predicted] — actual was [description]\"\n  demand_type: value                             # value | failure — WHY this cycle exists (Seddon)\n  demand_origin: \"\"                              # required when failure: the earlier work that caused it\n  demand_cost_class: null                        # optional: prevention|appraisal|internal-failure|external-failure\n  gates_fired:                                   # which theory gates fired; result pass|fail (fail = caught a real gap)\n    - {gate: \"\u003Cgate name>\", result: pass, caught: \"\"}\n  regressions:                                   # in-cycle phase regressions (NOT post-delivery rework)\n    in_cycle_count: 0\n    from_phase: null\n    to_phase: null\n    trigger: \"\"\n  learnings: \"Key learning from this cycle\"\n```\n\n**`demand_type` is the one field you should already know before the retrospective starts.** Ask why\nthe cycle existed: did a user, a goal or a deliberate bet ask for it (`value`), or did it exist\nbecause earlier work was wrong, missing or incomplete (`failure`)? **If you are reconstructing the\nanswer now, say so** — set `reconstructed_post_hoc: true`, because Seddon's method classifies demand\nas it ARRIVES and a type assigned weeks later reports on the assessor. **`failure` requires\n`demand_origin`**: a failure cycle that cannot name the earlier work that caused it is usually\nmis-classed as failure when it is value, or hiding the real cause. **Do not route this through\n`rework`** — that block is post-delivery defects in a 14-day window; work begun because earlier work\nwas incomplete is not a post-delivery regression, it is the reason the cycle exists.\n\n**Populate `gates_fired` and `regressions` from the analysis you already do below** (Step \"Where did the theory gates catch a real problem?\" → `gates_fired`; \"How many regressions occurred?\" → split: mid-cycle phase regressions go to `regressions.in_cycle_count`\u002F`from_phase`\u002F`to_phase`\u002F`trigger`, post-launch defects stay in `rework.post_delivery_regressions`). If no gate fired and no regression occurred, write the empty\u002Fzero forms explicitly — absence recorded is a measurement; a missing field is not (anti-pattern #9, Fail-Open on Absent Input).\n\nUpdate `calibration_summary.total_cycles` count. If total_cycles reaches a multiple of 5, prompt: \"5 cycles since last review. Run `\u002Fmycelium:framework-health` to check calibration?\"\n\n**Hard gate on `cycle_class: product-leaf`**: if the cycle being closed shipped an OST solution leaf, `predicted.ice_score` must be a recorded score. Recorded means: `total` is not zero, or `total` is zero and the three factors are there with at least one of them above zero (an Impact of 0 is legal in Gilad's ICE and totals 0; changed 0.319.0, until then the rule was \"`total` must be non-zero\"). `{i: 0, c: 0, e: 0, total: 0}` is not a score. Copy the score as it stood when the cycle opened, whichever arithmetic it was written under; do not recompute an older average or product into the current form. If no score is recorded, do NOT write the record yet — stop and ask: \"This cycle shipped a product leaf but has no recorded ICE prediction. Was `\u002Fmycelium:ice-score` run before the cycle opened? If yes, copy the score from `opportunities.yml`. If no, this is a Check 38 violation — class the cycle as `meta-dogfood` if no design tradeoff was actually scored, or backfill the ICE score with an honest reconstruction noted as `reconstructed_post_hoc: true`.\" Reconstructed scores are excluded from calibration aggregates but preserved for the audit trail.\n\n#### Step 5b. Log cycle calibration summary in .claude\u002Fharness\u002Fdecision-log.md\n\nWrite a decision log entry titled \"Cycle calibration record\" that includes ALL of the following (use these exact words):\n\n- **cycle** number and diamond ID\n- **predicted** ICE score and effort estimate (from the original canvas)\n- **actual** outcome and effort (from what really happened)\n- **calibration** assessment: was the prediction accurate?\n- **effort** delta: if the estimate was an **underestimate** or overestimate, state the **accuracy** gap (e.g., \"effort accuracy: predicted 5 days vs actual 7 days, 40% underestimate\")\n- Risk dimension accuracy (e.g., \"feasibility was predicted medium — actual confirmed, analytics pipeline was indeed the hardest part\")\n\nThis decision log entry ensures the calibration data is auditable alongside other decisions, not just buried in cycle-history.yml.\n\n### Step 2. What Went Well?\n- Which patterns from patterns.md were reused successfully?\n- What new approaches worked?\n- Where did the theory gates catch a real problem?\n\n### Step 3. What Didn't Go Well?\n- What mistakes were made? (Add to corrections.md)\n- Where did we skip a guardrail and regret it?\n- What took longer than expected and why?\n\n### Step 4. What Should Change?\n- New corrections to add\n- New patterns to capture\n- Process improvements\n- Guardrail adjustments\n- ADR review (if `docs\u002Fadr\u002F` exists): did implementation follow the decided approach? Any consequences that turned out differently than expected? Mark superseded ADRs.\n\n### Step 5. BVSSH Dimension Check\n- **Better**: Did quality improve or degrade?\n- **Value**: Did we deliver actual user value?\n- **Sooner**: Was our flow efficient?\n- **Safer**: Did we maintain security and trust?\n- **Happier**: How is team satisfaction? Customer advocacy? Societal impact? Was compute usage proportionate to value (not wasteful)?\n\n### Step 6. Rework Follow-Up (14-day window)\n\nIf this retrospective is for a cycle completed more than 14 days ago, check:\n- How many corrections were logged against this delivery since completion? → `rework.post_delivery_corrections`\n- How many regressions occurred? → `rework.post_delivery_regressions`\n- Days to first regression? → `rework.days_to_first_regression`\n\nUpdate the cycle record in `.claude\u002Fcanvas\u002Fcycle-history.yml` with the rework fields. This is the denominator — the hidden cost of delivery that velocity metrics miss.\n\nIf this retrospective is for a just-completed cycle, prompt: \"Set a reminder to check rework in 14 days. Run `\u002Fmycelium:retrospective rework-check [cycle-id]` after that.\"\n\n*Source: Paddo (the denominator problem — 43% of AI-assisted code requires post-delivery debugging). Forsgren (change failure rate as a trailing indicator).*\n\n## Root Cause Analysis (when \"What Didn't Go Well\" surfaces a significant problem)\n\nUse these two complementary techniques. Fishbone gives breadth (all possible causes). 5 Whys gives depth (one cause traced to its root).\n\n### Fishbone Diagram (Ishikawa)\n\nMap all potential causes before investigating any. Structure:\n\n```\n                        ┌─ People (skills, handoffs, communication)\n                        ├─ Process (gates, cadence, workflow)\nProblem ◄───────────────├─ Product (canvas, evidence, assumptions)\n(effect)                ├─ Platform (tools, infra, dependencies)\n                        ├─ Principles (which theory\u002Fguardrail failed?)\n                        └─ Pressures (deadlines, scope, external)\n```\n\n1. Write the specific problem at the head\n2. Brainstorm causes in each category — add as branches\n3. Drill into sub-causes until you reach actionable items\n4. Vote\u002Frank the most likely root causes for investigation\n\nIshikawa's original 6M manufacturing categories: Man (Manpower), Machine, Method, Material, Measurement, Mother Nature (Environment). Adapted for product development as: Man→People, Machine→Platform, Method→Process, Material→Product (inputs to the work), Measurement→Principles (what we measure against), Mother Nature→Pressures (external forces).\n\n### 5 Whys (Toyoda)\n\nFor the top-ranked cause from the fishbone, ask \"why?\" five times:\n\n1. Why did this happen? → [first-level cause]\n2. Why did that happen? → [second-level cause]\n3. Why? → [deeper]\n4. Why? → [deeper]\n5. Why? → [root cause — usually systemic]\n\n**Stop rule**: Stop when ANY of these conditions are met:\n- You reach something you can **change systemically** (a guardrail, gate, or process step)\n- Asking \"why\" again would require **speculation** rather than verifiable fact\n- You reach a cause **outside your sphere of influence** (an escalation point, not a dead end)\n- The answer would be **the same regardless** of asking \"why\" (you've hit bedrock)\n\n**Anti-pattern**: Stopping at \"human error\" — that's never the root cause. Ask why the system allowed the error.\n\n*Source: Ishikawa (cause-and-effect diagrams), Toyoda\u002FOhno (5 Whys), adapted for agentic product development.*\n\n### Waste Identification (Ohno — 7 Wastes \u002F TIMWOOD)\n\n\"Eliminating waste is the foundation of lean.\" (Ohno)\n\nBefore root cause analysis, identify which waste category the problem falls into:\n\n| Waste | Product Development Form | Detection |\n|---|---|---|\n| **T**ransportation | Handoffs between people\u002Fteams, between discovery and delivery | Count handoffs in the value stream |\n| **I**nventory | WIP, unshipped code, unfinished features, unmerged branches, open PRs | Check WIP limits, branch age |\n| **M**otion | Context switching between tasks, tools, codebases | Track focus time vs fragmented time |\n| **W**aiting | Blocked tasks, review queues, approval bottlenecks, blocked dependencies | Measure wait-to-work ratio |\n| **O**verproduction | Building features nobody uses, YAGNI violations | Compare shipped features to validated needs |\n| **O**verprocessing | Gold-plating, unnecessary abstraction, premature optimization | \"Would removing this step reduce value?\" |\n| **D**efects | Bugs, rework, corrections, failed deployments | Track defect escape rate |\n\nAlso watch for: **Muri** (overburden → BVSSH Happier \u002F sustainable pace) and **Mura** (unevenness → delivery cadence variation).\n\n*Source: Taiichi Ohno, Sakichi Toyoda (Toyota Production System). Mapped to product development via Poppendieck (Lean Software Development).*\n\n## Blameless Post-Mortem Format (SRE)\n\nFor incidents or significant failures, use the SRE blameless post-mortem:\n1. **Timeline**: What happened, when, in what order\n2. **Impact**: Who was affected, how severely, for how long\n3. **Contributing factors**: What conditions led to this (NOT \"who caused it\")\n4. **Root cause**: The systemic issue, not the human action (use fishbone + 5 Whys above)\n5. **Action items**: Specific, assigned, time-bound improvements\n6. **What went well**: What prevented it from being worse\n\nRule: No blame. Focus on the system, not the person. *Source: Beyer et al. (SRE)*\n\n## Refactoring Prompt\n\nAfter delivery retrospective, always ask:\n- \"Are there refactoring opportunities? Duplicated logic (DRY)? Unnecessary complexity (KISS)?\"\n*Source: Beck (XP), Fowler (Refactoring)*\n\n## Output\n1. Update `.claude\u002Fmemory\u002Fcorrections.md` with new corrections\n2. Update `.claude\u002Fmemory\u002Fpatterns.md` with new patterns\n3. Update `.claude\u002Fmemory\u002Fdelivery-journal.md` with retrospective entry\n4. Update .claude\u002Fcanvas\u002Fbvssh-health.yml if dimensions changed\n5. Log in .claude\u002Fharness\u002Fdecision-log.md\n6. Record cycle in `.claude\u002Fcanvas\u002Fcycle-history.yml` (see Cycle History Recording above)\n7. **Doctrine retrospective, when it is due** — see below.\n\n## The doctrine retrospective, and its firing condition (v0.230.0)\n\nDoctrine is the one register with a named producer and, until this release, **no trigger**.\n*\"Learn these continuously\"* is not a trigger, and an un-triggered retrospective is the shape that\nhas failed repeatedly in this project — a mechanism that runs when someone remembers is a mechanism\nthat reads green while doing nothing.\n\n**IT IS DUE WHEN**: `.claude\u002Fcanvas\u002Fdoctrine.yml#last_reviewed` is **absent**, or **earlier than the\nnewest `completed_at` in `diamonds\u002Factive.yml#completed_diamonds`** — or a climate prediction is\npast its `horizon` with no `outcome`. That is the trigger — an event that already gets recorded,\nnot a calendar someone has to keep. It became checkable only in this same release, when completion\nstopped being conflated with archival and got a writer; before that there was no event to hang it on.\n\n**YOU DO NOT HAVE TO REMEMBER TO ASK.** `scripts\u002Fcheck_doctrine_due.py` evaluates the condition and\n`session-start` relays its line, so a due retrospective arrives unprompted. Run it directly any time:\n\n```bash\npython3 \"${CLAUDE_PLUGIN_ROOT}\u002Fscripts\u002Fcheck_doctrine_due.py\" --project-dir .\n```\n\n*v0.231.0 shipped this condition with no evaluator — it lived only as the paragraph you are reading,\nso it fired when someone happened to open this skill. That is the \"runs when a person remembers\"\nshape the condition was written to replace, and **a condition nothing computes reads as satisfied**.\nThe evaluator landed in v0.231.2. Note what it will NOT say: with no diamond in `completed_diamonds`\nit reports that the trigger cannot fire, explicitly not that doctrine is current.*\n\nWhen it is due, ask Wardley's question — *\"look for what has changed and always ask why?\"* — and\nwrite to `.claude\u002Fcanvas\u002Fdoctrine.yml`:\n\n- **Doctrine**: did something we learned turn out to apply *universally* to our own work? Add it with\n  the incident it came from. **`learned_from` is required**, because a principle with no incident\n  behind it was imported rather than learned. Doctrine **grows and never completes** — *\"the more you\n  play the game then the more forms of doctrine you'll discover\"* — so **do not compute coverage\n  against a total.** There is no total. That is what made the 2026-04 audit's ratios unscoreable.\n- **Climate**: score any prediction whose horizon has passed — `held`, `failed`, or `unclear`.\n  **`unclear` is a real answer** and beats forcing a verdict; leaving it `unscored` is also honest,\n  but `unscored` must never be reported as `held`. Add new predictions **dated**, because a\n  prediction that cannot go stale cannot be scored.\n\nThen stamp `last_reviewed`. **An empty doctrine register after a review is a legitimate outcome** —\nwrite the stamp anyway, or the trigger fires forever and the nudge gets muted.\n\n## Counter-Argument Check (Bias Mitigation)\n\nBefore finalizing the retrospective, draft a one-line counter-argument for each major claim: *\"What's the strongest case that this 'went well' was actually luck? That this 'went wrong' was actually unavoidable? That this 'pattern' is actually noise?\"* If you can't articulate counter-cases, run `\u002Fmycelium:devils-advocate` before locking in the corrections\u002Fpatterns.\n\nThis addresses the bias cluster documented in corrections.md (L5 sycophancy 2026-04-20, eval overfitting 2026-04-30, sharper-framing-isn't-righter 2026-05-03). Retrospectives are particularly bias-prone — narrative coherence is rewarded, the agent is incentivized to find tidy patterns, and post-hoc rationalization is the natural mode. Counter-arguments break that gravity.\n\n### Hindsight Bias Check\n\nRetrospectives are the natural home of *hindsight bias* — the \"I knew it all along\" effect that rewrites uncertainty as foreknowledge. For every claim of the form \"we should have seen X coming,\" ask: *would I have predicted X with the evidence available BEFORE the outcome?* If the honest answer is \"no, that evidence only became diagnostic in retrospect,\" log it as a learning about evidence interpretation, not as a missed signal. This protects future retrospectives from manufacturing false should-have-knowns that distort confidence calibration.\n\n*Source: Fischhoff, \"Hindsight ≠ Foresight: The Effect of Outcome Knowledge on Judgment Under Uncertainty\" (1975).*\n\nEspecially important when proposing graduation candidates (recurring corrections → guardrails) — make sure the recurrence is real, not 3 instances of pattern-matching by the agent itself.\n\n## Postflight: Verify-After-Write (claim matches state)\n\n**Hard rule** (per the operating contract's Communication Rules, anti-pattern #7 *write-narration-verification* — mechanism Check 42, graduated v0.39.18; enforced surface expanded to this skill v0.44.0). This skill mandates multi-field canvas updates. Before narrating \"updated \u002F wrote \u002F refreshed [canvas]\" in any user-facing summary, RE-READ the value fields this skill's MANDATORY says to update and confirm they actually changed — not just `_meta.last_validated` or a freshness stamp. Each field you claim to have updated must reflect its new value. The symmetric half of the Read-before-Write Preflight: that one protects what gets read before a write; this one protects that the write matches the claim. Worked failures: 2026-06-05 #18 (`\u002Fdora-check` narrated \"updated\" with value fields unchanged) + #19 (`\u002Fretrospective` left a cycle-history aggregate un-propagated).\n",{"name":5,"metadata":48,"description":7},{"instruction_budget":49,"framework_dependency":29,"framework_dependency_note":50},"58","This skill is designed to run within the Mycelium framework (https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium). Standalone use will skip the canvas state, theory gates, and harness behavior the skill assumes. Install: \u002Fplugin install mycelium@haabe-mycelium.","main","d44421b0667bb71ad515ae7576dfc0f47b00504f","plugins\u002Fmycelium\u002Fskills\u002Fretrospective",6,"https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Fdocs\u002Fget-started.md","https:\u002F\u002Fgithub.com\u002Fhaabe","https:\u002F\u002Feccera.com\u002F","Building platform tooling for AI-assisted product development.","2026-11-07 04:07:58",{"source":8,"skillName":5,"commands":62,"prompt":72,"zipAvailable":73},[63,66,69],{"tool":64,"command":65},"npx","npx skills add haabe\u002Fmycelium --skill retrospective",{"tool":67,"command":68},"bunx","bunx skills add haabe\u002Fmycelium --skill retrospective",{"tool":70,"command":71},"pnpm","pnpm dlx skills add haabe\u002Fmycelium --skill retrospective","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Fplugins\u002Fmycelium\u002Fskills\u002Fretrospective\u002FSKILL.md",true,[],[76,88,101,112,118,125],{"skillNo":77,"name":78,"nameZh":6,"description":79,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":80,"categories":81,"keywords":83,"publishedAt":43},"01M6NVR17TVR7WM0MJD1TPY0CW","good_skill","Valid frontmatter.","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_8\u002Fvalid\u002Fplugins\u002Fmycelium\u002Fskills\u002Fgood_skill\u002FSKILL.md",[82],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[84,85,86,87],"good skill","good","frontmatter","valid",{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":95,"publishedAt":43},"01M6NVQPDAP1S4JQ5XFCT6P4PG","bad_skill","Has description but no name field.","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_8\u002Fmissing_name\u002Fplugins\u002Fmycelium\u002Fskills\u002Fbad_skill\u002FSKILL.md",[94],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[96,97,98,99,100],"bad skill","bad","name","but","no name",{"skillNo":102,"name":103,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":109,"publishedAt":43},"01M6NVQHEZAMP2JB45CA6Y3G1B","canvas-update","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_5\u002Fmissing_canvas_in_mapping\u002Fplugins\u002Fmycelium\u002Fskills\u002Fcanvas-update\u002FSKILL.md",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[34,110,111],"update","canvas update",{"skillNo":113,"name":103,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":117,"publishedAt":43},"01M6NVQDX6GEEHJ48WEPK0EG1Q","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_5\u002Fall_present\u002Fplugins\u002Fmycelium\u002Fskills\u002Fcanvas-update\u002FSKILL.md",[116],{"categoryNo":107,"categoryName":108,"taxonomyType":21,"taxonomyTypeDesc":22},[34,110,111],{"skillNo":119,"name":120,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":123,"publishedAt":43},"01M6NVQ5BH3VN7P9Q185Z2TMRN","ice-score","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_45\u002Fmissing_marker\u002Fplugins\u002Fmycelium\u002Fskills\u002Fice-score\u002FSKILL.md",[],[124],"ice score",{"skillNo":126,"name":127,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":128,"categories":129,"keywords":130,"publishedAt":43},"01M6NVPTQY2QMDABA1GJW5H1EG","bvssh-check","https:\u002F\u002Fgithub.com\u002Fhaabe\u002Fmycelium\u002Fblob\u002Fmain\u002Ftests\u002Fbash\u002Ffixtures\u002Fcheck_45\u002Fmissing_marker\u002Fplugins\u002Fmycelium\u002Fskills\u002Fbvssh-check\u002FSKILL.md",[],[131,132],"bvssh check","check"]