---
Transforms feature specifications into detailed technical implementation plans with technology research
/plugin marketplace add cahaseler/cc-track/plugin install cc-track@cc-track-marketplaceGoal: Transform tech-agnostic spec into detailed technical design with chosen tech stack.
Core Principle: Research before designing. Constitution before committing. Design before tasking.
ls -1 .cc-track/specs/ 2>/dev/null | tail -1ls .cc-track/constitution.md 2>/dev/null | head -1Find active spec directory:
CLAUDE.md## Active Task@.cc-track/specs/NNN-feature-name/spec.md path.cc-track/specs/NNN-feature-nameRead spec files:
.cc-track/specs/NNN-feature-name/spec.md.cc-track/specs/NNN-feature-name/.metadata.jsonVerify:
[NEEDS CLARIFICATION] markers remain in spec (should be resolved during /cc-track:specify)If NEEDS CLARIFICATION found:
❌ Cannot proceed with technical planning.
Found X unresolved clarifications in spec.md.
The spec should be complete before planning. Ask the user about these ambiguities now, or explicitly tell me to proceed anyway.
Before diving into design, assess whether this spec warrants exploring alternative approaches.
Ask yourself:
This assessment should take <30 seconds. Don't overthink it.
Only execute this phase if complexity assessment triggered it.
For each alternative, provide a brief sketch (not a full plan):
Alternative A: [Name - e.g., "Minimal/Direct"]
Alternative B: [Name - e.g., "Flexible/Extensible"]
Alternative C: [Name - e.g., "Performance-First"] (only if NFRs warrant)
State your recommendation and why:
"I recommend Alternative [X] because [specific reason related to this project's needs]."
Present alternatives to user:
I've considered [N] approaches for this feature:
A) [Name]: [One-liner summary]
B) [Name]: [One-liner summary]
C) [Name]: [One-liner summary] (if applicable)
Recommendation: [X] - [Brief rationale]
Proceed with this approach? Or discuss alternatives?
Wait for user confirmation before Step 3.
If .cc-track/constitution.md exists:
Read .cc-track/constitution.md
Ask user: "Before designing, what's the planned approach?"
For each potential violation:
⚠️ Constitution Check Warning:
Guardrail: "Maximum 3 separate services"
Your plan: Mentions 4 services (API, Auth, Notifications, Analytics)
This needs justification. Either:
A) Simplify to fit within 3 services
B) Justify why 4 services are necessary
Which approach?
Record violations for plan.md Complexity Tracking section.
One at a time (like /cc-track:specify questioning):
Required Questions:
Conditional Questions (based on spec):
For each chosen technology:
Researching [chosen tech] best practices...
- Latest version and features
- Common patterns for [spec requirements]
- Performance characteristics
- Security considerations
If any of these apply:
Delegate research to a specialized agent:
Task: "Research [technology] best practices for [specific use case].
Focus: [1-2 specific questions]
Format: Concise bullet points, max 300 words"
Subagent: researcher
Output: .cc-track/specs/NNN-feature-name/research-[topic].md
This saves your context for design work while getting thorough research.
Create research.md:
# Research: [Feature Name]
## Technology Decisions
### Decision: TypeScript + Bun
- **Chosen**: TypeScript 5.3 with Bun runtime
- **Rationale**: Built-in TypeScript, faster than Node, good for CLI tools
- **Alternatives Considered**:
- Node.js: More mature but slower
- Go: Faster but team unfamiliar
- **Tradeoffs**: Bun is newer, smaller ecosystem
### Decision: SQLite for Storage
...
**Language/Version**: TypeScript 5.3
**Runtime/Framework**: Bun
**Primary Dependencies**: commander, zod
**Storage**: SQLite
**Testing**: Bun test
**Target Platform**: CLI tool
**Performance Goals**: <100ms command execution
**Constraints**: Cross-platform (Linux, macOS, Windows)
**Scale/Scope**: Single-user local tool
## Data Model
### Entity: User
- **Purpose**: Represents authenticated user
- **Fields**:
- `id`: UUID (primary key)
- `email`: string (unique, indexed)
- `password_hash`: string (bcrypt)
- `created_at`: timestamp
- `last_login`: timestamp | null
- **Relationships**: One User → Many Sessions
- **Validation**: Email format, password complexity
- **State Transitions**: active → suspended → deleted
Save to data-model.md if data involved.
For each endpoint from spec:
## Endpoint: POST /api/users
**Purpose**: Create new user account
**Request**:
```json
{
"email": "string (email format)",
"password": "string (min 8 chars)"
}
Response (201):
{
"id": "uuid",
"email": "string",
"created_at": "iso8601"
}
Errors:
Save to `contracts/` directory.
### Write Plan Document
Use `templates/plan-template.md`:
- Summary
- Technical Context (from above)
- Constitution Check results
- Project Structure
- Step 4 (Research) - reference research.md
- Step 5 (Design) - reference data-model.md, contracts/
- Progress Tracking
- Risk Assessment
Save to `plan.md`.
---
## Step 6: Constitution Check (Post-Design)
**If constitution exists, re-validate**:
### Check Design Decisions
- Services/components within limits?
- Patterns follow guidelines?
- Dependencies within budget?
- Performance targets align with standards?
### Document Violations
If any violations remain:
```markdown
## Complexity Tracking
| Violation | Why Needed | Simpler Alternative Rejected Because |
|-----------|------------|-------------------------------------|
| 4 services | Analytics needs separate scaling | Combining with API would bloat codebase |
If violations can't be justified:
❌ Design violates constitution without justification.
Issue: [specific violation]
Required: Simplify or justify
Revising design...
Show user:
Technical plan complete! 🎯
[If alternatives were explored:]
Design approach: [Chosen alternative name]
Alternatives considered: [Brief list of rejected approaches]
Created files:
- plan.md (implementation plan)
- research.md (technology decisions)
- data-model.md (entity designs)
- contracts/ (API specifications)
Constitution status: ✅ All guardrails met
Tech stack: TypeScript + Bun + SQLite
Complexity: Low (single service, 3 dependencies)
Next step: Ready to run `/cc-track:tasks` to generate implementation breakdown?
User: "Just ignore the constitution for now"
Claude: "I can proceed, but I'll document the deviations in plan.md for future reference. Continue?"
Claude: "⚠️ Found that [technology] doesn't support [requirement] well.
Alternatives:
A) Switch to [alt tech] (better support)
B) Use workaround with [current tech]
C) Adjust requirement
Recommendation: A
What should I do?"
Claude: "This design is getting complex (7 components for 3 features).
YAGNI Check - Can we simplify by:
A) Merging [component X] into [component Y]
B) Deferring [feature Z] to later
C) Using [simpler pattern]
Recommend: A + B
Thoughts?"
.cc-track/constitution.md)mkdir -p .cc-track/specs/NNN-feature-name/contracts/cc-track:tasks job).metadata.json if status changesAfter /cc-track:plan completes: /cc-track:tasks