AlexanderMattTurner
@AlexanderMattTurner Organization
Public Skills
writing-tests
by AlexanderMattTurner
How to write, change, or review tests in this repo — the load-bearing rule is test real behavior, not source text. Also covers non-vacuity (prove the test can fail: red-on-old → green-on-new), e2e tests that secretly stub the component they name, drift guards as a design smell to name rather than launder, SSOT contract tests that must move with their data, covering enumerated sets member-by-member, fuzzing parser/Unicode logic, hostile-pre-state filesystem tests, stubs that must drain stdin, checks that must prove the subject ran before judging its output, probes that must not perturb the state they read, failure-signature lists that must carve out your own guards' refusals, the Python test idioms (repo-root discovery, exec()-ing a module's main, from future import annotations) that bite under pytest-xdist, and the c8 / kcov / mutation coverage floors. Activate whenever the user asks to write, add, fix, refactor, strengthen, or review tests ("write a test", "add tests", "test this", "regression test", "cover this", "why didn't this test catch it"), or when a coding task's last step is testing the change you just made.
git-workflow
by AlexanderMattTurner
The mechanics of committing, pushing, and resolving merge conflicts in this repo. Activate before you commit or push, when a PR reports a merge conflict or a dirty mergeable_state, when a merge-conflict label or an auto-resolve bot comment arrives, when you must audit a bot's merge resolution or answer a merge-delta finding thread, when you are about to push work that belongs to an already-open PR, and when you are tempted to re-run the suite locally after a push. The load-bearing rule is that a conflict belongs to the auto-resolve workflow, not to you.
pr-creation
by AlexanderMattTurner
Creates high-quality pull requests with an iterative compress-critique-fix loop before submission. Activate this skill whenever you are asked to create, open, submit, or push a pull request, OR whenever a new feature, fix, or refactor is complete and ready to ship. Also activate when the user says "make a PR", "open a PR", "submit this for review", "push and create a PR", "I'm done, create the PR", "the feature is done", "I'm finished", or any variation of completing work / requesting a pull request. Also activate to update, fix, or add to an existing PR — "update the PR", "fix the PR", "add this to the PR" (see "Updating an existing PR"). Always activate before opening or editing a PR, whatever the route — CLI or API tool.
defect-to-guard
by AlexanderMattTurner
Turn a defect class into a well-designed guard PROPOSAL (and, once a human promotes it, a well-built guard). Activate when writing a ## Proposed guards entry after fixing a bug, and when a human has explicitly approved implementing a lint, pre-commit hook, CI check, assertion, or ratchet — never to ship a guard inside a fix PR. Covers naming the defect CLASS rather than the instance, checking whether an existing guard should have fired (a gap in it is itself a bug), preferring a check that iterates the SSOT over a per-case assertion, naming the guard's HOME (this repo, or the shared ci-truth-serum pack) and what belongs in each, the inert-feature class that only a behavior-driving smoke test can catch, writing a repo-local checks/*.py line lint and dogfooding it against the real tree before shipping, the WATCHED-SURFACE question (when this goes red, who actually sees it?), the vacuous-green failure mode, and why mutation testing runs on CI and never locally.
vuln-research
by AlexanderMattTurner
How to find, confirm, and report a security vulnerability with an AI session — in this repo's own sandbox boundary, in a dependency, or upstream. Activate when the user asks to "find vulnerabilities", "look for a bypass", "attack the sandbox", "audit this for security bugs", "is this exploitable", "write up this finding", or when a scanner, eval, or audit produces a candidate finding you are about to escalate. Also activate before you open a security advisory, file an upstream security report, or claim a boundary is bypassable. Covers a /goal bug hunt, reproduce-before-report, scoring a candidate against THIS threat model instead of a generic pattern, corroborating with the classical tools already wired into this tree, independent refutation before escalation, the maintainer-burden rule that bounds what you send upstream, and why a human sees every finding before anyone outside does. The load-bearing rule is that a finding you cannot reproduce is not a finding.
babysit-prs
by AlexanderMattTurner
How to sit on a set of already-open PRs and drive them to landed — building the watch set, reading GitHub's mergeability and queue state correctly, re-arming auto-merge, dispatching fixes for reds, and deciding which wake-ups deserve a reply. Activate when asked to "babysit", "watch", "monitor", "sit on", "keep an eye on", "drive to green", "land" or "merge" one or more open PRs (a named stack included), when asked to re-enable auto-merge on PRs that lost it, when a PR sits in a state you cannot explain (unknown mergeability, auto-merge silently off, a required check that never reports), or when a wake-up arrives from a PR you are already watching. The load-bearing rule is that babysitting lands PRs through the auto-merge path — a direct merge is reserved for a narrow, reproduced fix for a red on main.
ci-triage
by AlexanderMattTurner
How to respond when a CI check goes red, a PR check fails, a test is flaky, a job times out, or a webhook reports a failing status — plus how to read GitHub check state at all (gh locally vs mcp__github__* on the web, and why one page of get_check_runs never proves "all green"). Activate whenever a check is red or cancelled, a workflow run failed, a shard timed out, a test is intermittent, you are about to claim a PR is green or mergeable, you are about to re-run a job, or you need a failing job's log. Also activate before dispatching an expensive/live-fire workflow to verify a fix. The load-bearing rule is that a red check is a bug you have not diagnosed yet — "flake", "pre-existing", "unrelated", and "infra" are conclusions you must earn by reading the log, never opening assumptions, and never a licence to re-run.
doctrine-capture
by AlexanderMattTurner
How to turn a rule the user just stated into doctrine this repo will still follow next session. Activate the moment the user writes NEVER or ALWAYS in capitals, and on the same shapes without the capitals — "don't ever", "from now on", "every time", "stop doing X". Also activate, unprompted, when the user faults HOW the session ran — "fatal flaw", "why only N", "too small", "you should have", or asks whether the work was complete — "did we fix all of it", "is there a guard", "why didn't CI catch this" — since that complaint names a rule the tree failed to carry. Also activate, unprompted, when YOU notice a defect class — a duplicate definition, a rule a sub-agent or open PR broke — before you record it. The load-bearing rule is that the capture happens in the session that heard it, on a PR that session already has open, never as a promise or an issue.
parallel-audit
by AlexanderMattTurner
Runs a broad, multi-dimension codebase audit by fanning out parallel read-only subagents (one per dimension x file-area), independently confirms their findings, then groups the survivors into one fix plan with partitioned commits, on as few PRs as the footprint bound allows, and self-critiques it before delivery. Activate when the user asks to "find dozens of issues", "audit the codebase", "find security/ robustness/testing/UX deficiencies", "use subagents to audit and confirm", "find bugs and missed opportunities", or "make a plan to fix all of these". Distinct from peer-review (which reviews a pending diff) and security-review (single-pass, current branch): this audits the WHOLE codebase along several axes at once and ends in a vetted fix plan, not edits.
explore-plan
by AlexanderMattTurner
Drives the Explore -> Plan -> Critique -> Review -> Verify discipline for a written plan. Activate on entry to plan mode, before writing the plan — including the plan-mode requests "plan this", "scope this out", "figure out how to do X", "explore the codebase first" — in auto mode at the start of any non-trivial task, where no plan gate fires — and in any other mode when the task obviously needs a plan (several files, an unfamiliar subsystem, more than one PR), invoked informally without entering plan mode. A trivial edit (typo, single-line change) activates nothing, in any mode. Enforces a self-critiqued written plan, convergent setup work started in the background while design questions settle, and real verification instead of trusting a success claim.
run-control-tower
by AlexanderMattTurner
How to run the external Control Tower / LinuxArena eval (glovebox's marginal-defense benchmark) — dispatching the live Kata-microVM e2e, building the cells JSON, picking the agent model + budget, and pulling the .eval transcripts back. Activate whenever the user asks to "run CT", "run the Control Tower eval", "smoke test the CT harness / all CT environments", "run a guarded-condition eval", "dispatch the CT e2e suite", "measure marginal defense / ΔS / ΔU", or wants to scan CT eval transcripts. Covers dispatch mechanics; the honesty rules live in .claude/rules/control-tower-eval.md and load with the CT tree.
run-ctf
by AlexanderMattTurner
How to run and report the live-fire breakout CTF — glovebox's containment test, where a real autonomous agent attacks the production sandbox stack and a judge grades whether it was contained. Covers the dispatch inputs, the postures (guarded, automode, control), the verdict vocabulary and what each verdict does NOT claim, and the results table a round set is reported as. Activate whenever the user asks to "run the CTF", "run the breakout CTF", "run N rounds on <model>", "check containment / does the sandbox hold", "summarize the CTF results", or wants a CTF transcript. Distinct from run-control-tower, which is the Control Tower / LinuxArena ΔS/ΔU benchmark — a different harness with a different question.
stress-test
by AlexanderMattTurner
Generates comprehensive smoke and stress tests for infrastructure components (sandbox runtimes, container orchestration, firewall rules, etc.), prioritizing end-to-end realism that catches real setup issues across platforms. Activate when the user asks to "stress test", "smoke test", "test the sandbox", "verify isolation", or wants comprehensive infrastructure testing for a component.
handoff
by AlexanderMattTurner
How to write the end-of-session handoff — the residue this session neither owned nor could fix. Activate when the user asks for a handoff, when a session is ending with a known failure still standing, or when you are about to call something "pre-existing", "unrelated" or "not mine". The load-bearing rule is that a handoff is what remains AFTER you fixed what root CLAUDE.md's scope rule makes yours and handed each shared failure to its one owner, never an alternative to either.
markdown-block
by AlexanderMattTurner
Outputs content inside a copyable fenced markdown code block so the user can copy the raw markdown verbatim. Activate whenever the user asks for "copyable markdown", "raw markdown", "the markdown source", "give me the markdown", "as a code block I can copy", or any variation of requesting markdown they can paste elsewhere (READMEs, docs, issues, PR descriptions, chat messages).
peer-review
by AlexanderMattTurner
Runs a fresh, unbiased review of pending changes by delegating to the read-only code-reviewer subagent, then triages and fixes the findings. Activate when the user asks to "review this", "peer review", "get a second opinion", "review my changes/diff/branch", or wants a review pass before opening a PR. Distinct from the built-in /code-review and /review skills: this one drives the project's code-reviewer agent to a fixed point.