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:
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
|
||||
540
.kilo/rules/orchestrator-self-evolution.md
Normal file
540
.kilo/rules/orchestrator-self-evolution.md
Normal file
@@ -0,0 +1,540 @@
|
||||
# Orchestrator Self-Evolution Rule
|
||||
|
||||
Auto-expansion protocol when no solution found in existing capabilities.
|
||||
|
||||
## Trigger Condition
|
||||
|
||||
Orchestrator initiates self-evolution when:
|
||||
|
||||
1. **No Agent Match**: Task requirements don't match any existing agent capabilities
|
||||
2. **No Skill Match**: Required domain knowledge not covered by existing skills
|
||||
3. **No Workflow Match**: Complex multi-step task needs new workflow pattern
|
||||
4. **Capability Gap**: `@capability-analyst` reports critical gaps
|
||||
|
||||
## Evolution Protocol
|
||||
|
||||
### Step 1: Create Research Milestone
|
||||
|
||||
Post to Gitea:
|
||||
|
||||
```python
|
||||
def create_evolution_milestone(gap_description, required_capabilities):
|
||||
"""Create milestone for evolution tracking"""
|
||||
|
||||
milestone = gitea.create_milestone(
|
||||
repo="UniqueSoft/APAW",
|
||||
title=f"[Evolution] {gap_description}",
|
||||
description=f"""## Capability Gap Analysis
|
||||
|
||||
**Trigger**: No matching capability found
|
||||
**Required**: {required_capabilities}
|
||||
**Date**: {timestamp()}
|
||||
|
||||
## Evolution Tasks
|
||||
|
||||
- [ ] Research existing solutions
|
||||
- [ ] Design new agent/skill/workflow
|
||||
- [ ] Implement component
|
||||
- [ ] Update orchestrator permissions
|
||||
- [ ] Verify access
|
||||
- [ ] Register in capability-index.yaml
|
||||
- [ ] Document in KILO_SPEC.md
|
||||
- [ ] Close milestone with results
|
||||
|
||||
## Expected Outcome
|
||||
|
||||
After completion, orchestrator will have access to new capabilities.
|
||||
"""
|
||||
)
|
||||
|
||||
return milestone['id'], milestone['number']
|
||||
```
|
||||
|
||||
### Step 2: Run Research Workflow
|
||||
|
||||
```python
|
||||
def run_evolution_research(milestone_id, gap_description):
|
||||
"""Run comprehensive research for gap filling"""
|
||||
|
||||
# Create research issue
|
||||
issue = gitea.create_issue(
|
||||
repo="UniqueSoft/APAW",
|
||||
title=f"[Research] {gap_description}",
|
||||
body=f"""## Research Scope
|
||||
|
||||
**Milestone**: #{milestone_id}
|
||||
**Gap**: {gap_description}
|
||||
|
||||
## Research Tasks
|
||||
|
||||
### 1. Existing Solutions Analysis
|
||||
- [ ] Search git history for similar patterns
|
||||
- [ ] Check external resources and best practices
|
||||
- [ ] Analyze if enhancement is better than new component
|
||||
|
||||
### 2. Component Design
|
||||
- [ ] Decide: Agent vs Skill vs Workflow
|
||||
- [ ] Define required capabilities
|
||||
- [ ] Specify permission requirements
|
||||
- [ ] Plan integration points
|
||||
|
||||
### 3. Implementation Plan
|
||||
- [ ] File locations
|
||||
- [ ] Dependencies
|
||||
- [ ] Update requirements: orchestrator.md, capability-index.yaml
|
||||
- [ ] Test plan
|
||||
|
||||
## Decision Matrix
|
||||
|
||||
| If | Then |
|
||||
|----|----|
|
||||
| Specialized knowledge needed | Create SKILL |
|
||||
| Autonomous execution needed | Create AGENT |
|
||||
| Multi-step process needed | Create WORKFLOW |
|
||||
| Enhancement to existing | Modify existing |
|
||||
|
||||
---
|
||||
**Status**: 🔄 Research Phase
|
||||
""",
|
||||
labels=["evolution", "research", f"milestone:{milestone_id}"]
|
||||
)
|
||||
|
||||
return issue['number']
|
||||
```
|
||||
|
||||
### Step 3: Execute Research with Agents
|
||||
|
||||
```python
|
||||
def execute_evolution_research(issue_number, gap_description, required_capabilities):
|
||||
"""Execute research using specialized agents"""
|
||||
|
||||
# 1. History search
|
||||
history_result = Task(
|
||||
subagent_type="history-miner",
|
||||
prompt=f"""Search git history for:
|
||||
1. Similar capability implementations
|
||||
2. Past solutions to: {gap_description}
|
||||
3. Related patterns that could be extended
|
||||
Return findings for gap analysis."""
|
||||
)
|
||||
|
||||
# 2. Capability analysis
|
||||
gap_analysis = Task(
|
||||
subagent_type="capability-analyst",
|
||||
prompt=f"""Analyze capability gap:
|
||||
|
||||
**Gap**: {gap_description}
|
||||
**Required**: {required_capabilities}
|
||||
|
||||
Output:
|
||||
1. Gap classification (critical/partial/integration/skill)
|
||||
2. Recommendation: create new or enhance existing
|
||||
3. Component type: agent/skill/workflow
|
||||
4. Required capabilities and permissions
|
||||
5. Integration points with existing system"""
|
||||
)
|
||||
|
||||
# 3. Design new component
|
||||
if gap_analysis.recommendation == "create_new":
|
||||
design_result = Task(
|
||||
subagent_type="agent-architect",
|
||||
prompt=f"""Design new component for:
|
||||
|
||||
**Gap**: {gap_description}
|
||||
**Type**: {gap_analysis.component_type}
|
||||
**Required Capabilities**: {required_capabilities}
|
||||
|
||||
Create complete definition:
|
||||
1. YAML frontmatter (model, mode, permissions)
|
||||
2. Role definition
|
||||
3. Behavior guidelines
|
||||
4. Task tool invocation table
|
||||
5. Integration requirements"""
|
||||
)
|
||||
|
||||
# Post research results
|
||||
post_comment(issue_number, f"""## ✅ Research Complete
|
||||
|
||||
### Findings:
|
||||
|
||||
**History Search**: {history_result.summary}
|
||||
**Gap Analysis**: {gap_analysis.classification}
|
||||
**Recommendation**: {gap_analysis.recommendation}
|
||||
|
||||
### Design:
|
||||
|
||||
```yaml
|
||||
{design_result.yaml_frontmatter}
|
||||
```
|
||||
|
||||
### Implementation Required:
|
||||
- Type: {gap_analysis.component_type}
|
||||
- Model: {design_result.model}
|
||||
- Permissions: {design_result.permissions}
|
||||
|
||||
**Next**: Implementation Phase
|
||||
""")
|
||||
|
||||
return {
|
||||
'type': gap_analysis.component_type,
|
||||
'design': design_result,
|
||||
'permissions_needed': design_result.permissions
|
||||
}
|
||||
```
|
||||
|
||||
### Step 4: Implement New Component
|
||||
|
||||
```python
|
||||
def implement_evolution_component(issue_number, milestone_id, design):
|
||||
"""Create new agent/skill/workflow based on research"""
|
||||
|
||||
component_type = design['type']
|
||||
|
||||
if component_type == 'agent':
|
||||
# Create agent file
|
||||
agent_file = f".kilo/agents/{design['design']['name']}.md"
|
||||
write_file(agent_file, design['design']['content'])
|
||||
|
||||
# Update orchestrator permissions
|
||||
update_orchestrator_permissions(design['design']['name'])
|
||||
|
||||
# Update capability index
|
||||
update_capability_index(
|
||||
agent_name=design['design']['name'],
|
||||
capabilities=design['design']['capabilities']
|
||||
)
|
||||
|
||||
elif component_type == 'skill':
|
||||
# Create skill directory
|
||||
skill_dir = f".kilo/skills/{design['design']['name']}"
|
||||
create_directory(skill_dir)
|
||||
write_file(f"{skill_dir}/SKILL.md", design['design']['content'])
|
||||
|
||||
elif component_type == 'workflow':
|
||||
# Create workflow file
|
||||
workflow_file = f".kilo/workflows/{design['design']['name']}.md"
|
||||
write_file(workflow_file, design['design']['content'])
|
||||
|
||||
# Post implementation status
|
||||
post_comment(issue_number, f"""## ✅ Component Implemented
|
||||
|
||||
**Type**: {component_type}
|
||||
**File**: {design['design']['file']}
|
||||
|
||||
### Created:
|
||||
- `{design['design']['file']}`
|
||||
- Updated: `.kilo/agents/orchestrator.md` (permissions)
|
||||
- Updated: `.kilo/capability-index.yaml`
|
||||
|
||||
**Next**: Verification Phase
|
||||
""")
|
||||
```
|
||||
|
||||
### Step 5: Update Orchestrator Permissions
|
||||
|
||||
```python
|
||||
def update_orchestrator_permissions(new_agent_name):
|
||||
"""Add new agent to orchestrator whitelist"""
|
||||
|
||||
orchestrator_file = ".kilo/agents/orchestrator.md"
|
||||
content = read_file(orchestrator_file)
|
||||
|
||||
# Parse YAML frontmatter
|
||||
frontmatter, body = parse_frontmatter(content)
|
||||
|
||||
# Add new permission
|
||||
if 'task' not in frontmatter['permission']:
|
||||
frontmatter['permission']['task'] = {"*": "deny"}
|
||||
|
||||
frontmatter['permission']['task'][new_agent_name] = "allow"
|
||||
|
||||
# Write back
|
||||
new_content = serialize_frontmatter(frontmatter) + body
|
||||
write_file(orchestrator_file, new_content)
|
||||
|
||||
# Log to Gitea
|
||||
post_comment(issue_number, f"""## 🔧 Orchestrator Updated
|
||||
|
||||
Added permission to call `{new_agent_name}` agent.
|
||||
|
||||
```yaml
|
||||
permission:
|
||||
task:
|
||||
"{new_agent_name}": allow
|
||||
```
|
||||
|
||||
**File**: `.kilo/agents/orchestrator.md`
|
||||
""")
|
||||
```
|
||||
|
||||
### Step 6: Verify Access
|
||||
|
||||
```python
|
||||
def verify_new_capability(agent_name):
|
||||
"""Test that orchestrator can now call new agent"""
|
||||
|
||||
try:
|
||||
result = Task(
|
||||
subagent_type=agent_name,
|
||||
prompt="Verification test - confirm you are operational"
|
||||
)
|
||||
|
||||
if result.success:
|
||||
return {
|
||||
'verified': True,
|
||||
'agent': agent_name,
|
||||
'response': result.response
|
||||
}
|
||||
else:
|
||||
raise VerificationError(f"Agent {agent_name} not responding")
|
||||
|
||||
except PermissionError as e:
|
||||
# Permission still blocked - escalation needed
|
||||
post_comment(issue_number, f"""## ❌ Verification Failed
|
||||
|
||||
**Error**: Permission denied for `{agent_name}`
|
||||
**Blocker**: Orchestrator still cannot call this agent
|
||||
|
||||
### Manual Action Required:
|
||||
1. Check `.kilo/agents/orchestrator.md` permissions
|
||||
2. Verify agent file exists
|
||||
3. Restart orchestrator session
|
||||
|
||||
**Status**: 🔴 Blocked
|
||||
""")
|
||||
raise
|
||||
```
|
||||
|
||||
### Step 7: Register in Documentation
|
||||
|
||||
```python
|
||||
def register_evolution_result(milestone_id, new_component):
|
||||
"""Update all documentation with new capability"""
|
||||
|
||||
# Update KILO_SPEC.md
|
||||
update_kilo_spec(new_component)
|
||||
|
||||
# Update AGENTS.md
|
||||
update_agents_md(new_component)
|
||||
|
||||
# Create changelog entry
|
||||
changelog_entry = f"""## {date()} - Evolution Complete
|
||||
|
||||
### New Capability Added
|
||||
|
||||
**Component**: {new_component['name']}
|
||||
**Type**: {new_component['type']}
|
||||
**Trigger**: {new_component['gap']}
|
||||
|
||||
### Files Modified:
|
||||
- `.kilo/agents/{new_component['name']}.md` (created)
|
||||
- `.kilo/agents/orchestrator.md` (permissions updated)
|
||||
- `.kilo/capability-index.yaml` (capability registered)
|
||||
- `.kilo/KILO_SPEC.md` (documentation updated)
|
||||
- `AGENTS.md` (reference added)
|
||||
|
||||
### Verification:
|
||||
- ✅ Agent file created
|
||||
- ✅ Orchestrator permissions updated
|
||||
- ✅ Capability index updated
|
||||
- ✅ Access verified
|
||||
- ✅ Documentation updated
|
||||
|
||||
---
|
||||
**Milestone**: #{milestone_id}
|
||||
**Status**: 🟢 Complete
|
||||
"""
|
||||
|
||||
append_to_file(".kilo/EVOLUTION_LOG.md", changelog_entry)
|
||||
```
|
||||
|
||||
### Step 8: Close Milestone
|
||||
|
||||
```python
|
||||
def close_evolution_milestone(milestone_id, issue_number, result):
|
||||
"""Finalize evolution milestone with results"""
|
||||
|
||||
# Close research issue
|
||||
close_issue(issue_number, f"""## 🎉 Evolution Complete
|
||||
|
||||
**Milestone**: #{milestone_id}
|
||||
|
||||
### Summary:
|
||||
- New capability: `{result['component_name']}`
|
||||
- Type: {result['type']}
|
||||
- Orchestrator access: ✅ Verified
|
||||
|
||||
### Metrics:
|
||||
- Duration: {result['duration']}
|
||||
- Agents involved: history-miner, capability-analyst, agent-architect
|
||||
- Files modified: {len(result['files'])}
|
||||
|
||||
**Evolution logged to**: `.kilo/EVOLUTION_LOG.md`
|
||||
""")
|
||||
|
||||
# Close milestone
|
||||
close_milestone(milestone_id, f"""Evolution complete. New capability '{result['component_name']}' registered and accessible.
|
||||
|
||||
- Issue: #{issue_number}
|
||||
- Verification: PASSED
|
||||
- Orchestrator access: CONFIRMED
|
||||
""")
|
||||
```
|
||||
|
||||
## Complete Evolution Flow
|
||||
|
||||
```
|
||||
[Task Requires Unknown Capability]
|
||||
↓
|
||||
1. Create Evolution Milestone → Gitea milestone + research issue
|
||||
↓
|
||||
2. Run History Search → @history-miner checks git history
|
||||
↓
|
||||
3. Analyze Gap → @capability-analyst classifies gap
|
||||
↓
|
||||
4. Design Component → @agent-architect creates spec
|
||||
↓
|
||||
5. Decision: Agent/Skill/Workflow?
|
||||
↓
|
||||
┌───────┼───────┐
|
||||
↓ ↓ ↓
|
||||
[Agent] [Skill] [Workflow]
|
||||
↓ ↓ ↓
|
||||
6. Create File → .kilo/agents/{name}.md (or skill/workflow)
|
||||
↓
|
||||
7. Update Orchestrator → Add to permission whitelist
|
||||
↓
|
||||
8. Update capability-index.yaml → Register capabilities
|
||||
↓
|
||||
9. Verify Access → Task tool test call
|
||||
↓
|
||||
10. Update Documentation → KILO_SPEC.md, AGENTS.md, EVOLUTION_LOG.md
|
||||
↓
|
||||
11. Close Milestone → Record in Gitea with results
|
||||
↓
|
||||
[Orchestrator Now Has New Capability]
|
||||
```
|
||||
|
||||
## Gitea Milestone Structure
|
||||
|
||||
```yaml
|
||||
milestone:
|
||||
title: "[Evolution] {gap_description}"
|
||||
state: open
|
||||
|
||||
issues:
|
||||
- title: "[Research] {gap_description}"
|
||||
labels: [evolution, research]
|
||||
tasks:
|
||||
- History search
|
||||
- Gap analysis
|
||||
- Component design
|
||||
|
||||
- title: "[Implement] {component_name}"
|
||||
labels: [evolution, implementation]
|
||||
tasks:
|
||||
- Create agent/skill/workflow file
|
||||
- Update orchestrator permissions
|
||||
- Update capability index
|
||||
|
||||
- title: "[Verify] {component_name}"
|
||||
labels: [evolution, verification]
|
||||
tasks:
|
||||
- Test orchestrator access
|
||||
- Update documentation
|
||||
- Close milestone
|
||||
|
||||
timeline:
|
||||
- 2026-04-06: Milestone created
|
||||
- 2026-04-06: Research complete
|
||||
- 2026-04-06: Implementation done
|
||||
- 2026-04-06: Verification passed
|
||||
- 2026-04-06: Milestone closed
|
||||
```
|
||||
|
||||
## Evolution Log Format
|
||||
|
||||
`.kilo/EVOLUTION_LOG.md`:
|
||||
|
||||
```markdown
|
||||
# Orchestrator Evolution Log
|
||||
|
||||
Timeline of capability expansions through self-modification.
|
||||
|
||||
## Entry: 2026-04-06T22:15:00+01:00
|
||||
|
||||
### Gap
|
||||
Task required NLP processing capability not available.
|
||||
|
||||
### Research
|
||||
- Milestone: #42
|
||||
- Issue: #43
|
||||
- Analysis: Critical gap - no NLP agent exists
|
||||
|
||||
### Implementation
|
||||
- Created: `.kilo/agents/nlp-processor.md`
|
||||
- Model: `ollama-cloud/nemotron-3-super`
|
||||
- Permissions: read, edit, task
|
||||
|
||||
### Verification
|
||||
- Test call: ✅ Success
|
||||
- Orchestrator access: ✅ Confirmed
|
||||
- Capability index: ✅ Registered
|
||||
|
||||
### Files Modified
|
||||
- .kilo/agents/nlp-processor.md (new)
|
||||
- .kilo/agents/orchestrator.md (permission added)
|
||||
- .kilo/capability-index.yaml (registered)
|
||||
- .kilo/KILO_SPEC.md (documented)
|
||||
|
||||
### Metrics
|
||||
- Duration: 15 minutes
|
||||
- Agents used: history-miner, capability-analyst, agent-architect
|
||||
- Tokens consumed: ~25,000
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
## Orchestrator Behavior Change
|
||||
|
||||
Add to orchestrator.md Behavior Guidelines:
|
||||
|
||||
```markdown
|
||||
## Self-Evolution Policy
|
||||
|
||||
When task requirements exceed current capabilities:
|
||||
|
||||
1. **Detect Gap**: If no agent/skill/workflow matches task
|
||||
2. **Create Milestone**: Document the evolution attempt in Gitea
|
||||
3. **Run Research**: Invoke capability-analyst + agent-architect
|
||||
4. **Implement**: Create new agent/skill/workflow
|
||||
5. **Self-Modify**: Add new permission to own whitelist
|
||||
6. **Verify**: Test access to new capability
|
||||
7. **Register**: Update all documentation
|
||||
8. **Log**: Record in EVOLUTION_LOG.md
|
||||
9. **Close**: Mark milestone complete with results
|
||||
|
||||
### Evolution Triggers
|
||||
|
||||
- Task type not in capability Routing Map
|
||||
- capability-analyst reports critical gap
|
||||
- Repeated task failures for same reason
|
||||
- User requests new specialized capability
|
||||
|
||||
### Self-Modification Rules
|
||||
|
||||
1. ONLY modify own permission whitelist
|
||||
2. NEVER modify other agents' definitions
|
||||
3. ALWAYS create milestone before changes
|
||||
4. ALWAYS verify access after changes
|
||||
5. ALWAYS log results to EVOLUTION_LOG.md
|
||||
```
|
||||
|
||||
## Prohibited Self-Evolution Actions
|
||||
|
||||
- DO NOT create agents without capability-analyst approval
|
||||
- DO NOT skip verification step
|
||||
- DO NOT modify other agents without permission
|
||||
- DO NOT close milestone without verification
|
||||
- DO NOT evolve for single-use scenarios
|
||||
- DO NOT create duplicate capabilities
|
||||
81
.kilo/rules/sdet-engineer.md
Normal file
81
.kilo/rules/sdet-engineer.md
Normal file
@@ -0,0 +1,81 @@
|
||||
# SDET Engineer Rules
|
||||
|
||||
- Write tests before implementation (TDD approach)
|
||||
- Tests must be deterministic and repeatable
|
||||
- Each test should verify one specific behavior
|
||||
- Use descriptive test names that explain expected behavior
|
||||
|
||||
## Test Structure
|
||||
|
||||
```javascript
|
||||
describe('ComponentName', () => {
|
||||
describe('methodName', () => {
|
||||
it('should do something when condition', () => {
|
||||
// Arrange
|
||||
const input = createTestInput();
|
||||
|
||||
// Act
|
||||
const result = methodUnderTest(input);
|
||||
|
||||
// Assert
|
||||
expect(result).toBe(expectedOutput);
|
||||
});
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
## Test Categories
|
||||
|
||||
### Unit Tests
|
||||
- Test individual functions/methods in isolation
|
||||
- Mock external dependencies
|
||||
- Focus on logic, not implementation details
|
||||
|
||||
### Integration Tests
|
||||
- Test component interactions
|
||||
- Use test databases/fixtures
|
||||
- Verify contracts between modules
|
||||
|
||||
### Edge Cases
|
||||
- Empty inputs
|
||||
- Null/undefined values
|
||||
- Boundary values
|
||||
- Error conditions
|
||||
|
||||
## Naming Conventions
|
||||
|
||||
```javascript
|
||||
// Good: describes behavior
|
||||
it('should return null when user not found')
|
||||
|
||||
// Bad: describes implementation
|
||||
it('tests the getUser function')
|
||||
```
|
||||
|
||||
## Examples
|
||||
|
||||
Unit test:
|
||||
```javascript
|
||||
describe('Calculator', () => {
|
||||
describe('add', () => {
|
||||
it('should return sum of two positive numbers', () => {
|
||||
expect(add(2, 3)).toBe(5);
|
||||
});
|
||||
|
||||
it('should handle negative numbers', () => {
|
||||
expect(add(-1, -2)).toBe(-3);
|
||||
});
|
||||
|
||||
it('should return 0 when both operands are 0', () => {
|
||||
expect(add(0, 0)).toBe(0);
|
||||
});
|
||||
});
|
||||
});
|
||||
```
|
||||
|
||||
## Test Coverage Goals
|
||||
|
||||
- Aim for 80%+ coverage minimum
|
||||
- Focus on critical paths first
|
||||
- Don't test trivial getters/setters
|
||||
- Prioritize behavior over implementation
|
||||
66
.kilo/skills/agent-architect-mcp/SKILL.md
Normal file
66
.kilo/skills/agent-architect-mcp/SKILL.md
Normal file
@@ -0,0 +1,66 @@
|
||||
# Agent Architect MCP Skill
|
||||
|
||||
Agent design patterns and REST-to-MCP conversion tools.
|
||||
|
||||
## Multi Agent Architect MCP
|
||||
|
||||
Library of vetted agent patterns from Anthropic, OpenAI, and Kilo.ai research.
|
||||
|
||||
### Patterns Catalog
|
||||
|
||||
| Pattern | Source | Description |
|
||||
|---------|--------|-------------|
|
||||
| Prompt Chaining | Anthropic | Sequential steps with gates |
|
||||
| Routing | Anthropic | Classify, then route |
|
||||
| Parallelization | Anthropic | Run independent subtasks |
|
||||
| Orchestrator-Workers | Anthropic | Dynamic decomposition |
|
||||
| Evaluator-Optimizer | Anthropic | Generate-evaluate-improve loop |
|
||||
| ReAct | Lilian Weng | Interleave reasoning + action |
|
||||
| Reflexion | Lilian Weng | Learn from mistakes |
|
||||
| Plan-Execute-Reflect | Kilo.ai | Decompose-plan-act-reflect |
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `pattern_search` | Find pattern by use-case or name |
|
||||
| `pattern_validate` | Validate workflow implements pattern correctly |
|
||||
| `pattern_apply` | Generate YAML for a given pattern |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const pattern = await mcpClient.callTool('pattern_search', {
|
||||
use_case: 'code review loop',
|
||||
min_quality: 8
|
||||
})
|
||||
```
|
||||
|
||||
## OpenAPI to MCP Converter
|
||||
|
||||
Convert REST APIs to MCP servers automatically.
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `convert_openapi` | OpenAPI spec to MCP server |
|
||||
| `convert_swagger` | Swagger 2.0 to MCP server |
|
||||
| `validate_conversion` | Check converted server output |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const conversion = await mcpClient.callTool('convert_openapi', {
|
||||
spec_url: 'https://api.example.com/openapi.json',
|
||||
server_name: 'example-api-mcp'
|
||||
})
|
||||
```
|
||||
|
||||
## Files
|
||||
|
||||
- `SKILL.md` - This file
|
||||
- `patterns-catalog.md` - Full pattern definitions with YAML
|
||||
- `openapi-converter.md` - Conversion reference
|
||||
|
||||
## Command
|
||||
|
||||
`/convert-api` - Convert OpenAPI spec to MCP server definition.
|
||||
58
.kilo/skills/api-catalog/SKILL.md
Normal file
58
.kilo/skills/api-catalog/SKILL.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# MCP Server Catalog Skill
|
||||
|
||||
Centralized registry of available MCP servers for agent discovery.
|
||||
|
||||
## Registry
|
||||
|
||||
### Phase 1 - Critical Dev Tools
|
||||
|
||||
| Server | Package | License | Port | Description |
|
||||
|--------|---------|---------|------|-------------|
|
||||
| Playwright MCP | microsoft/playwright-mcp | Apache 2.0 | 8931 | E2E browser automation |
|
||||
| GitMCP | | - | - | Repository context |
|
||||
| Multi Agent Architect | | MIT | - | Agent pattern library |
|
||||
| OpenAPI Converter | | MIT | - | REST to MCP |
|
||||
| Ai Prompt Library | - | MIT | - | Prompt version control |
|
||||
| DevTrends | - | MIT | - | Tech trend monitoring |
|
||||
| CVE Search | cve_search/cve-search | MIT | 5000 | Vulnerability scanning |
|
||||
| MCP Validator | - | MIT | - | Server validation |
|
||||
|
||||
### Phase 2 - Quality Tools
|
||||
|
||||
| Server | Package | License | Free Tier | Description |
|
||||
|--------|---------|---------|-----------|-------------|
|
||||
| Docfork | - | MIT | - | 9000+ lib docs |
|
||||
| API Doc | - | MIT | - | API doc search |
|
||||
| Brave Search | - | MIT | 2000 req/mo | Web search |
|
||||
| Tavily | - | MIT | 1000 req/mo | Search + extraction |
|
||||
| Wikipedia | - | MIT | Unlimited | Knowledge base |
|
||||
| ArXiv | - | MIT | Unlimited | Papers |
|
||||
| Markitdown | - | MIT | - | Doc conversion |
|
||||
| AntV Chart | antvis/mcp-server-chart | MIT | - | 26 chart types |
|
||||
| Cypress | - | MIT | - | E2E test runner |
|
||||
| Slack | - | MIT | - | Notifications |
|
||||
|
||||
## Capability Routing
|
||||
|
||||
- `mcp_list`: Lists all available servers per phase
|
||||
- `mcp_server_info`: Returns metadata for a given server
|
||||
- `mcp_verify_license`: Checks license compatibility
|
||||
|
||||
## Files
|
||||
|
||||
- `SKILL.md` - This file (catalog and metadata)
|
||||
- `servers.json` - Machine-readable server registry
|
||||
|
||||
## Integration Steps
|
||||
|
||||
1. Load `servers.json` into orchestrator context
|
||||
2. Use `mcp_server_info` to resolve server details before delegation
|
||||
3. Verify license compatibility for commercial use
|
||||
|
||||
## License Compatibility
|
||||
|
||||
| Project License | Compatible With |
|
||||
|-----------------|-----------------|
|
||||
| MIT | MIT, Apache, BSD |
|
||||
| Apache 2.0 | Apache, BSD |
|
||||
| Proprietary | Check with compliance |
|
||||
81
.kilo/skills/e2e-testing/SKILL.md
Normal file
81
.kilo/skills/e2e-testing/SKILL.md
Normal file
@@ -0,0 +1,81 @@
|
||||
# E2E Testing Skill
|
||||
|
||||
Cypress E2E tests, chart visualization, and Slack notifications.
|
||||
|
||||
## Cypress Test Runner MCP
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose | Agent |
|
||||
|------|---------|-------|
|
||||
| `cypress_run` | Execute test suite | sdet-engineer |
|
||||
| `cypress_record` | Record video + screenshots | sdet-engineer |
|
||||
| `cypress_parallel` | Run tests in parallel | pipeline-judge |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const result = await mcpClient.callTool('cypress_run', {
|
||||
spec: 'cypress/e2e/booking.cy.ts',
|
||||
browser: 'electron',
|
||||
record: true
|
||||
})
|
||||
```
|
||||
|
||||
## AntV Chart MCP
|
||||
|
||||
26+ chart types for test metrics visualization.
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `chart_create` | Generate chart image |
|
||||
| `chart_trend` | Time-series trend |
|
||||
| `chart_compare` | Compare metrics |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const chart = await mcpClient.callTool('chart_trend', {
|
||||
data: testResults.map(r => ({ date: r.date, pass: r.passed, fail: r.failed })),
|
||||
title: 'Test Pass Rate Over Time',
|
||||
chart_type: 'line'
|
||||
})
|
||||
```
|
||||
|
||||
## Slack MCP
|
||||
|
||||
Team notifications for test results.
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `slack_message` | Send channel message |
|
||||
| `slack_thread` | Reply in thread |
|
||||
| `slack_upload` | Upload file/image |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
await mcpClient.callTool('slack_message', {
|
||||
channel: '#testing',
|
||||
text: 'All 96 tests passing \u2705\nBuild: tenerifeprop #42'
|
||||
})
|
||||
```
|
||||
|
||||
## Test Report Workflow
|
||||
|
||||
1. **Run**: Cypress executes full suite
|
||||
2. **Visualize**: AntV charts for pass/fail trends
|
||||
3. **Notify**: Slack posts results to #testing
|
||||
4. **Archive**: Gitea comment on issue with chart attachments
|
||||
|
||||
## Files
|
||||
|
||||
- `SKILL.md` - This file
|
||||
- `cypress-config.md` - Test setup guide
|
||||
- `chart-types.md` - All 26 chart types reference
|
||||
- `slack-notify.md` - Notification templates
|
||||
|
||||
## Command
|
||||
|
||||
`/e2e-run` - Execute full E2E suite with notifications.
|
||||
77
.kilo/skills/knowledge-base/SKILL.md
Normal file
77
.kilo/skills/knowledge-base/SKILL.md
Normal file
@@ -0,0 +1,77 @@
|
||||
# Knowledge Base Skill
|
||||
|
||||
Documentation search and knowledge retrieval for architecture decisions.
|
||||
|
||||
## Docfork MCP
|
||||
|
||||
9000+ library documentation search.
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose | Input | Output |
|
||||
|------|---------|-------|--------|
|
||||
| `docfork_search` | Search library docs | library, version, topic | Relevant docs |
|
||||
| `docfork_api` | Get API reference | library, symbol | Signature + examples |
|
||||
| `docfork_example` | Get code examples | library, use_case | Runnable code |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const docs = await mcpClient.callTool('docfork_search', {
|
||||
library: 'hono',
|
||||
topic: 'rate limiting middleware',
|
||||
version: '4.0'
|
||||
})
|
||||
```
|
||||
|
||||
## API Doc MCP
|
||||
|
||||
API documentation search across providers.
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `apidoc_search` | Search API docs by endpoint pattern |
|
||||
| `apidoc_compare` | Compare two API designs |
|
||||
|
||||
## Wikipedia MCP
|
||||
|
||||
General knowledge queries.
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `wikipedia_search` | Search articles |
|
||||
| `wikipedia_summary` | Get article summary |
|
||||
| `wikipedia_references` | Get citations |
|
||||
|
||||
## ArXiv MCP
|
||||
|
||||
Scientific papers search.
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `arxiv_search` | Search by keyword, author, category |
|
||||
| `arxiv_paper` | Get paper abstract and PDF link |
|
||||
| `arxiv_related` | Find related papers |
|
||||
|
||||
## Architecture Decision Workflow
|
||||
|
||||
1. **Research**: Query Docfork for library docs, ArXiv for papers
|
||||
2. **Compare**: Use apidoc_compare to evaluate alternatives
|
||||
3. **Decide**: Save decision with references in Gitea comment
|
||||
4. **Document**: Link all sources in `architecture/decision-log.md`
|
||||
|
||||
## Files
|
||||
|
||||
- `SKILL.md` - This file
|
||||
- `docfork-guide.md` - Detailed search syntax
|
||||
- `wikipedia-guide.md` - Query patterns
|
||||
- `arxiv-guide.md` - Research workflows
|
||||
|
||||
## Command
|
||||
|
||||
`/research` - Run multi-source research query.
|
||||
69
.kilo/skills/mcp-integration/SKILL.md
Normal file
69
.kilo/skills/mcp-integration/SKILL.md
Normal file
@@ -0,0 +1,69 @@
|
||||
# MCP Integration Skill
|
||||
|
||||
Integration guide for Playwright MCP and GitMCP into the agent system.
|
||||
|
||||
## Playwright MCP
|
||||
|
||||
### Installation
|
||||
```bash
|
||||
docker run -d --name playwright-mcp \
|
||||
-p 8931:8931 \
|
||||
mcr.microsoft.com/playwright/mcp:latest
|
||||
```
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose | Agent |
|
||||
|------|---------|-------|
|
||||
| `playwright_navigate` | Load page | browser-automation |
|
||||
| `playwright_screenshot` | Capture screenshot | visual-tester |
|
||||
| `playwright_click` | Click element | browser-automation |
|
||||
| `playwright_fill` | Fill form input | browser-automation |
|
||||
| `playwright_evaluate` | Run JS in page | sdet-engineer |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const result = await mcpClient.callTool('playwright_navigate', {
|
||||
url: 'https://tenerifeprop.com',
|
||||
viewport: { width: 1280, height: 720 }
|
||||
})
|
||||
```
|
||||
|
||||
## GitMCP
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose | Agent |
|
||||
|------|---------|-------|
|
||||
| `git_repo_context` | Gets repo structure | history-miner |
|
||||
| `git_file_history` | Gets file changes | history-miner |
|
||||
| `git_search` | Searches code | history-miner |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const context = await mcpClient.callTool('git_repo_context', {
|
||||
repo: 'UniqueSoft/APAW',
|
||||
branch: 'main'
|
||||
})
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
Update `capability-index.yaml` to route MCP-dependent tasks:
|
||||
|
||||
```yaml
|
||||
capability_routing:
|
||||
browser_tests: browser-automation
|
||||
visual_regression: visual-tester
|
||||
git_history: history-miner
|
||||
```
|
||||
|
||||
## Files
|
||||
|
||||
- `SKILL.md` - This file
|
||||
- `playwright-config.md` - Detailed Playwright MCP reference
|
||||
- `gitmcp-config.md` - Detailed GitMCP reference
|
||||
|
||||
## Verification
|
||||
|
||||
Run `/mcp-test` to verify all MCP integrations are operational.
|
||||
65
.kilo/skills/prompt-manager/SKILL.md
Normal file
65
.kilo/skills/prompt-manager/SKILL.md
Normal file
@@ -0,0 +1,65 @@
|
||||
# Prompt Manager Skill
|
||||
|
||||
Prompt version control and AI trend monitoring.
|
||||
|
||||
## Ai Prompt Library MCP
|
||||
|
||||
Open-source alternative to PromptLayer (saves 9-299$/mo).
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `prompt_version` | Save prompt with version tag |
|
||||
| `prompt_diff` | Compare two versions |
|
||||
| `prompt_rollback` | Revert to previous version |
|
||||
| `prompt_list` | List all prompt versions |
|
||||
|
||||
### Usage Example
|
||||
|
||||
Save prompt version:
|
||||
```typescript
|
||||
await mcpClient.callTool('prompt_version', {
|
||||
name: 'lead-developer-task',
|
||||
version: '2.1.0',
|
||||
prompt: 'Implement...',
|
||||
tags: ['refactored', '2026-Q2']
|
||||
})
|
||||
```
|
||||
|
||||
## DevTrends MCP
|
||||
|
||||
Monitor new AI models and frameworks.
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `devtrends_models` | Latest model releases |
|
||||
| `devtrends_frameworks` | Framework updates |
|
||||
| `devtrends_benchmarks` | Performance benchmarks |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const trends = await mcpClient.callTool('devtrends_models', {
|
||||
provider: 'ollama-cloud',
|
||||
last_days: 7
|
||||
})
|
||||
```
|
||||
|
||||
## Prompt Optimization Workflow
|
||||
|
||||
1. **Version Control**: Save current prompt before changes
|
||||
2. **Benchmark**: Run pipeline-judge before and after
|
||||
3. **Compare**: Use `prompt_diff` to analyze changes
|
||||
4. **Rollback**: If fitness drops below 0.85, auto-rollback
|
||||
|
||||
## Files
|
||||
|
||||
- `SKILL.md` - This file
|
||||
- `prompt-library-guide.md` - Ai Prompt Library reference
|
||||
- `devtrends-guide.md` - DevTrends reference
|
||||
|
||||
## Command
|
||||
|
||||
`/prompt-versions` - List all prompt versions with diff links.
|
||||
92
.kilo/skills/search-integration/SKILL.md
Normal file
92
.kilo/skills/search-integration/SKILL.md
Normal file
@@ -0,0 +1,92 @@
|
||||
# Search Integration Skill
|
||||
|
||||
Web search and document conversion for RAG pipelines.
|
||||
|
||||
## Brave Search MCP
|
||||
|
||||
2,000 requests/month free tier.
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `brave_web_search` | Web search |
|
||||
| `brave_news_search` | News search |
|
||||
| `brave_image_search` | Image search |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const results = await mcpClient.callTool('brave_web_search', {
|
||||
query: 'latest AI agent frameworks 2026',
|
||||
count: 10,
|
||||
safe_search: true
|
||||
})
|
||||
```
|
||||
|
||||
## Tavily MCP
|
||||
|
||||
1,000 requests/month free tier. Search + content extraction.
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `tavily_search` | Search with extracted content |
|
||||
| `tavily_answer` | Direct question answering |
|
||||
| `tavily_sources` | List used sources |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const result = await mcpClient.callTool('tavily_answer', {
|
||||
query: 'How to implement evaluator-optimizer pattern in LLM agents?',
|
||||
max_results: 5
|
||||
})
|
||||
```
|
||||
|
||||
## Markitdown MCP
|
||||
|
||||
Convert 29+ document formats to Markdown.
|
||||
|
||||
### Supported Formats
|
||||
|
||||
| Format | Extension |
|
||||
|--------|-----------|
|
||||
| PDF | .pdf |
|
||||
| Word | .docx |
|
||||
| Excel | .xlsx |
|
||||
| PowerPoint | .pptx |
|
||||
| HTML | .html |
|
||||
| Jupyter | .ipynb |
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `markitdown_convert` | Convert file to markdown |
|
||||
| `markitdown_batch` | Batch convert directory |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const markdown = await mcpClient.callTool('markitdown_convert', {
|
||||
input: './docs/specification.pdf',
|
||||
output: './docs/specification.md'
|
||||
})
|
||||
```
|
||||
|
||||
## RAG Pipeline Integration
|
||||
|
||||
1. **Search**: Use Brave/Tavily to find relevant sources
|
||||
2. **Convert**: Use Markitdown for any non-Markdown documents
|
||||
3. **Chunk**: Split into chunks with overlap
|
||||
4. **Embed**: Store in vector DB
|
||||
5. **Query**: Semantic search over collected knowledge
|
||||
|
||||
## Files
|
||||
|
||||
- `SKILL.md` - This file
|
||||
- `search-guide.md` - Advanced search operators
|
||||
- `rag-pipeline.md` - End-to-end RAG setup
|
||||
|
||||
## Command
|
||||
|
||||
`/research` - Run multi-source research with automatic document conversion.
|
||||
73
.kilo/skills/security-scanner/SKILL.md
Normal file
73
.kilo/skills/security-scanner/SKILL.md
Normal file
@@ -0,0 +1,73 @@
|
||||
# Security Scanner Skill
|
||||
|
||||
Vulnerability scanning and MCP server validation for the security audit pipeline.
|
||||
|
||||
## CVE Search MCP
|
||||
|
||||
### Installation
|
||||
```bash
|
||||
docker run -d --name cve-search-mcp \
|
||||
-p 5000:5000 \
|
||||
cve_search/cve-search:latest
|
||||
```
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose | Input | Output |
|
||||
|------|---------|-------|--------|
|
||||
| `cve_search` | Search vulnerabilities | vendor, product, version | CVE list |
|
||||
| `cve_get` | Get CVE details | CVE-ID | Full description |
|
||||
| `cve_browse` | Browse by vendor | vendor | Affected products |
|
||||
|
||||
### Usage Examples
|
||||
|
||||
Search by vendor:
|
||||
```typescript
|
||||
const results = await mcpClient.callTool('cve_search', {
|
||||
vendor: 'microsoft'
|
||||
})
|
||||
```
|
||||
|
||||
Search specific software:
|
||||
```typescript
|
||||
const results = await mcpClient.callTool('cve_search', {
|
||||
vendor: 'apache',
|
||||
product: 'http_server',
|
||||
version: '2.4.41'
|
||||
})
|
||||
```
|
||||
|
||||
## MCP Validator
|
||||
|
||||
### Capabilities
|
||||
|
||||
| Tool | Purpose |
|
||||
|------|---------|
|
||||
| `mcp_validate_server` | Validates server spec compliance |
|
||||
| `mcp_validate_tools` | Checks tool definitions |
|
||||
| `mcp_validate_auth` | Verifies auth configuration |
|
||||
|
||||
### Usage Example
|
||||
```typescript
|
||||
const validation = await mcpClient.callTool('mcp_validate_server', {
|
||||
url: 'http://localhost:8931',
|
||||
spec_version: '2024-11-05'
|
||||
})
|
||||
```
|
||||
|
||||
## Security Audit Workflow
|
||||
|
||||
1. **Scan Dependencies**: Run CVE Search on all package.json dependencies
|
||||
2. **Validate MCP Servers**: Ensure all MCP servers comply with spec
|
||||
3. **Report Findings**: Generate Gitea issue for each CVE-2025 or higher
|
||||
4. **Auto-Fix**: `@the-fixer` analyzes and proposes patches
|
||||
|
||||
## Files
|
||||
|
||||
- `SKILL.md` - This file
|
||||
- `cve-search-guide.md` - Detailed CVE Search reference
|
||||
- `mcp-validator-guide.md` - MCP Validator reference
|
||||
|
||||
## Command
|
||||
|
||||
`/security-scan` - Run full security audit pipeline.
|
||||
Reference in New Issue
Block a user