/toolkit

description: "Use when a /team run must pick the best tool or skill for a capability, or when adding a discovered tool to the registry. Maps each capability to its best tool, quality notes, fallback, and when-to-skip rule."

Team Toolkit Registry

> **Purpose:** Maps capabilities to the best available tool/skill. > Layer 2 agents consult this before doing work — they use the best tool > available, not a hardcoded one. > > **How it's used:** The orchestrator (team.md) reads this file, extracts > entries relevant to the current action, and inlines them into Layer 2 > agent prompts. Agents never read this file directly. > > **Updating:** After every /team run, Layer 4 principals may recommend > toolkit updates based on Layer 3 review findings. The orchestrator > applies these updates. > > **Adding new tools:** When you discover a new repo, skill, or tool, > add an entry here. It becomes available to all future /team runs.

---

PRD Generation

• **Best tool:** prd-generator (skill; the PM Studio suite refers to it as /pmstudio-prd, but the skill declares itself as `prd-generator` and that is the name that resolves)
• **Quality notes:**
• Always include a rollback plan in the launch section
• Make success metrics measurable (not "improve UX" — use quantitative targets)
• NFR section tends to be generic — add project-specific NFRs
• **Alternative:** Direct writing by senior-pm role
• **When to skip tool:** PRD < 3 sections or highly specialized format

Stakeholder Communications

• **Best tool:** /pmstudio-comms
• **Quality notes:**
• Subject lines sometimes too formal — shorten and make actionable
• Add TL;DR for emails > 3 paragraphs
• **Alternative:** Direct writing by comms-specialist role
• **When to skip tool:** Simple 1-paragraph updates

Architecture Review Decks

• **Best tool:** /pmstudio-arb
• **Quality notes:**
• 11-slide consulting format is solid
• Data visualization sections need improvement — pair with data-viz-specialist
• This entry is a presentation generator, not an architecture tool. It formats an architecture for a review board audience; it does not analyse or decide one. For analysis use the Architecture Audit entry, and for the underlying structural facts use the Codebase Mapping and Code Graph Queries entries.
• **Alternative:** Direct creation by structured-presentation + narrative-architect roles
• **When to skip tool:** Non-consulting format presentations

Meeting Notes

• **Best tool:** /pmstudio-meeting-notes
• **Quality notes:** No findings yet
• **Alternative:** Direct writing by business-analyst role
• **When to skip tool:** Quick standup notes (< 5 bullet points)

Change Logs

• **Best tool:** /pmstudio-changelog
• **Quality notes:** No findings yet
• **Alternative:** Direct writing from git log
• **When to skip tool:** Single-item changes

Disaster Recovery Plans

• **Best tool:** /pmstudio-dr
• **Quality notes:** No findings yet
• **Alternative:** Direct writing by senior-cloud-architect + sre-devops roles
• **When to skip tool:** Non-SaaS products

Incident Response Plans

• **Best tool:** /pmstudio-irp
• **Quality notes:** No findings yet
• **Alternative:** Direct writing by sre-devops role
• **When to skip tool:** Internal tools with no SLA requirements

Recovery Runbooks

• **Best tool:** /pmstudio-recovery
• **Quality notes:** No findings yet
• **Alternative:** Direct writing by sre-devops role
• **When to skip tool:** When DR plan doesn't exist yet

Code Implementation

• **Best tool:** Superpowers pipeline (brainstorming → writing-plans → executing-plans)
• **Quality notes:**
• TDD enforcement is strong
• Plan granularity could be finer for complex features
• **Alternative:** Direct coding by engineering roles
• **When to skip tool:** Single-file changes or < 30 lines of code

Project Orchestration (Multi-Phase)

• **Best tool:** GSD (/gsd:plan-phase → /gsd:execute-phase → /gsd:verify-work)
• **Quality notes:**
• Good for multi-phase projects with persistent state
• Overkill for single-session tasks
• **Alternative:** Manual phasing with /team plan
• **When to skip tool:** Single-session scope or < 3 phases

Test Evidence Protocol

• **Best tool:** `team:evidence.md` (the canonical Test Evidence Protocol)
• **Quality notes:**
• Any quality claim (tests pass, lint clean, coverage N%) MUST follow this protocol and produce `EVIDENCE.md`. Evidence or it didn't happen.
• Determine the authoritative gate from CI config (`.github/workflows`, `Makefile`); use the CI-pinned tool versions, never a weaker local equivalent.
• Skipped tests are `UNVERIFIED`, never a pass. Provision integration deps (e.g. Postgres + DSN) so gated tests actually run, or label the gap.
• Coverage must be measured (`--cov --cov-branch`) and captured, not narrated.
• **Alternative:** None — this is mandatory for any pipeline that reports test/lint/coverage results.
• **When to skip tool:** Never for code that ships via PR. (Pure-docs runs have no test gate.)

Test-Driven Development

• **Best tool:** test-driven-development
• **Quality notes:** No findings yet
• **Alternative:** Direct test writing by qa-test-architect role
• **When to skip tool:** When adding tests to existing test suite (just follow patterns)

Systematic Debugging

• **Best tool:** systematic-debugging
• **Quality notes:** No findings yet
• **Alternative:** Direct debugging by relevant engineering role
• **When to skip tool:** Obvious bugs (typos, wrong variable names)

Code Review

• **Best tool:** requesting-code-review
• **Quality notes:** No findings yet
• **Alternative:** /team review action (uses full 4-layer pipeline)
• **When to skip tool:** Quick sanity checks on < 50 lines

Document Sync

• **Best tool:** /pmstudio-sync
• **Quality notes:** No findings yet
• **Alternative:** Manual sync
• **When to skip tool:** Single-document updates

NFR Audit

• **Best tool:** /pmstudio-nfr
• **Quality notes:** No findings yet
• **