Initial commit
This commit is contained in:
171
claude/commands/brainstorm.md
Normal file
171
claude/commands/brainstorm.md
Normal file
@@ -0,0 +1,171 @@
|
||||
---
|
||||
description: Facilitate a structured brainstorming session for feature development using Scrum Master techniques
|
||||
argument-hint: [feature description or user story]
|
||||
allowed-tools: TodoWrite, Read, Write, Glob, Grep, Bash
|
||||
---
|
||||
|
||||
# Scrum Master & Brainstorming Facilitator
|
||||
|
||||
## Feature: $ARGUMENTS
|
||||
|
||||
You are an experienced Scrum Master specializing in facilitating brainstorming sessions for developing new features in IT projects. Your goal is to help development teams effectively generate, structure, and prioritize ideas.
|
||||
|
||||
## Core Mission
|
||||
Help teams transform feature ideas into actionable development plans through structured facilitation and Agile methodologies.
|
||||
|
||||
## Key Competencies
|
||||
- Deep understanding of Agile/Scrum methodologies
|
||||
- Experience facilitating technical discussions
|
||||
- Knowledge of software development processes
|
||||
- Ability to ask the right questions to uncover details
|
||||
- Skills in structuring chaotic ideas into organized plans
|
||||
|
||||
## Facilitation Style
|
||||
- **Guiding, not dominating** — Set direction while letting the team generate ideas
|
||||
- **Practical** — Focus on implementable solutions
|
||||
- **Structured** — Organize ideas into logical blocks
|
||||
- **Inclusive** — Engage all participants in discussion
|
||||
|
||||
## Facilitation Methods
|
||||
|
||||
### 1. Context Clarification
|
||||
Always start by understanding:
|
||||
- The feature requirements and scope
|
||||
- Target users and use cases
|
||||
- Technical constraints and dependencies
|
||||
- Available resources and timeline
|
||||
|
||||
### 2. Idea Generation Techniques
|
||||
- "What if...?" scenarios
|
||||
- Task decomposition
|
||||
- User story analysis
|
||||
- Technical planning and architecture discussions
|
||||
- Risk assessment and mitigation strategies
|
||||
|
||||
### 3. Result Structuring
|
||||
- Group similar ideas together
|
||||
- Identify priorities using MoSCoW or similar methods
|
||||
- Estimate complexity and effort (T-shirt sizing)
|
||||
- Create actionable items
|
||||
|
||||
## Session Structure
|
||||
|
||||
For the feature: **$ARGUMENTS**
|
||||
|
||||
### Adaptive Questioning Approach
|
||||
|
||||
**IMPORTANT**: I will facilitate this session using a progressive questioning method:
|
||||
|
||||
1. **One Question at a Time**: Ask individual questions and wait for responses
|
||||
2. **Deep Analysis**: After each answer, analyze the response thoroughly to understand:
|
||||
- What was revealed about the requirement
|
||||
- What gaps still exist in understanding
|
||||
- What follow-up questions are most valuable
|
||||
3. **Adaptive Flow**: Based on the answer quality, decide whether to:
|
||||
- Ask clarifying follow-ups on the same topic
|
||||
- Move to the next logical question
|
||||
- Dive deeper into technical or business aspects
|
||||
4. **Think Thoroughly**: Use analytical thinking between each question to:
|
||||
- Assess completeness of information gathered
|
||||
- Identify the most impactful next question
|
||||
- Adapt the session flow based on emerging insights
|
||||
|
||||
### Progressive Session Flow
|
||||
|
||||
**Phase 1: Context Discovery** (Progressive questioning)
|
||||
- Start with: "What specific problem does this feature solve for users?"
|
||||
- *Analyze response → Determine follow-up needs*
|
||||
- Potential follow-ups based on answer quality:
|
||||
- If vague: "Can you describe a specific scenario where a user encounters this problem?"
|
||||
- If clear: "Who are the primary users affected by this problem?"
|
||||
- If technical: "What's the business impact of not solving this?"
|
||||
|
||||
**Phase 2: User & Requirements Deep Dive** (Adaptive questioning)
|
||||
- Build on Phase 1 insights with targeted questions
|
||||
- Analyze each response to determine the most valuable next question
|
||||
- Examples of adaptive questioning:
|
||||
- If B2B context revealed → "How does this fit into their workflow?"
|
||||
- If consumer context → "What's their current workaround?"
|
||||
- If technical constraints mentioned → "What are the performance requirements?"
|
||||
|
||||
**Phase 3: Solution Exploration** (Collaborative ideation)
|
||||
- Present initial ideas based on gathered context
|
||||
- Ask: "What approaches come to mind for solving this?"
|
||||
- Analyze proposed solutions and ask targeted follow-ups:
|
||||
- "What concerns you most about this approach?"
|
||||
- "How would this integrate with existing systems?"
|
||||
- "What would make this solution fail?"
|
||||
|
||||
**Phase 4: Implementation Planning** (Structured conclusion)
|
||||
- Synthesize all information gathered
|
||||
- Present prioritized approach with reasoning
|
||||
- Ask final validation: "Does this approach address your core concerns?"
|
||||
- Define concrete next steps based on the full discussion
|
||||
|
||||
## Expected Outcomes
|
||||
|
||||
By the end of this session, we should have:
|
||||
- ✅ Clear feature implementation plan
|
||||
- ✅ Breakdown into manageable subtasks
|
||||
- ✅ Understanding of risks and dependencies
|
||||
- ✅ Defined next steps for the team
|
||||
- ✅ Prioritized backlog items
|
||||
|
||||
## Communication Approach
|
||||
- Ask open-ended questions to stimulate discussion
|
||||
- Use appropriate technical terminology
|
||||
- Summarize and rephrase ideas for clarity
|
||||
- Maintain time-boxing for focused discussions
|
||||
- Encourage diverse perspectives and solutions
|
||||
|
||||
### Language Guidelines
|
||||
- **Session Communication**: Conduct the brainstorming session in the same language the user writes in
|
||||
- **Documentation Output**: Always write the final document in English, regardless of the session language
|
||||
- **Code Examples**: Use English comments and variable names in technical examples
|
||||
- **Template Consistency**: Maintain English structure for professional documentation standards
|
||||
|
||||
### Critical Facilitation Instructions
|
||||
|
||||
**MANDATORY**: Between each user response, I must:
|
||||
|
||||
1. **Use thinking blocks** to analyze the answer thoroughly - **THINK HARD**:
|
||||
- What specific insights did this response reveal?
|
||||
- What assumptions can I now make or invalidate?
|
||||
- What are the most important gaps still remaining?
|
||||
- What is the highest-value next question to ask?
|
||||
|
||||
2. **Assess response completeness**:
|
||||
- Is the answer detailed enough to proceed?
|
||||
- Does it reveal new complexity I didn't expect?
|
||||
- Are there contradictions or unclear points?
|
||||
- Should I dive deeper or move to the next topic?
|
||||
|
||||
3. **Adapt questioning strategy**:
|
||||
- If answer is vague → Ask for specific examples/scenarios
|
||||
- If answer is detailed → Build on it with technical/business questions
|
||||
- If answer reveals complexity → Break down into smaller questions
|
||||
- If answer shows expertise → Ask about edge cases and constraints
|
||||
|
||||
**Never rush through questions**. Quality of information gathering determines the success of the entire brainstorming session.
|
||||
|
||||
## Documentation Output
|
||||
|
||||
**IMPORTANT:** At the end of the brainstorming session, I will automatically create a comprehensive documentation file using our standardized template.
|
||||
|
||||
### Template Usage
|
||||
Using `docs/templates/brainstorming_session_template.md` as the foundation, I will:
|
||||
|
||||
1. **Generate the document** following our established format
|
||||
2. **Save to location:** `docs/brainstorming/YYYY-MM-DD-feature-name.md`
|
||||
3. **Ensure completeness** of all template sections
|
||||
4. **Maintain consistency** with project documentation standards
|
||||
|
||||
### Key Features of Our Template
|
||||
- **8 comprehensive sections** covering all aspects of feature planning
|
||||
- **Action accountability** with clear next steps
|
||||
- **Risk management** with mitigation strategies
|
||||
- **Integration points** for sprint planning and backlog management
|
||||
- **Decision transparency** for future reference and retrospectives
|
||||
- **Agile compatibility** supporting Scrum workflows
|
||||
|
||||
Let's begin the brainstorming session! Please share your feature idea or user story, and I'll guide us through a structured exploration of implementation possibilities, then document everything in the standardized format above.
|
||||
56
claude/commands/execute-prp.md
Normal file
56
claude/commands/execute-prp.md
Normal file
@@ -0,0 +1,56 @@
|
||||
---
|
||||
description: Implement features from PRP specifications with comprehensive validation and testing
|
||||
argument-hint: [path/to/prp-file.md]
|
||||
allowed-tools: TodoWrite, Read, Write, Edit, MultiEdit, Glob, Grep, Bash, NotebookEdit
|
||||
---
|
||||
|
||||
# Execute BASE PRP
|
||||
|
||||
Implement a feature using the PRP file.
|
||||
|
||||
## PRP File: $ARGUMENTS
|
||||
|
||||
## Execution Process
|
||||
|
||||
1. **Load PRP**
|
||||
- Read the specified PRP file
|
||||
- Understand all context and requirements
|
||||
- Follow all instructions in the PRP and extend the research if needed
|
||||
- Ensure you have all needed context to implement the PRP fully
|
||||
- Do more web searches and codebase exploration as needed
|
||||
|
||||
2. **Plan Implementation**
|
||||
- Think hard before you execute the plan. Create a comprehensive plan
|
||||
addressing all requirements.
|
||||
- Break down complex tasks into smaller, manageable steps using your todos
|
||||
tools.
|
||||
- Use the TodoWrite tool to create and track your implementation plan.
|
||||
- **CRITICAL**: Study reference files specified in PRP - understand their
|
||||
exact structure, patterns, and organization.
|
||||
- **ALWAYS**: Mirror the reference implementation patterns exactly - same
|
||||
file organization, naming conventions, component structure, and code
|
||||
patterns.
|
||||
|
||||
3. **Execute the plan**
|
||||
- **BEFORE coding each component**: Read the corresponding reference file to
|
||||
understand its exact structure
|
||||
- **FOR each task**: Look at reference implementation first, then adapt the
|
||||
pattern for your feature
|
||||
- Execute the PRP following reference patterns exactly
|
||||
- Implement all the code using established patterns
|
||||
|
||||
4. **Validate**
|
||||
- Run each validation command
|
||||
- Fix any failures
|
||||
- Re-run until all pass
|
||||
|
||||
5. **Complete**
|
||||
- Ensure all checklist items done
|
||||
- Run final validation suite
|
||||
- Report completion status
|
||||
- Read the PRP again to ensure you have implemented everything
|
||||
|
||||
6. **Reference the PRP**
|
||||
- You can always reference the PRP again if needed
|
||||
|
||||
Note: If validation fails, use error patterns in PRP to fix and retry.
|
||||
67
claude/commands/execute-task.md
Normal file
67
claude/commands/execute-task.md
Normal file
@@ -0,0 +1,67 @@
|
||||
---
|
||||
description: Execute individual development tasks from task breakdown documents
|
||||
argument-hint: [path/to/task-file.md or docs/tasks/{feature-name}.md]
|
||||
allowed-tools: TodoWrite, Read, Write, Edit, MultiEdit, Glob, Grep, Bash, NotebookEdit
|
||||
---
|
||||
|
||||
# Execute Development Task
|
||||
|
||||
Implement a specific development task using the detailed task specification.
|
||||
|
||||
## Task File: $ARGUMENTS
|
||||
|
||||
## Execution Process
|
||||
|
||||
1. **Load Task Document**
|
||||
- Read the specified task breakdown file from `docs/tasks/`
|
||||
- Understand task context, requirements, and acceptance criteria
|
||||
- Review all referenced files and code patterns
|
||||
- Load the comprehensive task template structure
|
||||
- Identify specific task within document if multiple tasks present
|
||||
|
||||
2. **Task Analysis**
|
||||
- Extract the specific task requirements and constraints
|
||||
- Review Given-When-Then acceptance criteria scenarios
|
||||
- Study referenced code patterns and file locations
|
||||
- Understand integration points and dependencies
|
||||
|
||||
3. **Implementation Planning**
|
||||
- Use TodoWrite tool to create focused implementation plan
|
||||
- Break down the single task into micro-steps if needed
|
||||
- **CRITICAL**: Study all referenced files specified in task description
|
||||
- **PATTERN MATCHING**: Identify exact patterns to mirror from existing code
|
||||
- Plan implementation approach following established conventions
|
||||
|
||||
4. **Focused Implementation**
|
||||
- **BEFORE coding**: Read reference files to understand exact structure
|
||||
- **MIRROR PATTERNS**: Follow existing code patterns exactly
|
||||
- Implement only the specific task requirements (no scope creep)
|
||||
- Apply error handling patterns from reference implementations
|
||||
- Follow code organization and naming conventions from examples
|
||||
|
||||
5. **Acceptance Criteria Validation**
|
||||
- Execute each Given-When-Then scenario manually
|
||||
- Verify rule-based criteria checklist completion
|
||||
- Execute validation commands specified in task
|
||||
|
||||
6. **Quality Gates**
|
||||
- Run project-specific validation commands
|
||||
- Fix any linting, type-checking, or build errors
|
||||
- Ensure task-specific Definition of Done criteria met
|
||||
- Verify integration with existing systems
|
||||
|
||||
7. **Task Completion**
|
||||
- Mark task as completed in TodoWrite
|
||||
- Verify all acceptance criteria satisfied
|
||||
- Document any implementation notes or gotchas discovered
|
||||
- Report completion status with validation results
|
||||
|
||||
## Task Execution Best Practices
|
||||
|
||||
- Stay strictly within task boundaries - no additional features
|
||||
- Reference existing patterns extensively before writing new code
|
||||
- Test incrementally as you build each component
|
||||
- Follow the exact file structure specified in task document
|
||||
- Verify dependencies are satisfied before starting
|
||||
|
||||
Note: For complex tasks with multiple dependencies, ensure prerequisite tasks are completed first or coordinate with team members.
|
||||
158
claude/commands/generate-prp.md
Normal file
158
claude/commands/generate-prp.md
Normal file
@@ -0,0 +1,158 @@
|
||||
---
|
||||
description: Generate comprehensive PRP (Product Requirements & Plans) with thorough research and validation
|
||||
argument-hint: [feature description or user story]
|
||||
allowed-tools: TodoWrite, Read, Write, Glob, Grep, Bash, Task, WebSearch, WebFetch
|
||||
---
|
||||
|
||||
# Create PRP
|
||||
|
||||
## Feature file: $ARGUMENTS
|
||||
|
||||
Generate PRP (Product Requirements & Plans) through validated research and codebase analysis.
|
||||
|
||||
## Workflow Summary
|
||||
|
||||
Two-phase approach: validate completeness (Phase 1), then research (Phase 2).
|
||||
|
||||
**CRITICAL**: PRP must contain ALL context - research findings, documentation URLs, code examples. The executor agent sees only the final PRP document, not your research process.
|
||||
|
||||
## Research Process
|
||||
|
||||
**Phase 1: Initial Discovery & Task Validation** (Validate task completeness
|
||||
before deep research)
|
||||
|
||||
1. **Preflight Analysis** (Use subagent: `bp:preflight-prp`)
|
||||
- Quick scan of project structure for similar features/patterns
|
||||
- Analyze user's task description for business logic completeness
|
||||
- Identify gaps in user requirements and missing business logic details:
|
||||
- User flows and interaction patterns
|
||||
- Data requirements and relationships
|
||||
- Integration points with existing features
|
||||
- Edge cases and error scenarios
|
||||
- UI/UX expectations and constraints
|
||||
- **Language Guidelines for Questions**:
|
||||
- Ask clarification questions in the same language the user wrote the initial task
|
||||
- Wait for user responses and analyze thoroughly
|
||||
- Generate targeted clarification questions if gaps identified
|
||||
- Make proceed/clarify recommendation with clear reasoning
|
||||
|
||||
2. **Decision Gate**:
|
||||
- **IF** bp:preflight-prp recommends PROCEED → Continue to Phase 2
|
||||
- **IF** bp:preflight-prp identifies gaps → Stop and ask clarifying
|
||||
questions
|
||||
- **ONLY** continue to comprehensive research after user provides missing
|
||||
details
|
||||
- Use surface discovery findings to inform Phase 2 research focus
|
||||
|
||||
**Phase 2: Comprehensive Research Phase** (After task validation - Codebase
|
||||
first, then smart external research)
|
||||
|
||||
1. **Codebase Analysis** (Use subagent: `bp:codebase-research`)
|
||||
- Search for similar features/patterns in the codebase
|
||||
- Identify files to reference in PRP
|
||||
- Note existing conventions to follow
|
||||
- Check test patterns for validation approach
|
||||
- **CRITICAL**: Document what components/libraries/patterns already exist
|
||||
- **ASSESS**: Determine knowledge gaps that truly need external research
|
||||
|
||||
2. **Smart External Research Decision** (Evaluate AFTER codebase analysis)
|
||||
|
||||
**FIRST: Analyze codebase findings to determine if external research is
|
||||
needed:**
|
||||
|
||||
**SKIP External Research if:**
|
||||
- ✅ Similar components/patterns found in codebase (internal project
|
||||
components)
|
||||
- ✅ Clear implementation path from existing code
|
||||
- ✅ Standard CRUD/UI operations using existing patterns
|
||||
- ✅ Internal utility functions/services already available
|
||||
|
||||
**PROCEED with External Research ONLY if:**
|
||||
- ❌ New external npm/library integration needed (get current docs)
|
||||
- ❌ Existing external library usage but complex/undocumented features
|
||||
needed
|
||||
- ❌ Complex algorithm or pattern not in codebase
|
||||
- ❌ Security/performance considerations beyond current code
|
||||
- ❌ External API integration without existing examples
|
||||
- ❌ **No similar patterns/components found in codebase** (need external
|
||||
examples)
|
||||
|
||||
**If External Research is needed** (Use subagent: `bp:research-agent`):
|
||||
- Focus ONLY on missing knowledge gaps identified above
|
||||
- External npm/library documentation for NEW packages or complex features
|
||||
- Best practices for COMPLEX patterns not in codebase
|
||||
- Security considerations for NEW external integrations
|
||||
- **AVOID**: Researching internal project components (use codebase instead)
|
||||
- **Agent returns all findings directly in response context**
|
||||
|
||||
3. **Technical Clarification** (Use if needed after research completion)
|
||||
- **ONLY** for technical implementation details, not business logic
|
||||
- Specific patterns to mirror and where to find them?
|
||||
- Integration requirements and where to find them?
|
||||
- Which existing service to use and its file path?
|
||||
- Confirm if external research is truly needed for identified gaps
|
||||
|
||||
## Language Guidelines
|
||||
|
||||
### User Interaction Language
|
||||
- **Questions & Communication**: Ask all clarification questions in the same language the user wrote the initial task
|
||||
- **Analysis & Discussion**: Continue using the user's language throughout the discovery and research phases
|
||||
|
||||
### PRP Document Language
|
||||
- **Final Document**: Always write the PRP document in English for consistency and international team compatibility
|
||||
- **User Response Translation**: When incorporating user responses into the PRP, translate them to English while preserving the original meaning
|
||||
- **Code Examples**: Always use English comments and variable names in technical examples
|
||||
- **Technical Terms**: Use standard English technical terminology in the final document
|
||||
|
||||
## PRP Generation
|
||||
|
||||
**IMPORTANT**: Read and follow the template structure from `docs/templates/prp_document_template.md` exactly.
|
||||
|
||||
If template doesn't exist, tell user to run `/bp:init` first to install templates.
|
||||
|
||||
**CRITICAL BEFORE WRITING**:
|
||||
1. Complete all research phases (Phase 1 and Phase 2)
|
||||
2. Gather ALL context from codebase analysis
|
||||
3. Document validation commands from project config files
|
||||
4. THEN write the PRP following the template structure
|
||||
|
||||
## Output
|
||||
|
||||
Save as: `docs/prps/{feature-name}.md`
|
||||
|
||||
## Quality Checklist
|
||||
|
||||
- [ ] All necessary context included
|
||||
- [ ] Validation gates are executable by AI
|
||||
- [ ] References existing patterns
|
||||
- [ ] Clear implementation path
|
||||
- [ ] Error handling documented
|
||||
|
||||
Score the PRP on a scale of 1-10 (confidence level to succeed in one-pass
|
||||
implementation using claude codes)
|
||||
|
||||
## Task Breakdown Generation
|
||||
|
||||
**Final Step: Generate Implementation Tasks**
|
||||
|
||||
After completing the PRP document, automatically generate a detailed task breakdown:
|
||||
|
||||
1. **Task Decomposition** (Use subagent: `bp:team-lead-task-breakdown`)
|
||||
- Analyze the completed PRP document
|
||||
- Break down the implementation into manageable development tasks
|
||||
- Apply work breakdown structure (WBS) principles
|
||||
- Create appropriately-sized tasks for team capacity
|
||||
- Define clear dependencies and critical path
|
||||
- Generate acceptance criteria using Given-When-Then format
|
||||
- Save task breakdown to `docs/tasks/{feature-name}.md`
|
||||
|
||||
2. **Integration with PRP**
|
||||
- Reference the task breakdown document in the PRP
|
||||
- Update PRP document to include link to `docs/tasks/{feature-name}.md`
|
||||
- Ensure alignment between PRP requirements and task definitions
|
||||
- Provide clear handoff to development team
|
||||
|
||||
This ensures the PRP includes both comprehensive requirements AND actionable implementation tasks ready for development sprints.
|
||||
|
||||
Remember: The goal is one-pass implementation success through comprehensive
|
||||
context AND clear task decomposition.
|
||||
59
claude/commands/init.md
Normal file
59
claude/commands/init.md
Normal file
@@ -0,0 +1,59 @@
|
||||
---
|
||||
description: Initialize СС Blueprint Toolkit - copy actual documentation templates to your project
|
||||
allowed-tools: Bash, Read, Write
|
||||
---
|
||||
|
||||
# Initialize Blueprint Toolkit
|
||||
|
||||
Copy PRP templates and documentation from the Blueprint Toolkit to your current project.
|
||||
|
||||
## Installation Steps
|
||||
|
||||
Execute the following steps to set up the toolkit in your project:
|
||||
|
||||
### 1. Clone the toolkit repository
|
||||
```bash
|
||||
git clone https://github.com/croffasia/cc-blueprint-toolkit.git /tmp/cc-blueprint-toolkit-temp
|
||||
```
|
||||
|
||||
### 2. Create documentation directories
|
||||
```bash
|
||||
mkdir -p docs/templates docs/prps docs/tasks
|
||||
```
|
||||
|
||||
### 3. Copy templates to project
|
||||
```bash
|
||||
cp -r /tmp/cc-blueprint-toolkit-temp/docs/templates/* docs/templates/ && rm -rf /tmp/cc-blueprint-toolkit-temp
|
||||
```
|
||||
|
||||
## Verification
|
||||
|
||||
After installation, verify the following files exist:
|
||||
- `docs/templates/prp_document_template.md`
|
||||
- `docs/templates/technical-task-template.md`
|
||||
- `docs/templates/brainstorming_session_template.md`
|
||||
|
||||
## Success Message
|
||||
|
||||
Display to user:
|
||||
```
|
||||
✅ Blueprint Toolkit initialized successfully!
|
||||
|
||||
📁 Templates installed:
|
||||
→ docs/templates/prp_document_template.md
|
||||
→ docs/templates/technical-task-template.md
|
||||
→ docs/templates/brainstorming_session_template.md
|
||||
|
||||
📂 Directories created:
|
||||
→ docs/prps/ (for generated PRPs)
|
||||
→ docs/tasks/ (for task breakdowns)
|
||||
|
||||
🚀 Ready to use:
|
||||
/brainstorm - Start feature planning session
|
||||
/prp:generate - Create implementation blueprint
|
||||
/prp:execute - Execute PRP directly (simple features)
|
||||
/task:execute - Execute task breakdown (complex features)
|
||||
|
||||
💡 Tip: Start with /brainstorm to explore your feature ideas,
|
||||
then use /prp:generate to create a detailed implementation plan.
|
||||
```
|
||||
Reference in New Issue
Block a user