Claude Skills by tmj-90

Use when a ticket adds or changes Python code and it must follow the repo's Python conventions — PEP 8, full type hints, dataclasses, pythonic idioms, explicit error handling, and pytest with coverage. Invoke for "add this in Python", "fix the type/lint errors", "add the FastAPI/Django endpoint", or as the language pack for any Python change.

Use after implementing a Dispatch ticket and running its checks, to produce and record acceptance-criterion evidence, then STOP. Invoke whenever you have finished and committed work on your claimed ticket and need to evidence each AC. Recording evidence is where your job ENDS — the runner (not you) records the delivery, pushes/opens the PR, and submits for review.

Use when a ticket asks to restructure code without changing what it does — extract a function, split a file, rename for clarity, reduce duplication — with behaviour preserved. Invoke for "refactor X", "clean up the Y module", or "extract Z" where no behaviour change is intended.

Use when an approved ticket's delivery branch cannot auto-merge into the default branch because of a merge conflict. Invoke for "resolve the merge conflict on branch X", "the auto-merge conflicted — reconcile it", or when the factory's merge-ticket runner hands you a conflicting gaffer/* branch. Merge the default branch INTO the delivery branch, resolve every conflict by preserving BOTH intents, prove it with tests, and commit the resolution ON THE BRANCH — never land it to the default branch...

Use as a reviewer agent to review another agent's `in_review` ticket — never your own. Judge whether each acceptance criterion is genuinely met and the change is sound, then record an ADVISORY verdict (per-AC evidence + an overall RECOMMEND APPROVE / RECOMMEND CHANGES line) via the scoped Dispatch MCP, leaving the ticket `in_review` for a HUMAN to make the final approve/reject decision. An agent review is NOT a human approval and must never mint one or merge. Invoke whenever a ticket is in `i...

Use when prioritising a feature backlog using RICE scoring (Reach, Impact, Confidence, Effort) or making a capacity-constrained prioritisation decision. Triggers on "prioritise these features", "RICE scoring", "what should we build first", "rank the backlog", or "capacity planning for the sprint".

Use when a ticket or acceptance criterion sets a coverage threshold or asks to raise coverage on a unit, and you need to measure and evidence it. Invoke for "coverage must stay above N%", "report the coverage delta", or "prove the new code is covered".

Use when a ticket or acceptance criterion requires the linter/formatter to pass, or after editing code to confirm it meets the repo's style gate. Invoke for "lint must be clean", "fix lint errors", or before submitting changes that touched source files.

Use when a ticket or acceptance criterion needs the test suite run and its result evidenced, or after making a change to confirm nothing broke. Invoke for "tests must pass", "verify the suite is green", or before submitting any code change for review.

Use when a service has no runbook, existing runbooks are inconsistent across teams, or on-call onboarding requires standardised operations docs. Triggers on "write a runbook", "document on-call procedures", "operational playbook", "incident playbook", or "runbook for <service>".

Use when implementing, auditing, or validating structured data (schema markup) on a website. Triggers on "structured data", "schema.org", "JSON-LD", "rich results", "rich snippets", "FAQ schema", "Product schema", "schema errors in Search Console", or "why no rich results". NOT for general SEO audits — use `seo-audit`. For AI-search citation optimisation, use `aeo`.

Use when a ticket touches authorization — who may perform an action or see a resource — adding access checks, roles/permissions, ownership/tenant scoping, or fixing an access-control gap. Invoke for "restrict X to admins", "add an ownership check", "enforce tenant isolation", or any change to protected resources.

Use when a ticket handles untrusted input — request bodies/params, query strings, headers, uploads, webhooks, or third-party API responses — and it must be validated and safely handled. Invoke for "validate the request", "sanitize user input", "fix the injection/XSS risk", or when adding any boundary that ingests external data.

Use when a ticket involves secrets — API keys, tokens, passwords, connection strings, signing keys — or their configuration, storage, logging, or rotation. Invoke for "wire up the API key", "load config from the environment", "stop logging the token", or when adding any integration that needs a credential.

Use after implementing a ticket and after its tests pass, but before submitting for review, to review your own diff as a skeptic would. Checks the finished `git diff` against every acceptance criterion (is each genuinely satisfied?), against scope (did you change only what the ticket needs?), and against quality (bugs, leftover debug, missed edge cases, repo conventions). If the diff reveals a gap, fix it and re-test before submitting. Invoke whenever implementation is complete and tests are ...

Use when auditing, reviewing, or diagnosing SEO issues on a site. Triggers on "SEO audit", "technical SEO", "why am I not ranking", "SEO issues", "on-page SEO", "meta tags review", or "SEO health check". For structured data specifically, use `schema-markup`. For AI-search citation optimisation, use `aeo`.

Use when asked to create a slide deck, presentation, pitch deck, or talk outline — or to convert a markdown document into a slides format. Triggers on "create a deck", "slide deck", "presentation", "pitch deck", "talk slides", "convert to slides", or "markdown to slides".

Use when defining, reviewing, or operating SLOs and SLIs — error budgets, burn-rate alerting, SLO review gates. Triggers on "define an SLO", "error budget", "burn rate", "SLI", "multi-window burn-rate alert", or any reliability-target question. For broader dashboard/alert-noise work, route to `observability-designer`.

Use to turn a brief into a structured product SPEC — a set of testable CLAUSES, each exactly one statement, tagged requirement / non-goal / decision — that a human edits and freezes before it feeds the decompose engine. Clarify genuine load-bearing ambiguity first, then draft. Invoke whenever someone describes an app or feature and wants the intent captured as a crisp, testable, traceable spec before any tickets exist. Proposes only — it never writes, freezes, or persists a spec; it emits a c...

Reference for how a finished ticket reaches human review in the Gaffer factory. Submission is RUNNER-OWNED — the agent commits its work and evidences the ACs, then stops; the runner records the delivery, pushes, opens the PR, and submits for review. Invoke when you think your work is ready to hand off, to confirm what you must do (commit + evidence) and what the runner does for you (push, PR, submit).

Use when designing Terraform modules, managing state backends, reviewing IaC for security or anti-patterns, implementing multi-region deployments, or standardising Terraform CI/CD. Triggers on ".tf files", "Terraform module", "remote state", "IaC review", "Terraform security", or "multi-region infra".

Use when hunting for threats in an environment, analysing IOCs, or detecting behavioural anomalies in telemetry. Covers hypothesis-driven threat hunting, IOC sweep generation, and MITRE ATT&CK-mapped signal prioritisation. For active declared incidents, use `incident-response`. For cloud misconfigurations, use `cloud-security`.

Use when a ticket adds or changes TypeScript/JavaScript code and it must follow the repo's TS conventions — strict typing, async correctness, module/import hygiene, and idiomatic patterns. Invoke for "add this in TypeScript", "fix the type errors", "tighten the types on X", or as the language pack for any TS/JS change.

Use when a ticket requires documentation to reflect a change — a README, API reference, changelog, or runbook — or when an acceptance criterion says "document X". Invoke for "update the docs for the new endpoint", "add a changelog entry", or "the README is now wrong".

Use when generating user stories with acceptance criteria, or planning sprint capacity against a set of stories. Triggers on "write user stories", "create stories for this feature", "break this into stories", "sprint planning", or "story points".