[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CWMYN0FCEE8MJD3YEK2KJY":3,"skill-same:01M6CWMYN0FCEE8MJD3YEK2KJY":53},{"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":27,"linkOnly":28,"markdownContent":29,"markdownBody":30,"frontMatter":31,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":35,"repositoryHtmlUrl":36,"repositoryHomepageUrl":6,"ownerHtmlUrl":37,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":38,"install":39,"resources":52},"01M6CWMYN0FCEE8MJD3YEK2KJY","gitignore-narrowing",null,"Use when narrowing or rewriting a .gitignore pattern so that some previously-ignored files become trackable, before staging or committing that change. Symptoms\u002Fkeywords — gitignore anchoring, git check-ignore, middle-slash patterns, testdata\u002F narrowing, newly-visible or newly-untracked files, git add -A, git add .","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\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskB\u002FB-S\u002Fskills\u002Fgitignore-narrowing\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26],"gitignore","gitignore narrowing","change","git","check","use","files","patterns","pattern","2026-11-10 10:12:30",false,"---\nname: gitignore-narrowing\ndescription: Use when narrowing or rewriting a .gitignore pattern so that some previously-ignored files become trackable, before staging or committing that change. Symptoms\u002Fkeywords — gitignore anchoring, git check-ignore, middle-slash patterns, testdata\u002F narrowing, newly-visible or newly-untracked files, git add -A, git add .\n---\n\n# Gitignore Narrowing: Anchor Verification and Explicit Visible-Set Staging\n\n## Overview\n\nNarrowing a `.gitignore` pattern (e.g. `testdata\u002F` -> `testdata\u002Frapid\u002F`) has two\nindependent failure modes: the new pattern can silently stop matching nested\npaths (a gitignore anchoring gotcha), and the files it newly exposes can get\nswept into a commit alongside unrelated untracked work if staged with a bare\n`git add -A`\u002F`git add .`. This skill is the verification-and-staging procedure\nthat catches both before anything is committed.\n\n## When to Use\n\nBefore shipping a narrowed or rewritten `.gitignore` pattern that makes some\npreviously-ignored files trackable. Triggers include:\n\n- Tightening a broad ignore rule (e.g. `testdata\u002F` -> `testdata\u002Frapid\u002F`) so\n  only a subset stays ignored.\n- Any `.gitignore` edit expected to newly expose files in nested\n  subdirectories, not just at the repo root.\n- About to stage the result of a `.gitignore` narrowing with `git add`.\n\n## Procedure\n\n1. In a scratch repo, write the proposed replacement `.gitignore` pattern.\n2. Run `git check-ignore -q \u003Cpath>` against representative paths, including\n   nested ones under subdirectories (e.g. `internal\u002F*\u002Ftestdata\u002Frapid\u002F`,\n   `test\u002Ftestdata\u002Frapid\u002F`), to confirm the pattern still matches at the\n   intended depth.\n3. If a pattern contains a middle slash (e.g. narrowing `testdata\u002F` to\n   `testdata\u002Frapid\u002F`), know it anchors to the `.gitignore`'s own directory\n   and silently stops matching nested paths; use a leading `**\u002F` form\n   instead (e.g. `**\u002Ftestdata\u002Frapid\u002F`) to keep matching at any depth. Never\n   verify anchoring by reading the pattern alone.\n4. In the real repo, write the proposed `.gitignore` and run\n   `git status --porcelain` to enumerate the full set of\n   newly-untracked\u002Fvisible files it exposes, then restore.\n5. Stage only the explicit enumerated paths from that list — never\n   `git add -A` or `git add .`.\n6. Confirm the staged set matches the enumerated list exactly by running\n   `git diff --cached --name-only`.\n\n## Done When\n\nThe pattern's anchoring form has been confirmed correct via a scratch-repo\n`git check-ignore` check against representative (including nested) paths,\nand the exact set of newly-visible files has been enumerated and staged as\nan explicit path list rather than swept up by `git add`.\n\n## Common Mistakes\n\n| Excuse under pressure | Reality |\n|---|---|\n| \"This exact pattern worked on another repo, it's proven — no need to re-derive or re-verify it\" | Anchoring depends on where the `.gitignore` lives and the directory structure of *this* repo. A pattern that matched elsewhere can still fail to match nested paths here. Re-verify with `git check-ignore -q` every time, even a \"proven\" pattern. |\n| \"We're out of time, just `git add -A` so nothing gets missed\" | `git add -A` sweeps in whatever else is untracked in the repo, not just the files the `.gitignore` change exposed. Enumerate the visible set from `git status --porcelain` and stage that explicit list instead. |\n| \"Skip the extra checks, just ship it\" | Skipping `git check-ignore` and the final `git diff --cached --name-only` check is exactly how a silently-broken anchor or an accidentally-staged unrelated file reaches a commit. |\n\n## Red Flags — Stop and Follow the Procedure\n\n- About to run `git add -A` or `git add .` right after a `.gitignore` change.\n- Trusting a narrowed pattern's anchoring \"by reading it\" instead of running\n  `git check-ignore -q` against a nested path.\n- Reusing a pattern from another repo or an earlier change without\n  re-verifying it against *this* repo's directory structure.\n- Committing before running `git diff --cached --name-only` to confirm the\n  staged set matches the enumerated visible-set list exactly.\n","# Gitignore Narrowing: Anchor Verification and Explicit Visible-Set Staging\n\n## Overview\n\nNarrowing a `.gitignore` pattern (e.g. `testdata\u002F` -> `testdata\u002Frapid\u002F`) has two\nindependent failure modes: the new pattern can silently stop matching nested\npaths (a gitignore anchoring gotcha), and the files it newly exposes can get\nswept into a commit alongside unrelated untracked work if staged with a bare\n`git add -A`\u002F`git add .`. This skill is the verification-and-staging procedure\nthat catches both before anything is committed.\n\n## When to Use\n\nBefore shipping a narrowed or rewritten `.gitignore` pattern that makes some\npreviously-ignored files trackable. Triggers include:\n\n- Tightening a broad ignore rule (e.g. `testdata\u002F` -> `testdata\u002Frapid\u002F`) so\n  only a subset stays ignored.\n- Any `.gitignore` edit expected to newly expose files in nested\n  subdirectories, not just at the repo root.\n- About to stage the result of a `.gitignore` narrowing with `git add`.\n\n## Procedure\n\n1. In a scratch repo, write the proposed replacement `.gitignore` pattern.\n2. Run `git check-ignore -q \u003Cpath>` against representative paths, including\n   nested ones under subdirectories (e.g. `internal\u002F*\u002Ftestdata\u002Frapid\u002F`,\n   `test\u002Ftestdata\u002Frapid\u002F`), to confirm the pattern still matches at the\n   intended depth.\n3. If a pattern contains a middle slash (e.g. narrowing `testdata\u002F` to\n   `testdata\u002Frapid\u002F`), know it anchors to the `.gitignore`'s own directory\n   and silently stops matching nested paths; use a leading `**\u002F` form\n   instead (e.g. `**\u002Ftestdata\u002Frapid\u002F`) to keep matching at any depth. Never\n   verify anchoring by reading the pattern alone.\n4. In the real repo, write the proposed `.gitignore` and run\n   `git status --porcelain` to enumerate the full set of\n   newly-untracked\u002Fvisible files it exposes, then restore.\n5. Stage only the explicit enumerated paths from that list — never\n   `git add -A` or `git add .`.\n6. Confirm the staged set matches the enumerated list exactly by running\n   `git diff --cached --name-only`.\n\n## Done When\n\nThe pattern's anchoring form has been confirmed correct via a scratch-repo\n`git check-ignore` check against representative (including nested) paths,\nand the exact set of newly-visible files has been enumerated and staged as\nan explicit path list rather than swept up by `git add`.\n\n## Common Mistakes\n\n| Excuse under pressure | Reality |\n|---|---|\n| \"This exact pattern worked on another repo, it's proven — no need to re-derive or re-verify it\" | Anchoring depends on where the `.gitignore` lives and the directory structure of *this* repo. A pattern that matched elsewhere can still fail to match nested paths here. Re-verify with `git check-ignore -q` every time, even a \"proven\" pattern. |\n| \"We're out of time, just `git add -A` so nothing gets missed\" | `git add -A` sweeps in whatever else is untracked in the repo, not just the files the `.gitignore` change exposed. Enumerate the visible set from `git status --porcelain` and stage that explicit list instead. |\n| \"Skip the extra checks, just ship it\" | Skipping `git check-ignore` and the final `git diff --cached --name-only` check is exactly how a silently-broken anchor or an accidentally-staged unrelated file reaches a commit. |\n\n## Red Flags — Stop and Follow the Procedure\n\n- About to run `git add -A` or `git add .` right after a `.gitignore` change.\n- Trusting a narrowed pattern's anchoring \"by reading it\" instead of running\n  `git check-ignore -q` against a nested path.\n- Reusing a pattern from another repo or an earlier change without\n  re-verifying it against *this* repo's directory structure.\n- Committing before running `git diff --cached --name-only` to confirm the\n  staged set matches the enumerated visible-set list exactly.\n",{"name":5,"description":7},"main","d2ce817c74ee4fc65645635887510b47b231230f","dev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskB\u002FB-S\u002Fskills\u002Fgitignore-narrowing",2,"https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram","https:\u002F\u002Fgithub.com\u002Ftoejough","2026-10-25 06:42:30",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add toejough\u002Fengram --skill gitignore-narrowing",{"tool":45,"command":46},"bunx","bunx skills add toejough\u002Fengram --skill gitignore-narrowing",{"tool":48,"command":49},"pnpm","pnpm dlx skills add toejough\u002Fengram --skill gitignore-narrowing","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskB\u002FB-S\u002Fskills\u002Fgitignore-narrowing\u002FSKILL.md",true,[],[54,69,74,79,100,118],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":27},"01M6CWPEHWS45MANQE0JW6Z146","recall","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",[],[56,61,62,63,64,65,66,67,23,68],"surfaces","memories","first","call","thinking","tool","user","good",{"skillNo":70,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":27},"01M6CWPAZ9N9CE1RC754XEJ021","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Fskills_auto\u002Frecall\u002FSKILL.md",[],[56,63,66,67,23,68,61,65,64,62],{"skillNo":75,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":27},"01M6CWP862CSBPDF1QW19P6C0F","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskWriteMemory\u002Frecall-learn\u002Frecall\u002FSKILL.md",[],[56,63,66,67,23,68,61,65,64,62],{"skillNo":80,"name":81,"nameZh":6,"description":82,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":83,"categories":84,"keywords":85,"publishedAt":27},"01M6CWP4XPAJYCJMZAPYNWTN3A","learn","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.","https:\u002F\u002Fgithub.com\u002Ftoejough\u002Fengram\u002Fblob\u002Fmain\u002Fdev\u002Feval\u002Fcumulative\u002Frunbook_vs_skill\u002Fphase2\u002Fencodings\u002FtaskWriteMemory\u002Frecall-learn\u002Flearn\u002FSKILL.md",[],[81,86,87,88,89,90,56,66,91,92,22,93,94,95,23,96,97,98,99,64],"time","remember","design","review","next","choice","work","behavior","fix","session","evidence","reusable","later","lesson",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":9,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":27},"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",[],[107,108,109,110,81,111,56,112,113,114,115,116,117],"write memory","write","memory","handoff","vault","command","reports","do","engram","another skill","judgment",{"skillNo":119,"name":120,"nameZh":6,"description":121,"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":129,"publishedAt":27},"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",[124],{"categoryNo":125,"categoryName":126,"taxonomyType":127,"taxonomyTypeDesc":128},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[130,131,132,133,134,23,135],"test","test driven development","development","writing","code","implementation"]