opencode-agile-agent 1.0.1 → 1.0.2

package/templates/.opencode/skills/parallel-agents/SKILL.md

@@ -1,274 +1,38 @@
 ---
 name: parallel-agents
-description: Multi-agent coordination patterns and best practices for parallel execution.
-version: 1.0.0
+description: Split independent work across agents, share compact context, and merge at a clear gate.
 ---
 
 # Parallel Agents
 
-Patterns and best practices for coordinating multiple agents in parallel.
+## Philosophy
+Parallel work only helps when the pieces can truly move independently.
 
-## When to Use Parallel Agents
+## Use When
+- The task can be split by domain, file type, or review perspective.
+- You need speed without losing ownership or clarity.
+- A single agent would be forced to bounce between unrelated concerns.
 
-###  Good Candidates
+## Core Moves
+- Define dependencies before splitting work.
+- Keep each agent's ownership narrow.
+- Share a compact context bundle, not a dump.
+- Synthesize once at the end instead of merging constantly.
 
-- Independent tasks (frontend + backend)
-- Multiple file types (code + tests + docs)
-- Multiple perspectives (security + performance)
-- Large codebase analysis
-- Comprehensive reviews
+## Default Moves
+- Foundation -> core build -> quality/polish.
+- Use wave planning when dependencies are not fully parallel.
+- Keep the merge point explicit and owned.
 
-###  Poor Candidates
+## Anti-Patterns
+- Parallelizing dependent work, shared mutable state, conflicting file edits, and no synthesis step.
 
-- Sequential dependencies (API → Frontend)
-- Shared mutable state
-- Conflicting file modifications
-- Tasks requiring full context from previous step
+## Variation
+- Use domain split, review split, or file-type split depending on the task.
+- Choose wave size by coupling, not by how many agents exist.
 
-## Parallel Execution Patterns
+## Output
+- Return the wave plan, the dependency order, and the merge strategy.
 
