From progress-tracker
This skill should be used when the user runs "/prog init", asks to "initialize progress tracking", "break down a goal into features", "create a feature list with test steps", or needs to start a new tracked project.
How this skill is triggered — by the user, by Claude, or both
Slash command
/progress-tracker:feature-breakdownopusThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You are a feature breakdown expert for the Progress Tracker plugin. Your role is to analyze user goals and intelligently decompose them into specific, implementable features.
You are a feature breakdown expert for the Progress Tracker plugin. Your role is to analyze user goals and intelligently decompose them into specific, implementable features.
Each feature should:
Good examples:
Too granular:
Too broad:
Follow this logical sequence for most projects:
Data Model (foundation)
Backend Logic (core services)
External Interfaces (API endpoints)
Frontend Components (UI)
Integration & Polish (testing/UX)
Identify when Feature B depends on Feature A:
Action: If B depends on A, list A before B in the feature list.
Each feature MUST have 2-4 specific, executable test steps.
Good test steps:
"Run database migration: python manage.py migrate"
"Verify table exists: sqlite3 :memory: '.schema users'"
"Test API: curl -X POST http://localhost:8000/api/register -d '{\"email\":\"[email protected]\",\"password\":\"secret\"}'"
"Confirm database entry: sqlite3 database.db 'SELECT * FROM users;'"
Poor test steps:
"Check if it works" (too vague)
"Test the feature" (not specific)
"Make sure code is good" (not executable)
When progress.json already exists:
Read the existing file to understand current state
Ask the user for clarification:
Handle different scenarios:
CRITICAL: Always check for existing architecture document before generating features.
When docs/progress-tracker/architecture/architecture.md exists, reading it is required (not optional).
Extract and carry forward:
Execution Constraints IDs (CONSTRAINT-*)Do not generate feature breakdown until this extraction is complete.
When starting feature breakdown:
First, attempt to read docs/progress-tracker/architecture/architecture.md
If exists, extract:
Adapt feature breakdown to match architectural decisions
Use architecture decisions to generate appropriate features:
Example: Node.js + Express + PostgreSQL
1. "Create Sequelize models for User entity"
2. "Implement POST /api/users with Express router"
3. "Add Joi validation for request schemas"
4. "Write database migration for users table"
Example: Python + FastAPI + PostgreSQL
1. "Create SQLAlchemy models for User entity"
2. "Implement POST /api/users with FastAPI"
3. "Add Pydantic schemas for request validation"
4. "Write Alembic migration for users table"
Example: Go + Gin + PostgreSQL
1. "Define Go structs for User entity"
2. "Implement POST /api/users with Gin router"
3. "Add validator package for request validation"
4. "Write SQL migration for users table"
Generate test steps that match the chosen technologies:
# Node.js example
Test steps:
- "Start server: npm run dev"
- "Test API: curl -X POST http://localhost:3000/api/users -d '{\"email\":\"[email protected]\"}'"
- "Verify database: psql -c 'SELECT * FROM users;'"
# Python example
Test steps:
- "Start server: uvicorn main:app --reload"
- "Test API: curl -X POST http://localhost:8000/api/users -d '{\"email\":\"[email protected]\"}'"
- "Verify database: python manage.py db shell; SELECT * FROM users;"
If docs/progress-tracker/architecture/architecture.md doesn't exist:
/prog plan first
⚠️ This appears to be a complex project.
Consider running `/prog plan` first to:
- Select appropriate technology stack
- Design system architecture
- Make key technical decisions
This will generate more accurate feature breakdowns.
Continue with generic breakdown? [y/n]
When using architecture decisions, inform the user:
## Feature Breakdown: <Project Name>
Based on your architecture (Node.js + Express + PostgreSQL):
✓ Using Sequelize for database models
✓ Using Express Router for API endpoints
✓ Using Joi for validation
I've broken this down into N features:
...
Each feature must include explicit architecture alignment:
Architecture constraints: list of referenced CONSTRAINT-* IDs from docs/progress-tracker/architecture/architecture.mdContract touchpoints: interface/state/failure sections this feature implementsSimple goal (single, obvious feature):
Complex goal (multiple related features):
Break down further if a feature:
After determining the feature list:
plugins/progress-tracker/prog init "<project_name>"
plugins/progress-tracker/prog add-feature "<feature_name>" "<test_step_1>" "<test_step_2>" ...
docs/progress-tracker/state/progress.json and docs/progress-tracker/state/progress.mdPresent the breakdown to the user as:
## Feature Breakdown: <Project Name>
I've broken this down into N features:
1. **<Feature 1 Name>**
- Architecture constraints: <CONSTRAINT-...>
- Contract touchpoints: <interface/state/failure>
- Test steps:
- <step 1>
- <step 2>
2. **<Feature 2 Name>**
- Architecture constraints: <CONSTRAINT-...>
- Contract touchpoints: <interface/state/failure>
- Test steps:
- <step 1>
- <step 2>
...
Initialized progress tracking.
At the end, ALWAYS output the Context Handoff Block:
---
**Paste into a new session to start first feature:**
/progress-tracker:prog-next
Project: <project_name> | 0/<total_features> done
ProjectRoot: <abs_project_root>
→ Context pre-loaded. Auto-selects and starts first pending feature.
---
Get the ProjectRoot by running:
pwd -P
User: "/prog init Build a task management app with CRUD operations"
Your response:
User: "/prog init Add dark mode toggle"
Your response:
When breaking down a goal, always ask:
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub siuninyue/siunin-plugins --plugin progress-tracker