[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71MTTNEH14DVYVG8FDS8TXE":3,"skill-same:01M71MTTNEH14DVYVG8FDS8TXE":67},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M71MTTNEH14DVYVG8FDS8TXE","commit-discipline",null,"Git branch naming, commit frequency, and commit message rules for this repository. Read before any commit, branch creation, or PR. Use whenever staging changes, writing commit messages, or deciding when to commit.","applypack\u002Fapplypack","applypack","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F323661273?v=4","01M71MTCGWDKJ7EXW015KCSM5Z","ApplyPack","01M71MTCHJ3VRWDNDAEAARMD1Q",32,"MIT","https:\u002F\u002Fgithub.com\u002Fapplypack\u002Fapplypack\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcommit-discipline\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"discipline","commit discipline","commit","commit message","Rules","Frequency","use","for","pr","commit messages","git","repository","read","message","when","writing","messages","creation","branch","git branch naming","2026-11-10 10:56:23",false,"---\nname: commit-discipline\ndescription: Git branch naming, commit frequency, and commit message rules for this repository. Read before any commit, branch creation, or PR. Use whenever staging changes, writing commit messages, or deciding when to commit.\n---\n\n# Commit Discipline\n\nThe goal: a commit history that reads like a senior engineer's worklog and tells the story of the project - small, green, one purpose each, written by a human. Frequent commits are a project requirement, not a preference.\n\n## Message style: short, natural, verb-first\n\nPlain messages, 2 to 5 words, starting with an action verb. No conventional-commit prefixes (feat:, fix:, chore:) - natural wording is more readable for a solo project and looks human, not generated.\n\nApproved verbs: add, create, setup, remove, rename, move, extract, refactor, optimize, improve, fix, update, support, test.\n\n```\nadd batch classifier\nextract ai provider\nfix remoteok meta row\nadd himalayas fetcher\ntest hn parser entities\nrefactor settings toggles\nupdate fit score badge\nsupport claude code provider\n```\n\nAn optional `phase-x.y:` prefix is fine when the work belongs to a numbered\nphase from SPEC.md (`phase-8.1: add ai provider`).\n\nThe One Question Rule before every commit: \"What changed after this commit?\" If the answer fits naturally in 3 to 5 words, the size is right. If you need a paragraph, split the commit.\n\nBody text only when the \"why\" is truly not obvious - one short line, plain English.\n\nAuthorship: single author (Nazar's git identity). Never add Co-Authored-By trailers, \"Generated with\" lines, or any AI attribution - includeCoAuthoredBy is disabled in settings and must stay disabled.\n\n## When to commit\n\n- After every coherent behavior with passing checks - roughly every 20 to 60 minutes of active work.\n- Immediately after a test goes green.\n- Before switching tasks and before any risky refactor.\n- Target throughput: 5 to 10+ meaningful commits per working day. One giant end-of-day commit means the process failed.\n\n## Never commit\n\nBroken builds; failing tests; mixed unrelated changes; debug output or console.log; commented-out code; generated artifacts (dist\u002F, __pycache__); formatting churn unrelated to the change; secrets (.env). CLAUDE.md, docs\u002F and .claude\u002F (skills, hooks, settings.json) ARE tracked here — only settings.local.json is not.\n\n## Branch naming: name the outcome, not the phase\n\nA branch is named after what it will merge into main: 2 to 4 words, kebab-case, no prefixes, no ticket numbers, no phase numbers. Anyone reading the branch list should understand the work in progress without opening a single diff.\n\n```\nai-provider               batch-classifier\ndashboard-tokens          jobs-table-redesign\njob-verifier              fix-remoteok-meta\n```\n\nExisting `phase-x.y-\u003Coutcome>` names are acceptable while phases are tracked\nin SPEC.md; the outcome part is mandatory. Bad: phase-8, wip, nazar-dev.\n\nBranches are short-lived: merged within a day or two, deleted after merge. Never rewrite shared history, never force-push shared branches. When a feature branch passes its verification, push it and open a PR right away (standing policy 2026-08-31, one per feature); merging to main stays with Nazar.\n\n## Pre-merge gate (before opening the PR)\n\nPer-commit hygiene is not enough — before the PR, review the **whole\nbranch diff** with fresh eyes:\n\n- Run the `code-review-expert` skill over `git diff main...HEAD`\n  (mandatory since 2026-08-31).\n- Ask of every added line: is it needed at all, can it be simpler, can\n  it be more readable? Delete speculative code now, not \"later\".\n- P0\u002FP1 findings are fixed before the PR exists; P2\u002FP3 go into the PR\n  body as named follow-ups — never silently dropped.\n- The PR description includes a \"Release notes\" draft (see the\n  `release-discipline` skill) so the post-merge release is one command.\n\nTags and GitHub releases after the merge follow the `release-discipline`\nskill (annotated minor per feature, release parity with tags).\n\n## Split large refactors\n\nNot \"refactor classifier\" but a sequence: extract ai provider, move prompt builders, remove duplicated retry loop. Small commits make history reviewable.\n\n## Pre-commit gate\n\n```\n[ ] One clear purpose, message answers \"what changed\" in 2-5 words\n[ ] Diff re-read: every line is needed (no dead code, unused imports\u002Fexports\u002Fprops\u002FCSS, no speculative abstractions)\n[ ] Comments minimal: only non-obvious \"why\", one sentence max, no fluff\n[ ] Code reads simply; any optimization has a measured reason\n[ ] `npm run lint:types && npm test` pass\n[ ] Pure logic has a *.test.ts next to it (see CLAUDE.md Testing)\n[ ] Schema change ships a hand-written migration (CLAUDE.md gotcha 7)\n[ ] Dashboard change checked at 1440 \u002F 768 \u002F 375 (one light theme), keyboard reachable\n```\n\nThe diff re-read is not optional. If a line does not earn its place, delete it before committing, not \"later\".\n","# Commit Discipline\n\nThe goal: a commit history that reads like a senior engineer's worklog and tells the story of the project - small, green, one purpose each, written by a human. Frequent commits are a project requirement, not a preference.\n\n## Message style: short, natural, verb-first\n\nPlain messages, 2 to 5 words, starting with an action verb. No conventional-commit prefixes (feat:, fix:, chore:) - natural wording is more readable for a solo project and looks human, not generated.\n\nApproved verbs: add, create, setup, remove, rename, move, extract, refactor, optimize, improve, fix, update, support, test.\n\n```\nadd batch classifier\nextract ai provider\nfix remoteok meta row\nadd himalayas fetcher\ntest hn parser entities\nrefactor settings toggles\nupdate fit score badge\nsupport claude code provider\n```\n\nAn optional `phase-x.y:` prefix is fine when the work belongs to a numbered\nphase from SPEC.md (`phase-8.1: add ai provider`).\n\nThe One Question Rule before every commit: \"What changed after this commit?\" If the answer fits naturally in 3 to 5 words, the size is right. If you need a paragraph, split the commit.\n\nBody text only when the \"why\" is truly not obvious - one short line, plain English.\n\nAuthorship: single author (Nazar's git identity). Never add Co-Authored-By trailers, \"Generated with\" lines, or any AI attribution - includeCoAuthoredBy is disabled in settings and must stay disabled.\n\n## When to commit\n\n- After every coherent behavior with passing checks - roughly every 20 to 60 minutes of active work.\n- Immediately after a test goes green.\n- Before switching tasks and before any risky refactor.\n- Target throughput: 5 to 10+ meaningful commits per working day. One giant end-of-day commit means the process failed.\n\n## Never commit\n\nBroken builds; failing tests; mixed unrelated changes; debug output or console.log; commented-out code; generated artifacts (dist\u002F, __pycache__); formatting churn unrelated to the change; secrets (.env). CLAUDE.md, docs\u002F and .claude\u002F (skills, hooks, settings.json) ARE tracked here — only settings.local.json is not.\n\n## Branch naming: name the outcome, not the phase\n\nA branch is named after what it will merge into main: 2 to 4 words, kebab-case, no prefixes, no ticket numbers, no phase numbers. Anyone reading the branch list should understand the work in progress without opening a single diff.\n\n```\nai-provider               batch-classifier\ndashboard-tokens          jobs-table-redesign\njob-verifier              fix-remoteok-meta\n```\n\nExisting `phase-x.y-\u003Coutcome>` names are acceptable while phases are tracked\nin SPEC.md; the outcome part is mandatory. Bad: phase-8, wip, nazar-dev.\n\nBranches are short-lived: merged within a day or two, deleted after merge. Never rewrite shared history, never force-push shared branches. When a feature branch passes its verification, push it and open a PR right away (standing policy 2026-08-31, one per feature); merging to main stays with Nazar.\n\n## Pre-merge gate (before opening the PR)\n\nPer-commit hygiene is not enough — before the PR, review the **whole\nbranch diff** with fresh eyes:\n\n- Run the `code-review-expert` skill over `git diff main...HEAD`\n  (mandatory since 2026-08-31).\n- Ask of every added line: is it needed at all, can it be simpler, can\n  it be more readable? Delete speculative code now, not \"later\".\n- P0\u002FP1 findings are fixed before the PR exists; P2\u002FP3 go into the PR\n  body as named follow-ups — never silently dropped.\n- The PR description includes a \"Release notes\" draft (see the\n  `release-discipline` skill) so the post-merge release is one command.\n\nTags and GitHub releases after the merge follow the `release-discipline`\nskill (annotated minor per feature, release parity with tags).\n\n## Split large refactors\n\nNot \"refactor classifier\" but a sequence: extract ai provider, move prompt builders, remove duplicated retry loop. Small commits make history reviewable.\n\n## Pre-commit gate\n\n```\n[ ] One clear purpose, message answers \"what changed\" in 2-5 words\n[ ] Diff re-read: every line is needed (no dead code, unused imports\u002Fexports\u002Fprops\u002FCSS, no speculative abstractions)\n[ ] Comments minimal: only non-obvious \"why\", one sentence max, no fluff\n[ ] Code reads simply; any optimization has a measured reason\n[ ] `npm run lint:types && npm test` pass\n[ ] Pure logic has a *.test.ts next to it (see CLAUDE.md Testing)\n[ ] Schema change ships a hand-written migration (CLAUDE.md gotcha 7)\n[ ] Dashboard change checked at 1440 \u002F 768 \u002F 375 (one light theme), keyboard reachable\n```\n\nThe diff re-read is not optional. If a line does not earn its place, delete it before committing, not \"later\".\n",{"name":5,"description":7},"main","bb5ed6f9e0ddbf410b1e9a4559f500f246c1677c",".claude\u002Fskills\u002Fcommit-discipline",11,"https:\u002F\u002Fgithub.com\u002Fapplypack\u002Fapplypack","https:\u002F\u002Fapplypack.dev","https:\u002F\u002Fgithub.com\u002Fapplypack","https:\u002F\u002Fwww.applypack.dev\u002F","2026-11-10 00:46:54",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add applypack\u002Fapplypack --skill commit-discipline",{"tool":59,"command":60},"bunx","bunx skills add applypack\u002Fapplypack --skill commit-discipline",{"tool":62,"command":63},"pnpm","pnpm dlx skills add applypack\u002Fapplypack --skill commit-discipline","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapplypack\u002Fapplypack\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcommit-discipline\u002FSKILL.md",true,[],[68,91,117,144,170,186],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":39},"01M71MVP13VV4T7N1D9019K27P","wizard","Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.","https:\u002F\u002Fgithub.com\u002Fapplypack\u002Fapplypack\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fwizard\u002FSKILL.md",[],[70,75,76,77,78,79,33,80,81,82,83,84,85,86,87,88,89,26,25,90],"up","ci","provisioning infrastructure","only","invoke","Bash","credentials","dashboard","generate","human","secrets","steps","infrastructure","running","setting","one",{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":102,"publishedAt":39},"01M71MVKNGWANA0EEWE4GXNFPY","ui-review","Senior UI\u002FUX review of an ApplyPack dashboard page, screenshot, or primitive. Use when asked to critique, audit, or find improvements in the dashboard. Produces prioritized findings, never code.","https:\u002F\u002Fgithub.com\u002Fapplypack\u002Fapplypack\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fui-review\u002FSKILL.md",[97],{"categoryNo":98,"categoryName":99,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[103,104,105,106,33,107,108,82,109,110,111,112,113,114,115,25,116],"review","ui","ui review","never","code","ui\u002Fux","critique","senior","audit","ux","screenshot","ux review","page","find",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":128,"publishedAt":39},"01M71MVGP02E5QF3RG8TAZNH93","testing-gate","Required verification per change type for ApplyPack (pure module → unit test, fetcher → smoke run, schema → hand-written migration, dashboard → rebuild + screenshot). Read before implementing any feature and before every commit.","https:\u002F\u002Fgithub.com\u002Fapplypack\u002Fapplypack\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ftesting-gate\u002FSKILL.md",[123],{"categoryNo":124,"categoryName":125,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[129,130,131,132,133,134,21,135,136,137,138,82,139,31,140,113,141,142,26,143],"testing","testing gate","gate","unit test","unit","implementing","hand","rebuild","verification","change","run","fetcher","smoke","feature","module",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":156,"publishedAt":39},"01M71MVESMK8EWKVQ3G5EHBS1C","stop-slop","Remove AI writing patterns from prose. Use when drafting, editing, or reviewing text to eliminate predictable AI tells.","https:\u002F\u002Fgithub.com\u002Fapplypack\u002Fapplypack\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fstop-slop\u002FSKILL.md",[150,153],{"categoryNo":151,"categoryName":152,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":154,"categoryName":155,"taxonomyType":100,"taxonomyTypeDesc":101},"01JBSEEDCAT000000000000036","内容创作者",[157,158,159,26,160,161,34,25,33,162,163,164,165,166,167,168,169],"slop","stop slop","stop","remove","editing","drafting","text","https","ai tells","drafts","prose","patterns","content",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":39},"01M71MVCHADA18SPKG8G4VFN35","resolving-merge-conflicts","Use when you need to resolve an in-progress git merge\u002Frebase conflict.","https:\u002F\u002Fgithub.com\u002Fapplypack\u002Fapplypack\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fresolving-merge-conflicts\u002FSKILL.md",[],[177,178,179,180,181,25,33,182,183,184,29,185],"merge conflicts","conflicts","resolving merge conflicts","merge","conflict","git merge","you","progress","rebase",{"skillNo":187,"name":188,"nameZh":6,"description":189,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":190,"categories":191,"keywords":192,"publishedAt":39},"01M71MVA895X32BXCMNXH8K1N6","release-discipline","Tag and GitHub-release rules for this repository — when a merge gets a version tag, how releases stay in parity with tags, and the release-notes format. Read after every PR merge, before tagging, and at the start of a new stage (parity check).","https:\u002F\u002Fgithub.com\u002Fapplypack\u002Fapplypack\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Frelease-discipline\u002FSKILL.md",[],[193,19,194,195,196,197,33,198,199,200,201,180,202,31,30,203,204,205,206,27],"release discipline","release","release-notes","pr merge","new","notes","releases","how","tagging","at","notes format","start","parity","parity check"]