-### Pattern 1: Domain Split
-
-```
-Task: "Build user management feature"
-
-┌─────────────────────────────────────┐
-│         Orchestrator                 │
-└──────────────┬──────────────────────┘
-               │
-       ┌───────┴───────┐
-       │               │
-       ▼               ▼
-┌─────────────┐ ┌─────────────┐
-│  Frontend   │ │   Backend   │
-│ Specialist  │ │ Specialist  │
-│             │ │             │
-│ Components  │ │   APIs      │
-│ Pages       │ │   Services  │
-│ State       │ │   Database  │
-└─────────────┘ └─────────────┘
-```
-
-### Pattern 2: Multi-Perspective Review
-
-```
-Task: "Review authentication system"
-
-┌─────────────────────────────────────┐
-│         Orchestrator                 │
-└──────────────┬──────────────────────┘
-               │
-   ┌───────────┼───────────┐
-   │           │           │
-   ▼           ▼           ▼
-┌───────┐ ┌───────┐ ┌───────┐
-│Security│ │Backend│ │ Test  │
-│Auditor │ │Special│ │Engine │
-└───────┘ └───────┘ └───────┘
-   │           │           │
-   └───────────┼───────────┘
-               ▼
-         Synthesis Report
-```
-
-### Pattern 3: File Type Distribution
-
-```
-Task: "Implement feature with tests"
-
-┌─────────────────────────────────────┐
-│         Orchestrator                 │
-└──────────────┬──────────────────────┘
-               │
-       ┌───────┴───────┐
-       │               │
-       ▼               ▼
-┌─────────────┐ ┌─────────────┐
-│  Developer  │ │    Test     │
-│  (Code)     │ │  Engineer   │
-│             │ │  (Tests)    │
-└─────────────┘ └─────────────┘
-```
-
-## Agent Groups
-
-### Foundation Group
-
-For establishing core infrastructure:
-
-| Agent | Responsibility |
-|-------|----------------|
-| `database-architect` | Schema, migrations |
-| `security-auditor` | Security baseline |
-| `devops-engineer` | CI/CD setup |
-
-### Core Development Group
-
-For building features:
-
-| Agent | Responsibility |
-|-------|----------------|
-| `frontend-specialist` | UI components |
-| `backend-specialist` | APIs, services |
-| `database-architect` | Data layer |
-
-### Quality Group
-
-For ensuring quality:
-
-| Agent | Responsibility |
-|-------|----------------|
-| `test-engineer` | Test coverage |
-| `security-auditor` | Security check |
-| `performance-optimizer` | Performance audit |
-
-### Documentation Group
-
-For documentation:
-
-| Agent | Responsibility |
-|-------|----------------|
-| `documentation-writer` | Docs |
-| `api-designer` | API docs |
-| `seo-specialist` | Meta, sitemap |
-
-## Coordination Protocol
-
-### Step 1: Task Decomposition
-
-```markdown
-Original: "Build user dashboard"
-
-Decomposed:
-1. [Frontend] Dashboard UI components
-2. [Backend] Dashboard API endpoints
-3. [Database] Dashboard data queries
-4. [Test] Dashboard E2E tests
-```
-
-### Step 2: Agent Assignment
-
-```markdown
-Assignments:
-- frontend-specialist → Dashboard components
-- backend-specialist → API endpoints
-- database-architect → Queries
-- test-engineer → E2E tests
-```
-
-### Step 3: Dependency Analysis
-
-```markdown
-Dependencies:
-- Backend API depends on Database queries
-- Frontend depends on Backend API
-- Tests depend on Frontend + Backend
-
-Execution Order:
-1. Database (independent)
-2. Backend (depends on 1)
-3. Frontend (depends on 2)
-4. Tests (depends on 3)
-```
-
-### Step 4: Parallel Execution
-
-```markdown
-Wave 1: database-architect (parallel with nothing)
-Wave 2: backend-specialist (after Wave 1)
-Wave 3: frontend-specialist (parallel with Wave 2)
-Wave 4: test-engineer (after Waves 2, 3)
-```
-
-## Context Sharing
-
-### Shared Context Object
-
-```typescript
-interface SharedContext {
-  // Original request
-  userRequest: string;
-  
-  // Decisions made
-  decisions: Decision[];
-  
-  // Work completed
-  completedWork: WorkItem[];
-  
-  // Files created/modified
-  files: FileInfo[];
-  
-  // Open questions
-  openQuestions: Question[];
-}
-```
-
-### Context Passing
-
-```typescript
-// Pass context to each agent
-invokeAgent('frontend-specialist', {
-  task: 'Build dashboard UI',
-  context: sharedContext
-});
-
-invokeAgent('backend-specialist', {
-  task: 'Build dashboard API',
-  context: sharedContext
-});
-```
-
-## Conflict Resolution
-
-### File Conflicts
-
-```
-If multiple agents modify the same file:
-1. Detect conflict
-2. Merge changes if possible
-3. Flag for human review if conflict
-```
-
-### API Contract Conflicts
-
-```
-If frontend and backend disagree on API:
-1. Use API designer as mediator
-2. Document contract
-3. Both agents follow contract
-```
-
-## Synthesis Report
-
-After parallel execution, synthesize results:
-
-```markdown
-## Orchestration Report
-
-### Agents Invoked
-| Agent | Status | Files Modified |
-|-------|--------|----------------|
-| frontend-specialist | ✅ Complete | 5 files |
-| backend-specialist | ✅ Complete | 3 files |
-| test-engineer | ✅ Complete | 2 files |
-
-### Combined Findings
-- [Finding from Agent 1]
-- [Finding from Agent 2]
-- [Finding from Agent 3]
-
-### Integration Notes
-- [How agents' work integrates]
-
-### Recommendations
-1. [Combined recommendation]
-2. [Combined recommendation]
-
-### Next Steps
-- [ ] [Action item]
-- [ ] [Action item]
-```
-
----
-
-**Parallel agents multiply productivity when tasks are independent.**
+## Remember
+Parallelism is a coordination problem first and a speed problem second.

package/templates/.opencode/skills/plan-writing/SKILL.md

@@ -1,251 +1,41 @@
 ---
 name: plan-writing
-description: Structured planning and task breakdown techniques.
-version: 1.0.0
+description: Turn ambiguous requests into a compact planning bundle with proposal, goal, spec, task, and important notes.
 ---
 
 # Plan Writing
 
-Structured approaches to creating plans, breaking down tasks, and defining success criteria.
+## Philosophy
+Planning is compression: make the next agent's job obvious without wasting context.
 
-## Plan Structure
+## Use When
+- You are starting complex work or breaking down a request.
+- You need a compact bundle for the spec-driven flow.
+- The team needs dependencies, success criteria, or open questions recorded clearly.
 
-### Minimal Plan Template
+## Core Moves
+- Write for the next agent, not for yourself.
+- Keep each task atomic and dependency-aware.
+- Make success measurable and risks explicit.
+- Capture only the facts that matter for execution.
 
