[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KWZSPMKM0PAZE4TDRXYC29":3,"skill-same:01M6KWZSPMKM0PAZE4TDRXYC29":73},{"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":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6KWZSPMKM0PAZE4TDRXYC29","minimal-change",null,"Finds the smallest change that actually solves a coding problem: question whether the code needs to exist, then reach for existing code, the standard library, native platform features, and installed dependencies before writing anything new. Use before adding a dependency, an abstraction, a config option, or a new module; when simplifying a diff before review; and when the user asks for the simplest solution or complains about over-engineering. Not for trivial edits or for writing prose.","dougborg\u002Fharness-kit","dougborg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1261222?v=4","01M6KWS4PB51EYD4ZDJJSGNGB2","Doug Borg","01M6KWS4T8ZZW6SX5QZS9B5BN2",0,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fminimal-change\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"minimal change","change","minimal","dependencies","new module","Existing","for","about","native","problem","module","platform","writing","dependency","diff","use","question","option","code","review","2026-11-10 10:12:30",false,"---\nname: minimal-change\ndescription: >-\n  Finds the smallest change that actually solves a coding problem: question\n  whether the code needs to exist, then reach for existing code, the standard\n  library, native platform features, and installed dependencies before writing\n  anything new. Use before adding a dependency, an abstraction, a config\n  option, or a new module; when simplifying a diff before review; and when the\n  user asks for the simplest solution or complains about over-engineering. Not\n  for trivial edits or for writing prose.\n---\n\n# Minimal Change\n\nUnderstand the problem fully, then build the least that solves it.\n\n## Read first\n\nRead the task and every file the change touches, and trace the real flow end\nto end, before choosing an approach. The smallest diff in the wrong place is a\nsecond bug. Done when you can name each place the change has to touch and\nwhy.\n\n## Climb the ladder\n\nThe ladder is a reflex, not a research project. Stop at the first rung that\nholds:\n\n1. **Does this need to exist?** If the need is speculative, skip it and say so\n   in one line.\n2. **Is it already in this codebase?** Reuse the helper, type, or pattern that\n   lives a few files over; reimplementing it is the most common waste.\n3. **Does the standard library do it?** Use it.\n4. **Does a native platform feature cover it?** `\u003Cinput type=\"date\">` over a\n   picker library, CSS over JavaScript, a database constraint over\n   application code.\n5. **Does an installed dependency solve it?** Use it. Add a new dependency\n   only when a few lines can't do the job.\n6. **Can it be one line?** Write one line.\n7. **Only then** write the minimum code that works.\n\nWhen two rungs work, take the higher one. When two standard-library options\nare the same size, take the one that is correct on edge cases: minimal means\nless code, not a flimsier algorithm.\n\nAdd an abstraction only when something varies: an interface gets a second\nimplementation, a factory a second product, a config value a second setting.\nPrefer fewer files. For a large request, ship the minimal version and name\nwhat you left out (\"Did X; Y covers it. Need full X? Say so.\").\n\nDone when each addition in the change sits on the highest rung that works.\n\n## Always keep\n\nThe ladder never removes these: input validation at trust boundaries, error\nhandling that prevents data loss, security measures, accessibility basics,\ncalibration knobs for real hardware, and anything the user explicitly asked\nfor. If the user wants the full version, build it.\n\nNon-trivial logic (a branch, a loop, a parser, a money or security path)\nkeeps one runnable check: the smallest test that fails if the logic breaks.\nTrivial one-liners need none.\n\n## Mark deliberate shortcuts\n\nWhen a simplification has a real ceiling (a global lock, an O(n²) scan, a\nnaive heuristic), mark it with a comment in this shape, using the file's\ncomment syntax:\n\n```text\n\u003Ccomment> shortcut: \u003Cthe ceiling> | revisit when \u003Cthe trigger>\n```\n\n```python\n# shortcut: one global lock | revisit when write throughput matters\n```\n\n```typescript\n\u002F\u002F shortcut: O(n²) dedupe | revisit when lists exceed ~1k items\n```\n\nDone when every shortcut in the change carries both a ceiling and a trigger,\nso a later sweep (`grep -rnE '(#|\u002F\u002F|--|\u002F\\*|\u003C!--) ?shortcut:'`) can list them\nand flag any without a trigger.\n\n## Report\n\nCode first, then at most three short lines: what you skipped and when to add\nit (`skipped: X, add when Y`). Explanation the user asked for is not padding;\ngive it in full.\n","# Minimal Change\n\nUnderstand the problem fully, then build the least that solves it.\n\n## Read first\n\nRead the task and every file the change touches, and trace the real flow end\nto end, before choosing an approach. The smallest diff in the wrong place is a\nsecond bug. Done when you can name each place the change has to touch and\nwhy.\n\n## Climb the ladder\n\nThe ladder is a reflex, not a research project. Stop at the first rung that\nholds:\n\n1. **Does this need to exist?** If the need is speculative, skip it and say so\n   in one line.\n2. **Is it already in this codebase?** Reuse the helper, type, or pattern that\n   lives a few files over; reimplementing it is the most common waste.\n3. **Does the standard library do it?** Use it.\n4. **Does a native platform feature cover it?** `\u003Cinput type=\"date\">` over a\n   picker library, CSS over JavaScript, a database constraint over\n   application code.\n5. **Does an installed dependency solve it?** Use it. Add a new dependency\n   only when a few lines can't do the job.\n6. **Can it be one line?** Write one line.\n7. **Only then** write the minimum code that works.\n\nWhen two rungs work, take the higher one. When two standard-library options\nare the same size, take the one that is correct on edge cases: minimal means\nless code, not a flimsier algorithm.\n\nAdd an abstraction only when something varies: an interface gets a second\nimplementation, a factory a second product, a config value a second setting.\nPrefer fewer files. For a large request, ship the minimal version and name\nwhat you left out (\"Did X; Y covers it. Need full X? Say so.\").\n\nDone when each addition in the change sits on the highest rung that works.\n\n## Always keep\n\nThe ladder never removes these: input validation at trust boundaries, error\nhandling that prevents data loss, security measures, accessibility basics,\ncalibration knobs for real hardware, and anything the user explicitly asked\nfor. If the user wants the full version, build it.\n\nNon-trivial logic (a branch, a loop, a parser, a money or security path)\nkeeps one runnable check: the smallest test that fails if the logic breaks.\nTrivial one-liners need none.\n\n## Mark deliberate shortcuts\n\nWhen a simplification has a real ceiling (a global lock, an O(n²) scan, a\nnaive heuristic), mark it with a comment in this shape, using the file's\ncomment syntax:\n\n```text\n\u003Ccomment> shortcut: \u003Cthe ceiling> | revisit when \u003Cthe trigger>\n```\n\n```python\n# shortcut: one global lock | revisit when write throughput matters\n```\n\n```typescript\n\u002F\u002F shortcut: O(n²) dedupe | revisit when lists exceed ~1k items\n```\n\nDone when every shortcut in the change carries both a ceiling and a trigger,\nso a later sweep (`grep -rnE '(#|\u002F\u002F|--|\u002F\\*|\u003C!--) ?shortcut:'`) can list them\nand flag any without a trigger.\n\n## Report\n\nCode first, then at most three short lines: what you skipped and when to add\nit (`skipped: X, add when Y`). Explanation the user asked for is not padding;\ngive it in full.\n",{"name":5,"description":7},"main","023b01bfb4a86fbf1e38a749f1044cce3e5da67d","skills\u002Fengineering\u002Fminimal-change",1,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit","https:\u002F\u002Fgithub.com\u002Fdougborg","http:\u002F\u002Fdougborg.org","Platforms and Infrastructure Software Engineer","2026-10-19 05:43:53",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add dougborg\u002Fharness-kit --skill minimal-change",{"tool":59,"command":60},"bunx","bunx skills add dougborg\u002Fharness-kit --skill minimal-change",{"tool":62,"command":63},"pnpm","pnpm dlx skills add dougborg\u002Fharness-kit --skill minimal-change","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fminimal-change\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"agents\u002Fopenai.yaml","REFERENCE","参考文档",117,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fengineering\u002Fminimal-change\u002Fagents\u002Fopenai.yaml",[74,93,114,142,166,183],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":85,"publishedAt":39},"01M6KX4J65S5FZKMSN5DQNPSZM","teach","Teach yourself a topic over several sessions, with lessons, references, and a record of what you've learned.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fteach\u002FSKILL.md",[80],{"categoryNo":81,"categoryName":82,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000039","教师与教育","PROFESSION","适用职业",[76,86,87,88,89,90,91,92],"lessons","you","with","learned","record","references","sessions",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":104,"publishedAt":39},"01M6KX4FSSG7MHF00JDT5QT0BQ","svg-logo-designer","Generate SVG logos with multiple concepts, layouts, and color variations.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fsvg-logo-designer\u002FSKILL.md",[99],{"categoryNo":100,"categoryName":101,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[105,106,107,108,109,110,88,111,112,113],"logo","designer","svg logo designer","SVG","color","concepts","write","read","generate",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":126,"publishedAt":39},"01M6KX4BD3J9MZPPSH4MENH7FP","documentation-writer","Writes and revises human-facing documentation — READMEs, contributor and setup guides, reference pages, architecture notes, CLAUDE.md, and changelog entries. Covers picking the right document type for the question being asked, structuring for skimming, writing examples that actually run, and keeping docs from going stale. Use when creating or rewriting docs, when a README has drifted from the code, or when deciding where a piece of information belongs. For SKILL.md and agent files, use \u002Fskill-writer instead.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fdocumentation-writer\u002FSKILL.md",[120,123],{"categoryNo":121,"categoryName":122,"taxonomyType":102,"taxonomyTypeDesc":103},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":124,"categoryName":125,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000036","内容创作者",[127,128,129,130,131,132,133,134,34,35,135,136,37,137,138,25,139,140,141,31],"writer","documentation writer","documentation","entries","changelog","architecture","document","files","README","notes","examples","pages","information","guides","type",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":39},"01M6KX47ZJ4ZWHDN3MY8SYAWZZ","adhd-mode","Shapes every response for a reader with ADHD: the next action first, numbered steps, progress restated each turn, tangents held back, concrete time estimates, wins made visible. Stays on for the rest of the session until the reader says \"stop adhd mode\". On Claude Code, the harness-kit:adhd output style does the same without invoking this skill.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fadhd-mode\u002FSKILL.md",[],[149,150,151,152,25,153,154,88,155,156,157,158,159,160,161,162,163,164,165,37],"adhd","mode","adhd mode","next","action","kit","output","style","progress","time","back","stop","session","reader","first","REST","harness",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":39},"01M6KX463Z6E18EPDW873GDHKB","wait-what","That last message didn't land: re-explain it with the missing context.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fwait-what\u002FSKILL.md",[],[173,174,175,88,176,177,178,179,180,181,182],"wait","wait what","re","it","missing","message","context","explain","land","last",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":39},"01M6KX43NE1NB0Y2HECY515730","to-questionnaire","Turn a decision you can't make alone into a questionnaire for the one person who can answer it, filled in async or together in a meeting.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fto-questionnaire\u002FSKILL.md",[],[190,191,25,192,193,194,195,87,196,176,197,198],"to questionnaire","questionnaire","person","can","answer","meeting","make","async","decision"]