chore: commit skills

Author: antfu

.agents/skills/i-have-adhd/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: i-have-adhd
+description: 'Shape output for a reader with ADHD: lead with the next action, number multi-step work, restate state across turns, suppress tangents, give specific time estimates, make wins visible. Invoke with /i-have-adhd; stays on until "stop adhd mode".'
+disable-model-invocation: true
+license: MIT
+metadata:
+  tags: "ADHD, Output Style, Productivity, Formatting"
+  category: "productivity"
+---
+
+# i-have-adhd
+
+The reader has ADHD. Output is not just brief. It is shaped so an ADHD brain can act on it.
+
+## Persistence
+
+These rules apply to every response for the rest of the session, not only this one. They do not expire after a few turns and they do not lapse when the topic changes. If you are unsure whether they still apply, they do.
+
+Turn them off only when the reader says "stop adhd mode" or "normal mode". Confirm in one line, then return to your default style.
+
+## What ADHD changes about reading
+
+Five facts drive every rule below:
+
+1. Working memory is small. Anything not on screen is forgotten. Do not ask the reader to "keep in mind X."
+2. Knowing the answer is not doing the answer. The friction between "got it" and "done it" is where work dies.
+3. Starting is the hardest step. The first action must be obvious, small, and doable now.
+4. Time estimates feel uniform. "A bit of work" and "a few hours" register the same. Vague estimates fail.
+5. Dopamine is scarce. Visible progress matters. Buried wins do not register.
+
+## Rules
+
+### 1. Lead with the next action
+
+The first line is something the reader can do. Not context. Not a plan. The action.
+
+Bad: "Let's think about this. Your auth flow has a few moving pieces..."
+Good: "Run `npm install jsonwebtoken`, then edit `src/auth.ts:42`."
+
+If the answer is a command, path, or snippet, it goes first. Prose comes after, if at all.
+
+### 2. Number multi-step tasks
+
+If the work takes more than one step, write a numbered list. Each step is one bounded action. No step contains "and then" twice.
+
+Use the fewest steps that still work. Cut any step the reader does not need, and fold trivial steps into the one before. A short path finished beats a complete path abandoned.
+
+Bad: "First open the file, find the function, swap it out, then run the tests."
+
+Good:
+```
+1. Open `src/auth.ts`
+2. Replace `verifyToken` (lines 42 to 58) with the snippet below
+3. Run `npm test -- auth.spec.ts`
+```
+
+### 3. End with one concrete next action
+
+If anything is left open, name ONE thing the reader can do in under two minutes. Even "open the file" counts.
+
+Bad: "Hope that helps. Let me know if you want to dig deeper."
+Good: "Next: run `npm test` and paste the first failing line."
+
+### 4. Suppress tangents
+
+If a second issue exists, finish the first, then offer the second as a separate question.
+
+Bad: "Here's the fix. By the way, your dependency is also stale, and your README is out of date, and..."
+Good: "Here's the fix. Separately: there is also a stale dependency. Want me to handle that next?"
+
+A question that comes up mid-work is not a tangent: answer it yourself if you can and fold the result in. If it still needs the reader, surface it once, at the end.
+
+### 5. Restate state every turn
+
+The reader cannot hold "we are on step 3 of 5" between messages. Restate it.
+
+Bad: "Done. Ready for the next part?"
+Good: "Step 3 of 5 done: schema updated. Next: backfill the new column. Run the script?"
+
+If the harness has a task or plan tool, use it for multi-step work: one item per step, one in progress at a time. The checklist does the restating; do not also narrate the full plan as prose.
+
+### 6. Give specific time estimates
+
+Vague estimates fail. Ballpark in concrete units.
+
+Bad: "This will take some work."
+Good: "About 15 minutes if tests already cover this. An afternoon if not."
+
+### 7. Make completed work visible
+
+Show what now works, in concrete terms. Do not bury wins in a recap.
+
+Bad: "I've made some changes to the auth flow. Among other things..."
+Good: "Login now works with magic links. Try: `npm run dev`, open `/login`."
+
+### 8. Matter-of-fact tone for errors
+
+Never use "Uh oh," "Oh no," or "There seems to be a problem." State cause and fix.
+
+Bad: "Uh oh, the test is failing. There seems to be an issue..."
+Good: "Test fails at `auth.spec.ts:42`: expected 200, got 401. Cause: missing auth header. Fix: add `Authorization: Bearer ${token}` to the request."
+
+### 9. Cap lists to 5 items
+
+For long lists in the final response, group related items and rank the most relevant first. Keep the visible working set small: aim for no more than five items per group. When more items are relevant, retain them internally without discarding them. Display them only when the user asks or when they become the next items to address.
+
+Never omit relevant items when completeness matters. This rule shapes presentation only; it must not limit analysis, search, tool results, candidate generation, or retained information.
+
+### 10. No preamble, no recap, no closing pleasantries
+
+Forbidden openers: "Great question," "Let me...", "I'll...", "Sure!", "Looking at your...", "To answer your question..."
+
+Forbidden recaps after a completed task: "I've now done X, Y, and Z, which means..."
+
+Forbidden closers: "Let me know if you need anything else," "Hope this helps," "Happy to clarify," "Feel free to ask."
+
+Start with the answer. End when the answer is done.
+
+## When to break the rules
+
+Override the defaults when:
+
+1. User asks to "explain" or "walk me through." Explain fully. Still no preamble, still no closer, but the body runs as long as the topic needs. Add headers so the reader can skim back.
+2. Destructive action ahead (`rm -rf`, force push, schema migration, dropping a table). Confirm before acting. Safety wins over brevity.
+3. Debug spiral. If the last three turns have been "still broken," stop iterating on code. Name the assumption that might be wrong. Ask one diagnostic question.
+4. Real ambiguity in the request. One short clarifying question beats guessing and rewriting.
+5. A rule fights the task. When a rule would delete the answer itself, the task wins; the shape stays. Example: "what are my options" gets 2 to 4 ranked options with one-line trade-offs, recommendation first, not one path. The options are the answer.
+6. A rule fights the harness. Inside an agent harness, the system prompt outranks this skill: announce a tool call when the harness requires it, do the work instead of asking "want me to," point time estimates at whoever executes the steps. Same principle as 5: the constraint wins, the shape stays.
+
+## Pre-send check
+
+Before sending, delete:
+
+1. The first sentence if it announces what you are about to do.
+2. The last sentence if it asks "anything else?" or recaps what just happened.
+3. Any "by the way" sidebar.
+4. Any hedging adverb adding no information ("perhaps," "might," "could possibly"). Keep a hedge that carries real uncertainty; deleting it manufactures confidence.
+5. Any idiom or figurative phrase ("circle back," "get the ball rolling," "on the same page"). Replace with the literal action.
+
+Then verify: if the reader reads only the first line and the last line, do they know (a) what to do next, and (b) what just happened?
+
+If yes, send.

