GitHub collection
bostonaholic/team
Imported from GitHub — is this yours?
18 skills imported from this repository.
create-team-skill
Authoring guide for creating a new skill in this plugin, matching the conventions the existing skills already use. Establishes the three decisions every skill must make before any prose is written: how it is invoked (entry point vs building block), how it acquires its input, and
code-review
Generator-evaluator separation and review methodology — loaded by review agents to enforce fresh-context review discipline and gate verdicts; findings from the code, security, and docs reviewers are formatted per the conventional-comments skill. Trigger on "review this diff", "re
eng-design-doc-review
Adversarially review a technical design document with fresh context. Dispatches the built-in read-only `Explore` subagent (clean context, no shared history with the design-author) against `docs/plans/<id>/design.md` and presents its verdict — APPROVE, REQUEST CHANGES, or COMMENT.
pr-cleanup
Tear down local and remote branch state after a pull request is finished, in one of two modes. Mode A (merged): verify the PR actually merged, remove the branch's worktree, resync the default branch, and delete the local branch. Mode B (closed / abandoned): close the PR(s), then
pr-rebase
Bring a feature branch up to date with its base without changing what the branch does: capture a pre-rebase check baseline, fetch, rebase onto the latest base, resolve each conflict from both sides' intent with the rationale recorded to disk, re-run the same checks, and treat any
pr-verify
Verify a pull request's test plan with evidence-rated verdicts: extract every test-plan item, classify each by verification strategy, collect cited evidence per item (PASS / FAIL / PARTIAL at HIGH / MEDIUM / LOW confidence), and report a READY / NEEDS ATTENTION / NOT READY final
pr-watch-as-author
Watch your own pull request for review feedback: undraft it when the cue clearly says it is ready (an ambiguous cue watches the draft), take a baseline snapshot, then poll GitHub in ~31-minute cycles for up to 24 hours and triage new feedback as it arrives — inline review threads
pr-watch-as-reviewer
Watch a pull request you are reviewing until your feedback is settled, re-review each settlement, then approve once: poll GitHub in ~31-minute cycles for up to 24 hours until every review thread you opened is resolved and every plain PR comment you posted has a later push behind
shipit
Land a reviewed pull request: discover the open PR for the current branch, push any unpushed commits, wait for CI to go green, then squash-merge it so the PR title (which may carry a version) lands as the commit subject. Handles a PR that has fallen behind its base (rebase + forc
team-design
Decide the approach before any code is written. The design-author drafts the ~200-line design document, resolving its own open questions autonomously as recorded assumptions, then an adversarial design review gates advancement. Trigger on "design this", "let's align on the approa
team-fix
Compressed bug-fix pipeline — reproduce, write failing test, minimal fix, verify, and open a draft PR. Skips Question/Research/Design/Structure/Plan phases. Invoke ONLY on explicit pipeline intent — the user says "run the bug-fix pipeline", "team-fix this bug", or runs "/team-fix
team-implement
Execute the implementation phase. Includes test-first sub-step (writing failing tests, mechanical confirmation gate) and adversarial verification (5 parallel reviewers with hard-gate retry loop). Trigger on "implement this", "execute the plan", or "/team-implement".
team-plan
Produce the tactical implementation plan from the structure. The plan is an autonomous artifact for the implementer — no approval gate at this phase (the design was already gated by the adversarial design review). Trigger on "plan the implementation", "spell out the steps", or "/
team-pr
Open the pull request after verification passes. Updates the changelog, optionally surfaces the tracking ticket, and closes out the topic. Trigger on "open the PR", "open a draft PR", or "/team-pr". To land/merge a reviewed PR (wait for CI, then squash-merge) use the separate /sh
team-question
Decompose a feature description, ticket, or issue link into the QRSPI Question artifacts (task.md, questions.md). Trigger on "shape this idea", "decompose this task", or "/team-question".
team-research
Research a codebase area before making changes. Dispatches parallel read-only agents (file-finder + researcher) that read questions.md only — never task.md. Trigger on "research this", "explore the codebase for", or "/team-research".
team-structure
Break the reviewed design into vertical slices with verification checkpoints. Runs autonomously and advances to PLAN — no approval gate. Trigger on "slice this up", "break the design into steps", or "/team-structure".
team-worktree
Prepare one or more isolated git worktrees — one per repository the topic touches. Router action — no agent. Trigger on "set up the worktree", "isolate this work", or "/team-worktree".
Agents (13)
code-reviewer
Use when an adversarial code review is needed after implementation. Reviews with fresh context and no shared conversation history to prevent self-evaluation bias. Produces a hard-gating verdict — REQUEST CHANGES blocks shipping. Example triggers — "review my changes", "code revie
design-author
Use after research is complete to draft the approach before any code is written. Drafts a ~200-line design document covering current state, desired end state, patterns to follow, and decisions made. Resolves its own open questions autonomously, recording each as an explicit, audi
file-finder
Use when you need to locate files in a codebase relevant to a specific area. Maps conceptual goals to actual file locations even when exact names are unknown. Operates from questions.md only, never the original task description.
implementer
Use when the implementation plan needs to be executed slice by slice. A seasoned coding expert that reads the plan, follows TDD discipline, executes one vertical slice at a time, and commits each slice atomically when its tests pass. Dispatched during the Implement phase.
planner
Use after the structure is produced to create the tactical implementation plan. Translates each vertical slice in structure.md into precise file-level steps with acceptance test mappings. The plan is a tactical artifact for the implementer — neither the structure nor the plan is
questioner
Use as the first agent of the QRSPI pipeline. Decomposes a user's task description into a full task record (task.md) and neutral research questions (questions.md), plus conditional artifacts — a prd.md when the PRD criteria apply, and a repos.md listing the repos the topic touche
researcher
Use when codebase facts need to be gathered before any design or implementation work. Reads code, traces dependencies, documents patterns. Receives only the path to questions.md, never the original task description.
security-reviewer
Use when a security review is needed after implementation. Applies OWASP-style checks with fresh context. Critical findings are a hard gate — they block shipping until resolved. Example triggers — "security review", "check for vulnerabilities", "audit this code for security issue
structure-planner
Use after the design review passes to break the work into vertical slices with verification checkpoints. Each slice is end-to-end (touches every layer needed to deliver one piece of functionality), independently testable, and atomically committable. Produces a ~2-page document th
technical-writer
Use after implementation to review whether project documentation needs updating. Reads the diff and compares against existing docs to identify gaps and stale content. Produces a structured report — does not rewrite docs itself. Example triggers — "check if docs need updating", "d
test-architect
Use after the worktree is prepared to write all failing acceptance tests from the structure. Tests form the immutable scope fence for implementation. Operates inside the implement phase as a sub-step before the implementer runs.
ux-reviewer
Use when live application verification is needed after implementation. Boots the application, interacts with it as a user would, and evaluates the experience. For API-only projects, sends real HTTP requests. Example triggers — "verify the app works", "test the UI", "check the use
verifier
Use when comprehensive verification checks need to run before completion. Runs all available checks (format, lint, type check, build, tests) in speed order and produces an evidence-based report. Example triggers — "run all checks", "verify the build", "pre-flight checks", "does e