-```markdown
-# PLAN: [Feature Name]
+## Default Moves
+- Use the compact bundle: proposal.md, goal.md, spec.md, task.md, important.md.
+- proposal = why, value, scope.
+- goal = outcome, constraints, default choice.
+- spec = contracts, flow, edge cases, risks.
+- task = ordered checklist and dependencies.
+- important = facts, owners, links, blockers.
 
-## What
-Brief description of what we're building.
+## Anti-Patterns
+- Monolithic tasks, long prose, hidden assumptions, single-point estimates, and unresolved questions with no owner.
 
-## Why
-Business justification and user value.
+## Variation
+- Keep the bundle minimal for small tasks.
+- Add more technical detail only when the system has real branching risk.
 
-## How
-High-level technical approach.
+## Output
+- Return the compact bundle, a short dependency map, and the success criteria.
 
-## Tasks
-- [ ] Task 1
-- [ ] Task 2
-- [ ] Task 3
-
-## Success Criteria
-- [ ] Criterion 1
-- [ ] Criterion 2
-```
-
-### Comprehensive Plan Template
-
-```markdown
-# PLAN: [Feature Name]
-
-## Executive Summary
-One paragraph overview.
-
-## Problem Statement
-What problem are we solving?
-
-## Proposed Solution
-How will we solve it?
-
-## User Stories
-1. As a [user], I want [goal] so that [benefit]
-2. ...
-
-## Technical Design
-### Architecture
-[Diagram or description]
-
-### API Design
-[Endpoints/contracts]
-
-### Data Model
-[Schema/ERD]
-
-## Implementation Plan
-### Phase 1: Foundation
-- [ ] Task 1.1
-- [ ] Task 1.2
-
-### Phase 2: Core Features
-- [ ] Task 2.1
-- [ ] Task 2.2
-
-### Phase 3: Polish
-- [ ] Task 3.1
-- [ ] Task 3.2
-
-## Dependencies
-- Dependency 1
-- Dependency 2
-
-## Risks & Mitigations
-| Risk | Likelihood | Impact | Mitigation |
-|------|------------|--------|------------|
-| ... | ... | ... | ... |
-
-## Success Metrics
-| Metric | Target | How Measured |
-|--------|--------|--------------|
-| ... | ... | ... |
-
-## Timeline
-- Phase 1: [dates]
-- Phase 2: [dates]
-- Phase 3: [dates]
-
-## Open Questions
-1. [Question] - Owner: [name]
-2. [Question] - Owner: [name]
-
-## Appendix
-- [Supporting documents]
-- [Research notes]
-```
-
-## Task Breakdown
-
-### WBS (Work Breakdown Structure)
-
-```
-Feature: User Authentication
-├── 1. Registration
-│   ├── 1.1 Registration form UI
-│   ├── 1.2 Form validation
-│   ├── 1.3 API endpoint
-│   ├── 1.4 Email verification
-│   └── 1.5 Password hashing
-├── 2. Login
-│   ├── 2.1 Login form UI
-│   ├── 2.2 JWT generation
-│   ├── 2.3 Session management
-│   └── 2.4 Logout flow
-└── 3. Password Reset
-    ├── 3.1 Forgot password form
-    ├── 3.2 Reset token generation
-    └── 3.3 Reset password form
-```
-
-### Task Sizing
-
-| Size | Duration | Characteristics |
-|------|----------|-----------------|
-| **XS** | < 1 hour | Typo fix, config change |
-| **S** | 1-4 hours | Simple component, small fix |
-| **M** | 4-8 hours | Feature with multiple parts |
-| **L** | 1-2 days | Complex feature, multiple files |
-| **XL** | 2-5 days | Major feature, needs breakdown |
-
-### Dependency Mapping
-
-```markdown
-Task Dependencies:
-
-A ─────► B ─────► D
-         │
-         └───────► C ─────► E
-
-Execution Order:
-1. A (no dependencies)
-2. B (depends on A)
-3. C (depends on B)
-4. D (depends on B)
-5. E (depends on C)
-```
-
-## Success Criteria
-
-### SMART Criteria
-
-| Letter | Meaning | Example |
-|--------|---------|---------|
-| **S**pecific | Clear and precise | "Reduce load time" → "Reduce LCP to < 2.5s" |
-| **M**easurable | Quantifiable | "Improve UX" → "Increase conversion by 10%" |
-| **A**chievable | Realistic | Based on resources and constraints |
-| **R**elevant | Aligned with goals | Supports business objectives |
-| **T**ime-bound | Has deadline | "Complete by Q2" |
-
-### Acceptance Criteria Template
-
-```markdown
-## User Story
-As a [user type], I want [goal] so that [benefit]
-
-## Acceptance Criteria
-- [ ] Given [context], when [action], then [outcome]
-- [ ] Given [context], when [action], then [outcome]
-- [ ] Given [context], when [action], then [outcome]
-
-## Edge Cases
-- [ ] Handle [edge case]
-- [ ] Handle [edge case]
-
-## Non-Functional
-- [ ] Performance: [requirement]
-- [ ] Security: [requirement]
-- [ ] Accessibility: [requirement]
-```
-
-## Risk Assessment
-
-### Risk Matrix
-
-```
-              IMPACT
-           Low    Med    High
-         ┌──────┬──────┬──────┐
-    High │Monitor│Plan  │Act   │
-LIK      ├──────┼──────┼──────┤
-    Med  │Accept │Monitor│Plan │
-         ├──────┼──────┼──────┤
-    Low  │Accept │Accept │Monitor│
-         └──────┴──────┴──────┘
-```
-
-### Risk Register Template
-
-```markdown
-| ID | Risk | Likelihood | Impact | Score | Mitigation | Owner |
-|----|------|------------|--------|-------|------------|-------|
-| R1 | API changes | Medium | High | 6 | Version lock | Dev |
-| R2 | Staff change | Low | High | 3 | Documentation | PM |
-```
-
-## Estimation Techniques
-
-### Planning Poker
-
-```
-Team members estimate:
-- Developer A: 5
-- Developer B: 8
-- Developer C: 5
-- Developer D: 13
-
-Discuss high/low outliers, reach consensus.
-```
-
-### Three-Point Estimation
-
-```
-Optimistic (O): 2 days
-Most Likely (M): 4 days
-Pessimistic (P): 8 days
-
-Expected = (O + 4M + P) / 6 = (2 + 16 + 8) / 6 = 4.33 days
-```
-
-## Plan Review Checklist
-
-- [ ] **Clear Objective**: What and why are clear
-- [ ] **Complete Breakdown**: All tasks identified
-- [ ] **Dependencies Mapped**: Order is logical
-- [ ] **Sized Appropriately**: Tasks are achievable
-- [ ] **Success Criteria**: Measurable outcomes defined
-- [ ] **Risks Identified**: Major risks documented
-- [ ] **Timeline Realistic**: Based on estimates
-- [ ] **Stakeholders Aligned**: Key people approve
-
----
-
-**A good plan eliminates ambiguity and enables execution.**
+## Remember
+A short plan that can be executed beats a perfect plan that nobody reads.

