Ahgraber Skills

Use when the user wants any spec-driven development action — exploring before speccing, deriving specs from code or translating specs from another system, proposing a change, applying or implementing, verifying, syncing delta specs, or archiving. Triggers: 'spec this out', 'create a change', 'apply tasks', 'verify implementation', 'sync specs', 'archive change', or any mention of 'specs' or 'sdd'.

Use when the user asks for proofreading or light copy editing while preserving original wording, tone, and order. Triggers: 'proofread', 'fix typos', 'grammar only', 'copy edit only', 'SPAG pass'. Not for rewrites, tone shifts, structural edits, or style upgrades; use antislop-writing for those requests.

Use when a Python change is about to be called done (before commit or PR) and whenever asked to review, audit, sanity-check, or clean up Python code or judge whether it meets standards. Also use at decision points the defaults cover: choosing retry/timeout/idempotency policy, config loading, pydantic placement, module boundaries, or a concurrency model.

Use when ongoing work or conversational context must continue in a new conversation, session, or agent with no shared history. Triggers: 'handoff', 'prepare context for next chat', 'summarize for a new session', 'continue this in another conversation'. Not for same-chat status updates or repository documentation.

Use when the user needs to see something to answer the current question — a sketch of logic, runtime flow, UI structure, or file layout; a Mermaid diagram; a chart of the data at hand; a mockup, wireframe, or side-by-side comparison during a design discussion (visual brainstorming). Triggers: "show me", "sketch this", "diagram this", "draw the flow", "what does this look like", "mock this up", "wireframe", "mermaid diagram", "chart this", "plot this data", "compare these visually". Not for: building understanding that must stick — background, sequencing, self-check (use teach-me); describing an image the user supplied (use alt-text); or building a durable deliverable such as a dashboard, report, or app.

Use when writing, debugging, or explaining Strudel live-coding music patterns — mini-notation syntax, pattern functions (fast/slow/every/off/stack), synth/sample selection, audio effects, scale/chord/voicing API, or EDM production recipes. Triggers: "write a Strudel pattern", "how do I make a bassline in Strudel", "what does .every() do", "strudel drum beat", "strudel chord voicing", any Strudel code question.

Use when the user shares an image, chart, diagram, screenshot, or figure and needs it described — for alt-text, accessibility, documentation, or to understand what it depicts.

Use when the user wants an elicitative interview — reaching alignment on a plan, decision, or idea by drawing out their decisions, unstated opinions, silent assumptions, and thoughts they find hard to put into words, through rounds of pointed questions. Triggers: "grill me", "interview me about this", "make sure we're aligned", "make sure you understand what I want", "help me pin down the decisions", "what am I assuming", "help me figure out what I actually want".

Use when changing the structure of working code without changing its behavior: decomposing an oversized function, extracting or merging a module, collapsing a layer, breaking an import cycle. Applies when the edit is structural enough to need a plan and explicit approval before it lands. Triggers: 'refactor this', 'decompose this function', 'split this module', 'break this dependency cycle', 'extract this into', 'restructure', 'work through the deferred items'. Not for slop cleanup (use simplify), judging a change (use code-review), fixing bugs, or adding behavior.

Use when merging delta specs from a change into the main baseline specs. Triggers: "sync specs", "merge delta specs", "update main specs", "apply the spec changes", "sync the change".

Use to cut slop out of working code: duplication, dead code, needless indirection, comment noise, defensive padding. Point it at the current changes, a file, a directory, or the whole repo. Triggers: 'simplify this', 'clean this up', 'de-slop this code', 'strip the cruft', 'tighten this diff', 'this code is bloated', 'audit this for slop'. Not for judging correctness or merge readiness (use code-review), and not for structural change that needs a plan and approval (use refactor).

Use when the user wants to be taught a subject, not just answered — "teach me X", "help me learn X", "help me understand X", "help me grok X", "explain how X works", "quiz me on X", "I keep bouncing off X" — where X can be anything: a historical period, a statistical method, music theory, a poem, a legal concept, a cooking technique, a library, a codebase, or a code change. Change-focused asks belong here too: "explain this diff/PR/branch", "walk me through this change", "onboarding doc for this change", "teach me what changed", "help me/my team understand this PR". Spans a quick in-chat lesson up to a saved, dated lesson artifact. Not for: a quick factual answer (just answer), needing only to see a shape or sketch (use show-me), writing a commit message (use commit-message), or reviewing code for defects (use code-review).

