feat: merge infrastructure skills and workflows from TenerifeProp
Add MCP-based infrastructure skills: - mcp-integration: Playwright + GitMCP - e2e-testing: Cypress + AntV + Slack - search-integration: Brave + Tavily + Markitdown - security-scanner: CVE Search + MCP Validator - knowledge-base: Docfork + Wikipedia + ArXiv - prompt-manager: version control + DevTrends - api-catalog: MCP server registry - agent-architect-mcp: patterns + OpenAPI converter Add workflow commands: - feature.md: full feature pipeline - hotfix.md: urgent bug fix workflow Add rules: - orchestrator-self-evolution.md - sdet-engineer.md Add audit: - WORKFLOW_AUDIT.md Source: UniqueSoft/TenerifeProp
This commit is contained in:
NW
255
.kilo/commands/feature.md
Normal file
255
.kilo/commands/feature.md
Normal file
@@ -0,0 +1,255 @@
|
||||
---
|
||||
description: Full feature development pipeline from requirements to release
|
||||
mode: feature
|
||||
model: openrouter/qwen/qwen3-coder:free
|
||||
color: "#059669"
|
||||
permission:
|
||||
read: allow
|
||||
edit: allow
|
||||
write: allow
|
||||
bash: allow
|
||||
glob: allow
|
||||
grep: allow
|
||||
task:
|
||||
"*": deny
|
||||
---
|
||||
|
||||
# Feature Command
|
||||
|
||||
Executes the complete development pipeline for implementing new features, following TDD and quality gates.
|
||||
|
||||
## Pipeline Flow
|
||||
|
||||
```
|
||||
Requirements → History → Design → Tests → Implementation → Review → Performance → Security → Release
|
||||
```
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Requirements Refinement
|
||||
**Agent**: `@RequirementRefiner`
|
||||
|
||||
- Transform vague ideas into strict User Stories
|
||||
- Define INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable)
|
||||
- Document acceptance criteria as checkboxes
|
||||
- Identify stakeholders and user personas
|
||||
- Create user story format:
|
||||
```
|
||||
As a [user type]
|
||||
I want [goal]
|
||||
So that [benefit]
|
||||
```
|
||||
|
||||
### Step 2: History Check
|
||||
**Agent**: `@HistoryMiner`
|
||||
|
||||
- Search for duplicate or similar past work
|
||||
- Query: `git log --all --oneline --grep="<feature>"`
|
||||
- Code search: `git log -p --all -S "<pattern>"`
|
||||
- Review closed PRs for related work
|
||||
- Identify reusable solutions
|
||||
- Document lessons learned from past attempts
|
||||
|
||||
### Step 3: System Design
|
||||
**Agent**: `@SystemAnalyst`
|
||||
|
||||
- Design technical specification
|
||||
- Create architecture diagram (ASCII or markdown)
|
||||
- Define data models and schemas
|
||||
- Specify API contracts
|
||||
- Identify integration points
|
||||
- Document security considerations
|
||||
- Create design document:
|
||||
```markdown
|
||||
## Technical Design
|
||||
|
||||
### Architecture
|
||||
[Diagram description]
|
||||
|
||||
### Components
|
||||
- Component A: [Purpose]
|
||||
- Component B: [Purpose]
|
||||
|
||||
### Data Flow
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
|
||||
### API Design
|
||||
[Endpoints, contracts]
|
||||
```
|
||||
|
||||
### Step 4: Test Creation (TDD)
|
||||
**Agent**: `@SDETEngineer`
|
||||
|
||||
- Write tests BEFORE implementation
|
||||
- Create test file near source file
|
||||
- Cover unit tests:
|
||||
- Happy path scenarios
|
||||
- Edge cases (empty, null, boundaries)
|
||||
- Error conditions
|
||||
- Create integration tests if needed
|
||||
- Ensure tests are deterministic and repeatable
|
||||
- Run tests to confirm they fail (red phase)
|
||||
- Test structure:
|
||||
```javascript
|
||||
describe('FeatureName', () => {
|
||||
describe('methodName', () => {
|
||||
it('should [expected behavior] when [condition]', () => {
|
||||
// Arrange
|
||||
// Act
|
||||
// Assert
|
||||
});
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
### Step 5: Implementation
|
||||
**Agent**: `@LeadDeveloper`
|
||||
|
||||
- Implement minimum code to pass tests
|
||||
- Follow existing code patterns and conventions
|
||||
- Use early returns to reduce nesting
|
||||
- Handle edge cases and errors
|
||||
- No comments unless explicitly requested
|
||||
- Check `package.json`/`cargo.toml` for dependencies
|
||||
- Use existing utilities when available
|
||||
- Run tests frequently (red-green-refactor)
|
||||
- Commit atomically with clear messages
|
||||
|
||||
### Step 6: Code Review
|
||||
**Agent**: `@CodeSkeptic`
|
||||
|
||||
- Review all changes adversarially
|
||||
- Check for:
|
||||
- Correctness and edge cases
|
||||
- Security vulnerabilities (XSS, SQL injection, secrets)
|
||||
- Performance issues (N+1 queries, memory leaks)
|
||||
- Maintainability (naming, DRY)
|
||||
- Generate review report:
|
||||
```markdown
|
||||
## Code Review Report
|
||||
|
||||
### Critical Issues
|
||||
- [Issue]: [File:line] - [Description] - [Suggestion]
|
||||
|
||||
### Warnings
|
||||
- [Issue]: [File:line] - [Description]
|
||||
|
||||
### Approved ✓
|
||||
- [List approved aspects]
|
||||
```
|
||||
- If FAIL: Route to `@TheFixer` → Return to Step 6
|
||||
- If PASS: Continue to Step 7
|
||||
|
||||
### Step 7: Performance Review
|
||||
**Agent**: `@PerformanceEngineer`
|
||||
|
||||
- Check for performance bottlenecks
|
||||
- Analyze time and space complexity
|
||||
- Review database query efficiency
|
||||
- Identify unnecessary computations
|
||||
- Check for proper use of caching
|
||||
- Suggest optimizations only if needed
|
||||
- Report format:
|
||||
```markdown
|
||||
## Performance Report
|
||||
|
||||
### Queries
|
||||
- [Query]: [Complexity] - [Optimization suggestion if needed]
|
||||
|
||||
### Algorithms
|
||||
- [Function]: [Time complexity] - [Improvement if critical]
|
||||
|
||||
### Status
|
||||
- PASS / FAIL with reasons
|
||||
```
|
||||
|
||||
### Step 8: Security Audit
|
||||
**Agent**: `@SecurityAuditor`
|
||||
|
||||
- Scan for vulnerabilities:
|
||||
- Input validation
|
||||
- Authentication/Authorization
|
||||
- Data exposure
|
||||
- Injection attacks
|
||||
- Sensitive data handling
|
||||
- Check for hardcoded secrets
|
||||
- Verify proper error handling
|
||||
- Review dependencies for known CVEs
|
||||
- Report format:
|
||||
```markdown
|
||||
## Security Audit
|
||||
|
||||
### Vulnerabilities Found
|
||||
- Severity: [Critical/High/Medium/Low]
|
||||
- Type: [Vulnerability type]
|
||||
- Location: [File:line]
|
||||
- Remediation: [Fix recommendation]
|
||||
|
||||
### Status
|
||||
- PASS / FAIL with reasons
|
||||
```
|
||||
|
||||
### Step 9: Release Preparation
|
||||
**Agent**: `@ReleaseManager`
|
||||
|
||||
- Run linting and type checking
|
||||
- Verify all tests pass
|
||||
- Check code coverage thresholds
|
||||
- Create/update changelog
|
||||
- Prepare commit messages
|
||||
- **Only commit if user explicitly requests**
|
||||
- Commit message format:
|
||||
```
|
||||
feat: [brief description of feature]
|
||||
|
||||
[Detailed explanation if needed]
|
||||
```
|
||||
|
||||
## Quality Gates
|
||||
|
||||
Each step must PASS before proceeding:
|
||||
|
||||
| Gate | Criteria |
|
||||
|------|----------|
|
||||
| Requirements | All acceptance criteria defined |
|
||||
| History | No duplicate work identified |
|
||||
| Design | Technical spec reviewed |
|
||||
| Tests | All tests written and failing |
|
||||
| Implementation | All tests passing |
|
||||
| Review | No critical issues remaining |
|
||||
| Performance | No critical bottlenecks |
|
||||
| Security | No critical vulnerabilities |
|
||||
|
||||
## Rollback Points
|
||||
|
||||
If issues arise, roll back to:
|
||||
- Design issues → Return to Step 3
|
||||
- Test failures → Return to Step 5
|
||||
- Security issues → Return to Step 5
|
||||
- Performance issues → Evaluate necessity
|
||||
|
||||
## Final Output
|
||||
|
||||
```markdown
|
||||
# Feature Complete: [Name]
|
||||
|
||||
## Summary
|
||||
- Requirements: ✓ [Count] criteria defined
|
||||
- History: ✓ No duplicates found
|
||||
- Design: ✓ [Document link]
|
||||
- Tests: ✓ [Count] tests passing
|
||||
- Implementation: ✓ Complete
|
||||
- Review: ✓ All issues resolved
|
||||
- Performance: ✓ Optimized
|
||||
- Security: ✓ No vulnerabilities
|
||||
|
||||
## Files Modified
|
||||
- [List of all modified files]
|
||||
|
||||
## Tests Added
|
||||
- [List of test files]
|
||||
|
||||
## Next Steps
|
||||
- [Release instructions or follow-up tasks]
|
||||
```
|
||||
270
.kilo/commands/hotfix.md
Normal file
270
.kilo/commands/hotfix.md
Normal file
@@ -0,0 +1,270 @@
|
||||
---
|
||||
description: Quick bug fix workflow for urgent production issues
|
||||
mode: hotfix
|
||||
model: openrouter/minimax/minimax-m2.5:free
|
||||
color: "#DC2626"
|
||||
permission:
|
||||
read: allow
|
||||
edit: allow
|
||||
write: allow
|
||||
bash: allow
|
||||
glob: allow
|
||||
grep: allow
|
||||
task:
|
||||
"*": deny
|
||||
---
|
||||
|
||||
# Hotfix Command
|
||||
|
||||
Rapid response workflow for urgent production bug fixes with minimal, targeted changes.
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Bug Analysis
|
||||
**Agent**: `@TheFixer`
|
||||
|
||||
- Collect bug report information:
|
||||
- Error messages
|
||||
- Stack traces
|
||||
- User-reported symptoms
|
||||
- Reproduction steps
|
||||
- Identify impact:
|
||||
- Severity: Critical / High / Medium / Low
|
||||
- Affected users: Count and segments
|
||||
- System components affected
|
||||
- Determine urgency:
|
||||
- Production down: Immediate
|
||||
- Data loss risk: Very High
|
||||
- User-facing bug: High
|
||||
- Internal tool: Medium
|
||||
|
||||
```markdown
|
||||
## Bug Report
|
||||
|
||||
### Symptom
|
||||
[What is happening]
|
||||
|
||||
### Expected
|
||||
[What should happen]
|
||||
|
||||
### Impact
|
||||
- Severity: [Level]
|
||||
- Affected: [Users/Components]
|
||||
- Urgency: [Level]
|
||||
|
||||
### Reproduction
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
```
|
||||
|
||||
### Step 2: Locate Bug
|
||||
**Agent**: `@TheFixer`
|
||||
|
||||
- Search for error messages: `grep -r "error message" src/`
|
||||
- Find related code: `grep "function_name" src/`
|
||||
- Trace stack to source
|
||||
- Identify root cause:
|
||||
- Logic error
|
||||
- Data issue
|
||||
- Integration failure
|
||||
- Environment difference
|
||||
- Document findings:
|
||||
```markdown
|
||||
## Root Cause Analysis
|
||||
|
||||
### Location
|
||||
- File: [path]
|
||||
- Line: [number]
|
||||
- Function: [name]
|
||||
|
||||
### Cause
|
||||
[Technical explanation]
|
||||
|
||||
### Trigger
|
||||
[What conditions cause the bug]
|
||||
```
|
||||
|
||||
### Step 3: Minimal Fix
|
||||
**Agent**: `@TheFixer`
|
||||
|
||||
- Principle: Smallest change that fixes the issue
|
||||
- Do NOT refactor or improve surrounding code
|
||||
- Do NOT add new features
|
||||
- Fix must be:
|
||||
- Targeted to specific bug
|
||||
- Low risk
|
||||
- Easy to review
|
||||
- Reversible if needed
|
||||
- Create fix with:
|
||||
- Clear before/after behavior
|
||||
- Focused change scope
|
||||
|
||||
```markdown
|
||||
## Fix Proposal
|
||||
|
||||
### Change
|
||||
- File: [path]
|
||||
- Lines: [range]
|
||||
- Type: [Logic fix / Condition update / Error handling]
|
||||
|
||||
### Before
|
||||
[code snippet]
|
||||
|
||||
### After
|
||||
[code snippet]
|
||||
|
||||
### Reasoning
|
||||
[Why this fix]
|
||||
```
|
||||
|
||||
### Step 4: Test Fix
|
||||
**Agent**: `@SDETEngineer`
|
||||
|
||||
- Create reproduction test:
|
||||
```javascript
|
||||
it('should [expected behavior] when [condition]', () => {
|
||||
// This test reproduces the bug
|
||||
// It should FAIL before fix, PASS after fix
|
||||
});
|
||||
```
|
||||
- Verify test fails without fix
|
||||
- Apply fix
|
||||
- Verify test passes with fix
|
||||
- Run existing tests to check for regressions
|
||||
- Document test:
|
||||
```markdown
|
||||
## Test Verification
|
||||
|
||||
### Reproduction Test
|
||||
- File: [test file]
|
||||
- Test: [test name]
|
||||
- Fails without fix: ✓
|
||||
- Passes with fix: ✓
|
||||
|
||||
### Regression Tests
|
||||
- All tests pass: ✓
|
||||
- Failed tests: [List or None]
|
||||
```
|
||||
|
||||
### Step 5: Quick Review
|
||||
**Agent**: `@CodeSkeptic`
|
||||
|
||||
- Focus on:
|
||||
- Does fix address root cause?
|
||||
- Are there obvious side effects?
|
||||
- Is change minimal?
|
||||
- Skip for critical production down:
|
||||
- If production is DOWN, proceed to deploy
|
||||
- Schedule full review post-deploy
|
||||
- Review checklist:
|
||||
```markdown
|
||||
## Hotfix Review
|
||||
|
||||
### Minimal Change
|
||||
- Changes scope: [Lines changed]
|
||||
- No unrelated changes: ✓/✗
|
||||
|
||||
### Correctness
|
||||
- Addresses root cause: ✓/✗
|
||||
- No side effects: ✓/✗
|
||||
|
||||
### Tests
|
||||
- Has reproduction test: ✓/✗
|
||||
- No regressions: ✓/✗
|
||||
|
||||
### Verdict
|
||||
- APPROVE / NEEDS_WORK
|
||||
```
|
||||
|
||||
### Step 6: Prepare for Merge
|
||||
**Agent**: `@ReleaseManager`
|
||||
|
||||
- Create hotfix branch from main
|
||||
- Apply changes
|
||||
- Update CHANGELOG.md:
|
||||
```markdown
|
||||
## [Unreleased]
|
||||
|
||||
### Fixed
|
||||
- [Bug description] fixing #[issue]
|
||||
```
|
||||
- Commit with clear message:
|
||||
```
|
||||
fix: [brief description]
|
||||
|
||||
- Root cause: [explanation]
|
||||
- Fix: [what changed]
|
||||
- Fixes #[issue]
|
||||
```
|
||||
- **Only merge if user explicitly requests**
|
||||
- Post-merge actions:
|
||||
- Monitor for issues
|
||||
- Schedule retrospective
|
||||
- Update documentation if needed
|
||||
|
||||
## Hotfix Branch Strategy
|
||||
|
||||
```
|
||||
main ───●───●───●───●
|
||||
\
|
||||
hotfix/xxx ●───●
|
||||
/
|
||||
main ───────●───●───● (merge back)
|
||||
```
|
||||
|
||||
1. Branch from main
|
||||
2. Apply minimal fix
|
||||
3. Test thoroughly
|
||||
4. Merge to main
|
||||
5. Tag release
|
||||
|
||||
## Quality Gates for Hotfix
|
||||
|
||||
| Gate | Requirement |
|
||||
|------|-------------|
|
||||
| Root cause identified | Must |
|
||||
| Minimal change scope | Must |
|
||||
| Reproduction test | Must |
|
||||
| No regressions | Must |
|
||||
| Reviewed | Unless production down |
|
||||
|
||||
## Post-Hotfix Actions
|
||||
|
||||
1. **Monitor**: Watch logs and metrics for 24-48 hours
|
||||
2. **Document**: Update runbooks if applicable
|
||||
3. **Retrospective**: Schedule bug postmortem
|
||||
4. **Prevention**: Add checks to prevent recurrence:
|
||||
- Additional tests
|
||||
- Monitoring alerts
|
||||
- Validation rules
|
||||
|
||||
## Rollback Plan
|
||||
|
||||
If hotfix causes issues:
|
||||
1. Revert commit immediately
|
||||
2. Restore previous version
|
||||
3. Investigate regression
|
||||
4. Create new hotfix if needed
|
||||
|
||||
```bash
|
||||
# Rollback command
|
||||
git revert <hotfix-commit>
|
||||
git push origin main
|
||||
```
|
||||
|
||||
## Time Targets
|
||||
|
||||
| Severity | Target Resolution |
|
||||
|----------|-------------------|
|
||||
| Critical (prod down) | 30 minutes |
|
||||
| High (user impact) | 2 hours |
|
||||
| Medium (internal) | 4 hours |
|
||||
| Low (minor) | Next sprint |
|
||||
|
||||
## Escalation
|
||||
|
||||
If fix is not straightforward:
|
||||
- Complex fix needed → Upgrade to `/feature` workflow
|
||||
- Requires redesign → Escalate to architect
|
||||
- Data migration needed → Coordinate with DBA
|
||||
Reference in New Issue
Block a user