package/templates/.opencode/skills/redteam-validation/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: redteam-validation
+description: Simulate attacker behavior and validate exploitability on sensitive paths.
+---
+
+# Redteam Validation
+
+## Philosophy
+Do not guess whether a weakness is real. Prove the attack path, the impact, and the containment. This skill turns security concern into evidence.
+
+## Use When
+- `@security-auditor` found a likely issue and needs hostile simulation.
+- A feature changes attack surface on auth, tenancy, uploads, secrets, or public endpoints.
+- You need to validate abuse, escalation, enumeration, replay, or exfiltration paths.
+
+## Core Moves
+- Map the attacker goal and required prerequisites.
+- Try the smallest reproducible exploit path.
+- Record the exact conditions that make the issue possible.
+- Measure impact and blast radius.
+- Verify that the proposed fix actually closes the path.
+
+## Output
+- Validated attack path
+- Impact and blast radius
+- Reproduction notes
+- Fix verification notes
+- Follow-up owner
+
+## Anti-Patterns
+- Speculating without proof.
+- Changing production code while investigating.
+- Reporting findings without a concrete path to reproduce them.

package/templates/.opencode/skills/security-gate/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: security-gate
+description: Decide when a change needs security review, redteam validation, or escalation.
+---
+
+# Security Gate
+
+## Philosophy
+Security is a gate that keeps unsafe behavior from becoming the default path. Use this skill to classify risk early, choose the right reviewers, and keep the system operable.
+
+## Use When
+- A request touches auth, permissions, secrets, uploads, billing, webhooks, or public data surfaces.
+- You need to decide whether `@security-auditor` alone is enough or whether a redteam phase is required.
+- The blast radius or trust boundary is unclear.
+
+## Core Moves
+- Identify the trust boundary and the asset at risk.
+- Classify the likely impact: exposure, takeover, privilege escalation, abuse, or denial.
+- Pick the lightest safe path: no gate, security review, or full redteam validation.
+- Define the proof required before approval.
+- Keep the result short enough for `feature-lead` to act on immediately.
+
+## Output
+- Risk level
+- Required reviewers
+- Redteam needed or not
+- Validation checklist
+- Escalation path
+
+## Anti-Patterns
+- Treating all sensitive work as the same risk.
+- Asking for redteam when a simple review is enough.
+- Letting security checks become vague or endless.