Use when writing, updating, or generating a CHANGELOG.md — for a new release, an unreleased section update, or drafting from git history or diff. Triggers: "update the changelog", "write release notes", "what changed since X", "generate changelog for v1.2.0", "add this to the changelog", "draft unreleased section". Not for commit messages (use commit-message skill) or internal deployment runbooks.

Use when a bug, test failure, build break, regression, flaky test, or unexpected behavior appears — before proposing or attempting fixes. Triggers: "why is this failing", "this test broke", "something's wrong", "help me debug", "it works on my machine", mysterious stack traces, intermittent failures. Not for: writing new features, reviewing working code, or routine refactors.

Use when implementing tasks from a change's tasks.md. Triggers: "apply tasks", "implement the change", "work through tasks", "start implementing", "continue implementing", "apply the change".

Use when designing, reviewing, or planning REST or GraphQL APIs — endpoint structure, schema design, versioning, error handling, pagination, URI naming, or choosing between REST and GraphQL. Also triggers for OpenAPI spec creation and API contract review.

Use when deriving SDD specs from existing code or retroactively documenting implemented behavior. Triggers: "derive specs", "generate specs from code", "document this code in SDD", "retrofit specs", "spec out what's already built".

Use when verifying that an implementation matches a change's SDD artifacts. Triggers: "verify", "check implementation", "did I implement everything", "verify the change", "is implementation complete", "check conformance".

Use when distilling the through-line gist of one or more sources — the spine, argument, tension, or recurring frame running through a set of documents, notes, research, or transcripts, OR across the ideas within a single rich piece — into a few concise paragraphs. Triggers: "synthesize", "what's the through-line/gist", "extract the insight", "pull these together". Not for faithful summary or condensation that covers what a source says, nor for comparisons or catalogs where enumeration is the deliverable.

Use when reviewing code changes before committing or merging — staged diffs, branch diffs, or PR readiness checks. Triggers: 'review my code', 'check these changes', 'review this branch', 'give feedback on my diff', 'is this PR ready?'. Not for implementing features, running test suites, formatting-only passes, or building understanding of a change (use teach-me).

Use when completing and archiving a change after all tasks are done and specs are synced. Triggers: "archive the change", "complete this change", "close out the change", "finish the change", "archive".

Use when the user wants to think through ideas, investigate problems, or clarify requirements before or during any SDD path. Triggers: "explore", "think through", "help me figure out", "what should I build", "I'm not sure where to start", "let's brainstorm", "investigate this", "I want to explore".

Use when creating a new change with all SDD artifacts — proposal, delta specs, design, and tasks. Triggers: "propose a change", "create a change for X", "I want to implement feature Y", "start a new change", "let's build X".

Use when an agent in one harness must create, observe, or steer one or more agents in another harness through a tmux session the user can watch. Triggers: "use an agent in another harness", "bridge to <agent>", "run <agent> in tmux", "use a different harness", "check on the external agent". Not for subagents or delegation inside the current harness (use `subagent-patterns`).

Use when tasks require current, source-backed technical information from MCP tools. Apply for library/API questions, dependency version checks, third-party integration work, framework- or SDK-specific debugging, and any case where stale model knowledge could cause incorrect guidance.

Use when turning a fuzzy idea into a refined design through dialogue — across software, writing, talks, events, naming, activities, or any creative/design task. Its adversarial lenses also stress-test a plan or proposal already on the table. Triggers: 'brainstorm', 'help me think about/through', 'figure out', 'work through', 'I have this idea', 'let's design', 'flesh this out'. Domain-agnostic. Not for: open-ended ideation with no anchor ('what should I build?'), implementing from a finalized spec, narrow binary decisions ('X or Y?'), retrospective review, mechanical refactors, or reframing whether the presenting question is the "real" one.

Use when the user wants a deep, multi-source, fact-checked web research report on a topic too broad for a single search. Triggers: "deep research on X", "research report", "investigate thoroughly", "comprehensive findings on", "what's the current state of X", "survey the landscape of". Not for: single-fact lookups, library/API/version questions (use mcp-research), or open-ended ideation (use brainstorming).

Use when translating or migrating existing specs from another tool or format (Spec Kit, Kiro, ADRs, Jira, Confluence, Word docs, or custom markdown requirements) into SDD spec format. Also use when the user says "convert these specs", "migrate to SDD", "translate from X to SDD", or "import specs".

Use when writing or reviewing code that handles external input, manages access, touches data or crypto, or changes dependencies. Triggers: endpoints, auth/authz, DB/ORM, file handling, secrets, "is this secure?", "security review". NOT for formatting, pure UI, or explaining code.

