[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CWM69MNAYVHJBP2095GRJS":3,"skill-same:01M6CWM69MNAYVHJBP2095GRJS":97},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":62},"01M6CWM69MNAYVHJBP2095GRJS","learn",null,"Use after work begun with recall, or any work requiring more than one tool call or non-trivial thought. Use immediately for explicit save requests (\"remember this\", \"save that\", \"note for next time\"), and the moment a review, failing check, or user correction confirms a lesson; capture it before applying the fix. Also use at session end when a presented conclusion, design, or finding was later overturned or corrected. Use when a specific approach is confirmed: the user praises a reusable behavior, or an uncertain choice succeeds with observable evidence. This preserves lessons for future recall.","toejough\u002Fengram","toejough","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F5317312?v=4","01M6CWKZ6HJN0226G1FYVY0H0N","01M6CWKZAGT1SPMDWCZ3V8C1HZ",10,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fagent-instructions\u002Fskills\u002Flearn\u002FSKILL.md",[],[5,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"fix","time","next","call","lesson","later","reusable","evidence","use","session","design","behavior","check","work","choice","tool","recall","remember","review","2026-11-10 10:12:30",false,"---\nname: learn\ndescription: >\n  Use after work begun with recall, or any work requiring more than one tool call or non-trivial thought. Use immediately\n  for explicit save requests (\"remember this\", \"save that\", \"note for next time\"), and the moment a review, failing check,\n  or user correction confirms a lesson; capture it before applying the fix. Also use at session end when a presented\n  conclusion, design, or finding was later overturned or corrected. Use when a specific approach is confirmed: the user\n  praises a reusable behavior, or an uncertain choice succeeds with observable evidence. This preserves lessons for\n  future recall.\n---\n\n# Learn — Sweep Raw Memory, Crystallize Explicit Lessons\n\nTwo jobs, in order: (1) mechanically true up the chunk index so every conversation and doc is searchable memory, and (2) write a vault note for every explicit lesson this session — user corrections, explicit save-requests, presented conclusions that were later overturned, and confirmed approaches (user-praised or self-validated). Nothing else.\n\n> **Raw event memory is AUTOMATIC.** `engram ingest` chunks and embeds session transcripts and\n> markdown itself — no summaries, no episode notes, no arc detection. The agent's only writing\n> job is crystallizing EXPLICIT lessons. Do not reconstruct the old episode workflow\n> (`engram transcript`, `engram learn episode`) — it is gone.\n\n> **Mid-cycle capture (fast path).** When you fire at a CORRECTION moment mid-task — a review, a\n> failing check, or the user just rejected your approach or named a different convention — or at a\n> subagent return whose `LESSONS:` line carries a lesson that clears the bar, this is a\n> focused single-note capture, NOT the open\u002Fclose of a cycle. **SKIP Step 1 (sweep) and Step 1.5\n> (vocab); go straight to Step 2** and crystallize the ONE confirmed correction (hand off to\n> write-memory as always). Do NOT run `engram ingest --auto` mid-task — the sweep is a\n> cycle-boundary job, it is wasteful here and can block on a large corpus, and losing the capture to\n> a hung sweep is the failure mode. The closing learn still sweeps.\n\n## Step 1 — Sweep (first; the closing learn always sweeps)\n\n```bash\nengram ingest --auto\n```\n\nThat's it. The binary stats every known source (repo markdown, `.claude` dirs, all session\ntranscripts), re-chunks and re-embeds only what changed — within one source, existing chunks are\nnever deleted (append-only history). Across sources, byte-identical content is deduplicated: only\none canonical copy is indexed, and a duplicate's index is removed only once its retained twin is\nverified to cover its records (not on hash-match alone) — see `engram prune --duplicates` for the\nretroactive cleanup mode. Unchanged corpus → returns in seconds. Report the per-source lines it\nprints, or \"memory index up to date\" when it prints nothing.\n\nIf the command fails, surface the error and continue to Step 2 — explicit lessons must not be\nlost to an ingest hiccup.\n\nSkip the sweep if one already ran earlier in THIS session, UNLESS this is the closing learn of a\nwork cycle — the closing learn ALWAYS sweeps (it captures the session's tail for future sessions).\nThis holds even under a \"something might have changed outside this session (another terminal,\nanother agent)\" worry — that gets picked up by the next sweep (yours or theirs), not by\nre-sweeping now on suspicion.\n\n## Step 1.5 — Vocab liveness check\n\nRun `engram vocab stats`.\n\nIf the verdict is `verdict: OK`, continue to Step 2 with no further vocab action.\n\nIf the output includes a line matching `verdict: REFIT_PENDING (\u003Creason>)`, run the refit\nautonomously — do not defer to the user:\n\n1. Run `engram vocab refit`. The binary derives the clusters itself — there is no plan to\n   author. (`--dry-run` prints the derivation diff without writing; use it on the first refit\n   over a long-drifted vault if you want to sanity-check a mass retirement first.)\n2. If it prints `vocab refit: no structure found; vocabulary unchanged`, nothing was written\n   and there is no version bump — report exactly that (\"Vocab refit ran: no structure found,\n   vocabulary unchanged.\") and continue to Step 2. Do NOT claim an applied refit.\n   If every cluster matched an existing term, the run applies directly — skip to step 4.\n   If there are new clusters, the command prints a JSON payload\n   (`naming_requests` + `fingerprint`) and exits WITHOUT writing. Name each new cluster from\n   its exemplars, then write an answer file:\n\n   ```json\n   {\"names\": [{\"cluster\": 0, \"term\": \"kebab-case-term\", \"description\": \"one line\"}],\n    \"fingerprint\": \"\u003Cechoed verbatim from the request payload>\"}\n   ```\n\n   Cover every new cluster exactly once. Re-run: `engram vocab refit --names \u002Fpath\u002Fanswer.json`.\n3. If the re-run fails with a stale-names error (the vault changed between runs), the requests\n   are void — re-run `engram vocab refit` from scratch to regenerate them, and answer those.\n4. **Report loudly:** \"Vocab refit applied: \u003Cversion bump>. Triggered by: \u003Creason>.\"\n\nAlso check the QA round-2 gate line. If the output includes `qa round-2 gate: READY (...)`, report to Joe:\n\"QA round-2 validation is due (≥20 pairs captured). Please schedule the round-2 gates recorded in\ndocs\u002FROADMAP.md (The roadmap → GATED → Q&A memory round-2): P2′ attribution fidelity, P3′ distribution, Arm V larger-n.\" Do NOT run round-2 validation\nautonomously — it requires Joe's oversight.\n\n## Step 2 — Crystallize explicit lessons (only when they exist)\n\n**Returned LESSONS lines are judged at the return; the closing learn is the backstop.** When a\nsubagent's report returns with a `LESSONS:` line (route's completion-report contract) that isn't\n`none`, apply the bar below to each lesson in it right then, on the mid-cycle fast path above: one\nnote per lesson that clears the bar, no sweep. At the closing learn, scan the session's collected\n`LESSONS:` lines from dispatched work (the `please` skill hands them over) alongside the raw\nsession content — every line, `none` entries included (skip those trivially). A line is\n**captured** when a note written earlier this session covers it: skip captured lines — never write\none a second time. Judge every other line against the same four\nkinds and the same quality bar below (confirmed, not hypothesized; a general reusable principle, not\na session-specific narrative). A line that doesn't clear the bar is discarded silently — no vault\nnote, no logged discard — the line is a low-bar offer, not a pre-judged lesson.\n\n**Every note clears two tests first: durable and atomic.**\n- **Durable** — still true and useful to a future task that has nothing to do with this one. Status or\n  progress of the work, plans, decisions about the work in hand, branch\u002Fworktree\u002Fticket\u002Fchange names,\n  timestamps, findings about this session's own incident, and episodes (\"what happened\") are not durable;\n  raw chunks already hold them. A save request (\"remember this\") for a durable fact is written; one for\n  status is not: say that it was not saved to the vault and where it belongs (the change's docs or the\n  project's memory).\n- **Atomic** — one claim per note. A second claim is its own lesson and clears both tests itself, or is\n  dropped; it is never folded into the note beside it.\n- The situation names the kind of task or moment that calls for the lesson, with no ticket, issue or\n  change number (such as #4417) and no branch name, unless the lesson is about that ticket itself.\n\nScan THIS session for exactly four kinds of moments. For each note you crystallize, first decide\nits Luhmann placement (below), then include the resulting `position`\u002F`target` in the write-memory\nhandoff alongside the kind-specific fields.\n\n**Disposition (placement) — decide before handing off:**\n\nGrounded in Niklas Luhmann's own Zettelkasten practice and Sönke Ahrens, *How to Take Smart\nNotes*: an ID's position encodes where a note sits in the thought tree, relative to notes written\nor recalled earlier in THIS session (not a full-vault search). Apply this test in order:\n\n1. Does the new note develop **one specific sub-point** raised inside an in-session note? →\n   `position=continuation`, `target=\u003Cthat note's ID>`.\n2. Else, does it continue\u002Fextend the **same overall thought** as an in-session note, at the same\n   level (not a sub-point of it)? → `position=sibling`, `target=\u003Cthat note's ID>`.\n3. Else → `position=top` (no target).\n\nNo in-session candidate note exists → always `position=top`; do not search the rest of the vault\nfor a placement target.\n\n1. **Corrections** — the user corrected your approach or behavior (\"don't suppress lint warnings —\n   fix the underlying issue\", \"never amend pushed commits\").\n\n   **REQUIRED SUB-SKILL:** invoke the **write-memory** skill with this handoff — kind=feedback,\n   slug, source (\"session \u003Cdate>, context: \u003Cone-line what-was-happening>\"), situation\n   (retrieval-shaped), behavior, impact, action; plus supersedes details if this correction\n   corrects an existing vault note. write-memory composes, executes, and reports the note path.\n\n2. **Explicit save-requests** — the user said \"remember this\u002Fthat X\", \"note for next time\",\n   \"write this down\".\n\n   **REQUIRED SUB-SKILL:** invoke the **write-memory** skill with this handoff — kind=fact,\n   slug, source (\"session \u003Cdate>, context: \u003Cone-line what-was-happening>\"), situation\n   (retrieval-shaped), subject, predicate, object; plus supersedes details if this fact\n   corrects an existing vault note. write-memory composes, executes, and reports the note path.\n\n3. **Reversals** — a conclusion, design, or verdict that was PRESENTED (to the user, a review\n   gate, or a committed plan) and later OVERTURNED — by you, a reviewer, or an instrument\n   (a superseded design, a retro-invalidated finding, an instrument-invalid measurement, a\n   redrawn boundary). Nobody needs to have SAID the correction — self-discovered reversals\n   qualify, and a repo-doc CORRECTION section or postscript does NOT count as capture\n   (record-correction ≠ lesson-capture). For each reversal, **REQUIRED SUB-SKILL:** invoke the\n   **write-memory** skill with this handoff — kind=feedback, slug, source (\"session \u003Cdate>,\n   context: \u003Cone-line what-was-happening>\"), situation (retrieval-shaped: when does this\n   failure mode apply), behavior = what the original reasoning did wrong, impact = what the\n   reversal cost, action = the guard that would have prevented it — the ROOT CAUSE, not a\n   narrative of the flip; plus supersedes details if the reversal corrects an existing vault\n   note.\n\n4. **Confirmed approaches (positive reinforcement)** — a specific, generalizable approach was\n   validated as good, either by the user or by the outcome. The positive mirror of kinds 1 and 3;\n   it fires on EITHER trigger:\n   - **4a — user-confirmed:** the user explicitly praised or thanked a SPECIFIC behavior you could\n     restate as a reusable tactic (\"thanks for attaching the file — easier to read from my phone\" →\n     \"attach deliverable files instead of inlining them\"). A bare pleasantry naming no behavior\n     (\"thanks!\", \"great work\") does NOT qualify.\n   - **4b — self-validated bet:** you made a genuine guess, or were uncertain about a plan, concept,\n     or idea, ACTED on it (embodied it in the work — a chosen approach, an implementation, a plan\n     step, a command run), and an OBSERVABLE, session-recorded outcome then confirmed it worked (a\n     test passed, the user confirmed it, an artifact functioned, a blocker cleared). The exact\n     positive mirror of a reversal: a bet that succeeded instead of failing.\n\n   **Completion-moment anchor:** scan for kind-4 specifically at the moment a unit of work's\n   outcome is CONFIRMED — a review or gate verdict lands, a check or test passes, or the user\n   explicitly confirms something. That includes the moment you read a dispatched subagent's\n   completion report (and its `LESSONS:` line) once its outcome is known — not only your own\n   direct work. Anchor on that concrete event, not on \"did the session feel successful overall.\"\n\n   **Real-world exemplars** (kind-4 under-fires more than any other kind in practice — use these\n   to calibrate what counts, since the pattern is easy to walk past):\n   - Unsure whether a design assumption held; ran a targeted code search to check it before\n     finalizing the design; the search confirmed it → confirmed approach (the check-before-you-\n     commit method), not \"just design work.\"\n   - Suspected a defect existed; wrote and ran a targeted reproduction test that confirmed it →\n     confirmed approach (the targeted-reproduction method), not \"just found a bug.\"\n   - A vendor's documented capability claim mattered to a decision; verified it directly against\n     evidence (a real call, a test, a spec) instead of trusting the docs → confirmed approach\n     (\"verify vendor claims against evidence, don't assume\"), regardless of which way the\n     verification came out.\n\n   The action is capturing what WORKED — NOT logging every success. A bare pleasantry, a routine\n   success with no bet behind it, or an unconfirmed guess is never the signal — just as a repo-doc\n   CORRECTION does not count as reversal-capture, a routine success does not count as\n   reinforcement-capture; the signal is a resolved uncertainty or an explicit specific\n   confirmation, never \"it worked\".\n\n   **Runbook vs. feedback — pick by shape, not by trigger:** a confirmed approach that is a\n   reusable, ordered, multi-step procedure for a recurring task (e.g. \"run tests → tag the release\n   → push the tag → update the changelog\" for releasing a Go module; running an eval harness; a\n   recall-moment discovery sequence) → **kind=runbook**. A confirmed approach that is a single\n   behavioral tweak with no natural step structure (e.g. \"attach deliverable files instead of\n   inlining them\") → **kind=feedback**, as before.\n\n   For a **runbook**, **REQUIRED SUB-SKILL:** invoke the **write-memory** skill with this\n   handoff — kind=runbook, slug, source (\"session \u003Cdate>, context: \u003Cone-line what-was-happening>\"),\n   situation (retrieval-shaped: when would this approach apply again), done_when = what should be\n   true once the procedure is complete, body = the numbered steps (may `[[wikilink]]` fact\u002Ffeedback\n   notes worth reading along the way); plus supersedes details if this confirmation corrects an\n   existing vault note. The runbook note itself already is the \"remember to do it this way\"\n   capture — if the user also instructs \"do that going forward,\" do NOT additionally fire a\n   kind=fact save-request (kind 2) for the same content; that redundancy-avoidance is specific to\n   the runbook case.\n\n   For **feedback**, **REQUIRED SUB-SKILL:** invoke the **write-memory** skill with this handoff —\n   kind=feedback, slug, source (\"session \u003Cdate>, context: \u003Cone-line what-was-happening>\"), situation\n   (retrieval-shaped: when would this approach apply again), behavior = what worked, impact = the\n   confirming evidence (the user's quote for 4a, or the observed outcome that resolved the\n   uncertainty for 4b), action = keep doing it + its trigger conditions; plus supersedes details if\n   this confirmation corrects an existing vault note. (If the user also instructs \"do that going\n   forward\", that is additionally a save-request — kind 2.)\n\nRules:\n- **State the general principle**, not the session-specific instance — future-you recalls by\n  situation similarity, not by remembering this session.\n- The `--situation` phrase is the retrieval handle: phrase it the way a future task would be\n  described (\"releasing a Go module\", \"writing eval harness metrics\").\n- One note per distinct principle. An explicit save-request for a durable lesson ALWAYS gets its note,\n  immediately — \"remember this\" means stop and write before anything else. A save-request for status gets\n  none (the durable test above): tell the user.\n- If the new lesson CORRECTS, narrows, or refutes an existing vault note, include the superseded note's basename, type, and claim in the handoff.\n- **No moments of any kind → write nothing.** Routine work is already captured by Step 1;\n  a session with no corrections, no save-requests, no reversals, and no confirmed approaches is a two-command learn (sweep + report).\n\n**With `ENGRAM_PARENT` set, every write is offered to the parent automatically.** The note is\nwritten locally first; the binary then offers it upward, with nothing for you to run. A warning\n`engram: parent unreachable (retry after …); N offer(s) queued` means the write is **done**: the\nnote is in the local vault, and the offer waits in the queue until a later engram command reaches\nthe parent. Report the note as saved, and that its offer is queued for the parent. Do not re-run the\nwrite, and never set `ENGRAM_SERVER` (that mode is gone; setting it is a hard error).\n\n## Step 2.5 — Ad-hoc QA capture (only when a new substantive Q&A occurred this session)\n\nScan THIS session for substantive answered questions: a question was substantively answered if\nthe answer body contains ≥1 `[[full-basename]]` wikilink OR if you crystallized a\nnew vault note (Step 2) as the answer. Both conditions make the answer traceable (D2 observable\nbar). Skip questions answered with generic advice or without `[[...]]` wikilinks.\n\nFor each uncaptured substantive Q&A from this session, **invoke the **write-memory** skill** with\nthis handoff — kind=qa, slug, verbatim question, answer body (copy; no re-derive), contributor\nbasenames, certainty, source (\"ad-hoc capture, learn session \u003Cdate>\").\n\nContributors come ONLY from `[[full-basename]]` wikilinks in the written answer — never\nfree-listed. Do NOT pre-validate whether contributors exist in the vault; extract the wikilink\ncontent verbatim and include the basenames in the write-memory handoff. Validation happens at\nwrite time; if write-memory reports a contributor rejection, surface it.\nIf no `[[...]]` wikilinks appear in the answer and no note was crystallized, skip (D2 bar not met).\n\n**Gate — do not duplicate:** if a QA pair was already written (e.g. by recall's Step 4 during\nthis session), do not write it again here. This also covers your own Step 2 crystallization: if\na question was answered by a Step 2 note YOU wrote this turn, that note already IS the capture\n(whatever wikilinks it cites) — do not additionally write a QA pair for the same question, even\nthough \"crystallized a new vault note (Step 2) as the answer\" above nominally qualifies it as\nsubstantively answered. The wikilink-based trigger stays live on its own: a question answered by\nciting an EXISTING prior note, with no new Step 2 note written for it this turn, still gets its\nQA pair. One pair per distinct answered question.\n\n## Batch mode — Luhmann re-eval answers (`--reparent-luhmann`)\n\n**Trigger:** you were handed a derive-phase candidate JSON payload from\n`engram update --reparent-luhmann` (fields: `candidates` — each with `note`, `note_excerpt`,\n`target`, `target_excerpt`, `similarity` — plus `instruction` and `fingerprint`), and asked to\nproduce its answers file. This is a deliberate, explicitly-invoked mode — NOT part of the normal\nStep 1→2.5 sequence a per-capture `learn` run walks; it runs standalone, once, over a batch.\n\nFor EACH candidate pair, apply the **same disposition test as Step 2's placement decision above**\n— read `note_excerpt` and `target_excerpt` and judge the content relationship, not the\n`similarity` score alone (a high score can still be an unrelated false positive: two notes can\nshare vocabulary while addressing different problems):\n\n1. `note_excerpt` develops one specific sub-point of `target_excerpt`? → `position=continuation`.\n2. Else, same overall thought as `target_excerpt`, at the same level? → `position=sibling`.\n3. Else (unrelated despite the similarity score) → `position=top`.\n\nIn all three cases, `target` is only meaningful for `continuation`\u002F`sibling`; a `top` verdict\nstill needs a full answer entry.\n\n**Coverage requirement:** every candidate's `note` MUST get exactly one entry in the answers file\n— there is no \"skip this one\" option. If a note appears as `note` in more than one candidate\n(multiple targets above the floor), judge each candidate independently and answer with the ONE\n`target`\u002F`position` you find most correct; still exactly one output entry per distinct `note`.\n\nWrite the answers file as JSON, matching this shape exactly — do not rename fields or add others:\n\n```json\n{\n  \"reparenting\": [\n    {\"note\": \"\u003Cid>\", \"position\": \"continuation|sibling|top\", \"target\": \"\u003Cid>\"}\n  ],\n  \"fingerprint\": \"\u003Cechoed VERBATIM from the input payload's fingerprint field>\"\n}\n```\n\nSave it to a file (e.g. `\u002Ftmp\u002Freparent-answers.json`) and tell the user to run:\n\n```\nengram update --reparent-luhmann --answers \u003Cfile> --dry-run\n```\n\nto review the resulting renames, then re-run the same command without `--dry-run` to apply. This\nskill does not invoke either command itself — that is the acting agent's (or user's) next step.\n\n## Red flags — STOP and re-read\n\n| Sign you're off-script | What you should be doing |\n| --- | --- |\n| You ran `engram transcript` anything | Step 1's `engram ingest --auto` replaced the whole transcript workflow |\n| You're writing an episode or summarizing the session into a note | Don't — raw chunks already hold it |\n| You're writing a note that holds status, a plan, a branch\u002Fworktree\u002Fticket name, a timestamp, an incident finding or \"what happened\" | Not durable — drop it; the raw chunks hold episodes. Not even a \"remember this\" makes status durable |\n| One note holds two claims, or you're about to fold a second claim into a note | Atomic — split it: each claim clears both tests alone, or is dropped |\n| The situation of the note names #NNN or a branch | Rewrite it as the kind of task that calls for the lesson |\n| You're writing facts for things nobody asked you to remember | Only corrections, save-requests, reversals, and confirmed approaches crystallize here |\n| You're writing a confirmed-approach note for a routine success or a bare \"thanks!\" | Kind 4 needs a genuine bet with observable confirmation, or explicit praise of a SPECIFIC behavior — never mere success |\n| You skipped the sweep because \"nothing changed\" | The sweep IS the check — it costs seconds when nothing changed — skipping because a sweep already ran this session is the prescribed exception |\n| `--tier` flags or L3\u002FADR writing | Tiers are not part of learn anymore |\n| You corrected a repo doc (CORRECTION\u002Fpostscript) and skipped the vault note | Write the vault note for the reversal's root cause — record-correction is not capture |\n| A write printed `parent unreachable … offer(s) queued` and you're retrying it, calling it failed, or reaching for `ENGRAM_SERVER` | The note is saved locally and the offer is queued — report it as done |\n| At Step 2.5 you're about to write a QA pair for a question you just answered with your OWN Step 2 note this turn | Don't — that note is already the capture; the Gate excludes this case even though it nominally meets the substantive-answer bar |\n","# Learn — Sweep Raw Memory, Crystallize Explicit Lessons\n\nTwo jobs, in order: (1) mechanically true up the chunk index so every conversation and doc is searchable memory, and (2) write a vault note for every explicit lesson this session — user corrections, explicit save-requests, presented conclusions that were later overturned, and confirmed approaches (user-praised or self-validated). Nothing else.\n\n> **Raw event memory is AUTOMATIC.** `engram ingest` chunks and embeds session transcripts and\n> markdown itself — no summaries, no episode notes, no arc detection. The agent's only writing\n> job is crystallizing EXPLICIT lessons. Do not reconstruct the old episode workflow\n> (`engram transcript`, `engram learn episode`) — it is gone.\n\n> **Mid-cycle capture (fast path).** When you fire at a CORRECTION moment mid-task — a review, a\n> failing check, or the user just rejected your approach or named a different convention — or at a\n> subagent return whose `LESSONS:` line carries a lesson that clears the bar, this is a\n> focused single-note capture, NOT the open\u002Fclose of a cycle. **SKIP Step 1 (sweep) and Step 1.5\n> (vocab); go straight to Step 2** and crystallize the ONE confirmed correction (hand off to\n> write-memory as always). Do NOT run `engram ingest --auto` mid-task — the sweep is a\n> cycle-boundary job, it is wasteful here and can block on a large corpus, and losing the capture to\n> a hung sweep is the failure mode. The closing learn still sweeps.\n\n## Step 1 — Sweep (first; the closing learn always sweeps)\n\n```bash\nengram ingest --auto\n```\n\nThat's it. The binary stats every known source (repo markdown, `.claude` dirs, all session\ntranscripts), re-chunks and re-embeds only what changed — within one source, existing chunks are\nnever deleted (append-only history). Across sources, byte-identical content is deduplicated: only\none canonical copy is indexed, and a duplicate's index is removed only once its retained twin is\nverified to cover its records (not on hash-match alone) — see `engram prune --duplicates` for the\nretroactive cleanup mode. Unchanged corpus → returns in seconds. Report the per-source lines it\nprints, or \"memory index up to date\" when it prints nothing.\n\nIf the command fails, surface the error and continue to Step 2 — explicit lessons must not be\nlost to an ingest hiccup.\n\nSkip the sweep if one already ran earlier in THIS session, UNLESS this is the closing learn of a\nwork cycle — the closing learn ALWAYS sweeps (it captures the session's tail for future sessions).\nThis holds even under a \"something might have changed outside this session (another terminal,\nanother agent)\" worry — that gets picked up by the next sweep (yours or theirs), not by\nre-sweeping now on suspicion.\n\n## Step 1.5 — Vocab liveness check\n\nRun `engram vocab stats`.\n\nIf the verdict is `verdict: OK`, continue to Step 2 with no further vocab action.\n\nIf the output includes a line matching `verdict: REFIT_PENDING (\u003Creason>)`, run the refit\nautonomously — do not defer to the user:\n\n1. Run `engram vocab refit`. The binary derives the clusters itself — there is no plan to\n   author. (`--dry-run` prints the derivation diff without writing; use it on the first refit\n   over a long-drifted vault if you want to sanity-check a mass retirement first.)\n2. If it prints `vocab refit: no structure found; vocabulary unchanged`, nothing was written\n   and there is no version bump — report exactly that (\"Vocab refit ran: no structure found,\n   vocabulary unchanged.\") and continue to Step 2. Do NOT claim an applied refit.\n   If every cluster matched an existing term, the run applies directly — skip to step 4.\n   If there are new clusters, the command prints a JSON payload\n   (`naming_requests` + `fingerprint`) and exits WITHOUT writing. Name each new cluster from\n   its exemplars, then write an answer file:\n\n   ```json\n   {\"names\": [{\"cluster\": 0, \"term\": \"kebab-case-term\", \"description\": \"one line\"}],\n    \"fingerprint\": \"\u003Cechoed verbatim from the request payload>\"}\n   ```\n\n   Cover every new cluster exactly once. Re-run: `engram vocab refit --names \u002Fpath\u002Fanswer.json`.\n3. If the re-run fails with a stale-names error (the vault changed between runs), the requests\n   are void — re-run `engram vocab refit` from scratch to regenerate them, and answer those.\n4. **Report loudly:** \"Vocab refit applied: \u003Cversion bump>. Triggered by: \u003Creason>.\"\n\nAlso check the QA round-2 gate line. If the output includes `qa round-2 gate: READY (...)`, report to Joe:\n\"QA round-2 validation is due (≥20 pairs captured). Please schedule the round-2 gates recorded in\ndocs\u002FROADMAP.md (The roadmap → GATED → Q&A memory round-2): P2′ attribution fidelity, P3′ distribution, Arm V larger-n.\" Do NOT run round-2 validation\nautonomously — it requires Joe's oversight.\n\n## Step 2 — Crystallize explicit lessons (only when they exist)\n\n**Returned LESSONS lines are judged at the return; the closing learn is the backstop.** When a\nsubagent's report returns with a `LESSONS:` line (route's completion-report contract) that isn't\n`none`, apply the bar below to each lesson in it right then, on the mid-cycle fast path above: one\nnote per lesson that clears the bar, no sweep. At the closing learn, scan the session's collected\n`LESSONS:` lines from dispatched work (the `please` skill hands them over) alongside the raw\nsession content — every line, `none` entries included (skip those trivially). A line is\n**captured** when a note written earlier this session covers it: skip captured lines — never write\none a second time. Judge every other line against the same four\nkinds and the same quality bar below (confirmed, not hypothesized; a general reusable principle, not\na session-specific narrative). A line that doesn't clear the bar is discarded silently — no vault\nnote, no logged discard — the line is a low-bar offer, not a pre-judged lesson.\n\n**Every note clears two tests first: durable and atomic.**\n- **Durable** — still true and useful to a future task that has nothing to do with this one. Status or\n  progress of the work, plans, decisions about the work in hand, branch\u002Fworktree\u002Fticket\u002Fchange names,\n  timestamps, findings about this session's own incident, and episodes (\"what happened\") are not durable;\n  raw chunks already hold them. A save request (\"remember this\") for a durable fact is written; one for\n  status is not: say that it was not saved to the vault and where it belongs (the change's docs or the\n  project's memory).\n- **Atomic** — one claim per note. A second claim is its own lesson and clears both tests itself, or is\n  dropped; it is never folded into the note beside it.\n- The situation names the kind of task or moment that calls for the lesson, with no ticket, issue or\n  change number (such as #4417) and no branch name, unless the lesson is about that ticket itself.\n\nScan THIS session for exactly four kinds of moments. For each note you crystallize, first decide\nits Luhmann placement (below), then include the resulting `position`\u002F`target` in the write-memory\nhandoff alongside the kind-specific fields.\n\n**Disposition (placement) — decide before handing off:**\n\nGrounded in Niklas Luhmann's own Zettelkasten practice and Sönke Ahrens, *How to Take Smart\nNotes*: an ID's position encodes where a note sits in the thought tree, relative to notes written\nor recalled earlier in THIS session (not a full-vault search). Apply this test in order:\n\n1. Does the new note develop **one specific sub-point** raised inside an in-session note? →\n   `position=continuation`, `target=\u003Cthat note's ID>`.\n2. Else, does it continue\u002Fextend the **same overall thought** as an in-session note, at the same\n   level (not a sub-point of it)? → `position=sibling`, `target=\u003Cthat note's ID>`.\n3. Else → `position=top` (no target).\n\nNo in-session candidate note exists → always `position=top`; do not search the rest of the vault\nfor a placement target.\n\n1. **Corrections** — the user corrected your approach or behavior (\"don't suppress lint warnings —\n   fix the underlying issue\", \"never amend pushed commits\").\n\n   **REQUIRED SUB-SKILL:** invoke the **write-memory** skill with this handoff — kind=feedback,\n   slug, source (\"session \u003Cdate>, context: \u003Cone-line what-was-happening>\"), situation\n   (retrieval-shaped), behavior, impact, action; plus supersedes details if this correction\n   corrects an existing vault note. write-memory composes, executes, and reports the note path.\n\n2. **Explicit save-requests** — the user said \"remember this\u002Fthat X\", \"note for next time\",\n   \"write this down\".\n\n   **REQUIRED SUB-SKILL:** invoke the **write-memory** skill with this handoff — kind=fact,\n   slug, source (\"session \u003Cdate>, context: \u003Cone-line what-was-happening>\"), situation\n   (retrieval-shaped), subject, predicate, object; plus supersedes details if this fact\n   corrects an existing vault note. write-memory composes, executes, and reports the note path.\n\n3. **Reversals** — a conclusion, design, or verdict that was PRESENTED (to the user, a review\n   gate, or a committed plan) and later OVERTURNED — by you, a reviewer, or an instrument\n   (a superseded design, a retro-invalidated finding, an instrument-invalid measurement, a\n   redrawn boundary). Nobody needs to have SAID the correction — self-discovered reversals\n   qualify, and a repo-doc CORRECTION section or postscript does NOT count as capture\n   (record-correction ≠ lesson-capture). For each reversal, **REQUIRED SUB-SKILL:** invoke the\n   **write-memory** skill with this handoff — kind=feedback, slug, source (\"session \u003Cdate>,\n   context: \u003Cone-line what-was-happening>\"), situation (retrieval-shaped: when does this\n   failure mode apply), behavior = what the original reasoning did wrong, impact = what the\n   reversal cost, action = the guard that would have prevented it — the ROOT CAUSE, not a\n   narrative of the flip; plus supersedes details if the reversal corrects an existing vault\n   note.\n\n4. **Confirmed approaches (positive reinforcement)** — a specific, generalizable approach was\n   validated as good, either by the user or by the outcome. The positive mirror of kinds 1 and 3;\n   it fires on EITHER trigger:\n   - **4a — user-confirmed:** the user explicitly praised or thanked a SPECIFIC behavior you could\n     restate as a reusable tactic (\"thanks for attaching the file — easier to read from my phone\" →\n     \"attach deliverable files instead of inlining them\"). A bare pleasantry naming no behavior\n     (\"thanks!\", \"great work\") does NOT qualify.\n   - **4b — self-validated bet:** you made a genuine guess, or were uncertain about a plan, concept,\n     or idea, ACTED on it (embodied it in the work — a chosen approach, an implementation, a plan\n     step, a command run), and an OBSERVABLE, session-recorded outcome then confirmed it worked (a\n     test passed, the user confirmed it, an artifact functioned, a blocker cleared). The exact\n     positive mirror of a reversal: a bet that succeeded instead of failing.\n\n   **Completion-moment anchor:** scan for kind-4 specifically at the moment a unit of work's\n   outcome is CONFIRMED — a review or gate verdict lands, a check or test passes, or the user\n   explicitly confirms something. That includes the moment you read a dispatched subagent's\n   completion report (and its `LESSONS:` line) once its outcome is known — not only your own\n   direct work. Anchor on that concrete event, not on \"did the session feel successful overall.\"\n\n   **Real-world exemplars** (kind-4 under-fires more than any other kind in practice — use these\n   to calibrate what counts, since the pattern is easy to walk past):\n   - Unsure whether a design assumption held; ran a targeted code search to check it before\n     finalizing the design; the search confirmed it → confirmed approach (the check-before-you-\n     commit method), not \"just design work.\"\n   - Suspected a defect existed; wrote and ran a targeted reproduction test that confirmed it →\n     confirmed approach (the targeted-reproduction method), not \"just found a bug.\"\n   - A vendor's documented capability claim mattered to a decision; verified it directly against\n     evidence (a real call, a test, a spec) instead of trusting the docs → confirmed approach\n     (\"verify vendor claims against evidence, don't assume\"), regardless of which way the\n     verification came out.\n\n   The action is capturing what WORKED — NOT logging every success. A bare pleasantry, a routine\n   success with no bet behind it, or an unconfirmed guess is never the signal — just as a repo-doc\n   CORRECTION does not count as reversal-capture, a routine success does not count as\n   reinforcement-capture; the signal is a resolved uncertainty or an explicit specific\n   confirmation, never \"it worked\".\n\n   **Runbook vs. feedback — pick by shape, not by trigger:** a confirmed approach that is a\n   reusable, ordered, multi-step procedure for a recurring task (e.g. \"run tests → tag the release\n   → push the tag → update the changelog\" for releasing a Go module; running an eval harness; a\n   recall-moment discovery sequence) → **kind=runbook**. A confirmed approach that is a single\n   behavioral tweak with no natural step structure (e.g. \"attach deliverable files instead of\n   inlining them\") → **kind=feedback**, as before.\n\n   For a **runbook**, **REQUIRED SUB-SKILL:** invoke the **write-memory** skill with this\n   handoff — kind=runbook, slug, source (\"session \u003Cdate>, context: \u003Cone-line what-was-happening>\"),\n   situation (retrieval-shaped: when would this approach apply again), done_when = what should be\n   true once the procedure is complete, body = the numbered steps (may `[[wikilink]]` fact\u002Ffeedback\n   notes worth reading along the way); plus supersedes details if this confirmation corrects an\n   existing vault note. The runbook note itself already is the \"remember to do it this way\"\n   capture — if the user also instructs \"do that going forward,\" do NOT additionally fire a\n   kind=fact save-request (kind 2) for the same content; that redundancy-avoidance is specific to\n   the runbook case.\n\n   For **feedback**, **REQUIRED SUB-SKILL:** invoke the **write-memory** skill with this handoff —\n   kind=feedback, slug, source (\"session \u003Cdate>, context: \u003Cone-line what-was-happening>\"), situation\n   (retrieval-shaped: when would this approach apply again), behavior = what worked, impact = the\n   confirming evidence (the user's quote for 4a, or the observed outcome that resolved the\n   uncertainty for 4b), action = keep doing it + its trigger conditions; plus supersedes details if\n   this confirmation corrects an existing vault note. (If the user also instructs \"do that going\n   forward\", that is additionally a save-request — kind 2.)\n\nRules:\n- **State the general principle**, not the session-specific instance — future-you recalls by\n  situation similarity, not by remembering this session.\n- The `--situation` phrase is the retrieval handle: phrase it the way a future task would be\n  described (\"releasing a Go module\", \"writing eval harness metrics\").\n- One note per distinct principle. An explicit save-request for a durable lesson ALWAYS gets its note,\n  immediately — \"remember this\" means stop and write before anything else. A save-request for status gets\n  none (the durable test above): tell the user.\n- If the new lesson CORRECTS, narrows, or refutes an existing vault note, include the superseded note's basename, type, and claim in the handoff.\n- **No moments of any kind → write nothing.** Routine work is already captured by Step 1;\n  a session with no corrections, no save-requests, no reversals, and no confirmed approaches is a two-command learn (sweep + report).\n\n**With `ENGRAM_PARENT` set, every write is offered to the parent automatically.** The note is\nwritten locally first; the binary then offers it upward, with nothing for you to run. A warning\n`engram: parent unreachable (retry after …); N offer(s) queued` means the write is **done**: the\nnote is in the local vault, and the offer waits in the queue until a later engram command reaches\nthe parent. Report the note as saved, and that its offer is queued for the parent. Do not re-run the\nwrite, and never set `ENGRAM_SERVER` (that mode is gone; setting it is a hard error).\n\n## Step 2.5 — Ad-hoc QA capture (only when a new substantive Q&A occurred this session)\n\nScan THIS session for substantive answered questions: a question was substantively answered if\nthe answer body contains ≥1 `[[full-basename]]` wikilink OR if you crystallized a\nnew vault note (Step 2) as the answer. Both conditions make the answer traceable (D2 observable\nbar). Skip questions answered with generic advice or without `[[...]]` wikilinks.\n\nFor each uncaptured substantive Q&A from this session, **invoke the **write-memory** skill** with\nthis handoff — kind=qa, slug, verbatim question, answer body (copy; no re-derive), contributor\nbasenames, certainty, source (\"ad-hoc capture, learn session \u003Cdate>\").\n\nContributors come ONLY from `[[full-basename]]` wikilinks in the written answer — never\nfree-listed. Do NOT pre-validate whether contributors exist in the vault; extract the wikilink\ncontent verbatim and include the basenames in the write-memory handoff. Validation happens at\nwrite time; if write-memory reports a contributor rejection, surface it.\nIf no `[[...]]` wikilinks appear in the answer and no note was crystallized, skip (D2 bar not met).\n\n**Gate — do not duplicate:** if a QA pair was already written (e.g. by recall's Step 4 during\nthis session), do not write it again here. This also covers your own Step 2 crystallization: if\na question was answered by a Step 2 note YOU wrote this turn, that note already IS the capture\n(whatever wikilinks it cites) — do not additionally write a QA pair for the same question, even\nthough \"crystallized a new vault note (Step 2) as the answer\" above nominally qualifies it as\nsubstantively answered. The wikilink-based trigger stays live on its own: a question answered by\nciting an EXISTING prior note, with no new Step 2 note written for it this turn, still gets its\nQA pair. One pair per distinct answered question.\n\n## Batch mode — Luhmann re-eval answers (`--reparent-luhmann`)\n\n**Trigger:** you were handed a derive-phase candidate JSON payload from\n`engram update --reparent-luhmann` (fields: `candidates` — each with `note`, `note_excerpt`,\n`target`, `target_excerpt`, `similarity` — plus `instruction` and `fingerprint`), and asked to\nproduce its answers file. This is a deliberate, explicitly-invoked mode — NOT part of the normal\nStep 1→2.5 sequence a per-capture `learn` run walks; it runs standalone, once, over a batch.\n\nFor EACH candidate pair, apply the **same disposition test as Step 2's placement decision above**\n— read `note_excerpt` and `target_excerpt` and judge the content relationship, not the\n`similarity` score alone (a high score can still be an unrelated false positive: two notes can\nshare vocabulary while addressing different problems):\n\n1. `note_excerpt` develops one specific sub-point of `target_excerpt`? → `position=continuation`.\n2. Else, same overall thought as `target_excerpt`, at the same level? → `position=sibling`.\n3. Else (unrelated despite the similarity score) → `position=top`.\n\nIn all three cases, `target` is only meaningful for `continuation`\u002F`sibling`; a `top` verdict\nstill needs a full answer entry.\n\n**Coverage requirement:** every candidate's `note` MUST get exactly one entry in the answers file\n— there is no \"skip this one\" option. If a note appears as `note` in more than one candidate\n(multiple targets above the floor), judge each candidate independently and answer with the ONE\n`target`\u002F`position` you find most correct; still exactly one output entry per distinct `note`.\n\nWrite the answers file as JSON, matching this shape exactly — do not rename fields or add others:\n\n```json\n{\n  \"reparenting\": [\n    {\"note\": \"\u003Cid>\", \"position\": \"continuation|sibling|top\", \"target\": \"\u003Cid>\"}\n  ],\n  \"fingerprint\": \"\u003Cechoed VERBATIM from the input payload's fingerprint field>\"\n}\n```\n\nSave it to a file (e.g. `\u002Ftmp\u002Freparent-answers.json`) and tell the user to run:\n\n```\nengram update --reparent-luhmann --answers \u003Cfile> --dry-run\n```\n\nto review the resulting renames, then re-run the same command without `--dry-run` to apply. This\nskill does not invoke either command itself — that is the acting agent's (or user's) next step.\n\n## Red flags — STOP and re-read\n\n| Sign you're off-script | What you should be doing |\n| --- | --- |\n| You ran `engram transcript` anything | Step 1's `engram ingest --auto` replaced the whole transcript workflow |\n| You're writing an episode or summarizing the session into a note | Don't — raw chunks already hold it |\n| You're writing a note that holds status, a plan, a branch\u002Fworktree\u002Fticket name, a timestamp, an incident finding or \"what happened\" | Not durable — drop it; the raw chunks hold episodes. Not even a \"remember this\" makes status durable |\n| One note holds two claims, or you're about to fold a second claim into a note | Atomic — split it: each claim clears both tests alone, or is dropped |\n| The situation of the note names #NNN or a branch | Rewrite it as the kind of task that calls for the lesson |\n| You're writing facts for things nobody asked you to remember | Only corrections, save-requests, reversals, and confirmed approaches crystallize here |\n| You're writing a confirmed-approach note for a routine success or a bare \"thanks!\" | Kind 4 needs a genuine bet with observable confirmation, or explicit praise of a SPECIFIC behavior — never mere success |\n| You skipped the sweep because \"nothing changed\" | The sweep IS the check — it costs seconds when nothing changed — skipping because a sweep already ran this session is the prescribed exception |\n| `--tier` flags or L3\u002FADR writing | Tiers are not part of learn anymore |\n| You corrected a repo doc (CORRECTION\u002Fpostscript) and skipped the vault note | Write the vault note for the reversal's root cause — record-correction is not capture |\n| A write printed `parent unreachable … offer(s) queued` and you're retrying it, calling it failed, or reaching for `ENGRAM_SERVER` | The note is saved locally and the offer is queued — report it as done |\n| At Step 2.5 you're about to write a QA pair for a question you just answered with your OWN Step 2 note this turn | Don't — that note is already the capture; the Gate excludes this case even though it nominally meets the substantive-answer bar |\n",{"name":5,"description":7},"main","d2ce817c74ee4fc65645635887510b47b231230f","agent-instructions\u002Fskills\u002Flearn",2,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram","https:\u002F\u002Fgithub.com\u002Ftoejough","2026-10-25 06:42:30",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":61},[51,54,57],{"tool":52,"command":53},"npx","npx skills add toejough\u002Fengram --skill learn",{"tool":55,"command":56},"bunx","bunx skills add toejough\u002Fengram --skill learn",{"tool":58,"command":59},"pnpm","pnpm dlx skills add toejough\u002Fengram --skill learn","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fagent-instructions\u002Fskills\u002Flearn\u002FSKILL.md",true,[63,69,73,77,81,85,89,93],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"tests\u002Fbaseline-autonomous-trigger.md","REFERENCE","参考文档",3942,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fagent-instructions\u002Fskills\u002Flearn\u002Ftests\u002Fbaseline-autonomous-trigger.md",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"tests\u002Fbaseline-clean-write.md",2216,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fagent-instructions\u002Fskills\u002Flearn\u002Ftests\u002Fbaseline-clean-write.md",{"path":74,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":75,"sourceHtmlUrl":76},"tests\u002Fbaseline-confirmed-approach.md",2916,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fagent-instructions\u002Fskills\u002Flearn\u002Ftests\u002Fbaseline-confirmed-approach.md",{"path":78,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":79,"sourceHtmlUrl":80},"tests\u002Fbaseline-hindsight-framing.md",2256,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fagent-instructions\u002Fskills\u002Flearn\u002Ftests\u002Fbaseline-hindsight-framing.md",{"path":82,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":83,"sourceHtmlUrl":84},"tests\u002Fbaseline-information-not-knowledge.md",2043,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fagent-instructions\u002Fskills\u002Flearn\u002Ftests\u002Fbaseline-information-not-knowledge.md",{"path":86,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":87,"sourceHtmlUrl":88},"tests\u002Fbaseline-project-specific.md",2334,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fagent-instructions\u002Fskills\u002Flearn\u002Ftests\u002Fbaseline-project-specific.md",{"path":90,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":91,"sourceHtmlUrl":92},"tests\u002Fbaseline-vocab-refit.md",2656,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fagent-instructions\u002Fskills\u002Flearn\u002Ftests\u002Fbaseline-vocab-refit.md",{"path":94,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":95,"sourceHtmlUrl":96},"tests\u002FREADME.md",2774,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fagent-instructions\u002Fskills\u002Flearn\u002Ftests\u002FREADME.md",[98,110,115,120,125,143],{"skillNo":99,"name":34,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":103,"publishedAt":37},"01M6CWPEHWS45MANQE0JW6Z146","Use after any user request that might entail more than a single tool call or anything more than quick, shallow thinking. This surfaces relevant memories that are VITAL to recall for a good user experience and a greater chance at first-pass success for the user's request.","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Fskills_auto_l2\u002Frecall\u002FSKILL.md",[],[34,104,105,106,21,107,33,108,26,109],"surfaces","memories","first","thinking","user","good",{"skillNo":111,"name":34,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":37},"01M6CWPAZ9N9CE1RC754XEJ021","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Fskills_auto\u002Frecall\u002FSKILL.md",[],[34,106,33,108,26,109,104,107,21,105],{"skillNo":116,"name":34,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":119,"publishedAt":37},"01M6CWP862CSBPDF1QW19P6C0F","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskWriteMemory\u002Frecall-learn\u002Frecall\u002FSKILL.md",[],[34,106,33,108,26,109,104,107,21,105],{"skillNo":121,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":37},"01M6CWP4XPAJYCJMZAPYNWTN3A","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskWriteMemory\u002Frecall-learn\u002Flearn\u002FSKILL.md",[],[5,19,35,28,36,20,34,33,32,31,30,29,18,27,26,25,24,23,22,21],{"skillNo":126,"name":127,"nameZh":6,"description":128,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":129,"categories":130,"keywords":131,"publishedAt":37},"01M6CWP2649X2F3WZ6EBJHA4MS","write-memory","Executes a vault write handed off by another skill (recall, learn): composes the engram command from the provided fields, runs it, verifies the result, and reports the written note path. Requires a handoff — do not fire on your own judgment that something is worth remembering.","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskWriteMemory\u002FWM-S\u002Fskills\u002Fwrite-memory\u002FSKILL.md",[],[132,133,134,135,5,136,34,137,138,139,140,141,142],"write memory","write","memory","handoff","vault","command","reports","do","engram","another skill","judgment",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":154,"publishedAt":37},"01M6CWNYJCGD4B180MM5852D1N","test-driven-development","Use when implementing any feature or bugfix, before writing implementation code","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskTDD\u002FTDD-S\u002Fskills\u002Ftest-driven-development\u002FSKILL.md",[149],{"categoryNo":150,"categoryName":151,"taxonomyType":152,"taxonomyTypeDesc":153},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[155,156,157,158,159,26,160],"test","test driven development","development","writing","code","implementation"]