gauntlet

Plugin gauntlet from marketplace pi-gauntlet in jjuraszek/pi-gauntlet. Commands read from the repo's manifest — yesterday.

Skills (22)

• release

  Use when asked to release, publish, bump the version, or cut a tag for jjuraszek/pi-gauntlet.

• brainstorming

  Use only when the user explicitly requests brainstorming or selects a handoff into it; the subject is a free prompt, one tracker ticket, or one open PR or a leading list of related open PRs reworked on the home PR's branch.

• chase-bug

  Use when a human hands you a bug report to triage - a Slack paste, tracker ticket, GitHub issue, or described symptom - and the goal is an evidenced verdict (real bug, not-a-bug, cannot reproduce, already fixed or reported); triage itself never fixes - a real-bug verdict may hand off to a bounded ho

• check-delivery

  Use only when explicitly asked to prove delivery of one or more named merged tickets ("check delivery of #12 #15", a loop task naming the ticket and the verb) before their tracker status advances; pre-merge gating belongs to /skill:gatekeep-pr.

• dispatching-parallel-agents

  Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies, when fanning out review-finding fixes in parallel, or when checking a reviewer's Parallel-safe: line before doing so

• finishing-a-development-branch

  Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

• forge-skill

  Use when creating or editing a SKILL.md, a skill's reference file, an agent persona, a prompt template, a slash command, or a file the repo's AGENTS.md or CLAUDE.md routes here, in pi or Claude Code - including one-line edits - or when such a file exceeds 500 lines, gains if/else branching, or drift

• gatekeep-pr

  Use only when explicitly asked to gatekeep, verify, or gate a named pull request before it merges - or on pi a set of them - ("gatekeep PR 123", "gatekeep PRs 123 124 125", a loop task naming the PR and the verb); post-merge delivery proof belongs to /skill:check-delivery.

• gauntlet-handoff

  Human-only producer of a gauntlet handoff brief - invokes pi-cohort's `handoff` skill, then appends the gauntlet process-state section (phase/plan tracker status) to the brief it wrote, per the shared brief contract. Run at the end of a session whose flow a fresh session will continue with /skill:ga

• gauntlet-performance

  Use when a human asks how gauntlet runs perform across the recorded telemetry - explicit invocation only (/skill:gauntlet-performance [--dir <path>]... [--since <version>]).

• gauntlet-resume

  Use when a human wants to continue an interrupted gauntlet flow in a fresh session - from a gauntlet-handoff brief (file, pasted, or picked from the default handoff directory), from a bare worktree that already holds a spec, or from a spec tracked on main (creates or reuses its worktree via `/skill:

• linear

  Use when reading, searching, commenting on, editing, or managing Linear tickets via the `linearis` CLI - ticket IDs like ABC-123, "check ticket ABC-99", "move ABC-12 to done", or when a tracker-facing skill routes Linear mechanics here. Authoring a NEW ticket (structure, acceptance criteria) belongs

• loop-implementation

  Use after approval selects the loop engine, or when resuming an acceptance-criteria ledger in the implement phase.

• receiving-code-review

  Use when receiving code review feedback from a human or external reviewer (GitHub review, human partner), before implementing suggestions, especially when feedback is unclear or technically questionable - verify, push back with evidence, never perform agreement; the subagent-driven-development revie

• requesting-code-review

  Use when completing tasks, implementing major features, or before merging to verify work meets requirements

• roasting-the-spec

  Use after writing a spec when the resolved piGauntlet.specCouncil members list is non-empty. Auto-dispatched by /skill:brainstorming as its configured critique pass with a fresh-context applier executor before the spec review gate.

• shape-ticket

  Use when asked to file, create, or shape a ticket, open a tracker issue, or repair or clean up one or more existing ones (ticket IDs like ABC-123, or a comma- or space-separated list "ABC-123, ABC-124") - including when another skill or command routes ticket authoring here.

• subagent-driven-development

  Use when executing an implementation plan in the current session (the task-plan implement engine; the acceptance-criteria ledger engine is /skill:loop-implementation)

• test-driven-development

  Use when implementing any feature or bugfix, before writing implementation code

• using-git-worktrees

  Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

• verification-before-completion

  Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

• writing-plans

  Use when you have a spec or requirements for a multi-step task, before touching code

Subagents (11)

• conformance-reviewer

  Closing-loop conformance auditor. Confronts the delivered code AND docs against the *origin* (spec + verbatim original prompt), skipping the plan, and reports requirement coverage. Read-only — proposes remediation directions, never edits and never decides disposition.

• delivery-checker

  Use for one ticket dispatched by check-delivery set mode. Not for direct dispatch.

• implementer

  Strict TDD implementation. Writes a failing test, then makes it pass, then refactors. Verifies with real test runs before claiming done.

• loop-implementer

  Dispatch for a loop-engine iteration on the target acceptance-criteria row plus proved same-leg extras, with evidence and one decision line each.

• plan-writer

  Writes, checks, and repairs the gauntlet implementation plan for one approved spec in a fresh context; the plan file is its only output. Dispatched only by the writing-plans skill; not for direct dispatch.

• pr-gatekeeper

  runs one PR of a gatekeep-pr multi-PR set to its report or executes one queued pick. Not for direct dispatch.

• spec-council-applier

  Applies a spec-council chair report to the spec under review and returns the audit. Dispatched by the roasting-the-spec skill; not for direct dispatch.

• spec-council-member

  Adversarial single-model spec critic dispatched by the roasting-the-spec or shape-ticket skills, and in `Mode: amendment-review` by brainstorming's amendment surface to clear or escalate proposed spec amendments; assesses whether a spec is sound, complete, and actionable. Not for direct dispatch.

• spec-council-synthesizer

  Neutral chair that consolidates and adjudicates spec-council member critiques into a single ranked, conflict-resolved report. Dispatched by the roasting-the-spec or shape-ticket skills; not for direct dispatch.

• spec-summarizer

  Produces a plain-language briefing (at most 300 words) of a single spec for the brainstorming user review gate. Fresh context, read-only, reads only the spec file it is given. Dispatched only by the brainstorming skill's gate step; not for direct dispatch.

• wave-reviewer

  Wave review over an integrated diff: spec-clause table when a spec anchor is supplied plus prioritized code findings (Critical and Moderate block, Minor is a nit). Read-only - does not edit.