Initial commit
This commit is contained in:
Zhongwei Li
150
commands/code-review.md
Normal file
150
commands/code-review.md
Normal file
@@ -0,0 +1,150 @@
|
||||
---
|
||||
name: code-review
|
||||
description: Get comprehensive code review from relevant specialists
|
||||
tools: Read, Glob, Grep, Bash, TodoWrite, Task
|
||||
model: inherit
|
||||
arguments:
|
||||
- name: target
|
||||
description: File path, directory, or git diff to review
|
||||
required: false
|
||||
---
|
||||
|
||||
# Code Review
|
||||
|
||||
Get a comprehensive code review from multiple specialist perspectives.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Identify Code to Review
|
||||
|
||||
Determine what to review based on `$ARGUMENTS.target`:
|
||||
|
||||
1. **If file path provided**: Review that specific file
|
||||
2. **If directory provided**: Review recent changes in that directory
|
||||
3. **If no argument**: Review staged or recent uncommitted changes
|
||||
|
||||
```bash
|
||||
# Check for staged changes
|
||||
git diff --staged --name-only
|
||||
|
||||
# Check for unstaged changes
|
||||
git diff --name-only
|
||||
|
||||
# Recent commits
|
||||
git log --oneline -5
|
||||
```
|
||||
|
||||
### Step 2: Analyze File Types
|
||||
|
||||
Categorize the files being reviewed:
|
||||
- **Frontend** (`.tsx`, `.jsx`, `.css`, `.scss`): Include Frontend Engineer
|
||||
- **Backend** (`.ts` API routes, `.py`, database files): Include Backend Engineer
|
||||
- **Both**: Include Full-Stack Engineer
|
||||
- **All changes**: Include Security Engineer and QA Engineer
|
||||
|
||||
### Step 3: Full-Stack Engineer Review
|
||||
|
||||
Invoke `full-stack-engineer` agent for:
|
||||
|
||||
- **Correctness**: Does the code do what it's supposed to?
|
||||
- **Maintainability**: Is it readable and well-structured?
|
||||
- **Type Safety**: Are types correct and complete?
|
||||
- **Error Handling**: Are errors handled gracefully?
|
||||
- **Testing**: Is test coverage adequate?
|
||||
|
||||
### Step 4: Domain-Specific Review
|
||||
|
||||
Based on file types, invoke appropriate specialist:
|
||||
|
||||
**For Frontend Files** - Invoke `frontend-engineer`:
|
||||
- Component structure and composition
|
||||
- State management approach
|
||||
- Performance (re-renders, bundle size)
|
||||
- Accessibility
|
||||
- Responsive design
|
||||
|
||||
**For Backend Files** - Invoke `backend-engineer`:
|
||||
- API design and contracts
|
||||
- Database queries and performance
|
||||
- Input validation
|
||||
- Error responses
|
||||
- Logging
|
||||
|
||||
### Step 5: Security Engineer Review
|
||||
|
||||
Invoke `security-engineer` agent for:
|
||||
|
||||
- Authentication/authorization checks
|
||||
- Input validation and sanitization
|
||||
- Secrets or sensitive data exposure
|
||||
- SQL injection or XSS vulnerabilities
|
||||
- Security header considerations
|
||||
|
||||
### Step 6: QA Engineer Review
|
||||
|
||||
Invoke `qa-engineer` agent for:
|
||||
|
||||
- Test coverage suggestions
|
||||
- Edge cases to consider
|
||||
- Integration test recommendations
|
||||
- Manual testing scenarios
|
||||
- Quality gate compliance
|
||||
|
||||
### Step 7: Compile Review
|
||||
|
||||
Create a consolidated review:
|
||||
|
||||
```markdown
|
||||
## Code Review Summary
|
||||
|
||||
**Files Reviewed**: [count]
|
||||
**Overall Assessment**: [Good / Needs Work / Blocker]
|
||||
|
||||
---
|
||||
|
||||
### Critical Issues (Must Fix)
|
||||
| Issue | Location | Severity |
|
||||
|-------|----------|----------|
|
||||
| [Issue] | `file:line` | Critical |
|
||||
|
||||
### Suggestions (Should Fix)
|
||||
| Suggestion | Location | Impact |
|
||||
|------------|----------|--------|
|
||||
| [Suggestion] | `file:line` | High/Medium/Low |
|
||||
|
||||
### Minor Comments (Nice to Have)
|
||||
- [Comment] at `file:line`
|
||||
|
||||
---
|
||||
|
||||
### Full-Stack Engineer Notes
|
||||
[Summary]
|
||||
|
||||
### [Frontend/Backend] Engineer Notes
|
||||
[Summary]
|
||||
|
||||
### Security Review
|
||||
- [ ] No hardcoded secrets
|
||||
- [ ] Input validation present
|
||||
- [ ] Auth checks in place
|
||||
- [ ] XSS prevention verified
|
||||
|
||||
### QA Notes
|
||||
**Recommended Tests:**
|
||||
- [ ] [Test scenario]
|
||||
- [ ] [Test scenario]
|
||||
|
||||
---
|
||||
|
||||
### Approval Status
|
||||
- [ ] Full-Stack: Approved / Changes Requested
|
||||
- [ ] Security: Approved / Changes Requested
|
||||
- [ ] QA: Approved / Changes Requested
|
||||
```
|
||||
|
||||
## Severity Levels
|
||||
|
||||
- **Critical**: Blocks merge - security vulnerability, data loss risk, broken functionality
|
||||
- **High**: Should fix before merge - bugs, missing error handling, performance issues
|
||||
- **Medium**: Fix soon - code quality, maintainability concerns
|
||||
- **Low**: Nice to have - style suggestions, minor improvements
|
||||
183
commands/debug-assist.md
Normal file
183
commands/debug-assist.md
Normal file
@@ -0,0 +1,183 @@
|
||||
---
|
||||
name: debug-assist
|
||||
description: Collaborative debugging with relevant specialists
|
||||
tools: Read, Glob, Grep, Bash, TodoWrite, Task
|
||||
model: inherit
|
||||
arguments:
|
||||
- name: issue
|
||||
description: Description of the issue to debug
|
||||
required: true
|
||||
---
|
||||
|
||||
# Debug Assist
|
||||
|
||||
Get collaborative debugging help from relevant team specialists.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Capture Issue Details
|
||||
|
||||
Use `$ARGUMENTS.issue` and gather more context:
|
||||
|
||||
```
|
||||
To help debug, please provide:
|
||||
1. What's the expected behavior?
|
||||
2. What's actually happening?
|
||||
3. Steps to reproduce
|
||||
4. Any error messages?
|
||||
5. When did it start? Any recent changes?
|
||||
```
|
||||
|
||||
### Step 2: Classify the Issue
|
||||
|
||||
Determine issue type to route to appropriate agents:
|
||||
|
||||
- **Frontend Issue** (UI bugs, rendering, state): Frontend Engineer
|
||||
- **Backend Issue** (API errors, data issues): Backend Engineer
|
||||
- **Infrastructure Issue** (deployment, performance, timeouts): DevOps Engineer
|
||||
- **Full Stack** (unclear origin): Full-Stack Engineer first
|
||||
- **All Issues**: Customer Support for user perspective
|
||||
|
||||
### Step 3: Full-Stack Engineer Investigation
|
||||
|
||||
Invoke `full-stack-engineer` agent for initial investigation:
|
||||
|
||||
1. **Reproduce the Issue**
|
||||
- Verify steps to reproduce
|
||||
- Identify consistent vs intermittent behavior
|
||||
|
||||
2. **Narrow Down the Layer**
|
||||
- Frontend vs Backend vs Infrastructure
|
||||
- Check network requests, console errors, logs
|
||||
|
||||
3. **Initial Hypotheses**
|
||||
- Most likely causes
|
||||
- Quick checks to validate/invalidate
|
||||
|
||||
4. **Suggested Investigation Path**
|
||||
- What to check first
|
||||
- What logs to examine
|
||||
- What tests to run
|
||||
|
||||
### Step 4: Domain-Specific Investigation
|
||||
|
||||
Based on classification, invoke appropriate specialist:
|
||||
|
||||
**Frontend Issue** - Invoke `frontend-engineer`:
|
||||
- Browser console errors
|
||||
- React component state
|
||||
- Network request/response
|
||||
- CSS/rendering issues
|
||||
- Hydration problems
|
||||
|
||||
**Backend Issue** - Invoke `backend-engineer`:
|
||||
- Server logs
|
||||
- Database queries
|
||||
- API response codes
|
||||
- Authentication/authorization
|
||||
- Third-party service status
|
||||
|
||||
**Infrastructure Issue** - Invoke `devops-engineer`:
|
||||
- Deployment logs
|
||||
- Infrastructure health
|
||||
- Resource utilization
|
||||
- Recent deployments
|
||||
- External service status
|
||||
|
||||
### Step 5: Customer Support Perspective
|
||||
|
||||
Invoke `customer-support` agent:
|
||||
- User impact assessment
|
||||
- Similar reports from other users?
|
||||
- Workarounds available?
|
||||
- Communication needs
|
||||
|
||||
### Step 6: Compile Debugging Plan
|
||||
|
||||
Create a structured debugging plan:
|
||||
|
||||
```markdown
|
||||
## Debug Plan: [Issue Title]
|
||||
|
||||
### Issue Summary
|
||||
- **Reported**: [Description]
|
||||
- **Expected**: [Behavior]
|
||||
- **Actual**: [Behavior]
|
||||
- **Severity**: Critical / High / Medium / Low
|
||||
|
||||
### Initial Assessment
|
||||
|
||||
**Most Likely Layer**: [Frontend / Backend / Infrastructure]
|
||||
|
||||
**Primary Hypotheses**:
|
||||
1. [Hypothesis 1] - [Confidence: High/Medium/Low]
|
||||
2. [Hypothesis 2] - [Confidence: High/Medium/Low]
|
||||
3. [Hypothesis 3] - [Confidence: High/Medium/Low]
|
||||
|
||||
---
|
||||
|
||||
### Investigation Steps
|
||||
|
||||
#### Phase 1: Quick Checks
|
||||
- [ ] [Check 1] - tests hypothesis [X]
|
||||
- [ ] [Check 2] - tests hypothesis [Y]
|
||||
|
||||
#### Phase 2: Deep Investigation
|
||||
- [ ] [Investigation 1]
|
||||
- [ ] [Investigation 2]
|
||||
|
||||
#### Phase 3: If Above Fails
|
||||
- [ ] [Fallback investigation]
|
||||
|
||||
---
|
||||
|
||||
### Logs to Check
|
||||
- [ ] [Log location 1]
|
||||
- [ ] [Log location 2]
|
||||
|
||||
### Commands to Run
|
||||
```bash
|
||||
# [Description]
|
||||
[command]
|
||||
|
||||
# [Description]
|
||||
[command]
|
||||
```
|
||||
|
||||
### Files to Examine
|
||||
- `[file path]` - [reason]
|
||||
- `[file path]` - [reason]
|
||||
|
||||
---
|
||||
|
||||
### User Impact
|
||||
- **Users Affected**: [Estimate]
|
||||
- **Workaround Available**: [Yes/No - details]
|
||||
- **Communication Needed**: [Yes/No]
|
||||
|
||||
---
|
||||
|
||||
### Resolution Tracking
|
||||
|
||||
| Hypothesis | Status | Finding |
|
||||
|------------|--------|---------|
|
||||
| [Hypothesis 1] | 🔍 Investigating | |
|
||||
| [Hypothesis 2] | ⏳ Pending | |
|
||||
|
||||
### Root Cause
|
||||
[To be filled after investigation]
|
||||
|
||||
### Fix
|
||||
[To be filled after resolution]
|
||||
|
||||
### Prevention
|
||||
[How to prevent this in the future]
|
||||
```
|
||||
|
||||
## Tips
|
||||
|
||||
- Start with the simplest hypothesis
|
||||
- Check for recent changes that correlate with issue start
|
||||
- Look at logs with timestamps around the issue
|
||||
- Don't assume - verify each step
|
||||
- Document findings even if negative
|
||||
185
commands/feature-kickoff.md
Normal file
185
commands/feature-kickoff.md
Normal file
@@ -0,0 +1,185 @@
|
||||
---
|
||||
name: feature-kickoff
|
||||
description: Kick off a new feature with full team input
|
||||
tools: Read, Write, Glob, Grep, TodoWrite, AskUserQuestion, Task
|
||||
model: inherit
|
||||
arguments:
|
||||
- name: feature
|
||||
description: Description of the feature to kick off
|
||||
required: true
|
||||
---
|
||||
|
||||
# Feature Kickoff
|
||||
|
||||
Kick off a new feature with input from multiple team perspectives to create a comprehensive feature brief.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Capture Feature Description
|
||||
|
||||
Use the provided `$ARGUMENTS.feature` or ask the user:
|
||||
|
||||
```
|
||||
What feature would you like to kick off? Please describe:
|
||||
- What it should do
|
||||
- Who it's for
|
||||
- Why it's needed
|
||||
```
|
||||
|
||||
### Step 2: Product Manager Phase
|
||||
|
||||
Invoke the `product-manager` agent to create:
|
||||
|
||||
1. **User Story**
|
||||
- As a [user type]
|
||||
- I want to [action]
|
||||
- So that [benefit]
|
||||
|
||||
2. **Acceptance Criteria**
|
||||
- [ ] Criteria 1
|
||||
- [ ] Criteria 2
|
||||
- [ ] Criteria 3
|
||||
|
||||
3. **Success Metrics**
|
||||
- Primary metric
|
||||
- Secondary metrics
|
||||
|
||||
4. **Scope Definition**
|
||||
- In scope
|
||||
- Out of scope
|
||||
|
||||
### Step 3: UI/UX Designer Phase
|
||||
|
||||
Invoke the `ui-ux-designer` agent to provide:
|
||||
|
||||
1. **User Flow**
|
||||
- Entry points
|
||||
- Key interactions
|
||||
- Exit points
|
||||
|
||||
2. **UX Considerations**
|
||||
- Accessibility requirements
|
||||
- Mobile considerations
|
||||
- Edge cases (empty states, errors)
|
||||
|
||||
3. **Design Requirements**
|
||||
- New components needed
|
||||
- Existing components to reuse
|
||||
- Animation/interaction notes
|
||||
|
||||
### Step 4: Full-Stack Engineer Phase
|
||||
|
||||
Invoke the `full-stack-engineer` agent to provide:
|
||||
|
||||
1. **Technical Approach**
|
||||
- High-level architecture
|
||||
- Data model changes
|
||||
- API design
|
||||
|
||||
2. **Complexity Estimate**
|
||||
- T-shirt size (S/M/L/XL)
|
||||
- Key complexity drivers
|
||||
- Suggested breakdown
|
||||
|
||||
3. **Technical Considerations**
|
||||
- Dependencies
|
||||
- Performance implications
|
||||
- Security considerations
|
||||
- Testing strategy
|
||||
|
||||
### Step 5: Growth Marketer Phase
|
||||
|
||||
Invoke the `growth-marketer` agent to provide:
|
||||
|
||||
1. **Analytics Requirements**
|
||||
- Events to track
|
||||
- Funnel definition
|
||||
- Success metrics setup
|
||||
|
||||
2. **Growth Implications**
|
||||
- SEO considerations
|
||||
- Conversion opportunities
|
||||
- A/B testing opportunities
|
||||
|
||||
### Step 6: Compile Feature Brief
|
||||
|
||||
Create a comprehensive feature brief:
|
||||
|
||||
```markdown
|
||||
# Feature Brief: [Feature Name]
|
||||
|
||||
## Overview
|
||||
[Brief description]
|
||||
|
||||
## User Story
|
||||
As a [user type], I want to [action], so that [benefit].
|
||||
|
||||
## Acceptance Criteria
|
||||
- [ ] [Criterion 1]
|
||||
- [ ] [Criterion 2]
|
||||
- [ ] [Criterion 3]
|
||||
|
||||
## Success Metrics
|
||||
- **Primary**: [Metric]
|
||||
- **Secondary**: [Metric]
|
||||
|
||||
## Scope
|
||||
### In Scope
|
||||
- [Item]
|
||||
|
||||
### Out of Scope
|
||||
- [Item]
|
||||
|
||||
---
|
||||
|
||||
## User Flow
|
||||
[Flow description or diagram]
|
||||
|
||||
## UX Requirements
|
||||
- [Requirement]
|
||||
|
||||
## Design Notes
|
||||
- [Note]
|
||||
|
||||
---
|
||||
|
||||
## Technical Approach
|
||||
[Architecture description]
|
||||
|
||||
## Complexity: [S/M/L/XL]
|
||||
**Drivers:**
|
||||
- [Driver]
|
||||
|
||||
## Suggested Breakdown
|
||||
1. [Task 1] - [Size]
|
||||
2. [Task 2] - [Size]
|
||||
|
||||
## Technical Considerations
|
||||
- **Dependencies**: [List]
|
||||
- **Performance**: [Notes]
|
||||
- **Security**: [Notes]
|
||||
|
||||
---
|
||||
|
||||
## Analytics Plan
|
||||
### Events
|
||||
- `[event_name]` - [when triggered]
|
||||
|
||||
### Funnel
|
||||
1. [Step]
|
||||
2. [Step]
|
||||
|
||||
---
|
||||
|
||||
## Open Questions
|
||||
- [ ] [Question 1]
|
||||
- [ ] [Question 2]
|
||||
|
||||
## Next Steps
|
||||
1. [Step]
|
||||
2. [Step]
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
Save the feature brief to a file or display inline based on user preference.
|
||||
251
commands/hire-for.md
Normal file
251
commands/hire-for.md
Normal file
@@ -0,0 +1,251 @@
|
||||
---
|
||||
name: hire-for
|
||||
description: Get job description and interview plan for a role
|
||||
tools: Read, Write, Glob, Grep, TodoWrite, AskUserQuestion, Task
|
||||
model: inherit
|
||||
arguments:
|
||||
- name: role
|
||||
description: The role to create hiring materials for
|
||||
required: true
|
||||
---
|
||||
|
||||
# Hire For
|
||||
|
||||
Generate a comprehensive job description and interview plan for a role.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Identify Role
|
||||
|
||||
Use `$ARGUMENTS.role` to determine the role. Map to team expertise:
|
||||
|
||||
- **Engineering roles**: Full-Stack, Frontend, Backend, DevOps, Security, QA
|
||||
- **Product roles**: Product Manager
|
||||
- **Design roles**: UI/UX Designer
|
||||
- **Growth roles**: Growth Marketer, Content Creator, Data Analyst
|
||||
- **Support roles**: Customer Support
|
||||
|
||||
### Step 2: Product Manager Input
|
||||
|
||||
Invoke `product-manager` agent to define:
|
||||
|
||||
1. **Role Requirements**
|
||||
- Why we're hiring
|
||||
- Team structure and reporting
|
||||
- Key responsibilities
|
||||
- Success criteria (30/60/90 day goals)
|
||||
|
||||
2. **Candidate Profile**
|
||||
- Must-have qualifications
|
||||
- Nice-to-have qualifications
|
||||
- Culture fit indicators
|
||||
|
||||
### Step 3: Specialist Input
|
||||
|
||||
Invoke the relevant specialist agent for the role:
|
||||
|
||||
**Technical Roles** - Invoke matching engineer agent:
|
||||
- Required technical skills
|
||||
- Tech stack proficiency expectations
|
||||
- Technical interview questions
|
||||
- Take-home assignment ideas
|
||||
|
||||
**Product/Design Roles** - Invoke `product-manager` or `ui-ux-designer`:
|
||||
- Portfolio expectations
|
||||
- Case study prompts
|
||||
- Design challenge ideas
|
||||
|
||||
**Growth Roles** - Invoke `growth-marketer` or `data-analyst`:
|
||||
- Analytics proficiency requirements
|
||||
- Campaign experience expectations
|
||||
- Data analysis exercise ideas
|
||||
|
||||
### Step 4: Generate Job Description
|
||||
|
||||
Create the job posting:
|
||||
|
||||
```markdown
|
||||
# [Role Title]
|
||||
|
||||
## About Us
|
||||
[Company description - to be filled by user]
|
||||
|
||||
## About the Role
|
||||
[Role context and why it matters]
|
||||
|
||||
## What You'll Do
|
||||
- [Responsibility 1]
|
||||
- [Responsibility 2]
|
||||
- [Responsibility 3]
|
||||
- [Responsibility 4]
|
||||
- [Responsibility 5]
|
||||
|
||||
## What You'll Bring
|
||||
|
||||
### Must Have
|
||||
- [Requirement 1]
|
||||
- [Requirement 2]
|
||||
- [Requirement 3]
|
||||
|
||||
### Nice to Have
|
||||
- [Nice-to-have 1]
|
||||
- [Nice-to-have 2]
|
||||
|
||||
## Tech Stack / Tools
|
||||
- [Tool/Tech 1]
|
||||
- [Tool/Tech 2]
|
||||
|
||||
## What We Offer
|
||||
[Benefits - to be filled by user]
|
||||
|
||||
## Interview Process
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
4. [Step 4]
|
||||
|
||||
---
|
||||
|
||||
*[Company name] is an equal opportunity employer.*
|
||||
```
|
||||
|
||||
### Step 5: Create Interview Plan
|
||||
|
||||
Generate the interview structure:
|
||||
|
||||
```markdown
|
||||
# Interview Plan: [Role Title]
|
||||
|
||||
## Overview
|
||||
- **Total Process Length**: [X] weeks
|
||||
- **Interview Stages**: [X]
|
||||
- **Decision Timeline**: [X] days after final
|
||||
|
||||
---
|
||||
|
||||
## Stage 1: Initial Screen (30 min)
|
||||
|
||||
**Interviewer**: Recruiter / Hiring Manager
|
||||
|
||||
**Goals**:
|
||||
- Verify basic qualifications
|
||||
- Assess communication skills
|
||||
- Explain role and company
|
||||
- Gauge interest and availability
|
||||
|
||||
**Questions**:
|
||||
1. Tell me about your background and what brings you here
|
||||
2. [Role-specific question]
|
||||
3. What are you looking for in your next role?
|
||||
4. [Logistics: timeline, compensation expectations]
|
||||
|
||||
**Scorecard**:
|
||||
- [ ] Communication: Clear and articulate
|
||||
- [ ] Relevant experience: Matches requirements
|
||||
- [ ] Interest level: Genuinely interested
|
||||
- [ ] Cultural fit indicators: Positive
|
||||
|
||||
---
|
||||
|
||||
## Stage 2: Technical / Skills Interview (60 min)
|
||||
|
||||
**Interviewer**: [Relevant team member]
|
||||
|
||||
**Goals**:
|
||||
- Assess core technical/functional skills
|
||||
- Understand problem-solving approach
|
||||
- Evaluate depth of experience
|
||||
|
||||
**Questions**:
|
||||
1. [Technical question 1]
|
||||
2. [Technical question 2]
|
||||
3. [Scenario-based question]
|
||||
|
||||
**Exercise** (if applicable):
|
||||
[Description of live coding, design exercise, or case study]
|
||||
|
||||
**Scorecard**:
|
||||
- [ ] Technical proficiency: [1-5]
|
||||
- [ ] Problem-solving: [1-5]
|
||||
- [ ] Communication of technical concepts: [1-5]
|
||||
|
||||
---
|
||||
|
||||
## Stage 3: Take-Home Assignment (Optional)
|
||||
|
||||
**Time limit**: [X] hours
|
||||
|
||||
**Assignment**:
|
||||
[Description of take-home project]
|
||||
|
||||
**Evaluation Criteria**:
|
||||
- [ ] Functionality: Does it work?
|
||||
- [ ] Code quality: Is it well-structured?
|
||||
- [ ] Communication: Is it documented?
|
||||
|
||||
---
|
||||
|
||||
## Stage 4: Team Interview (45 min each)
|
||||
|
||||
**Interviewers**: [2-3 team members]
|
||||
|
||||
**Goals**:
|
||||
- Assess collaboration style
|
||||
- Evaluate cultural fit
|
||||
- Different perspectives on candidate
|
||||
|
||||
**Focus Areas**:
|
||||
- Interviewer 1: [Focus area]
|
||||
- Interviewer 2: [Focus area]
|
||||
- Interviewer 3: [Focus area]
|
||||
|
||||
---
|
||||
|
||||
## Stage 5: Final Interview (45 min)
|
||||
|
||||
**Interviewer**: [Senior leader / Founder]
|
||||
|
||||
**Goals**:
|
||||
- Final culture assessment
|
||||
- Answer candidate questions
|
||||
- Sell the opportunity
|
||||
|
||||
**Questions**:
|
||||
1. [Values-based question]
|
||||
2. [Growth/ambition question]
|
||||
3. What questions do you have for me?
|
||||
|
||||
---
|
||||
|
||||
## Evaluation & Decision
|
||||
|
||||
### Skills Matrix
|
||||
|
||||
| Skill | Must Have | Candidate Score |
|
||||
|-------|-----------|-----------------|
|
||||
| [Skill 1] | Yes | |
|
||||
| [Skill 2] | Yes | |
|
||||
| [Skill 3] | Nice | |
|
||||
|
||||
### Overall Assessment
|
||||
|
||||
- **Technical/Functional**: [1-5]
|
||||
- **Communication**: [1-5]
|
||||
- **Culture Fit**: [1-5]
|
||||
- **Growth Potential**: [1-5]
|
||||
|
||||
### Recommendation
|
||||
[ ] Strong Hire
|
||||
[ ] Hire
|
||||
[ ] No Hire
|
||||
[ ] Strong No Hire
|
||||
|
||||
### Notes
|
||||
[Summary of key findings and concerns]
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
- Job description ready to post
|
||||
- Complete interview plan
|
||||
- Scorecard templates for each stage
|
||||
203
commands/ship-checklist.md
Normal file
203
commands/ship-checklist.md
Normal file
@@ -0,0 +1,203 @@
|
||||
---
|
||||
name: ship-checklist
|
||||
description: Pre-launch checklist from all team perspectives
|
||||
tools: Read, Glob, Grep, Bash, TodoWrite, Task
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# Ship Checklist
|
||||
|
||||
Generate a comprehensive pre-launch checklist with input from all team perspectives.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Gather Context
|
||||
|
||||
Understand what's being shipped:
|
||||
|
||||
```
|
||||
What are you preparing to ship?
|
||||
- Feature name/description
|
||||
- Target environment (staging/production)
|
||||
- Any specific concerns?
|
||||
```
|
||||
|
||||
Also check:
|
||||
- Recent commits and changes
|
||||
- PR description if available
|
||||
- Related issues or tickets
|
||||
|
||||
### Step 2: DevOps Engineer Checklist
|
||||
|
||||
Invoke `devops-engineer` agent for deployment readiness:
|
||||
|
||||
```markdown
|
||||
### Deployment Readiness
|
||||
- [ ] CI/CD pipeline is green
|
||||
- [ ] Environment variables configured
|
||||
- [ ] Database migrations ready (if applicable)
|
||||
- [ ] Rollback plan documented
|
||||
- [ ] Deployment runbook updated
|
||||
|
||||
### Infrastructure
|
||||
- [ ] Resource scaling appropriate
|
||||
- [ ] Monitoring dashboards ready
|
||||
- [ ] Alerts configured
|
||||
- [ ] Load testing completed (if high traffic expected)
|
||||
```
|
||||
|
||||
### Step 3: QA Engineer Checklist
|
||||
|
||||
Invoke `qa-engineer` agent for testing readiness:
|
||||
|
||||
```markdown
|
||||
### Testing Status
|
||||
- [ ] Unit tests passing
|
||||
- [ ] Integration tests passing
|
||||
- [ ] E2E tests passing
|
||||
- [ ] Manual smoke test completed
|
||||
- [ ] Regression suite green
|
||||
|
||||
### Test Coverage
|
||||
- [ ] Happy path tested
|
||||
- [ ] Error cases tested
|
||||
- [ ] Edge cases documented
|
||||
- [ ] Performance acceptable
|
||||
```
|
||||
|
||||
### Step 4: Security Engineer Checklist
|
||||
|
||||
Invoke `security-engineer` agent for security review:
|
||||
|
||||
```markdown
|
||||
### Security Review
|
||||
- [ ] No secrets in code
|
||||
- [ ] Authentication verified
|
||||
- [ ] Authorization checked
|
||||
- [ ] Input validation complete
|
||||
- [ ] Security headers configured
|
||||
- [ ] Dependency scan clean
|
||||
```
|
||||
|
||||
### Step 5: Growth Marketer Checklist
|
||||
|
||||
Invoke `growth-marketer` agent for analytics and tracking:
|
||||
|
||||
```markdown
|
||||
### Analytics & Tracking
|
||||
- [ ] Events implemented and tested
|
||||
- [ ] Funnel tracking verified
|
||||
- [ ] Success metrics dashboard ready
|
||||
- [ ] A/B test configured (if applicable)
|
||||
- [ ] SEO checked (titles, meta, indexability)
|
||||
```
|
||||
|
||||
### Step 6: Customer Support Checklist
|
||||
|
||||
Invoke `customer-support` agent for documentation readiness:
|
||||
|
||||
```markdown
|
||||
### Documentation & Support
|
||||
- [ ] User-facing docs updated
|
||||
- [ ] FAQ prepared for new features
|
||||
- [ ] Support team briefed
|
||||
- [ ] Known issues documented
|
||||
- [ ] Rollout communication drafted
|
||||
```
|
||||
|
||||
### Step 7: Product Manager Checklist
|
||||
|
||||
Invoke `product-manager` agent for launch readiness:
|
||||
|
||||
```markdown
|
||||
### Launch Readiness
|
||||
- [ ] Acceptance criteria met
|
||||
- [ ] Stakeholders notified
|
||||
- [ ] Release notes prepared
|
||||
- [ ] Success metrics baseline captured
|
||||
- [ ] Post-launch review scheduled
|
||||
```
|
||||
|
||||
### Step 8: Compile Ship Checklist
|
||||
|
||||
Create the final checklist:
|
||||
|
||||
```markdown
|
||||
# Ship Checklist: [Feature/Release Name]
|
||||
|
||||
**Target Date**: [Date]
|
||||
**Environment**: [Staging/Production]
|
||||
**Owner**: [Name]
|
||||
|
||||
---
|
||||
|
||||
## Go/No-Go Summary
|
||||
|
||||
| Area | Status | Owner |
|
||||
|------|--------|-------|
|
||||
| Deployment | ⚪ | DevOps |
|
||||
| Testing | ⚪ | QA |
|
||||
| Security | ⚪ | Security |
|
||||
| Analytics | ⚪ | Growth |
|
||||
| Documentation | ⚪ | Support |
|
||||
| Product | ⚪ | PM |
|
||||
|
||||
**Legend**: 🟢 Ready | 🟡 Partial | 🔴 Blocked | ⚪ Not Started
|
||||
|
||||
---
|
||||
|
||||
## Detailed Checklists
|
||||
|
||||
### Deployment
|
||||
[DevOps checklist items]
|
||||
|
||||
### Testing
|
||||
[QA checklist items]
|
||||
|
||||
### Security
|
||||
[Security checklist items]
|
||||
|
||||
### Analytics
|
||||
[Growth checklist items]
|
||||
|
||||
### Documentation
|
||||
[Support checklist items]
|
||||
|
||||
### Product
|
||||
[PM checklist items]
|
||||
|
||||
---
|
||||
|
||||
## Known Issues / Risks
|
||||
- [Issue 1]: [Mitigation]
|
||||
- [Issue 2]: [Mitigation]
|
||||
|
||||
## Rollback Plan
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
|
||||
## Post-Launch Tasks
|
||||
- [ ] Monitor error rates for 24h
|
||||
- [ ] Check analytics data flowing
|
||||
- [ ] Review user feedback
|
||||
- [ ] Schedule post-mortem
|
||||
|
||||
---
|
||||
|
||||
## Approval
|
||||
|
||||
| Role | Name | Approved |
|
||||
|------|------|----------|
|
||||
| Engineering Lead | | [ ] |
|
||||
| Product Manager | | [ ] |
|
||||
| QA Lead | | [ ] |
|
||||
|
||||
**Ship Decision**: [ ] GO / [ ] NO-GO
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
- Display the checklist with current status
|
||||
- Highlight any blocking items
|
||||
- Offer to save as a file
|
||||
186
commands/team-consult.md
Normal file
186
commands/team-consult.md
Normal file
@@ -0,0 +1,186 @@
|
||||
---
|
||||
name: team-consult
|
||||
description: Consult with the full team on any topic - automatically routes to relevant agents
|
||||
tools: Read, Write, Glob, Grep, Bash, TodoWrite, AskUserQuestion, Task
|
||||
model: inherit
|
||||
arguments:
|
||||
- name: question
|
||||
description: The question or task to consult the team about
|
||||
required: true
|
||||
---
|
||||
|
||||
# Team Consult
|
||||
|
||||
Consult with your virtual webapp team on any topic. Questions are automatically routed to the most relevant specialists who provide their perspectives.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Analyze Input
|
||||
|
||||
Parse `$ARGUMENTS.question` to determine relevant agents. Look for:
|
||||
|
||||
**Technical Implementation Keywords**:
|
||||
- code, implement, build, develop, architecture, refactor → `full-stack-engineer`
|
||||
- frontend, react, component, CSS, UI → `frontend-engineer`
|
||||
- backend, API, database, server → `backend-engineer`
|
||||
- deploy, CI/CD, infrastructure → `devops-engineer`
|
||||
|
||||
**User Experience Keywords**:
|
||||
- design, UX, flow, accessibility, user → `ui-ux-designer`
|
||||
- requirements, story, prioritize, roadmap → `product-manager`
|
||||
|
||||
**Security/Quality Keywords**:
|
||||
- security, auth, vulnerability, OWASP → `security-engineer`
|
||||
- test, QA, bug, quality → `qa-engineer`
|
||||
|
||||
**Growth/Data Keywords**:
|
||||
- growth, marketing, SEO, conversion → `growth-marketer`
|
||||
- analytics, metrics, data, tracking → `data-analyst`
|
||||
|
||||
**Content/Support Keywords**:
|
||||
- content, copy, writing → `content-creator`
|
||||
- user feedback, support, documentation → `customer-support`
|
||||
|
||||
### Step 2: Check for @Mentions
|
||||
|
||||
If the user includes @mentions, prioritize those agents:
|
||||
- `@full-stack` → `full-stack-engineer`
|
||||
- `@frontend` → `frontend-engineer`
|
||||
- `@backend` → `backend-engineer`
|
||||
- `@devops` → `devops-engineer`
|
||||
- `@pm` or `@product` → `product-manager`
|
||||
- `@design` or `@ux` → `ui-ux-designer`
|
||||
- `@security` → `security-engineer`
|
||||
- `@qa` → `qa-engineer`
|
||||
- `@growth` → `growth-marketer`
|
||||
- `@data` → `data-analyst`
|
||||
- `@content` → `content-creator`
|
||||
- `@support` → `customer-support`
|
||||
|
||||
### Step 3: Select Agents (Max 4)
|
||||
|
||||
Choose 3-4 most relevant agents. Order by:
|
||||
1. Strategy/requirements first (PM, UX)
|
||||
2. Implementation second (Engineers)
|
||||
3. Support functions third (QA, Security, Growth)
|
||||
|
||||
Avoid including too many agents - that creates noise.
|
||||
|
||||
### Step 4: Invoke Agents
|
||||
|
||||
For each selected agent, use the Task tool to invoke them with:
|
||||
|
||||
```
|
||||
Context: [Original user question]
|
||||
|
||||
Provide your perspective as the [role] on this question. Focus on:
|
||||
- Key considerations from your domain
|
||||
- Recommendations
|
||||
- Potential concerns or risks
|
||||
- Questions that need answering
|
||||
|
||||
Keep your response concise (3-5 key points).
|
||||
```
|
||||
|
||||
### Step 5: Synthesize Responses
|
||||
|
||||
Compile agent responses into a structured summary:
|
||||
|
||||
```markdown
|
||||
## Team Consultation: [Topic]
|
||||
|
||||
### Consulted Specialists
|
||||
- [Agent 1] - [Role]
|
||||
- [Agent 2] - [Role]
|
||||
- [Agent 3] - [Role]
|
||||
|
||||
---
|
||||
|
||||
### Consensus Points
|
||||
Areas where the team agrees:
|
||||
- [Point 1]
|
||||
- [Point 2]
|
||||
- [Point 3]
|
||||
|
||||
### Key Perspectives
|
||||
|
||||
#### [Agent 1 Role]
|
||||
[Summary of their input]
|
||||
|
||||
**Recommendations**:
|
||||
- [Recommendation 1]
|
||||
- [Recommendation 2]
|
||||
|
||||
#### [Agent 2 Role]
|
||||
[Summary of their input]
|
||||
|
||||
**Recommendations**:
|
||||
- [Recommendation 1]
|
||||
- [Recommendation 2]
|
||||
|
||||
[Continue for each agent...]
|
||||
|
||||
---
|
||||
|
||||
### Trade-offs Identified
|
||||
| Option | Pros | Cons | Recommended By |
|
||||
|--------|------|------|----------------|
|
||||
| [Option A] | [Pros] | [Cons] | [Agent] |
|
||||
| [Option B] | [Pros] | [Cons] | [Agent] |
|
||||
|
||||
### Open Questions
|
||||
Questions that need resolution:
|
||||
- [ ] [Question 1] - Ask: [Who to ask]
|
||||
- [ ] [Question 2] - Ask: [Who to ask]
|
||||
|
||||
### Dissenting Opinions
|
||||
If agents disagree:
|
||||
- **[Agent 1]** thinks [X] because [reason]
|
||||
- **[Agent 2]** thinks [Y] because [reason]
|
||||
|
||||
---
|
||||
|
||||
### Recommended Next Steps
|
||||
Based on team input:
|
||||
1. [Action 1]
|
||||
2. [Action 2]
|
||||
3. [Action 3]
|
||||
|
||||
### Additional Consultation Needed?
|
||||
[Suggest which other agents might have valuable input if any]
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Technical Question
|
||||
**Input**: "How should we implement user authentication?"
|
||||
|
||||
**Agents Selected**:
|
||||
1. Security Engineer (security considerations)
|
||||
2. Full-Stack Engineer (implementation approach)
|
||||
3. Backend Engineer (API/session design)
|
||||
4. Product Manager (requirements/user impact)
|
||||
|
||||
### Example 2: Feature Question
|
||||
**Input**: "Should we add dark mode to the app?"
|
||||
|
||||
**Agents Selected**:
|
||||
1. Product Manager (prioritization, user value)
|
||||
2. UI/UX Designer (design system impact)
|
||||
3. Frontend Engineer (implementation complexity)
|
||||
4. Growth Marketer (adoption metrics)
|
||||
|
||||
### Example 3: With @Mentions
|
||||
**Input**: "@security @devops How should we handle secrets in CI/CD?"
|
||||
|
||||
**Agents Selected**:
|
||||
1. Security Engineer (mentioned)
|
||||
2. DevOps Engineer (mentioned)
|
||||
3. Full-Stack Engineer (general implementation context)
|
||||
|
||||
## Notes
|
||||
|
||||
- Keep agent responses focused (3-5 key points each)
|
||||
- Highlight disagreements - they're valuable
|
||||
- Suggest follow-up with specific agents if needed
|
||||
- Don't overload with too many perspectives
|
||||
222
commands/team-roster.md
Normal file
222
commands/team-roster.md
Normal file
@@ -0,0 +1,222 @@
|
||||
---
|
||||
name: team-roster
|
||||
description: Display all available team agents and their specialties
|
||||
tools: Read, Glob
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# Team Roster
|
||||
|
||||
Display all available webapp team agents, their specialties, and when to use them.
|
||||
|
||||
## Instructions
|
||||
|
||||
Display the following team roster:
|
||||
|
||||
```markdown
|
||||
# Webapp Team Roster
|
||||
|
||||
Your virtual web application development team with specialized agents for every aspect of product development.
|
||||
|
||||
---
|
||||
|
||||
## Engineering Team 🔧
|
||||
|
||||
### Critical Roles
|
||||
|
||||
| Agent | Role | Color | Specialty |
|
||||
|-------|------|-------|-----------|
|
||||
| `full-stack-engineer` | Senior Full-Stack Engineer | 🔵 #2563eb | End-to-end feature development, TypeScript/React/Node.js |
|
||||
|
||||
**Full-Stack Engineer**
|
||||
- End-to-end feature development
|
||||
- TypeScript/React/Next.js frontend
|
||||
- Node.js/Python backend
|
||||
- PostgreSQL/Prisma data modeling
|
||||
- API design (REST, GraphQL, tRPC)
|
||||
|
||||
*Triggers*: Implementation tasks, feature building, debugging, code review
|
||||
|
||||
---
|
||||
|
||||
### Specialist Roles
|
||||
|
||||
| Agent | Role | Color | Specialty |
|
||||
|-------|------|-------|-----------|
|
||||
| `frontend-engineer` | Frontend Engineer | 🔵 #3b82f6 | React/Next.js, performance, component libraries |
|
||||
| `backend-engineer` | Backend/API Engineer | 🔵 #60a5fa | API design, databases, integrations |
|
||||
| `devops-engineer` | DevOps/Platform Engineer | 🔵 #93c5fd | CI/CD, infrastructure, monitoring |
|
||||
| `qa-engineer` | QA/Test Engineer | 🔵 #1e40af | Test strategy, automation, quality |
|
||||
| `security-engineer` | Security Engineer | 🔵 #1e3a8a | Security audits, auth, compliance |
|
||||
|
||||
**Frontend Engineer**
|
||||
- React/Next.js architecture
|
||||
- State management (Zustand, React Query)
|
||||
- Performance optimization (Core Web Vitals)
|
||||
- Component library development
|
||||
|
||||
*Triggers*: Frontend architecture, performance issues, component design
|
||||
|
||||
**Backend Engineer**
|
||||
- API design (REST, GraphQL, tRPC)
|
||||
- Database optimization
|
||||
- Authentication/authorization patterns
|
||||
- Third-party integrations
|
||||
|
||||
*Triggers*: API design, database schema, integrations, backend architecture
|
||||
|
||||
**DevOps Engineer**
|
||||
- CI/CD pipeline design
|
||||
- Infrastructure as Code
|
||||
- Monitoring and alerting
|
||||
- Disaster recovery
|
||||
|
||||
*Triggers*: Deployment issues, infrastructure decisions, monitoring setup
|
||||
|
||||
**QA Engineer**
|
||||
- Test strategy and planning
|
||||
- E2E test automation (Playwright)
|
||||
- Bug lifecycle management
|
||||
- Quality gates
|
||||
|
||||
*Triggers*: Test strategy, bug investigation, test automation
|
||||
|
||||
**Security Engineer**
|
||||
- OWASP Top 10 vulnerabilities
|
||||
- Authentication security
|
||||
- Data encryption
|
||||
- Compliance awareness
|
||||
|
||||
*Triggers*: Security review, auth implementation, data handling
|
||||
|
||||
---
|
||||
|
||||
## Product & Design Team 🎨
|
||||
|
||||
| Agent | Role | Color | Specialty |
|
||||
|-------|------|-------|-----------|
|
||||
| `product-manager` | Product Manager | 🟣 #7c3aed | Requirements, prioritization, roadmap |
|
||||
| `ui-ux-designer` | UI/UX Designer | 🟣 #8b5cf6 | User flows, accessibility, design systems |
|
||||
|
||||
**Product Manager**
|
||||
- User story writing and acceptance criteria
|
||||
- Roadmap prioritization (RICE, MoSCoW)
|
||||
- PRD and spec writing
|
||||
- Success metrics definition
|
||||
|
||||
*Triggers*: Feature planning, prioritization, user stories, requirements
|
||||
|
||||
**UI/UX Designer**
|
||||
- User flow mapping
|
||||
- Accessibility (WCAG 2.1)
|
||||
- Mobile-first responsive design
|
||||
- Design tokens and component libraries
|
||||
|
||||
*Triggers*: UI decisions, user flow questions, accessibility, design systems
|
||||
|
||||
---
|
||||
|
||||
## Growth & Marketing Team 📈
|
||||
|
||||
| Agent | Role | Color | Specialty |
|
||||
|-------|------|-------|-----------|
|
||||
| `growth-marketer` | Growth Marketing Generalist | 🟢 #059669 | SEO, analytics, conversion optimization |
|
||||
| `content-creator` | Content Creator/Copywriter | 🟢 #10b981 | Blog posts, landing pages, product copy |
|
||||
| `data-analyst` | Data/Analytics Specialist | 🟠 #f59e0b | Event tracking, dashboards, A/B testing |
|
||||
|
||||
**Growth Marketer**
|
||||
- SEO (technical and content)
|
||||
- Paid acquisition (Meta, Google)
|
||||
- Landing page optimization
|
||||
- A/B testing strategy
|
||||
|
||||
*Triggers*: Growth discussions, analytics setup, SEO, conversion optimization
|
||||
|
||||
**Content Creator**
|
||||
- Blog post writing (SEO-optimized)
|
||||
- Landing page copy
|
||||
- Product microcopy (CTAs, error messages)
|
||||
- Brand voice development
|
||||
|
||||
*Triggers*: Copywriting, content strategy, blog posts, email copy
|
||||
|
||||
**Data Analyst**
|
||||
- Event tracking implementation
|
||||
- Dashboard design
|
||||
- Cohort and funnel analysis
|
||||
- Experiment analysis
|
||||
|
||||
*Triggers*: Analytics setup, data questions, metric definitions, reporting
|
||||
|
||||
---
|
||||
|
||||
## Operations Team ⚙️
|
||||
|
||||
| Agent | Role | Color | Specialty |
|
||||
|-------|------|-------|-----------|
|
||||
| `customer-support` | Customer Support Lead | 🟠 #d97706 | Bug translation, documentation, feedback synthesis |
|
||||
|
||||
**Customer Support**
|
||||
- Ticket triage and prioritization
|
||||
- Bug report translation
|
||||
- FAQ and help documentation
|
||||
- User feedback synthesis
|
||||
|
||||
*Triggers*: User feedback, bug clarification, documentation, support workflows
|
||||
|
||||
---
|
||||
|
||||
## Quick Reference
|
||||
|
||||
### How to Invoke Agents
|
||||
|
||||
**Direct invocation** (via Task tool):
|
||||
```
|
||||
Use the full-stack-engineer agent to review this code
|
||||
```
|
||||
|
||||
**Via @mentions** (in /team-consult):
|
||||
```
|
||||
/team-consult @frontend @ux How should we implement this component?
|
||||
```
|
||||
|
||||
### Team Commands
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/team-consult <question>` | Consult with relevant agents |
|
||||
| `/team-roster` | Display this roster |
|
||||
| `/team-standup` | Run virtual standup |
|
||||
| `/feature-kickoff <feature>` | Plan new feature with team input |
|
||||
| `/code-review <target>` | Get comprehensive code review |
|
||||
| `/ship-checklist` | Pre-launch checklist from all perspectives |
|
||||
| `/debug-assist <issue>` | Collaborative debugging |
|
||||
| `/hire-for <role>` | Create job description and interview plan |
|
||||
|
||||
### Team Skills
|
||||
|
||||
| Skill | Description |
|
||||
|-------|-------------|
|
||||
| `write-prd` | Create Product Requirements Document |
|
||||
| `estimate-complexity` | Estimate implementation complexity |
|
||||
| `write-test-plan` | Create comprehensive test plan |
|
||||
| `security-checklist` | Security review checklist |
|
||||
| `analytics-plan` | Define analytics tracking plan |
|
||||
| `write-user-docs` | Write user-facing documentation |
|
||||
|
||||
---
|
||||
|
||||
## Team Philosophy
|
||||
|
||||
This virtual team operates on these principles:
|
||||
|
||||
1. **User-first**: Every decision starts with user value
|
||||
2. **Ship fast, iterate**: Prefer small, testable increments
|
||||
3. **Quality built-in**: Security, accessibility, testing from the start
|
||||
4. **Data-informed**: Measure impact, not just activity
|
||||
5. **Collaborate**: Best solutions come from multiple perspectives
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
Display the roster formatted for easy reading. Highlight which agents are most commonly used (full-stack-engineer, product-manager, ui-ux-designer).
|
||||
99
commands/team-standup.md
Normal file
99
commands/team-standup.md
Normal file
@@ -0,0 +1,99 @@
|
||||
---
|
||||
name: team-standup
|
||||
description: Run a virtual standup across relevant team agents
|
||||
tools: Read, Glob, Grep, TodoWrite, AskUserQuestion, Task
|
||||
model: inherit
|
||||
---
|
||||
|
||||
# Team Standup
|
||||
|
||||
Run a virtual standup with your webapp team to get multiple perspectives on current work, blockers, and priorities.
|
||||
|
||||
## Instructions
|
||||
|
||||
### Step 1: Gather Context
|
||||
|
||||
Ask the user to provide context about their current work:
|
||||
|
||||
```
|
||||
Please share:
|
||||
1. What have you been working on recently?
|
||||
2. What are you planning to work on next?
|
||||
3. Any blockers or concerns?
|
||||
```
|
||||
|
||||
If the user doesn't provide this, check for:
|
||||
- Recent git commits (`git log --oneline -10`)
|
||||
- Open TODO items in the codebase
|
||||
- Recent file changes
|
||||
|
||||
### Step 2: Product Manager Perspective
|
||||
|
||||
Invoke the `product-manager` agent to provide:
|
||||
- Priority alignment check
|
||||
- User impact assessment
|
||||
- Any scope concerns
|
||||
- Dependencies to be aware of
|
||||
|
||||
### Step 3: Full-Stack Engineer Perspective
|
||||
|
||||
Invoke the `full-stack-engineer` agent to provide:
|
||||
- Technical blockers or concerns
|
||||
- Architecture considerations
|
||||
- Technical debt observations
|
||||
- Testing recommendations
|
||||
|
||||
### Step 4: UI/UX Designer Perspective
|
||||
|
||||
Invoke the `ui-ux-designer` agent to provide:
|
||||
- UX considerations for current work
|
||||
- Accessibility reminders
|
||||
- Design system alignment
|
||||
- User flow implications
|
||||
|
||||
### Step 5: Synthesize Standup Summary
|
||||
|
||||
Create a structured standup summary:
|
||||
|
||||
```markdown
|
||||
## Standup Summary - [Date]
|
||||
|
||||
### Current Focus
|
||||
[Summary of what's being worked on]
|
||||
|
||||
### Team Perspectives
|
||||
|
||||
**Product Manager:**
|
||||
- [Key points]
|
||||
|
||||
**Full-Stack Engineer:**
|
||||
- [Key points]
|
||||
|
||||
**UI/UX Designer:**
|
||||
- [Key points]
|
||||
|
||||
### Action Items
|
||||
- [ ] [Action item 1]
|
||||
- [ ] [Action item 2]
|
||||
|
||||
### Blockers
|
||||
- [Any blockers identified]
|
||||
|
||||
### Priorities for Today
|
||||
1. [Priority 1]
|
||||
2. [Priority 2]
|
||||
3. [Priority 3]
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
The standup should be:
|
||||
- Concise (each perspective 2-4 bullet points)
|
||||
- Actionable (clear next steps)
|
||||
- Time-boxed (total ~5 minute read)
|
||||
|
||||
## Notes
|
||||
|
||||
- Skip agents that aren't relevant to current work
|
||||
- Highlight disagreements between perspectives
|
||||
- Flag urgent items that need immediate attention
|
||||
Reference in New Issue
Block a user