Use when the user asks for a security scan or review of a repository, a scoped path (package, folder, or submodule), or a Git-backed change set (pull request, commit, branch diff, or working-tree patch). Point it at the target; it runs the full threat-model, discovery, validation, and attack-path pipeline and writes a report. Do not use to triage externally supplied findings or to fix a single finding.

Use when writing or reviewing Bash scripts and shell snippets, especially for shebang selection, quoting, parameter expansion ("${VAR}" style), test expressions (`[ ]` vs `[[ ]]`), ShellCheck-guided fixes, and portability decisions across POSIX sh, Bash, and zsh compatibility targets.

Use when writing or reviewing tests in any language, or diagnosing a suite that is slow, brittle, or hard to read. Triggers: "write tests", "how should I test this", "what kind of test", "test is flaky/fragile", "should I mock this", "test is hard to read". Python-specific practices (mocking, pytest, async) are included in `references/python-testing.md`.

Use whenever a Conventional Commit message is being drafted — whether the user asks ("write commit message", "draft commit from staged changes", "generate conventional commit", "split this into commits") or you are about to propose one proactively after finishing work (e.g. completing tasks, wrapping up a feature, or summarizing staged changes). Invoke before writing the message inline. Not for creating commits, amending history, or full code review.

Use when creating or refining SKILL.md-based skills, or diagnosing weak triggering (under/over-triggering, vague descriptions, bloated context, or missing workflow guidance).

Write, rewrite, or line-edit prose so it reads as a professional wrote it, not a model: clear, specific, register-appropriate, and free of AI writing tells. Apply to any prose a human will read. Triggers include "make this sound human", "remove the AI tells", "de-slop this", "does this read like ChatGPT wrote it", "humanize this draft", "rewrite this professionally", or any request to draft or sharpen an email, blog post, op-ed, report, memo, or longform message.

Use when the user wants rigorous, non-sycophantic editorial feedback on a draft, essay, blog post, or argument through back-and-forth dialogue — pressure-testing thesis, structure, argument, clarity, tone, and evidence. Triggers: "be my sparring partner", "pressure-test this draft", "poke holes in my argument", "is this ready to publish", "sharpen this post", "where is this weak". Not for one-shot copyediting, proofreading, or ghostwriting.

Use when dispatching development work to one or more subagents and deciding how to shape each dispatch. Triggers: "use subagents", "orchestrate subagents", "delegate to a cheaper/stronger model", "big:little" / "little:big", "verifier / adversary / explorer / oracle subagent", "run this with subagents", "get an independent second opinion". Not for: the parallel code-review path (use `code-review`), or driving a separate agent CLI non-interactively.

You MUST use this when receiving feedback that evaluates a text-based work artifact you produced or are responsible for — code, specs, design docs, PRDs, proposals, plans, or prose — by asserting a defect, questioning a decision, supplying reasoning, or proposing a change for assessment. Also use when asked to implement external review comments that must first be assessed. Not for an unambiguous parameter choice, approval, confirmation, typo or formatting fix, or direct revision instruction that supplies no claim or rationale to evaluate.

Use when the user asks for a deep, exhaustive, multi-pass, or variance-reducing repository-wide or scoped-path security scan. Run repeated independent discovery passes over one resolved scope with worker-specific threat models, semantically merge candidates, synthesize one canonical validation threat model, then run validation, attack-path analysis, canonical JSON completion, and generated reporting once. Do not use for PRs, commits, branch diffs, or working-tree diffs.

Use when the user explicitly asks to fix and verify a validated or plausible security finding. Do not use as the primary trigger for full PR, commit, branch, patch, or repository scans.

Use when writing or reviewing asyncio code in Jupyter notebooks or '#%%' cell workflows — structuring event-loop ownership, orchestrating async tasks, or choosing compatibility strategies. Also use when hitting RuntimeError: This event loop is already running, asyncio.run() failures in cells, or tasks silently never completing.

Use when the user supplies existing security findings or vulnerability reports — SARIF results, CVE/GHSA or advisory text, scanner tickets, bug bounty reports, or finding artifacts — and wants static repo-impact triage. Do not use for discovery, duplicate-bug triage, validation, or fixes.

Use when authoring or reviewing a hands-on demo, tour, or walkthrough notebook (`#%%` percent-format or Jupyter) that demonstrates a feature, library, or API and doubles as semi-interactive documentation. Triggers: "write a demo notebook", "build a feature demo", "demo this library/API", "a notebook to walk through X", "interactive docs for this feature". Not for production/analysis notebooks or pure asyncio event-loop mechanics (see python-notebooks-async).