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
2026-05-06 23:04:14 +01:00
parent 80dca09ae0
commit defe57d53a
12 changed files with 1727 additions and 0 deletions

255
.kilo/commands/feature.md Normal file
View 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
View 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

View 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

View 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

View 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.

View 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 |

View 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.

View 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.

View 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.

View 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.

View 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.

View 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.