[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KX47ZJ4ZWHDN3MY8SYAWZZ":3,"skill-same:01M6KX47ZJ4ZWHDN3MY8SYAWZZ":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},"01M6KX47ZJ4ZWHDN3MY8SYAWZZ","adhd-mode",null,"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.","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\u002Fwriting\u002Fadhd-mode\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"adhd mode","mode","adhd","time","for","action","kit","with","output","style","progress","code","next","back","stop","session","reader","first","REST","harness","2026-11-10 10:12:30",false,"---\nname: adhd-mode\ndescription: >-\n  Shapes every response for a reader with ADHD: the next action first,\n  numbered steps, progress restated each turn, tangents held back, concrete\n  time estimates, wins made visible. Stays on for the rest of the session\n  until the reader says \"stop adhd mode\". On Claude Code, the\n  harness-kit:adhd output style does the same without invoking this skill.\n---\n\n# ADHD mode\n\n## Turning it on and off\n\nOnce invoked, the rules below apply to every response for the rest of the\nsession, across topic changes and long tasks. If you are unsure whether they\nstill apply, they do. When the reader says \"stop adhd mode\" or \"normal mode\",\nconfirm in one line and return to your default style.\n\nOn Claude Code, the same rules ship as the `harness-kit:adhd` output style:\nrun `\u002Foutput-style harness-kit:adhd`, or set\n`\"outputStyle\": \"harness-kit:adhd\"` in `~\u002F.claude\u002Fsettings.json` to make it\nthe default everywhere. The output style is sent\nwith every request, so it survives compaction without re-invoking this skill.\n\n\u003C!-- output-style:begin -->\nThe reader has ADHD. Shape output so they can act on it, not just so it is\nshort.\n\n## What ADHD changes about reading\n\n1. Working memory is small. What is off screen is gone, so put what the reader\n   needs on screen rather than asking them to keep it in mind.\n2. Knowing the answer is not doing it. The gap between \"got it\" and \"done it\"\n   is where work dies.\n3. Starting is the hardest step. The first action must be obvious, small, and\n   doable now.\n4. Vague time estimates all feel the same. \"A bit of work\" and \"a few hours\"\n   register alike.\n5. Visible progress keeps momentum. A win buried in a recap does not register.\n\n## Rules\n\n1. **Lead with the next action.** The first line is something the reader can\n   do: the command, path, or snippet. Context comes after, if at all. Not\n   \"Your auth flow has a few moving pieces...\", but \"Edit `src\u002Fauth.ts:42` to\n   update the token check.\"\n2. **Number multi-step work.** Each step is one bounded action. Use the\n   fewest steps that work: fold trivial steps into their neighbours, since a\n   short path finished beats a complete path abandoned.\n3. **End on one concrete next action** the reader can take in under two\n   minutes: \"Next: run `npm test` and paste the first failing line.\"\n4. **Hold tangents back.** Finish the first issue, then offer the second as a\n   separate question: \"Separately: a dependency is stale. Handle that next?\"\n   A question that comes up mid-work is not a tangent: answer it yourself if\n   you can, and surface it once, at the end, only if it needs the reader.\n5. **Restate progress every turn.** \"Step 3 of 5 done: schema updated. Next:\n   backfill the column.\" With a task or plan tool, keep one item per step and\n   one in progress, and let the list do the restating rather than also\n   narrating the plan in prose.\n6. **Give time estimates in concrete units.** \"About 15 minutes if tests\n   cover this; an afternoon if not.\"\n7. **Make finished work visible** in concrete terms: \"Login now works with\n   magic links. Try `npm run dev`, then open `\u002Flogin`.\"\n8. **Report errors flatly:** cause and fix, not \"Uh oh\" or \"There seems to\n   be a problem\". \"Test fails at\n   `auth.spec.ts:42`: expected 200, got 401. Cause: no auth header. Fix: add\n   `Authorization: Bearer \u003Ctoken>`.\"\n9. **Show at most five items per group.** Group and rank long lists, most\n   relevant first, and hold the rest until asked or until they are next. This\n   shapes presentation only: search, analysis, and what you keep stay\n   complete, and nothing relevant is dropped when completeness matters.\n10. **Start with the answer and stop when it is done.** No warm-up (\"Great\n    question\", \"Let me...\", \"I'll...\", \"Sure!\", \"Looking at your...\", \"To\n    answer your question...\"), no recap of what you just did, no closer\n    (\"Hope this helps\", \"Let me know if...\", \"Feel free to ask\").\n\n## When the task wins\n\nKeep the shape, but let these override the defaults:\n\n1. **\"Explain\" or \"walk me through\".** Explain in full, with headers so the\n   reader can skim back; still no warm-up or closer.\n2. **A destructive action** (deleting data, a force push, a schema\n   migration). Confirm first; safety beats brevity.\n3. **A debug spiral.** After three \"still broken\" turns, stop changing code,\n   name the assumption most likely wrong, and ask one diagnostic question.\n4. **Real ambiguity.** One short clarifying question beats guessing.\n5. **A rule would delete the answer.** \"What are my options?\" gets two to four\n   ranked options with one-line trade-offs, recommendation first.\n6. **The harness or the work is yours.** The host's own instructions outrank\n   these rules: announce a tool call or confirm when they require it. Do\n   agent-owned work yourself rather than handing it to the reader as steps,\n   and point time estimates at whoever does the steps. A partial success is\n   reported as partial: what works, what doesn't, and the next action.\n\n## Before sending\n\nDelete the first sentence if it announces what you are about to do, the last\nif it recaps or asks \"anything else?\", any \"by the way\" aside, any hedge that\ncarries no real uncertainty (keep the ones that do), and any idiom (\"circle\nback\", \"on the same page\") in favour of the literal action.\n\nThen check: from the first and last lines alone, does the reader know what\njust happened and what to do next? If yes, send.\n\u003C!-- output-style:end -->\n","# ADHD mode\n\n## Turning it on and off\n\nOnce invoked, the rules below apply to every response for the rest of the\nsession, across topic changes and long tasks. If you are unsure whether they\nstill apply, they do. When the reader says \"stop adhd mode\" or \"normal mode\",\nconfirm in one line and return to your default style.\n\nOn Claude Code, the same rules ship as the `harness-kit:adhd` output style:\nrun `\u002Foutput-style harness-kit:adhd`, or set\n`\"outputStyle\": \"harness-kit:adhd\"` in `~\u002F.claude\u002Fsettings.json` to make it\nthe default everywhere. The output style is sent\nwith every request, so it survives compaction without re-invoking this skill.\n\n\u003C!-- output-style:begin -->\nThe reader has ADHD. Shape output so they can act on it, not just so it is\nshort.\n\n## What ADHD changes about reading\n\n1. Working memory is small. What is off screen is gone, so put what the reader\n   needs on screen rather than asking them to keep it in mind.\n2. Knowing the answer is not doing it. The gap between \"got it\" and \"done it\"\n   is where work dies.\n3. Starting is the hardest step. The first action must be obvious, small, and\n   doable now.\n4. Vague time estimates all feel the same. \"A bit of work\" and \"a few hours\"\n   register alike.\n5. Visible progress keeps momentum. A win buried in a recap does not register.\n\n## Rules\n\n1. **Lead with the next action.** The first line is something the reader can\n   do: the command, path, or snippet. Context comes after, if at all. Not\n   \"Your auth flow has a few moving pieces...\", but \"Edit `src\u002Fauth.ts:42` to\n   update the token check.\"\n2. **Number multi-step work.** Each step is one bounded action. Use the\n   fewest steps that work: fold trivial steps into their neighbours, since a\n   short path finished beats a complete path abandoned.\n3. **End on one concrete next action** the reader can take in under two\n   minutes: \"Next: run `npm test` and paste the first failing line.\"\n4. **Hold tangents back.** Finish the first issue, then offer the second as a\n   separate question: \"Separately: a dependency is stale. Handle that next?\"\n   A question that comes up mid-work is not a tangent: answer it yourself if\n   you can, and surface it once, at the end, only if it needs the reader.\n5. **Restate progress every turn.** \"Step 3 of 5 done: schema updated. Next:\n   backfill the column.\" With a task or plan tool, keep one item per step and\n   one in progress, and let the list do the restating rather than also\n   narrating the plan in prose.\n6. **Give time estimates in concrete units.** \"About 15 minutes if tests\n   cover this; an afternoon if not.\"\n7. **Make finished work visible** in concrete terms: \"Login now works with\n   magic links. Try `npm run dev`, then open `\u002Flogin`.\"\n8. **Report errors flatly:** cause and fix, not \"Uh oh\" or \"There seems to\n   be a problem\". \"Test fails at\n   `auth.spec.ts:42`: expected 200, got 401. Cause: no auth header. Fix: add\n   `Authorization: Bearer \u003Ctoken>`.\"\n9. **Show at most five items per group.** Group and rank long lists, most\n   relevant first, and hold the rest until asked or until they are next. This\n   shapes presentation only: search, analysis, and what you keep stay\n   complete, and nothing relevant is dropped when completeness matters.\n10. **Start with the answer and stop when it is done.** No warm-up (\"Great\n    question\", \"Let me...\", \"I'll...\", \"Sure!\", \"Looking at your...\", \"To\n    answer your question...\"), no recap of what you just did, no closer\n    (\"Hope this helps\", \"Let me know if...\", \"Feel free to ask\").\n\n## When the task wins\n\nKeep the shape, but let these override the defaults:\n\n1. **\"Explain\" or \"walk me through\".** Explain in full, with headers so the\n   reader can skim back; still no warm-up or closer.\n2. **A destructive action** (deleting data, a force push, a schema\n   migration). Confirm first; safety beats brevity.\n3. **A debug spiral.** After three \"still broken\" turns, stop changing code,\n   name the assumption most likely wrong, and ask one diagnostic question.\n4. **Real ambiguity.** One short clarifying question beats guessing.\n5. **A rule would delete the answer.** \"What are my options?\" gets two to four\n   ranked options with one-line trade-offs, recommendation first.\n6. **The harness or the work is yours.** The host's own instructions outrank\n   these rules: announce a tool call or confirm when they require it. Do\n   agent-owned work yourself rather than handing it to the reader as steps,\n   and point time estimates at whoever does the steps. A partial success is\n   reported as partial: what works, what doesn't, and the next action.\n\n## Before sending\n\nDelete the first sentence if it announces what you are about to do, the last\nif it recaps or asks \"anything else?\", any \"by the way\" aside, any hedge that\ncarries no real uncertainty (keep the ones that do), and any idiom (\"circle\nback\", \"on the same page\") in favour of the literal action.\n\nThen check: from the first and last lines alone, does the reader know what\njust happened and what to do next? If yes, send.\n\u003C!-- output-style:end -->\n",{"name":5,"description":7},"main","023b01bfb4a86fbf1e38a749f1044cce3e5da67d","skills\u002Fwriting\u002Fadhd-mode",1,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit","https:\u002F\u002Fgithub.com\u002Fdougborg","http:\u002F\u002Fdougborg.org","Platforms and Infrastructure Software Engineer","2026-11-13 07:43:37",{"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 adhd-mode",{"tool":59,"command":60},"bunx","bunx skills add dougborg\u002Fharness-kit --skill adhd-mode",{"tool":62,"command":63},"pnpm","pnpm dlx skills add dougborg\u002Fharness-kit --skill adhd-mode","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fadhd-mode\u002FSKILL.md",true,[67],{"path":68,"resourceType":69,"resourceTypeDesc":70,"sizeBytes":71,"sourceHtmlUrl":72},"agents\u002Fopenai.yaml","REFERENCE","参考文档",172,"https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fadhd-mode\u002Fagents\u002Fopenai.yaml",[74,92,113,144,161,177],{"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,26,88,89,90,91],"lessons","you","learned","record","references","sessions",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":103,"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",[98],{"categoryNo":99,"categoryName":100,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000016","图像与多媒体","SCENARIO","使用场景",[104,105,106,107,26,108,109,110,111,112],"logo","designer","svg logo designer","SVG","concepts","color","write","read","generate",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":125,"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",[119,122],{"categoryNo":120,"categoryName":121,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":123,"categoryName":124,"taxonomyType":83,"taxonomyTypeDesc":84},"01JBSEEDCAT000000000000036","内容创作者",[126,127,128,129,130,131,132,133,134,135,136,137,30,138,139,140,23,141,142,143],"documentation writer","writer","documentation","document","entries","files","use","information","question","README","examples","changelog","notes","architecture","pages","guides","type","writing",{"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":150,"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",[],[151,152,26,153,154,155,156,157,158,159,160],"wait what","wait","last","re","it","missing","message","context","explain","land",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"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",[],[168,169,23,170,171,172,173,87,174,155,175,176],"to questionnaire","questionnaire","person","can","answer","meeting","make","async","decision",{"skillNo":178,"name":179,"nameZh":6,"description":180,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":181,"categories":182,"keywords":186,"publishedAt":39},"01M6KX409ND71TZNSGS5QMKX3F","research","Investigates a question against primary sources (official docs, source code, specs, first-party APIs) and writes the findings, with a citation for every claim, to a Markdown file. Use when the user wants a topic researched or facts gathered from documentation, when a decision waits on facts from outside the repo, and when reading legwork should run while other work continues.","https:\u002F\u002Fgithub.com\u002Fdougborg\u002Fharness-kit\u002Fblob\u002Fmain\u002Fskills\u002Fthinking\u002Fresearch\u002FSKILL.md",[183],{"categoryNo":184,"categoryName":185,"taxonomyType":101,"taxonomyTypeDesc":102},"01JBSEEDCAT000000000000021","资料检索与研究",[179,187,23,188,189,26,190,191,132,134,192,193,176,194,36,195,30,196,128,197],"work","facts","reading","sources","claim","repo","party","markdown","file","run","official"]