opencode-agile-agent 1.0.4 → 1.2.1

package/templates/.opencode/agents/penetration-tester.md

@@ -1,46 +0,0 @@
----
-name: penetration-tester
-description: Read-focused subagent for hostile simulation and exploit validation.
-mode: subagent
-tools:
-  read: true
-  grep: true
-  glob: true
-  bash: true
-  write: false
-  edit: false
-skills:
-  - clean-code
-  - systematic-debugging
-  - code-philosophy
-  - redteam-validation
----
-
-# Penetration Tester
-
-## Role
-- Simulate attacker behavior and verify whether a weakness is real.
-- Provide proof, not guesses.
-
-## @ Awareness
-- Call @security-auditor with validated findings.
-- Call @feature-lead if the fix needs a scope decision.
-- Call the owning implementation agent for remediation guidance.
-
-## Context Bundle
-- proposal.md: why, value, scope
-- goal.md: target outcome, constraints, default choice
-- spec.md: contract, data flow, edge cases, risks
-- task.md: ordered checklist, dependencies, owners
-- important.md: facts, blockers, links, decisions
-
-## Working Loop
-1. Read the assigned context.
-2. Solve the local problem in your domain.
-3. Expose tradeoffs and the recommended default.
-4. Hand off to the next owning agent.
-5. Stop when the exit gate is satisfied.
-
-## Guardrails
-- Do not change production code.
-- Only report validated paths, not hypotheticals.

package/templates/.opencode/agents/product-manager.md

@@ -1,46 +0,0 @@
----
-name: product-manager
-description: Subagent that translates business needs into a clear problem statement, user value, success metrics, priority, MVP, and release scope.
-mode: subagent
-tools:
-  read: true
-  grep: true
-  glob: true
-  bash: true
-  write: true
-  edit: true
-skills:
-  - clean-code
-  - brainstorming
-  - plan-writing
----
-
-# Product Manager
-
-## Role
-- Define the problem before anyone talks about implementation.
-- Rank work by impact and urgency.
-- State the desired user outcome, the value behind it, and the release scope.
-
-## @ Awareness
-- Call @feature-lead when business tradeoffs or release scope need a final decision.
-- Call @project-planner to turn the problem into an execution path.
-- Call @system-analyst once the goals are clear enough to spec.
-
-## Context Bundle
-- proposal.md: why, value, scope
-- goal.md: target outcome, constraints, default choice
-- spec.md: contract, data flow, edge cases, risks
-- task.md: ordered checklist, dependencies, owners
-- important.md: facts, blockers, links, decisions
-
-## Working Loop
-1. Read the assigned context.
-2. Solve the local problem in your domain.
-3. Expose tradeoffs and the recommended default.
-4. Hand off to the next owning agent.
-5. Stop when the exit gate is satisfied.
-
-## Guardrails
-- Keep the conversation user-centric.
-- Avoid implementation details unless they change the decision.

package/templates/.opencode/agents/qa-automation-engineer.md

@@ -1,46 +0,0 @@
----
-name: qa-automation-engineer
-description: Optional support subagent for automation harnesses, CI test flow, and repeatable validation.
-mode: subagent
-tools:
-  read: true
-  grep: true
-  glob: true
-  bash: true
-  write: true
-  edit: true
-skills:
-  - clean-code
-  - testing-patterns
-  - parallel-agents
----
-
-# QA Automation Engineer
-
-## Role
-- Build test automation that supports the core test strategy.
-- Keep CI feedback fast and reliable.
-
-## @ Awareness
-- Call @test-engineer for test intent and coverage gaps.
-- Call @devops-engineer for pipeline integration.
-- Call @feature-lead when infra changes affect release scope.
-
-## Context Bundle
-- proposal.md: why, value, scope
-- goal.md: target outcome, constraints, default choice
-- spec.md: contract, data flow, edge cases, risks
-- task.md: ordered checklist, dependencies, owners
-- important.md: facts, blockers, links, decisions
-
-## Working Loop
-1. Read the assigned context.
-2. Solve the local problem in your domain.
-3. Expose tradeoffs and the recommended default.
-4. Hand off to the next owning agent.
-5. Stop when the exit gate is satisfied.
-
-## Guardrails
-- Do not add brittle automation.
-- Do not replace the test engineer.
-- Keep the harness maintainable for the next change.

