skills

Catch an architectural or technical decision as it is being made and draft an Architecture Decision Record (ADR) in the team's format, leaving explicit TODOs for fields the conversation did not cover. Never writes or commits without explicit confirmation. Use this when the user asks to "draft an ADR", "record this decision", "capture this as an ADR", AND proactively offer it when the conversation shows a commitment pattern — "we'll go with X over Y because Z", "let's standardize on...", "decided to...", "we're choosing..." — paired with a rationale. It assigns the next ADR id, fills what the discussion supports, and flags team-mandatory sections (e.g. regulatory impact, data classification, rollback plan) as TODO when missing. Do NOT use for: exploratory discussion with no commitment ("we might try", "could consider", "what if we"), non-architectural decisions (scheduling, naming, trivial style), or generating product/requirements specs. When unsure whether a real decision was actually made, ask one question rather than draft.

Translate articles, essays, blog posts, threads, and other longer-form prose between any pair of languages while preserving the author's voice, register, and rhetorical structure. Use this whenever the user asks to translate, localize, render, or "give me in [language]" any text longer than a few paragraphs — news articles, op-eds, essays, blog posts, longreads, newsletters, technical writeups, conference transcripts, Twitter/X threads, or non-fiction excerpts. Trigger even when the user does not say the word "translate" explicitly — for example "I need this in English for our investors", "rewrite this for a Russian audience", or "make this readable to a German reader" all count. Do not use for single sentences, UI strings, code-only inputs, or short slogans — those are too small to benefit from this workflow.

Turn a regular Claude Code session into a learn-by-doing coding tutorial. The user codes alongside Claude in a real repository, but at deliberate moments Claude hands off a focused chunk (a function, an endpoint, a refactor, a test) for the user to write by hand, then reviews their work. Maintains a per-repo learning plan and a spaced-repetition log under .claude/learning/ so topics resurface for review at the right time. Use this skill whenever the user mentions wanting to learn, practice, train, "do it themselves", improve at programming, or asks Claude to coach, teach, tutor, mentor, or pair-learn with them in a coding context. Also consult this skill at the very start of any session in a repo that contains a .claude/learning/ directory — there's an active learning plan that may have topics due for review or homework in flight. Trigger phrases include "coach me", "teach me X", "I want to learn Y", "help me practice Z", "let me try it myself", "review what I wrote", "give me a task", "what should I learn next", as well as any signal that the user wants to grow as a developer rather than just ship code.

Onboard a newcomer to THIS codebase, or answer a targeted "how does our X work" question, by walking curated reading lists and synthesizing the mental model — never by guessing. Works out of the box: if a maintainer has committed .onboard/topics.yaml it uses that curated path; if not, it cold-starts from the repo's own authoritative docs (README, CLAUDE.md / AGENTS.md, ARCHITECTURE.md, docs/, the dependency manifest, the entry point) and is explicit about what curated knowledge is still missing. The newcomer never has to create files, run setup, or change code. Use this for "I'm new, help me understand this project", "where do I start", "onboard me", and for "explain our auth flow", "how does our scheduler work", "walk me through our X". Do NOT use for: generic programming or public-library questions, debugging a specific error or stack trace, or writing/modifying code. This skill teaches an existing system; it does not generate documentation or code, and it does not invent gotchas or assert which files are load-bearing beyond what the sources actually say.

A thinking partner that helps you reach your OWN answer instead of handing you one. It opens passively — invites you to explain the problem, reflects back the key facts and the assumptions it heard — and escalates to pointed diagnostic questions only when you're stuck or going in circles. Use this when the user wants to reason something out: "help me think through this", "rubber duck this with me", "I'm stuck on this bug", "talk me through this design", "let me think out loud". Do NOT fire when the user wants a direct answer — "just tell me the fix", "give me the answer", "what's the bug" — that is a different intent and should get a straight reply, not questions. Also not for factual lookups, time-pressured incidents where speed beats learning, or requests to write code. The withholding is the feature, but withholding past usefulness is a failure: there is an explicit escape hatch.