ahgraber
52 verified skills68 total stars
writing-tests
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". For Python-specific guidance see `python-testing`.
development2
sdd-translate
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".
tools2
sdd-explore
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".
development2
code-review
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, or formatting-only passes.
development2
api-design
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.
development2
receiving-feedback
You MUST use this when receiving feedback on any text-based work artifact — code, specs, design docs, PRDs, proposals, plans, or prose — before implementing suggestions, especially if feedback seems unclear or technically questionable.
development2
skills/debugging
--- name: debugging description: 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. --- # Debugging Random fixes waste time and create new bugs. Symptom patches mask root
development2
changelog
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.
devops2
brainstorming
Use when turning a fuzzy idea into a refined design through dialogue — across software, writing, talks, events, naming, activities, or any creative/design task. 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.
development2
sdd-derive
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".
development2
sdd
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'.
development2
sdd-sync
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".
data-ai2
synthesize
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.
testing2
securing-code
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.
development2
simplify
Review changed code for reuse, quality, and efficiency, then fix any issues found.
development2
editorial-review
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.
development2
sdd-propose
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".
development2
python-notebooks-async
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.
development2
optimize-skills
Use when creating or refining SKILL.md-based skills, or diagnosing weak triggering (under/over-triggering, vague descriptions, bloated context, or missing workflow guidance).
tools2
sdd-apply
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".
tools2
alt-text
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.
documentation2
proof
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 good-prose for those requests.
development2
sdd-verify
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".
testing2
python-testing
Use when writing or reviewing tests for Python behavior, contracts, async lifecycles, or reliability paths. Also use when tests are flaky, coupled to implementation details, missing regression coverage, slow to run, or when unclear what tests a change needs. Use for multi-Python version testing (nox) and free-threaded Python thread-safety validation.
development2
commit-message
Use whenever a Conventional Commit message is being drafted — whether the user asks ("write commit message", "draft commit from staged changes", "generate conventional commit", "message for git commit -F -") 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.
development2
visual-brainstorming
Browser-based visual companion for brainstorming sessions — showing mockups, wireframes, diagrams, and side-by-side comparisons. Use when a brainstorming question is inherently visual: layout choices, UI mockups, architecture diagrams, design comparisons. Not for: text-based questions, conceptual A/B choices, requirements scope, or tradeoff lists (those stay in terminal). Requires user consent before starting a session.
data-ai2
strudel
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.
development2
spec-kit-clarify
Use when an existing Spec Kit `spec.md` has high-impact ambiguity (for example `[NEEDS CLARIFICATION]`, unresolved scope decisions, or unquantified requirements) that must be resolved before `spec-kit-plan`.
testing1
spec-kit-plan
Use when an approved Spec Kit `spec.md` must be translated into technical design artifacts (`plan.md`, `research.md`, `data-model.md`, `contracts/`, `quickstart.md`) before `spec-kit-tasks`, or when `plan.md` is missing/outdated after spec or constitution changes.
data-ai1
mermaid
Generate Mermaid diagrams for chatbot flows that render in Markdown, including choosing diagram types, producing valid Mermaid code blocks, and validating or rendering diagrams locally via the bundled scripts. Use when a user asks for chatbot flowcharts/sequence/state diagrams, wants Mermaid syntax, or needs to verify/render Mermaid without a web service.
development1
spec-kit-specify
Use when a Spec Kit feature needs `spec.md` authored or rewritten from natural-language requirements, especially when the feature has no usable specification or requirements are too vague for planning.
testing1
spec-kit-tasks
Use when an approved Spec Kit `plan.md` + `spec.md` must be decomposed into dependency-ordered `tasks.md`, or when `tasks.md` is missing/stale after planning or reconciliation changes.
testing1
spec-kit-implement
Use when approved Spec Kit `tasks.md` must be executed into implementation changes, or when task execution is blocked by sequencing/checklist gates before feature completion.
testing1
sdd-archive
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".
tools1
good-prose
Write, rewrite, or line-edit professional or semi-formal prose for letters, emails, blog posts, op-eds, reports, or longform messages. Apply to ANY prose humans will read. Makes your writing clearer, stronger, and more professional.
development1
handoff
Use when ongoing work 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.
development1
mcp-research
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.
tools1
spec-kit-analyze
Use when `spec.md`, `plan.md`, and `tasks.md` exist and you need a read-only Spec Kit audit for consistency, requirement-to-task coverage, ambiguity, duplication, or constitution conflicts before implementation.
testing1
spec-kit-checklist
Use when a Spec Kit feature has `spec.md` and you need a requirements-quality checklist (clarity, completeness, consistency, measurability, coverage), not implementation/runtime test cases.
testing1
spec-kit-constitution
Use when creating or amending a Spec Kit project constitution, especially when `memory/constitution.md` is missing, contains `[PLACEHOLDER]` tokens, or principle changes must be propagated to planning/spec/task templates.
testing1
spec-kit-reconcile
Use when specification drift is discovered at any stage and existing Spec Kit artifacts (`spec.md`, `plan.md`, `tasks.md`) must be reconciled in-place without creating a new feature branch.
testing1
python-design-modularity
Use when designing module boundaries, planning refactors, or reviewing architecture in Python codebases. Also use when facing tangled dependencies, god classes, deep inheritance hierarchies, unclear ownership, or risky structural changes.
development
python-concurrency-performance
Use when designing or reviewing concurrent Python code — selecting between asyncio, threads, or multiprocessing; structuring cancellation and deadline propagation; bounding fan-out and backpressure. Also use when diagnosing race conditions, deadlocks, slow throughput, or thread/task leaks under load.
development
python-integrations-resilience
Use when building or reviewing external API integrations in Python — designing client boundaries, defining outbound reliability policy, or structuring contract tests. Also use when provider SDK details leak into domain logic, outbound calls lack timeout/retry policy, or failure paths are untested.
tools
python
Python skill router. Use when planning, implementing, or reviewing Python changes and you need to select focused skills for workflow, design, typing/contracts, reliability, testing, data/state, concurrency, integrations, runtime operations, or notebook async behavior.
development
python-data-state
Use when designing data ownership, validation boundaries, consistency models, or configuration strategy in Python. Also use when encountering unclear ownership across modules, shared mutable state leaking between layers, validation gaps at ingress, cross-module transactional coupling, or config drift between environments.
development
python-runtime-operations
Use when building or reviewing service, job, or CLI runtime behavior in Python — designing startup validation, shutdown sequences, observability, and structured logging. Also use when startup crashes from late config, shutdown leaves orphaned processes, terminal states are implicit, or logs lack structure.
tools
python-workflow-delivery
Use when preparing branches, commits, or PRs for Python changes — scoping work, running validation gates, and ensuring merge readiness. Also use when debugging CI gate failures, resolving lockfile conflicts, or uncertain what checks to run before opening a PR.
development
python-types-contracts
Use when defining or evolving public interfaces, schema boundaries, or pydantic usage in Python. Also use when annotations are missing on public APIs, pydantic models appear everywhere instead of at trust boundaries, contract changes lack migration guidance, or Any/object types are overused across module boundaries.
development
spec-kit
Use when work involves Spec Kit and you need to choose the correct `spec-kit-*` sub-skill, enforce artifact-order gates, or route remediation work (for example sequence violations or specification drift at any stage).
testing
python-errors-reliability
Use when designing error handling, retry policies, timeout behavior, or failure classification in Python. Also use when code swallows exceptions, loses error context across boundaries, has unbounded retries, silent failures, or lacks idempotency guarantees on retried writes.
development
shell-scripts
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.
testing