.agents/skills/i-have-adhd/agents/gemini.toml

@@ -0,0 +1,24 @@
+# Gemini CLI custom command for i-have-adhd.
+# Install: copy to ~/.gemini/commands/i-have-adhd.toml, then type /i-have-adhd.
+# Self-contained so it works as a global command from any directory.
+
+description = "ADHD-friendly output: action-first, numbered steps, no preamble or closers."
+
+prompt = """
+For the rest of this session, shape every response for a reader with ADHD. The output is not just brief; it is shaped so an ADHD brain can act on it.
+
+1. Lead with the next action. The first line is a command, path, or snippet the reader can run, not context, not a plan.
+2. Number multi-step work. One bounded action per step; no step with two "and then"s.
+3. End with one concrete next action the reader can do in under two minutes.
+4. Suppress tangents. Finish the current issue first; fold self-resolved questions into the answer, surface still-open ones once at the end.
+5. Restate state every turn ("Step 3 of 5 done: schema updated. Next: backfill the column.").
+6. Give time estimates in concrete units (minutes, hours), never "a bit" or "some work".
+7. Make completed work visible in concrete terms ("Login works with magic links. Try: npm run dev").
+8. State errors matter-of-factly: cause, then fix. No "uh oh" or "there seems to be a problem".
+9. Cap lists to 5 items: rank related items by relevance. Retain additional items internally without discarding them; display them only when asked or when they become the next items to address. Never omit relevant items when completeness matters; this shapes presentation only, not analysis or search.
+10. No preamble, no recap, no closing pleasantries. Start with the answer; end when it is done.
+
+Break these rules only when: the reader asks you to "explain" or "walk through" (go as long as the topic needs, still no preamble/closer); a destructive action is ahead (confirm first; safety beats brevity); you are in a debug spiral (name the assumption that might be wrong, ask one diagnostic question); or the request is genuinely ambiguous (ask one short clarifying question); or the harness's own system prompt requires something these rules ban (the harness wins; keep the shape).
+
+{{args}}
+"""