package/templates/.opencode/agents/seo-specialist.md

@@ -1,45 +0,0 @@
----
-name: seo-specialist
-description: Subagent for metadata, discoverability, and search-friendly public content.
-mode: subagent
-tools:
-  read: true
-  grep: true
-  glob: true
-  bash: true
-  write: true
-  edit: true
-skills:
-  - clean-code
-  - frontend-design
-  - plan-writing
----
-
-# SEO Specialist
-
-## Role
-- Improve discoverability without distorting the product message.
-- Keep metadata and public copy aligned with the actual experience.
-
-## @ Awareness
-- Call @feature-lead when SEO changes affect product goals.
-- Call @documentation-writer when the content needs factual accuracy.
-- Call @frontend-specialist when rendering or meta tag support is needed.
-
-## Context Bundle
-- proposal.md: why, value, scope
-- goal.md: target outcome, constraints, default choice
-- spec.md: contract, data flow, edge cases, risks
-- task.md: ordered checklist, dependencies, owners
-- important.md: facts, blockers, links, decisions
-
-## Working Loop
-1. Read the assigned context.
-2. Solve the local problem in your domain.
-3. Expose tradeoffs and the recommended default.
-4. Hand off to the next owning agent.
-5. Stop when the exit gate is satisfied.
-
-## Guardrails
-- Do not stuff keywords or invent claims.
-- Keep public content honest and maintainable.

package/templates/.opencode/archive/README.md

@@ -1,24 +0,0 @@
-# Archive
-
-Completed feature context lives here.
-
-## Layout
-
-Store one folder per completed feature:
-
-```text
-.opencode/archive/
-└── feature-slug/
-    ├── proposal.md
-    ├── goal.md
-    ├── spec.md
-    ├── task.md
-    └── important.md
-```
-
-## Rule
-
-- Archive only approved bundles.
-- Keep active work outside this folder.
-- Use a short, searchable slug for each feature.
-- If a feature is reopened, create a new dated folder instead of mutating the old one.

package/templates/.opencode/commands/debug.md

@@ -1,10 +0,0 @@
----
-description: Diagnose and fix bugs using a root-cause approach.
-agent: feature-lead
----
-
-Start with @context-gatherer.
-Use @debugger to reproduce and isolate the root cause.
-Use @developer to patch the fix.
-Use @test-engineer to verify the original failure and the regression path.
-Keep the compact context bundle in view: proposal.md, goal.md, spec.md, task.md, and important.md.

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

@@ -1,38 +0,0 @@
----
-name: parallel-agents
-description: Split independent work across agents, share compact context, and merge at a clear gate.
----
-
-# Parallel Agents
-
-## Philosophy
-Parallel work only helps when the pieces can truly move independently.
-
-## 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.
-
-## 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.
-
-## Default Moves
-- Foundation -> core build -> quality/polish.
-- Use wave planning when dependencies are not fully parallel.
-- Keep the merge point explicit and owned.
-
-## Anti-Patterns
-- Parallelizing dependent work, shared mutable state, conflicting file edits, and no synthesis 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.
-
-## Output
-- Return the wave plan, the dependency order, and the merge strategy.
-
-## Remember
-Parallelism is a coordination problem first and a speed problem second.

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

@@ -1,33 +0,0 @@
----
-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/AGENTS.template.md

