Skills

Each page uses the same reference layout: synopsis, YAML front matter, the full SKILL.md, then links to the rest of the pack.

1. 01 write-tech-core Applies shared evidence, audience, structure, style, and verification rules when drafting or revising technical writing with the write-tech skill family.
2. 02 write-tech-spec Writes or revises a spec for a work item — the problem, the intended outcome, user-visible stories, decisions already made, and what is out of scope. Use when a kit::spec MR needs its SPEC.md written or corrected, before any plan exists.
3. 03 write-tech-epic-plan Writes or revises an epic plan — its outcome, the real problems it solves, task boundaries, cross-task dependencies, epic acceptance, and proof. Use when an epic MR is drafted, or when a merged epic is split into task plans.
4. 04 write-tech-task-plan Writes or revises a task plan — the problem and its evidence, the behaviour in scope, the risks and dependencies that change the work, acceptance criteria, and proof. Use when a kit::task MR needs its plan.md written or deepened, before any code exists.
5. 05 write-tech-pr-description Writes or revises a pull request (or merge request) description that explains the change, its reason, review boundaries, and verified evidence. Use when opening a draft, after planning, or after implementation.
6. 06 write-tech-pr-description-docs Writes a documentation merge request description that records what was documented, what was deliberately not documented, and why. Use when opening or updating a docs merge request after a feature merge.
7. 07 write-tech-blog-post Writes or revises a technical blog post or article for a defined reader, using a focused claim, verified examples, and an intentional authorial voice.
8. 08 write-tech-getting-started Writes or revises a getting-started tutorial that takes a new user through one verified path to an early, visible success.
9. 09 write-tech-how-to Writes or revises a goal-oriented how-to guide for a reader who needs to complete one specific technical task.
10. 10 write-tech-reference Writes or revises a precise, scannable reference page for a command, API, configuration surface, schema, or other technical interface.
11. 11 write-tech-readme Writes or revises a repository README that helps the intended reader understand, try, use, and navigate a technical project.
12. 12 write-tech-pr-comment Writes or revises evidenced, actionable pull request review comments and replies.
13. 13 write-tech-commit-message Writes or revises a Git commit subject and body that record one coherent change, its reason, and verified consequences.
14. 14 write-tech-landing Use when writing or redesigning a public product landing page; when a first draft is only a hook and a few facts; when product process names appear without definition; when the lede or heading names an engine, store file, or query language; when getting started is a repo clone or a language runner; when values are copied from a brief without grilling; or when the site also needs a first-success path and an interface lookup.
15. 15 refining-skills Use when a skill produced a bad result and there is an example plus a comment about what was wrong; when someone reports a skill failure or regression; when you are about to add a sentence to a skill and ship without reproducing the failure. Fork this conversation into a subagent that owns the loop. Replay the failing example from this session. Do not wait for it.
16. 16 slopkit-push Use when working on SlopKit Push deploys — deploy.nix, the GitLab catalog component slopkit/push/deploy, flake.nix push input, dockerfile vs static apps, app.components, extraDomains, k3s/kubenix/Traefik/cert-manager, local e2e VM, or Roast/Hurl/Clown/site production deploys.
17. 17 analytics-page Use when adding or changing a SlopKit Analytics panel page — MDX under pages/, named SQL in queries/, charts from existing events, metrics, catalog, or queries. Do not invent event or metric names. Explore infer, catalog, and existing queries first.
18. 18 analytics-instrument Use when adding a new SlopKit Analytics event or metric to a product — pick a name and schema, implement the track or metric call, write the catalog file, then add a dedicated panel page. After the name exists, use analytics-page for the page. Do not invent generic views that already exist on /events and /metrics.