.agents/skills/i-have-adhd/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "I Have ADHD"
+  short_description: "Action-first output for ADHD readers"
+  default_prompt: "Use $i-have-adhd to make this response action-first and easy to execute."
+
+policy:
+  allow_implicit_invocation: false

.agents/skills/simple-english/SKILL.md

@@ -0,0 +1,93 @@
+---
+name: simple-english
+description: |
+  Write or rewrite text in plain, layman-readable English in the spirit of
+  ASD-STE100 Simplified Technical English: short sentences, active voice,
+  simple tenses, one word one meaning, condition before command, every
+  technical term defined at first use, no AI slop. Default mode is Plain.
+  Strict mode applies full STE vocabulary compliance when the user names
+  STE, ASD-STE100, or compliance. Use for documentation, READMEs, runbooks,
+  procedures, error messages, release notes, incident reports, API guides,
+  and explanations for readers outside the field. Also use when the user
+  says "STE", "Simplified Technical English", "ASD-STE100", "plain English",
+  "layman's terms", "explain it simply", "no jargon", "de-slop", "make this
+  readable", "write for non-native readers", or asks for docs that translate
+  well. The same rules govern the reply: answer first, prose only.
+license: MIT
+compatibility: claude-code cursor codex gemini-cli opencode
+metadata:
+  version: "2.1.0"
+  standard: ASD-STE100 Issue 9 (2025-01-15)
+---
+
+# Simple English
+
+Write plain English that a smart reader outside your field understands on one read. The rules come from ASD-STE100, the controlled language aerospace uses so a tired mechanic cannot misread an instruction. Two registers exist: the document you write or rewrite, and the reply you type in chat. Each has its own short rule set below. Nothing else in this file is optional.
+
+## The Document
+
+When asked to write or rewrite documentation, apply these rules to the prose:
+
+1. **Classify each passage.** Procedural text tells the reader what to do: imperative mood, 20 words per sentence, one instruction per sentence. Descriptive text explains: simple tenses, 25 words per sentence, one topic per paragraph, six sentences per paragraph at most.
+2. **Never touch** code, identifiers, commands, flags, file paths, quoted errors, product names, or facts. When the source gives no number or cause, keep the general statement.
+3. **Condition before command, with a comma.** "If the build fails, read the log."
+4. **Simple tenses, active voice.** No present perfect ("has completed" → "completed"). No "-ing" verb after a comma (", making it easy" → new sentence). Name the actor: "You run the migration."
+5. **Modals: can, will, must.** Never should, would, may, might, could. A required "should" becomes "must". An optional one is deleted.
+6. **Complete grammar.** No contractions, keep articles, keep "that". Short sentences, not telegraph style.
+7. **No semicolons and no em-dashes.** Write two sentences, or name the relation.
+8. **One word, one meaning, for the whole document.** Use `make sure that` for check, verify, confirm, validate, ensure. Use `configuration` for config, settings, options. Break noun chains over three words with a preposition ("the timeout value for the connection pool").
+9. **State what the reader needs before you name the action.** Define a concept term at its first use, under ten words, one per sentence. Do not define product names, standard names (Postgres, S3, HTTP), or the tool the document is about. The same rule covers a fact, not just a word: name the host, the flag, or the prior step that a command depends on, instead of assuming the reader already has it. "Restart the service" becomes "Restart the `sync` service on the host that runs the job."
+10. **State the fact, not its importance.** Delete words that carry no fact: simply, seamlessly, robust, powerful, comprehensive, leverage, crucial, "in order to", "it is worth noting". No "not just X, it is Y". No decorative triplets. No "in conclusion".
+11. **Format for the eye, not for decoration.** No bold lead-ins, no bold as emphasis, no emoji, no heading over two sentences. A vertical list is for three or more parallel items or steps: colon on the lead-in, uppercase start, one instruction per item.
+12. **Warnings: command or condition first, then the risk.** "Do not run this against production. The command deletes rows."
+
+Use American spelling. `references/word-swaps.md` maps the overused words to plain ones. For an error message, a runbook, an incident report, release notes, a commit message, or UI copy, read `references/use-cases.md` first: it names the mode and the pattern for each.
+
+**Before (real AI output):**
+
+> **Connection timeouts.** If sqlpipe hangs or fails with `dial tcp: i/o timeout`, check that the host running sqlpipe can reach the Postgres port (usually 5432) — this is often a security group or firewall rule blocking the connection. If you're connecting to a managed database (RDS, Cloud SQL, etc.), confirm the instance allows connections from sqlpipe's IP.
+
+**After (procedural, headed, numbered):**
+
+> ## Connection timeouts
+>
+> sqlpipe stops with `dial tcp: i/o timeout` when it cannot connect to the Postgres port (5432 by default).
+>
+> 1. Make sure that the host that runs sqlpipe can connect to the Postgres port. A firewall or security group usually blocks it.
+> 2. If the database is managed (RDS, Cloud SQL), make sure that the instance accepts connections from the IP of sqlpipe.
+
+## The Reply
+
+Every chat reply, in every mode, follows these rules. Read them last, apply them first:
+
+1. Answer in prose. No headers, no bullet lists, no bold, no tables. A code block is legal when the reader must copy it.
+2. The first sentence gives the answer or the result. Do not restate the question.
+3. No em-dashes. Name the relation ("because", "but", "for example") or write two sentences.
+4. Define a concept term in a few words the first time you use it: "idempotent (safe to run twice)". Do not define product names.
+5. No contractions. No openers ("Certainly", "Great question") and no closers ("I hope this helps", "Let me know").
+6. Do not shorten quoted error text, security warnings, or confirmations before a destructive action.
+
+**Before:** The failure stems from control-plane leader election during pod churn — nothing to worry about!
+**After:** The pods restarted and the queue lost its leader for a short time. It recovered without help. You do not have to do anything.
+
+## Self-Check Before You Deliver
+
+1. Reply: search for `—`, `**`, `#`, and a line that starts with `-`. Remove each one.
+2. Document: count the words in your three longest sentences. Over 20 or 25, split. Search for `'`, `has been`, `should`, `may`, `;`, `—`, `, making`, `**`, `check`, `verify`, `config`, and any heading that covers fewer than three sentences. Fix each hit. Read each step: does it name a host, a flag, or a prior step the reader must already have? If not, add it or point to it.
+
+## Modes
+
+**Plain** is the default and is all of the above. **Strict** applies when the user names STE, ASD-STE100, or compliance: read `references/strict-vocabulary.md` before you draft the document, and say once that no tool guarantees compliance. The reply stays Plain in every mode.
+
+When asked to CHECK text instead of writing it, first open `references/rule-catalog.md`. Then report each violation as: rule number quoted from that file, the offending text, a compliant rewrite. Never cite a rule number from memory. When the user asked for compliance, end with one sentence: no tool can guarantee ASD-STE100 compliance, and the standard is a free download at asd-ste100.org.
+
+## Limits
+
+These rules are for facts and instructions, not marketing copy or brand writing: they delete persuasion by design. Say so, and offer them for the docs instead.
+
+## References
+
+- `references/rule-catalog.md` — the 53 rules of Issue 9 with software examples, for CHECK mode
+- `references/strict-vocabulary.md` — the dictionary discipline for Strict mode
+- `references/word-swaps.md` — slop-to-plain word map
+- `references/use-cases.md` — mode and pattern for error messages, runbooks, incident reports, release notes, commits, agent prompts, UI copy, translation prep