Help us improve
Share bugs, ideas, or general feedback.
From tk
Creates PRDs via user interviews, codebase exploration, and module design. Use when starting new features or changes.
npx claudepluginhub helderberto/tracerkit --plugin tkHow this skill is triggered — by the user, by Claude, or both
Slash command
/tk:prdThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Skip satisfied steps. If argument provided, skip to Step 2.
Guides technical evaluation of code review feedback: read fully, restate for understanding, verify against codebase, respond with reasoning or pushback before implementing.
Share bugs, ideas, or general feedback.
Skip satisfied steps. If argument provided, skip to Step 2.
Interactive prompts: present options as a numbered list and wait for the user's choice.
The argument is: $ARGUMENTS
If empty, go to Step 1; derive slug after gathering the idea. If provided, derive slug:
— or – (if present)<slug>Output: .tracerkit/prds/<slug>.md. If file exists, present options and wait:
Ask the user for a detailed description of the problem and any solution ideas.
Map current state: data models, services, API routes, frontend, tests. Note exists vs. must build.
Research protocol: codebase first, then docs. Unverifiable claims → flag as uncertain, never fabricate.
One question at a time. Lead with your recommended answer (mark it (Recommended) and list first). Explore code instead of asking when possible. Present 2–4 options for each question — structured choices are faster than free-text.
| Branch | Key questions | Skip when |
|---|---|---|
| Scope & Surface | Where? New page or integrated? Roles? | CLI/library, no new entry points |
| Data & Concepts | Definitions, existing vs missing data | Never skip |
| Behavior | Interaction patterns, filtering, search | No user-facing behavior |
| Display | Numbers, tables, charts, exports | No UI |
| Access & Privacy | Who sees what? Sensitive data? | Single-user, no auth |
| Boundaries | Out of scope, deferred features | Never skip |
| Integration | Schema, services, external deps | Self-contained change |
Surface ambiguities, contradictions, unstated assumptions. For each gray area, present proposed resolution options. Resolve all before continuing.
Sketch modules. Favor deep modules — simple interface (1-3 entry points) hiding large implementation over shallow modules where interface ≈ implementation.
Shallow signals: many small 1:1 functions, callers compose multiple calls, feature changes require interface changes.
Present modules. Confirm which need tests.
Save to .tracerkit/prds/<slug>.md (create dir if missing).
# Feature Name
PRD body structure. Omit empty sections. No file paths or code snippets.
## Problem Statement
## Current State (skip if greenfield)
## Solution (user experience, not architecture)
## User Stories (numbered, cover happy + edge + error)
## Implementation Decisions
### New Modules (name, purpose, interface signatures)
### Architectural Decisions (definitions, data flow, state)
### Schema Changes
### API Contracts
### Navigation
## Testing Decisions (behavior tests, key cases, prior art)
## Out of Scope (be specific)
Present options and wait for the user's choice:
/tk:plan <slug> (Recommended)