[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M73558FN1TYWMMRZYJQSTAK8":3,"skill-same:01M73558FN1TYWMMRZYJQSTAK8":51},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":30,"commitSha":31,"skillDirectory":32,"forksCount":33,"repositoryHtmlUrl":34,"repositoryHomepageUrl":35,"ownerHtmlUrl":36,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":37,"install":38,"resources":50},"01M73558FN1TYWMMRZYJQSTAK8","memorize",null,"Persist memory across sessions.","Morrison-Lab\u002Fai-config","Morrison-Lab","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F104235520?v=4","01M734G0451S2G35MN4HFQK7XP","Morrison Lab","01M734G059BYFDFQA8YTPDGPMH",4,"MIT","https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config\u002Fblob\u002Fmain\u002Fskills\u002Fmemorize\u002FSKILL.md",[],[],"2026-11-11 15:11:14",false,"---\nname: memorize\ndescription: \"Persist memory across sessions.\"\nuser-invocable: true\nallowed-tools:\n  - Read\n  - Write\n  - Edit\n  - Bash\n---\n\n# Memorize\n\nPersist a single fact or preference so it survives across sessions, machines,\nand agents. **`remember` \u002F `\u002Fremember` and `always` \u002F `\u002Falways` are synonyms\nfor this skill** — same behavior; the wording the user happens to use doesn't\nchange anything.\n\nUnlike `ums` (which reviews the whole session and may also update skill definitions), this stores exactly what the user says — no scanning, no skill updates.\nA memory counts only once it is committed to the repo that owns it (ai-config for a cross-repo rule or fact), so memorize **commits and pushes** the one change;\notherwise the note is lost when the session ends (ephemeral cloud containers are reclaimed) and no other project or machine sees it.\n\n## When this fires\n\n- \"memorize …\", \"remember that …\", \"\u002Fremember …\", \"note that …\",\n  \"add to memories: …\"\n- A standing directive phrased as a preference: \"always …\", \"never …\",\n  \"I prefer …\", \"from now on …\"\n\n## First: is it actually a memory?\n\nIf the request is an **automated every-time action** (\"after each commit run\nX\", \"whenever I edit Y do Z\"), memory can't execute it — that needs a **hook**\nin `settings.json` \u002F `settings.local.json` (use the `update-config` skill).\nSay so and route it there; don't store a note that will never fire.\n\nUnsure whether a request is really a memory versus a skill, subagent, hook, or\n`gha` capability? `config-ai` (`ca`\u002F`cai`) is the broader router across all of\nthose forms — this skill is what it hands off to once memory is the answer.\n\n## Procedure\n\n1. **Parse** the fact\u002Fpreference from the user's message.\n2. **Choose scope by relevance**:\n   - **Project-specific, a repo we own** — a fact, convention, or gotcha tied\n     to ONE specific repo we own (\"renders with renv via `R_LIBS_USER`\") →\n     commit it to **that project's own repo** via a PR (its `CLAUDE.md`,\n     `.github\u002Fcopilot-instructions.md`, or whatever agent-doc infrastructure\n     it already has), so the whole team and every `@claude` session there\n     can see it. (NOT `memories\u002Frepo\u002F` inside ai-config; that directory is\n     removed.) If the repo has no agent-doc infrastructure yet, write to its\n     local Claude project memory instead —\n     `~\u002F.claude\u002Fprojects\u002F\u003Cproject-path>\u002Fmemory\u002F\u003Cfile>.md` — as **short-lived\n     staging only, not a durable destination**, and tell the user a PR\n     adding agent-doc infrastructure to that repo (plus migrating the staged\n     memory there) is still needed. The project path is the repo's\n     directory path with `\u002F` replaced by `-` — e.g.\n     `\u002FUsers\u002Fyou\u002FDocuments\u002FGitHub\u002Frme` → `-Users-you-Documents-GitHub-rme`.\n     Update `MEMORY.md` in that directory as an index entry when you used\n     this local-staging fallback — not when the fact was committed directly\n     to the owned repo's own agent docs, which needs no local copy.\n   - **Project-specific, an external repo we don't own** — never open a\n     direct PR autonomously. Route it through\n     [`upstream-issues`](..\u002F..\u002Fshared\u002Fworkflow\u002Fupstream-issues.md): check\n     the repo's contribution policy first (some ban autonomous AI PRs\u002Fissues\n     outright), then draft and get **explicit user approval** before posting\n     anything. Until approved, stage the fact in that repo's local Claude\n     project memory as short-lived, not-yet-durable staging, and update\n     `MEMORY.md` there as an index entry too.\n   - **General standing rule** — an always-apply working preference across ALL repos (\"always link PRs in tables\", \"use Pacific time\") → ai-config's own `AGENTS.md` (cross-agent) or `CLAUDE.md` \u002F a `shared\u002F` fragment (Claude-specific detail), committed to `Morrison-Lab\u002Fai-config` by PR.\n     The plugin's `hooks\u002Finject-core-rules.py` starts every session with `AGENTS.md`'s section index and an order to read it in full, so that is what makes the rule reach other projects.\n     Keep the `AGENTS.md` entry to the rule in a line or two with a pointer, and put detail in a `shared\u002F` fragment: `AGENTS.md` has a hard 32,768-byte cap.\n     Do not write it to `~\u002F.claude\u002FCLAUDE.md` unless that file is a symlink into an ai-config checkout: the symlink install was removed, and a plain file there is invisible to every other machine, container and project.\n   - **Host memory is a copy, never the home.**\n     A claude.ai project's memory, a Cowork or desktop memory store, or any other memory the harness offers is read only inside that project.\n     A cross-project rule goes to ai-config as above;\n     the host memory may hold a pointer to it (ai-config#4208).\n   - **General reference fact** — a cross-project fact that only matters when\n     relevant (\"gh opens a pager — pipe to cat\") → a topical file in\n     `\u002Fmemories\u002F`, or `tools.md` for what fits none of them.\n     Read `memories\u002FMEMORY.md` for the current set and what each one covers;\n     it is the registry, so naming the files here too would only go stale.\n     When you add a *new* file here (not just a bullet to an existing one),\n     register it in `memories\u002FMEMORY.md` as an index entry: a table row of\n     its own whose first cell links to it.\n     `scripts\u002Fcheck-memory-index.py` fails CI on a file with no such row\n     (ai-config#4987).\n   - **Conversation-only** → `\u002Fmemories\u002Fsession\u002F`\n   - When ambiguous between project and general, judge by relevance; default\n     to general.\n3. **Choose file**: read the target's current contents first. Append to an\n   existing section\u002Ffile if one fits; otherwise create a descriptively named\n   file — and when you create a *new* file under `\u002Fmemories\u002F`, add a row for it\n   to `memories\u002FMEMORY.md` (the index).\n   Don't duplicate -- grep the target file for the subject\n   (the tool name, the API call, the error string),\n   not just the region you're appending to;\n   a long file like `memories\u002Fr-quarto.md` can already cover it\n   hundreds of lines away.\n   Grep every topical file, not just the one you picked -- a fact about\n   `gh workflow run` could plausibly have landed in `github.md` or\n   `github-actions.md`.\n   If it's already recorded, update in place rather than stacking a second\n   copy, and say so.\n   Delete a memory that turns out wrong instead of leaving a contradiction.\n4. **Write** a concise bullet (one line preferred), matching the file's voice;\n   include the *why* if it isn't obvious.\n   Don't record what the repo already documents (code structure, git history) — capture only the non-obvious.\n   When the entry records where a directive or fact came from, cite that source as a link to the PR, issue or comment it arose on, not as a bare repository name ([ai-config#4310](https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config\u002Fpull\u002F4310)'s first review caught exactly that).\n5. **Commit & push** the change so it persists.\n   What that means depends on where step 2 wrote it:\n   - **Project's own repo, owned** — commit, push a branch, and open a PR\n     there, same as any other change to that repo.\n   - **Project's own repo, external (not owned)** — never push\u002Fopen a PR\n     directly; follow `upstream-issues` (policy check, draft, explicit user\n     approval) instead.\n   - **`~\u002F.claude\u002Fprojects\u002F*\u002Fmemory\u002F` staging** (the project repo has no\n     agent-doc infrastructure yet, or is external and not yet approved) —\n     no git commit; it persists locally only. Update `MEMORY.md` in that\n     directory as an index entry. Tell the user this is temporary staging\n     and what's still needed (agent-doc infra added via a PR, or upstream\n     approval).\n   - **`\u002Fmemories\u002Fsession\u002F`** — skip; conversation-only notes shouldn't enter the shared repo.\n   - **No `~\u002F.claude\u002Fmemories` symlink** (a cloud or project session, or any machine set up after the symlink install was removed) — attach or clone `Morrison-Lab\u002Fai-config`, commit the change there on a branch, and open a PR (`push-memory` does this).\n     A write under `~\u002F.claude` that is not a symlink into ai-config is lost with the container or stays on one machine, which is how the user ends up repeating themselves.\n   - **Everything else gets committed** to ai-config.\n     The commands below apply only to a machine that still has the legacy `~\u002F.claude\u002Fmemories` symlink into an ai-config checkout and works in that checkout;\n     without the symlink, use the bullet above.\n     When you're **working primarily in another repo** and want to push a general memory to ai-config from there, use `push-memory` instead --- it delivers on a branch + PR and never touches the repo you're in.\n     Resolve the repo from the `memories\u002F` symlink and stage the file by its path *within* the repo (`git rev-parse --show-toplevel` follows the symlink to the repo root, robust across one or many hops, unlike single-hop `readlink`):\n\n   ```bash\n   [ -L ~\u002F.claude\u002Fmemories ] || { echo \"no ~\u002F.claude\u002Fmemories symlink: use the no-symlink path (push-memory)\"; exit 1; }\n   repo=\"$(git -C ~\u002F.claude\u002Fmemories rev-parse --show-toplevel)\"   # ai-config repo root\n   rel=\"CLAUDE.md\"   # or memories\u002F\u003Cfile>.md  (NOT memories\u002Frepo\u002F — that's gone)\n   git -C \"$repo\" add \"$rel\" \\\n     && git -C \"$repo\" commit -m \"memorize: \u003Cone-line summary>\"\n   ```\n\n   Push as a separate Bash call, per [`check-before-pushing`](..\u002F..\u002Fshared\u002Fworkflow\u002Fcheck-before-pushing.md)'s \"Keep the commit in its own Bash call\":\n\n   ```bash\n   repo=\"$(git -C ~\u002F.claude\u002Fmemories rev-parse --show-toplevel)\"   # re-derived: a separate Bash call does not inherit the variable\n   git -C \"$repo\" push origin HEAD   # current branch; not HEAD:main -- that would push a feature branch's commits onto main\n   ```\n\n   The push targets the ai-config repo's **current branch**, so run memorize\n   from a checkout on `main` (the normal case) — that's where shared memory\n   belongs. In an ephemeral cloud session the push is mandatory: an unpushed\n   commit dies with the container.\n\n   **Worktree session \u002F occupied main checkout (legacy symlink machines).**\n   Where `~\u002F.claude\u002Fmemories` and `~\u002F.claude\u002FCLAUDE.md` are still symlinked to the **main** checkout, `git -C ~\u002F.claude\u002Fmemories rev-parse --show-toplevel` resolves to the main checkout — *not* your worktree.\n   If that checkout is on a non-`main` branch (e.g. another session is working there, possibly with uncommitted edits), committing through the symlink lands your memory on the wrong branch and can tangle with that session's work.\n   In that case don't commit through the symlink: edit the memory file at its path inside **your** worktree, commit on your worktree branch, and land it via branch + PR + merge.\n   It only reaches the live symlinked memory once it merges to `main` and the main checkout updates.\n   (See the worktree-isolation and no-`cd`-in-worktree bullets in\n   `memories\u002Fpreferences.md`, and the `session-lock` skill.)\n6. **Confirm**: one sentence — what was stored, where, and that it was pushed.\n\n## Don't\n\n- Don't run a full session review or touch skill files (that's `ums`).\n- Don't commit unrelated changes — stage only the file you wrote.\n- Don't push conversation-only (`\u002Fmemories\u002Fsession\u002F`) notes to the shared repo.\n- Don't store secrets, tokens, or passwords.\n- Don't over-elaborate — one bullet per fact.\n","# Memorize\n\nPersist a single fact or preference so it survives across sessions, machines,\nand agents. **`remember` \u002F `\u002Fremember` and `always` \u002F `\u002Falways` are synonyms\nfor this skill** — same behavior; the wording the user happens to use doesn't\nchange anything.\n\nUnlike `ums` (which reviews the whole session and may also update skill definitions), this stores exactly what the user says — no scanning, no skill updates.\nA memory counts only once it is committed to the repo that owns it (ai-config for a cross-repo rule or fact), so memorize **commits and pushes** the one change;\notherwise the note is lost when the session ends (ephemeral cloud containers are reclaimed) and no other project or machine sees it.\n\n## When this fires\n\n- \"memorize …\", \"remember that …\", \"\u002Fremember …\", \"note that …\",\n  \"add to memories: …\"\n- A standing directive phrased as a preference: \"always …\", \"never …\",\n  \"I prefer …\", \"from now on …\"\n\n## First: is it actually a memory?\n\nIf the request is an **automated every-time action** (\"after each commit run\nX\", \"whenever I edit Y do Z\"), memory can't execute it — that needs a **hook**\nin `settings.json` \u002F `settings.local.json` (use the `update-config` skill).\nSay so and route it there; don't store a note that will never fire.\n\nUnsure whether a request is really a memory versus a skill, subagent, hook, or\n`gha` capability? `config-ai` (`ca`\u002F`cai`) is the broader router across all of\nthose forms — this skill is what it hands off to once memory is the answer.\n\n## Procedure\n\n1. **Parse** the fact\u002Fpreference from the user's message.\n2. **Choose scope by relevance**:\n   - **Project-specific, a repo we own** — a fact, convention, or gotcha tied\n     to ONE specific repo we own (\"renders with renv via `R_LIBS_USER`\") →\n     commit it to **that project's own repo** via a PR (its `CLAUDE.md`,\n     `.github\u002Fcopilot-instructions.md`, or whatever agent-doc infrastructure\n     it already has), so the whole team and every `@claude` session there\n     can see it. (NOT `memories\u002Frepo\u002F` inside ai-config; that directory is\n     removed.) If the repo has no agent-doc infrastructure yet, write to its\n     local Claude project memory instead —\n     `~\u002F.claude\u002Fprojects\u002F\u003Cproject-path>\u002Fmemory\u002F\u003Cfile>.md` — as **short-lived\n     staging only, not a durable destination**, and tell the user a PR\n     adding agent-doc infrastructure to that repo (plus migrating the staged\n     memory there) is still needed. The project path is the repo's\n     directory path with `\u002F` replaced by `-` — e.g.\n     `\u002FUsers\u002Fyou\u002FDocuments\u002FGitHub\u002Frme` → `-Users-you-Documents-GitHub-rme`.\n     Update `MEMORY.md` in that directory as an index entry when you used\n     this local-staging fallback — not when the fact was committed directly\n     to the owned repo's own agent docs, which needs no local copy.\n   - **Project-specific, an external repo we don't own** — never open a\n     direct PR autonomously. Route it through\n     [`upstream-issues`](..\u002F..\u002Fshared\u002Fworkflow\u002Fupstream-issues.md): check\n     the repo's contribution policy first (some ban autonomous AI PRs\u002Fissues\n     outright), then draft and get **explicit user approval** before posting\n     anything. Until approved, stage the fact in that repo's local Claude\n     project memory as short-lived, not-yet-durable staging, and update\n     `MEMORY.md` there as an index entry too.\n   - **General standing rule** — an always-apply working preference across ALL repos (\"always link PRs in tables\", \"use Pacific time\") → ai-config's own `AGENTS.md` (cross-agent) or `CLAUDE.md` \u002F a `shared\u002F` fragment (Claude-specific detail), committed to `Morrison-Lab\u002Fai-config` by PR.\n     The plugin's `hooks\u002Finject-core-rules.py` starts every session with `AGENTS.md`'s section index and an order to read it in full, so that is what makes the rule reach other projects.\n     Keep the `AGENTS.md` entry to the rule in a line or two with a pointer, and put detail in a `shared\u002F` fragment: `AGENTS.md` has a hard 32,768-byte cap.\n     Do not write it to `~\u002F.claude\u002FCLAUDE.md` unless that file is a symlink into an ai-config checkout: the symlink install was removed, and a plain file there is invisible to every other machine, container and project.\n   - **Host memory is a copy, never the home.**\n     A claude.ai project's memory, a Cowork or desktop memory store, or any other memory the harness offers is read only inside that project.\n     A cross-project rule goes to ai-config as above;\n     the host memory may hold a pointer to it (ai-config#4208).\n   - **General reference fact** — a cross-project fact that only matters when\n     relevant (\"gh opens a pager — pipe to cat\") → a topical file in\n     `\u002Fmemories\u002F`, or `tools.md` for what fits none of them.\n     Read `memories\u002FMEMORY.md` for the current set and what each one covers;\n     it is the registry, so naming the files here too would only go stale.\n     When you add a *new* file here (not just a bullet to an existing one),\n     register it in `memories\u002FMEMORY.md` as an index entry: a table row of\n     its own whose first cell links to it.\n     `scripts\u002Fcheck-memory-index.py` fails CI on a file with no such row\n     (ai-config#4987).\n   - **Conversation-only** → `\u002Fmemories\u002Fsession\u002F`\n   - When ambiguous between project and general, judge by relevance; default\n     to general.\n3. **Choose file**: read the target's current contents first. Append to an\n   existing section\u002Ffile if one fits; otherwise create a descriptively named\n   file — and when you create a *new* file under `\u002Fmemories\u002F`, add a row for it\n   to `memories\u002FMEMORY.md` (the index).\n   Don't duplicate -- grep the target file for the subject\n   (the tool name, the API call, the error string),\n   not just the region you're appending to;\n   a long file like `memories\u002Fr-quarto.md` can already cover it\n   hundreds of lines away.\n   Grep every topical file, not just the one you picked -- a fact about\n   `gh workflow run` could plausibly have landed in `github.md` or\n   `github-actions.md`.\n   If it's already recorded, update in place rather than stacking a second\n   copy, and say so.\n   Delete a memory that turns out wrong instead of leaving a contradiction.\n4. **Write** a concise bullet (one line preferred), matching the file's voice;\n   include the *why* if it isn't obvious.\n   Don't record what the repo already documents (code structure, git history) — capture only the non-obvious.\n   When the entry records where a directive or fact came from, cite that source as a link to the PR, issue or comment it arose on, not as a bare repository name ([ai-config#4310](https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config\u002Fpull\u002F4310)'s first review caught exactly that).\n5. **Commit & push** the change so it persists.\n   What that means depends on where step 2 wrote it:\n   - **Project's own repo, owned** — commit, push a branch, and open a PR\n     there, same as any other change to that repo.\n   - **Project's own repo, external (not owned)** — never push\u002Fopen a PR\n     directly; follow `upstream-issues` (policy check, draft, explicit user\n     approval) instead.\n   - **`~\u002F.claude\u002Fprojects\u002F*\u002Fmemory\u002F` staging** (the project repo has no\n     agent-doc infrastructure yet, or is external and not yet approved) —\n     no git commit; it persists locally only. Update `MEMORY.md` in that\n     directory as an index entry. Tell the user this is temporary staging\n     and what's still needed (agent-doc infra added via a PR, or upstream\n     approval).\n   - **`\u002Fmemories\u002Fsession\u002F`** — skip; conversation-only notes shouldn't enter the shared repo.\n   - **No `~\u002F.claude\u002Fmemories` symlink** (a cloud or project session, or any machine set up after the symlink install was removed) — attach or clone `Morrison-Lab\u002Fai-config`, commit the change there on a branch, and open a PR (`push-memory` does this).\n     A write under `~\u002F.claude` that is not a symlink into ai-config is lost with the container or stays on one machine, which is how the user ends up repeating themselves.\n   - **Everything else gets committed** to ai-config.\n     The commands below apply only to a machine that still has the legacy `~\u002F.claude\u002Fmemories` symlink into an ai-config checkout and works in that checkout;\n     without the symlink, use the bullet above.\n     When you're **working primarily in another repo** and want to push a general memory to ai-config from there, use `push-memory` instead --- it delivers on a branch + PR and never touches the repo you're in.\n     Resolve the repo from the `memories\u002F` symlink and stage the file by its path *within* the repo (`git rev-parse --show-toplevel` follows the symlink to the repo root, robust across one or many hops, unlike single-hop `readlink`):\n\n   ```bash\n   [ -L ~\u002F.claude\u002Fmemories ] || { echo \"no ~\u002F.claude\u002Fmemories symlink: use the no-symlink path (push-memory)\"; exit 1; }\n   repo=\"$(git -C ~\u002F.claude\u002Fmemories rev-parse --show-toplevel)\"   # ai-config repo root\n   rel=\"CLAUDE.md\"   # or memories\u002F\u003Cfile>.md  (NOT memories\u002Frepo\u002F — that's gone)\n   git -C \"$repo\" add \"$rel\" \\\n     && git -C \"$repo\" commit -m \"memorize: \u003Cone-line summary>\"\n   ```\n\n   Push as a separate Bash call, per [`check-before-pushing`](..\u002F..\u002Fshared\u002Fworkflow\u002Fcheck-before-pushing.md)'s \"Keep the commit in its own Bash call\":\n\n   ```bash\n   repo=\"$(git -C ~\u002F.claude\u002Fmemories rev-parse --show-toplevel)\"   # re-derived: a separate Bash call does not inherit the variable\n   git -C \"$repo\" push origin HEAD   # current branch; not HEAD:main -- that would push a feature branch's commits onto main\n   ```\n\n   The push targets the ai-config repo's **current branch**, so run memorize\n   from a checkout on `main` (the normal case) — that's where shared memory\n   belongs. In an ephemeral cloud session the push is mandatory: an unpushed\n   commit dies with the container.\n\n   **Worktree session \u002F occupied main checkout (legacy symlink machines).**\n   Where `~\u002F.claude\u002Fmemories` and `~\u002F.claude\u002FCLAUDE.md` are still symlinked to the **main** checkout, `git -C ~\u002F.claude\u002Fmemories rev-parse --show-toplevel` resolves to the main checkout — *not* your worktree.\n   If that checkout is on a non-`main` branch (e.g. another session is working there, possibly with uncommitted edits), committing through the symlink lands your memory on the wrong branch and can tangle with that session's work.\n   In that case don't commit through the symlink: edit the memory file at its path inside **your** worktree, commit on your worktree branch, and land it via branch + PR + merge.\n   It only reaches the live symlinked memory once it merges to `main` and the main checkout updates.\n   (See the worktree-isolation and no-`cd`-in-worktree bullets in\n   `memories\u002Fpreferences.md`, and the `session-lock` skill.)\n6. **Confirm**: one sentence — what was stored, where, and that it was pushed.\n\n## Don't\n\n- Don't run a full session review or touch skill files (that's `ums`).\n- Don't commit unrelated changes — stage only the file you wrote.\n- Don't push conversation-only (`\u002Fmemories\u002Fsession\u002F`) notes to the shared repo.\n- Don't store secrets, tokens, or passwords.\n- Don't over-elaborate — one bullet per fact.\n",{"name":5,"description":7,"allowed-tools":24,"user-invocable":29},[25,26,27,28],"Read","Write","Edit","Bash",true,"main","f8f5ea79cc52e903c30773b5e264e384e715c4c7","skills\u002Fmemorize",1,"https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config","https:\u002F\u002Fmorrison-lab.github.io\u002Fai-config\u002F","https:\u002F\u002Fgithub.com\u002FMorrison-Lab","2026-11-12 06:23:19",{"source":8,"skillName":5,"commands":39,"prompt":49,"zipAvailable":29},[40,43,46],{"tool":41,"command":42},"npx","npx skills add Morrison-Lab\u002Fai-config --skill memorize",{"tool":44,"command":45},"bunx","bunx skills add Morrison-Lab\u002Fai-config --skill memorize",{"tool":47,"command":48},"pnpm","pnpm dlx skills add Morrison-Lab\u002Fai-config --skill memorize","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config\u002Fblob\u002Fmain\u002Fskills\u002Fmemorize\u002FSKILL.md",[],[52,59,66,73,80,87],{"skillNo":53,"name":54,"nameZh":6,"description":55,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":19},"01M735B6T9KP24YK73HZYS361B","triage","Triage backlog: P1\u002FP2\u002FP3 or close.","https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config\u002Fblob\u002Fmain\u002Fskills\u002Ftriage\u002FSKILL.md",[],[],{"skillNo":60,"name":61,"nameZh":6,"description":62,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":63,"categories":64,"keywords":65,"publishedAt":19},"01M735ABCWNZ3WJKPC1ABJ7W8B","st","Start task issue-first.","https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config\u002Fblob\u002Fmain\u002Fskills\u002Fst\u002FSKILL.md",[],[],{"skillNo":67,"name":68,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":19},"01M7355RRVTEEFJ16QVM86EK7X","mwc","Session merge grant with confidence gate.","https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config\u002Fblob\u002Fmain\u002Fskills\u002Fmwc\u002FSKILL.md",[],[],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":79,"publishedAt":19},"01M7355JBSBYP7AQQ2165FJKBW","migrate-discussion","Move items between Issues and Discussions.","https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config\u002Fblob\u002Fmain\u002Fskills\u002Fmigrate-discussion\u002FSKILL.md",[],[],{"skillNo":81,"name":82,"nameZh":6,"description":83,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":84,"categories":85,"keywords":86,"publishedAt":19},"01M7351KXGW9QTKQHH1HJFS4YF","defer-issue","File issue for deferred work.","https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config\u002Fblob\u002Fmain\u002Fskills\u002Fdefer-issue\u002FSKILL.md",[],[],{"skillNo":88,"name":89,"nameZh":6,"description":90,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":91,"categories":92,"keywords":93,"publishedAt":19},"01M73512AEG0J04NPM2YP9CEW8","create-release-checklist","Create an R package release-checklist issue.","https:\u002F\u002Fgithub.com\u002FMorrison-Lab\u002Fai-config\u002Fblob\u002Fmain\u002Fskills\u002Fcreate-release-checklist\u002FSKILL.md",[],[]]