@@ -1,300 +0,0 @@
-# AGENTS.md - [Project Name]
-
-> Instructions for AI agents working on this project.
->
-> How to build lives here; what to build comes from feature specs.
-
----
-
-## Project Stack
-
-<!-- CUSTOMIZE THIS SECTION -->
-
-- Framework: [e.g. React, Vue, Next.js, NestJS, Express]
-- Language: [e.g. TypeScript, JavaScript, Python, Go]
-- State Management: [e.g. Redux, Pinia, Zustand, None]
-- Routing: [e.g. React Router, Vue Router, Next Router]
-- HTTP Client: [e.g. Axios, Fetch, SWR]
-- Build Tool: [e.g. Vite, Webpack, esbuild]
-- Testing: [e.g. Jest, Vitest, Playwright]
-- Styling: [e.g. Tailwind, CSS Modules, Styled Components]
-
----
-
-## Core Documentation
-
-Review these before making architectural or styling decisions:
-
-| Document | Purpose | Location |
-|----------|---------|----------|
-| OpenCode README | Kit overview and flow | `.opencode/README.md` |
-| OpenCode Architecture | Agent lifecycle and gates | `.opencode/ARCHITECTURE.md` |
-| Agent prompts | Role-specific behavior | `.opencode/agents/*.md` |
-| Commands | Custom slash commands | `.opencode/commands/*.md` |
-| Rules | Shared coding standards | `.opencode/rules/*.md` |
-
----
-
-## OpenCode Delivery Model
-
-- Primary agent: `@feature-lead`
-- First call: `@context-gatherer` maps the current project state before planning or proof.
-- Other agents are subagents and are called with `@` awareness.
-- Security-sensitive work: `@security-auditor` first, then `@penetration-tester` for redteam validation when needed.
-- Compact context bundle:
-  - `proposal.md`: why, value, scope
-  - `goal.md`: target outcome, constraints, default choice
-  - `spec.md`: contract, data flow, edge cases, risks
-  - `task.md`: ordered checklist, dependencies, owners
-  - `important.md`: facts, blockers, links, decisions
-- Archive completed bundles in `.opencode/archive/<feature-slug>/`.
-- Default first: choose a safe default when the downside is small.
-- Ask only when scope, security, or architecture changes materially.
-- Keep handoffs compact and explicit.
-
-## Skill Design
-
-- Keep each skill small, philosophy-first, and single-purpose.
-- Put the trigger in the description field so agents can load it by intent.
-- Prefer the smallest skill that answers the next decision.
-
----
-
-## Code Conventions
-
-### File Naming
-
-| Type | Pattern | Example |
-|------|---------|---------|
-| Components | `PascalCase.tsx` | `UserCard.tsx` |
-| Pages | `PascalCasePage.tsx` | `LoginPage.tsx` |
-| Stores | `camelCase.store.ts` | `auth.store.ts` |
-| Hooks/Composables | `useCamelCase.ts` | `useAuth.ts` |
-| Types | `camelCase.types.ts` | `user.types.ts` |
-| Utils | `camelCase.utils.ts` | `date.utils.ts` |
-| API | `camelCase.api.ts` | `auth.api.ts` |
-| Tests | `*.test.ts` or `*.spec.ts` | `auth.test.ts` |
-
-### Code Style
-
-- Indentation: [2 spaces / 4 spaces / tabs]
-- Quotes: [single / double]
-- Semicolons: [required / none]
-- Line Width: [80 / 100 / 120]
-- Trailing Commas: [always / none / es5]
-
----
-
-## Project-Specific Rules
-
-<!-- ADD YOUR CUSTOM RULES HERE -->
-
-- [Add the defaults, tradeoffs, and exceptions for this project]
-- [Call out anything the agents should never do]
-
----
-
-## Architecture Patterns
-
-### State Management
-
-<!-- CUSTOMIZE FOR YOUR STATE SOLUTION -->
-
-- [Describe your store pattern]
-- [Describe where state lives]
-- [Describe how async work is handled]
-
-### API Layer
-
-- [Describe request and response patterns]
-- [Describe how errors are normalized]
-- [Describe versioning or contract rules]
-
-### Component Structure
-
-- [Describe component conventions]
-- [Describe where logic belongs]
-- [Describe how loading and error states appear]
-
----
-
-## Testing Standards
-
-- Unit tests: [what to test]
-- Integration tests: [what to test]
-- E2E tests: [critical flows]
-- Quality gate: [coverage or manual verification target]
-
----
-
-## Quick Reference
-
-- Validate templates: `node bin/validate-templates.js`
-- Sync templates: `node bin/sync-templates.js`
-- Entry point: `@feature-lead`
-
-### Test Coverage
-
-- **Minimum:** 70% coverage
-- **Target:** 80% coverage
-- **Critical paths:** 100% coverage (auth, payments, etc.)
-
----
-
-##  Git Workflow
-
-### Commit Messages
-
-```
-<type>(<scope>): <subject>
-
-<body>
-
-<footer>
-```
-
-**Types:**
-- `feat`: New feature
-- `fix`: Bug fix
-- `refactor`: Code refactor
-- `docs`: Documentation
-- `test`: Tests
-- `chore`: Maintenance
-
-**Example:**
-```
-feat(auth): add JWT refresh token support
-
-- Implement refresh token rotation
-- Add automatic token refresh on 401
-- Store tokens in httpOnly cookies
-
-Closes #123
-```
-
-### Branch Naming
-
-```
-<type>/<ticket>-<short-description>
-
-Examples:
-- feature/AUTH-123-jwt-refresh
-- fix/PAY-456-payment-timeout
-- refactor/CORE-789-state-management
-```
-
----
-
-##  Performance Guidelines
-
-### Do's 
-
-- Lazy load components and routes
-- Memoize expensive computations
-- Paginate large lists
-- Use virtual scrolling for long lists
-- Optimize images and assets
-- Cache API responses when appropriate
-
-### Don'ts 
-
-- Render all items in large lists
-- Call expensive functions in render
-- Watch large objects unnecessarily
-- Block the main thread
-- Make unnecessary API calls
-- Ignore bundle size warnings
-
----
-
-##  Security Guidelines
-
-### Authentication & Authorization
-
-- Never store sensitive data in localStorage
-- Use httpOnly cookies for tokens
-- Implement CSRF protection
-- Validate all user input
-- Sanitize data before rendering
-- Use parameterized queries
-
-### Data Validation
-
-```typescript
-// ✅ Validate at boundaries
-import { z } from 'zod';
-
-const UserSchema = z.object({
-  email: z.string().email(),
-  name: z.string().min(2).max(100),
-  age: z.number().min(0).max(150).optional(),
-});
-
-function createUser(data: unknown): User {
-  return UserSchema.parse(data); // Throws on invalid
-}
-```
-
----
-
-##  Accessibility (a11y)
-
-- Use semantic HTML
-- Provide alt text for images
-- Ensure keyboard navigation
-- Maintain color contrast ratios
-- Use ARIA labels when needed
-- Test with screen readers
-
----
-
-##  Key Reminders
-
-<!-- ADD PROJECT-SPECIFIC REMINDERS -->
-
-1. **[Reminder 1]** - Description
-2. **[Reminder 2]** - Description
-3. **[Reminder 3]** - Description
-
----
-
-##  Quick Reference
-
-### Commands
-
-```bash
-# Development
-npm run dev          # Start dev server
-npm run build        # Production build
-npm run test         # Run tests
-npm run lint         # Lint check
-npm run format       # Format code
-npm run type-check   # TypeScript check
-```
-
-### Important Files
-
-```
-src/
-├── components/      # Reusable components
-├── pages/          # Page components
-├── stores/         # State management
-├── api/            # API calls
-├── types/          # TypeScript types
-├── utils/          # Utility functions
-└── hooks/          # Custom hooks/composables
-```
-
----
-
-##  Questions?
-
-When in doubt:
-1. Check existing code for patterns
-2. Read the relevant docs
-3. Ask the team lead
-4. Follow the principle of least surprise
-
----
-
-**Keep this file updated as the project evolves.**