pantheon-opencode 1.0.0

package/src/skills/git-workflow-and-versioning/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: git-workflow-and-versioning
+description: "Atomic commits, conventional commits, trunk-based development"
+---
+
+# Git Workflow & Versioning
+
+**Commits atômicos, mensagens claras, trunk-based.**
+
+## Commit Style (Conventional Commits)
+```
+feat: add login endpoint
+fix: handle null user in profile
+refactor: extract auth middleware
+test: add migration up/down test
+docs: update README setup steps
+```
+
+## Rules
+1. **Atomic commits** — um commit = uma mudança lógica. Não acumule
+2. **Trunk-based** — branches curtas (< 2 dias), PRs pequenos
+3. **Mensagens no imperativo** — "add" não "added" ou "adds"
+4. **Commits quebram o build?** Só se for intencional (WIP)
+5. **Nunca force push em branch compartilhada**
+
+## Branch Strategy
+```
+main ← produção
+├── feat/<descrição>  — features
+├── fix/<descrição>   — bug fixes
+└── refactor/<descrição> — refatorações
+```

package/src/skills/incremental-implementation/SKILL.md

@@ -0,0 +1,27 @@
+---
+name: incremental-implementation
+description: "Implement in thin vertical slices — one commit per task, testable, rollback-safe"
+---
+
+# Incremental Implementation
+
+**Construa em fatias finas testáveis. Um commit por task.**
+
+## Rules
+1. Cada slice entrega valor testável de forma independente
+2. Um commit por slice — sempre com tests passando
+3. Se o slice cresceu > 50 linhas, quebre em 2
+4. Rollback de um slice não quebra os anteriores
+
+## Slice Pattern
+```
+Slice 1 — Schema + model (migration up/down testada)
+Slice 2 — API endpoint (teste → implementação → refactor)
+Slice 3 — Frontend component (mock API → UI → integração)
+Slice N — Integração E2E (caminho feliz + edge cases)
+```
+
+## Anti-patterns
+- ❌ Slices horizontais (backend inteiro, depois frontend inteiro)
+- ❌ Commits de 500+ linhas
+- ❌ Implementar sem testar antes (RED → GREEN)

package/src/skills/memory-bank/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: memory-bank
+description: "Memory bank rules, structure, and optimization — complete guide to Pantheon memory management."
+context: fork
+globs: []
+alwaysApply: false
+---
+
+# Memory Bank
+
+Complete guide to Pantheon memory bank — structure, rules, optimization, and maintenance.
+
+---
+
+## Two-System Model
+
+| System | Where | Owner | Lifetime | Purpose |
+|--------|-------|-------|----------|---------|
+| **Memory Bank** | `.pantheon/memory-bank/` | Team | Permanent, versioned | Project context: architecture, patterns, progress |
+| **VS Code `/memories/`** | `.vscode/` or workspace | Agent | Session/repo scoped | Atomic facts, conversation plans |
+
+---
+
+## Memory Bank Structure
+
+```
+.pantheon/memory-bank/
+├── 00-project.md           ← What is this project? (fill once)
+├── 00-architecture.md      ← System design and agent hierarchy
+├── 00-components.md        ← Component breakdown and ownership
+├── 00-tech-stack.md        ← Tech stack, setup, environment
+├── 01-active-context.md    ← Current sprint focus, decisions, blockers (MOST IMPORTANT)
+├── 02-progress-log.md      ← What works, what's left, milestones (append-only)
+├── _tasks/
+│   ├── _index.md           ← Task master list
+│   └── TASK0001-name.md    ← Individual task records
+└── _notes/
+    ├── _index.md           ← Notes index
+    └── NOTE0001-topic.md   ← Architectural decisions, findings
+```
+
+### File Update Frequency
+
+| File | Fill when | Update frequency |
+|------|-----------|-----------------|
+| `00-project.md` | Project start | Rarely |
+| `00-architecture.md` | Project start | On significant changes |
+| `00-components.md` | Project start | When components added/removed |
+| `00-tech-stack.md` | Project start | On stack changes |
+| `01-active-context.md` | Each sprint | Each sprint / major decision |
+| `02-progress-log.md` | First completion | Append-only per milestone |
+| `_tasks/` | Sprint tracking | Per task |
+| `_notes/` | Significant findings | Per finding |
+
+---
+
+## Golden Rules
+
+1. **Never create `.md` files outside `.pantheon/memory-bank/`** (except `README.md`, `CONTRIBUTING.md`)
+2. **Never create `ANALYSIS_*.md`, `SUMMARY_*.md`, `STATUS_*.md`** anywhere
+3. **`01-active-context.md` is the priority file** — keep it current
+4. **`02-progress-log.md` is append-only** — never edit history
+5. **`_notes/` decisions are immutable** — supersede, never edit
+
+---
+
+## Session → Active Context Graduation
+
+```
+During sprint:
+  Athena writes plan → /memories/session/sprint-plan.md   (ephemeral)
+  Agents track wip   → /memories/session/wip.md            (ephemeral)
+
+At sprint close:
+  @mnemosyne consolidates → .pantheon/memory-bank/01-active-context.md
+                          → .pantheon/memory-bank/02-progress-log.md (appended)
+```
+
+---
+
+## Who Writes What
+
+| Content | Written by | Where |
+|---------|-----------|-------|
+| Project overview, architecture | Mnemosyne (at init) | `00-03.md` |
+| Sprint context, decisions | Agent / Mnemosyne | `01-active-context.md` |
+| Milestone completions | Any agent | `02-progress-log.md` (append) |
+| Task records | Mnemosyne (on request) | `_tasks/TASK000X-*.md` |
+| Architecture decisions | Mnemosyne (on request) | `_notes/NOTE000X-*.md` |
+| Atomic facts | Any agent | `/memories/repo/` |
+| Conversation plans | Athena / any agent | `/memories/session/` |
+
+---
+
+## Optimization: Compression Rules
+
+### Problem: Memory bank files grow too large, wasting tokens on every load.
+
+### Strategy: Lazy-load only what's needed
+
+| Rule | Before | After |
+|------|--------|-------|
+| **Active context** | 500+ lines of history | 50 lines: current sprint only |
+| **Progress log** | Everything since day 1 | Link to archived logs; keep last 50 lines |
+| **Task records** | All tasks in one file | One file per task; archive completed |
+| **Notes** | Long narrative | Bullet points with links to source |
+
+### Compression Targets
+
+- `01-active-context.md`: Keep under 100 lines. Archive old sprints to `_notes/`.
+- `02-progress-log.md`: Keep last 20 entries. Archive older to `_notes/archive/`.
+- `_tasks/`: Mark completed tasks `[x]`, move to `_tasks/archive/`.
+
+### Commands
+
+```
+@mnemosyne Compress memory bank          # Audit and compress all files
+@mnemosyne Archive completed tasks       # Move done tasks to archive
+@mnemosyne Trim active context           # Keep only current sprint
+```
+
+---
+
+## Anti-Patterns
+
+### ❌ Session output as files
+```
+# Wrong
+Create IMPLEMENTATION_SUMMARY.md
+Create STATUS.md
+
+# Right
+@mnemosyne Append to 02-progress-log.md: [summary]
+```
+
+### ❌ Mandatory handoff after every phase
+```
+# Wrong: After every phase → handoff to @mnemosyne
+
+# Right: Agent appends to 01-active-context.md directly
+At sprint close → explicit @mnemosyne invocation
+```
+
+### ❌ Duplicating information
+```
+# Wrong: Stack in 00-project.md AND /memories/repo/stack.json
+
+# Right: Atomic facts → /memories/repo/ (auto-loaded)
+         Narrative context → 00-project.md (explicit read)
+```
+
+---
+
+## Adopting in a Product
+
+```bash
+mkdir -p .pantheon/memory-bank/_tasks .pantheon/memory-bank/_notes
+touch .pantheon/memory-bank/_tasks/.gitkeep .pantheon/memory-bank/_notes/.gitkeep
+# @mnemosyne Initialize memory bank for this repository
+```
+
+Add to `.github/copilot-instructions.md`:
+```markdown
+Always read .pantheon/memory-bank/01-active-context.md before answering.
+```

package/src/skills/orchestration-workflow/SKILL.md

@@ -0,0 +1,311 @@
+---
+name: orchestration-workflow
+description: "Practical step-by-step walkthrough for orchestrating features end-to-end using the multi-agent system, from planning through deployment"
+context: fork
+globs: ["**/AGENTS.md", "**/agents/*.agent.md"]
+alwaysApply: false
+---
+
+# Orchestration Workflow: Step-by-Step Guide
+
+Practical walkthrough for using the multi-agent system end-to-end. This is your "how-to" guide for orchestrating features from planning through production deployment.
+
+---
+
+## Your First Feature (Real Example)
+
+**Scenario:** You want to add JWT authentication to your app.  
+**Time:** ~6-8 hours total (spread across 1-2 days)  
+**Team:** All agents working together  
+**Result:** Complete feature with 95% coverage, security audit passed, ready to deploy
+
+---
+
+## Step 1: Plan the Feature (30 minutes)
+
+### What You Do
+
+Open VS Code, start a chat with Copilot:
+
+```
+@athena: Plan JWT authentication with refresh tokens
+
+Requirements:
+- User login with email + password
+- JWT access token (15 min expiry)
+- Refresh token (7 day expiry)
+- Secure token storage (httpOnly cookies)
+- Token verification on protected routes
+- Rate limiting (5 attempts/min)
+- OWASP Top 10 compliant
+
+Please create a detailed 3-4 phase implementation plan.
+```
+
+### What Athena Does
+
+Athena researches patterns, calls Apollo for existing auth code, and creates:
+
+```
+📋 Plan: JWT Authentication
+├─ Phase 1: Database Schema (Demeter)
+│  ├─ Tasks: Create user + token tables
+│  ├─ Test requirements: 5 test cases
+│  └─ Risk: Zero-downtime migration
+├─ Phase 2: Backend Services (Hermes)
+│  ├─ Tasks: JWT service + endpoints
+│  ├─ Test requirements: 8 test cases
+│  └─ Risk: Token expiry edge cases
+├─ Phase 3: Frontend Integration (Aphrodite)
+│  ├─ Tasks: LoginForm + useAuth hook
+│  ├─ Test requirements: 6 test cases
+│  └─ Risk: Token refresh race condition
+└─ FAQ: Answers to common questions
+```
+
+### What You Do
+
+1. Review the plan presented by Athena in chat
+2. **Ask questions or approve**
+   - If concerns: `@athena: Please adjust plan because...`
+   - If approved: "Plan looks good, let's proceed"
+
+### ⏸️ PAUSE POINT 1: Plan Approval
+
+```
+Athena: ✅ Plan approved! Ready to orchestrate implementation
+Zeus: Starting Phase 1 - Database Schema
+```
+
+---
+
+## Step 2: Orchestrate Implementation
+
+### Phase 1: Database Schema
+
+**Zeus delegates to Demeter:**
+```
+@demeter: Implement database schema for JWT auth
+
+Requirements:
+- User table: id, email, hashed_password
+- Token table: id, user_id, token, issued_at, expires_at, revoked_at
+- Indexes: user(email), token(user_id, token)
+
+TDD: RED → GREEN → REFACTOR
+Coverage target: >80%
+```
+
+**Demeter does:**
+1. Write FAILING migration test (RED)
+2. Write minimal migration (GREEN)
+3. Refactor (REFACTOR) — add types, indexes, constraints, timestamps
+
+**Demeter delivers:** Schema files + tests, >80% coverage
+
+**Themis reviews:** Coverage, security, performance, tests → APPROVED
+
+**Background dispatch for independent phases (OpenCode v1.16.2+):**
+If Phase 2 (backend) and Phase 3 (frontend) have no file dependencies, Zeus can dispatch both in **background** simultaneously and continue working while they execute. This eliminates the sequential wait.
+
+### ⏸️ PAUSE POINT 2: Phase Review
+
+```
+Zeus: "Phase 1 complete! Coverage: >80% ✅ Security: ✅ Tests: passing ✅
+Ready to continue to Phase 2?"
+
+User: "continue"
+```
+
+### Phase 2: Backend Services
+
+**Zeus delegates to Hermes:**
+```
+@hermes: Implement backend services for JWT auth
+
+Create:
+1. JWTService: generate, verify, refresh JWT
+2. AuthService: handle login/logout
+3. Auth endpoints: POST /auth/login, POST /auth/refresh, GET /auth/verify
+
+TDD: RED → GREEN → REFACTOR
+Coverage target: >80%
+```
+
+**Hermes does (TDD):**
+1. Write failing test for JWT generation (RED)
+2. Write minimal JWT service (GREEN)
+3. Refactor with proper types, error handling (REFACTOR)
+4. Repeat for all endpoints
+
+**Hermes delivers:** Services + tests, >80% coverage
+
+**Themis reviews:** Coverage, security (OWASP), performance → APPROVED
+
+### ⏸️ PAUSE POINT 2: Phase Review
+
+```
+Zeus: "Phase 2 complete! Coverage: >80% ✅ Security: OWASP ✅ Tests: passing ✅
+Ready to continue to Phase 3?"
+
+User: "continue"
+```
+
+### Phase 3: Frontend Integration
+
+**Zeus delegates to Aphrodite:**
+```
+@aphrodite: Implement frontend for JWT auth
+
+Create:
+1. LoginForm component
+2. useAuth hook for state management
+3. Protected route wrapper
+
+TDD: RED → GREEN → REFACTOR
+Coverage target: >80%
+```
+
+**Aphrodite does (TDD):**
+1. Write failing component test (RED)
+2. Write minimal component (GREEN)
+3. Refactor with proper accessibility, error handling (REFACTOR)
+
+**Aphrodite delivers:** Components + tests, >80% coverage
+
+**Themis reviews:** Coverage, accessibility, security → APPROVED
+
+### ⏸️ PAUSE POINT 2: Phase Review
+
+```
+Zeus: "Phase 3 complete! Coverage: >80% ✅ Accessibility: ✅ Tests: passing ✅
+All phases approved!"
+```
+
+---
+
+## Step 3: Final Summary
+
+```
+✅ JWT Authentication Complete
+
+📊 Metrics:
+- 3 phases: Database, Backend, Frontend
+- >80% coverage across all layers
+- Security: OWASP compliant ✅
+- All tests passing ✅
+
+🚀 Ready to commit
+```
+
+---
+
+## Step 4: Git Commit
+
+### ⏸️ PAUSE POINT 3: Git Commit
+
+```
+Zeus: "All phases approved! Ready to commit."
+
+Suggested commit message:
+feat: Add JWT authentication with refresh tokens
+
+- Create User + Token database schema
+- Implement JWTService + AuthService
+- Add login, refresh, verify endpoints
+- Create LoginForm + useAuth hook
+- Full TDD: >80% coverage
+- Security: OWASP Top 10 compliant
+
+User: git add -A && git commit -m "..."
+```
+
+---
+
+## Quick Reference: Workflow Commands
+
+```bash
+# Step 1: Plan
+@athena: Plan [feature description]
+
+# Step 2: Orchestrate
+@zeus: Implement feature using plan
+
+# Step 3: At pause points
+# - Review phase results
+# - Approve before proceeding
+
+# Step 4: Commit
+git add -A
+git commit -m "feat: ..."
+
+# Step 5: Deploy
+git push origin [branch]
+```
+
+---
+
+## Troubleshooting
+
+### Problem: Phase coverage is <80%
+**Solution:** Implementer adds missing test cases, re-runs coverage, Themis re-reviews.
+
+### Problem: Security audit found issue
+**Solution:** Relevant agent fixes (parameterized queries, input validation), re-audit, Themis approves.
+
+### Problem: Frontend accessibility below target
+**Solution:** Aphrodite improves ARIA labels, keyboard navigation, re-checks, Themis approves.
+
+---
+
+## Common Patterns
+
+### Pattern 1: Simple Bug Fix (Skip Athena)
+```
+Discovery: @apollo: Find bug in authentication
+Fix:      @hermes: Fix the validation error
+Review:   @themis: Auto-invoked after fix
+Result:   Minimal change, minimal risk (~30 min)
+```
+
+### Pattern 2: Complex Feature (Full System)
+```
+Plan:        @athena: Plan architecture
+Orchestrate: @zeus: Implement using plan
+Result:      Complete feature, >80% coverage (1-2 days)
+```
+
+### Pattern 3: Database Optimization
+```
+Discovery:   @apollo: Find N+1 queries
+Optimize:    @demeter: Add indexes + optimize
+Review:      @themis: Auto-invoked
+Result:      10x faster queries (~2 hours)
+```
+
+---
+
+## Pro Tips
+
+🎯 **Plan First** — Saves 2-3x rework time  
+🎯 **Use Pause Points** — You control when to proceed  
+🎯 **Trust Themis** — Code review catches issues early  
+🎯 **Commit Atomically** — One phase = one commit  
+🎯 **Test First** — RED tests before code  
+🎯 **Coverage Matters** — <80% = blocked, no exceptions  
+🎯 **Security First** — Themis enforces OWASP compliance  
+🎯 **Background Dispatch** — Use OpenCode v1.16.2+ background agents to run independent phases in parallel without polling  
+
+---
+
+## Next Steps
+
+1. ✅ Read this guide
+2. ✅ Review agent reference in `agent-coordination/SKILL.md`
+3. ✅ Review TDD standards in `tdd-with-agents/SKILL.md`
+4. 🚀 Start your first feature: `@athena: Plan [your idea]`
+
+---
+
+**Philosophy:** Plan → Orchestrate → Review → Commit → Deploy
+Every phase has a pause point where YOU control the outcome.

package/src/skills/security-hardening/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: security-hardening
+description: "Security gate — OWASP, SAST, secrets, MCP hardening, dependency audit"
+---
+
+# Security Hardening
+
+**Código inseguro em produção = pesadelo. Isso é não-negociável.**
+
+## Scope
+| Domain | Coverage |
+|--------|----------|
+| **SAST** | SQL injection, XSS, CSRF, path traversal, command injection |
+| **MCP** | Credential leakage prevention, tool access control, input sanitization |
+| **Secrets** | No hardcoded keys, tokens, passwords in code/logs |
+| **Deps** | Known CVEs, outdated packages, deprecated libs |
+| **Container** | Non-root user, health checks, minimal base images |
+
+## MCP Security (Mandatory)
+- Never log credentials, tokens, or API keys
+- Validate all MCP inputs
+- Restrict tool access per agent via `mcp_tools` YAML field
+- Audit MCP server URLs (no unverified endpoints)
+
+## SAST Checklist
+- [ ] Input validation on ALL endpoints
+- [ ] Parameterized queries (no string concatenation)
+- [ ] CSRF protection on state-changing requests
+- [ ] Rate limiting on sensitive endpoints
+- [ ] Safe error messages (no stack traces to client)
+
+## Dep Audit
+```bash
+pip-audit --requirement requirements.txt
+npm audit
+```

package/src/skills/session-goal/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: session-goal
+description: "Pin session objectives to prevent scope creep. Use for alignment across long multi-agent sessions."
+context: fork
+globs: []
+alwaysApply: false
+---
+
+# Session Goal — Alignment Anchor
+
+Use this skill to pin a session objective at the start of a long or complex session. All subsequent todos, delegation decisions, and verification steps must align with the pinned goal.
+
+---
+
+## Usage
+
+Invoke via the `/focus` command:
+
+```
+/focus Implement JWT authentication with refresh token rotation
+```
+
+Or state it explicitly at the start of a session:
+
+```
+SESSION GOAL: Add product review feature with backend, frontend, and database layers.
+All work in this session must serve this goal.
+```
+
+---
+
+## What Pinning a Goal Does
+
+1. **Focuses todos** — every todo added must relate to the goal
+2. **Focuses delegation** — Zeus only invokes agents relevant to the goal
+3. **Focuses verification** — Themis checks that implementations serve the goal
+4. **Surfaces drift** — if a task drifts from the goal, flag it before proceeding
+
+---
+
+## Goal Format
+
+A good session goal has 4 components:
+
+```
+GOAL: <What to build>
+SCOPE: <Which layers/modules are in scope>
+SUCCESS CRITERIA: <How we know it's done>
+OUT OF SCOPE: <What to explicitly exclude>
+```
+
+**Example:**
+```
+GOAL: Add email verification to the registration flow
+SCOPE: Backend (POST /auth/verify, token model), Frontend (VerifyEmail page), DB (verification_tokens table)
+SUCCESS CRITERIA: User can register, receive a verification email link, click it, and have their account marked as verified. All layers tested >80% coverage.
+OUT OF SCOPE: Password reset, 2FA, email template design
+```
+
+---
+
+## Alignment Check Pattern
+
+Before each major delegation or decision, run this quick check:
+
+> "Does this task directly serve the pinned goal?"
+> - **Yes** → proceed
+> - **Partial** → flag the out-of-scope portion and ask for clarification
+> - **No** → defer to a future session, note it as a separate task
+
+---
+
+## Cross-Session Persistence
+
+For goals that span multiple sessions, write the goal to `/memories/session/`:
+
+```
+/memories/session/current-goal.md
+
+# Active Session Goal
+Goal: Implement JWT authentication
+Started: 2026-05-15
+Status: Phase 2 of 3 (backend done, frontend in progress)
+Next: POST /auth/refresh endpoint
+```
+
+This ensures the goal survives context compaction and session restarts.
+
+---
+
+## When to Update the Goal
+
+- When the user explicitly redirects the session
+- When a phase completes and the next phase has a different scope
+- When an unexpected blocker changes the scope
+
+Never silently drift from the goal — always confirm with the user before changing it.
+
+---
+
+## Session Reuse (Cross-Task Continuity)
+
+Reuse agent sessions between related delegations to avoid re-reading files and re-building context.
+
+### When to Reuse
+
+Prefer reusing an existing session when:
+- Follow-up task touches the **same files** or **same feature thread** as a previous delegation
+- The specialist already loaded relevant file context in the prior session
+- Debugging continues on the same stack trace or module
+
+### When to Start Fresh
+
+Force a new session when:
+- Unrelated feature or different part of the codebase
+- Previous session has too much noise from an abandoned investigation
+- The specialist's accumulated context would mislead the new task
+
+### How to Signal Reuse
+
+When dispatching a follow-up task, include the session reuse context explicitly:
+
+```
+@hermes — continuing the auth endpoint work from the previous session.
+Files already explored: backend/routers/auth.py, backend/services/auth_service.py.
+New task: add refresh token rotation.
+```
+
+### Session Tracking
+
+Zeus tracks active sessions with a `task_id` per delegation:
+
+| Agent | Active Session | Files in Context | Max Age |
+|-------|---------------|-----------------|---------|
+| hermes | ses_abc123 | 4 files | 15 min |
+| aphrodite | ses_def456 | 3 files | 15 min |
+
+When `session_max: 2` is set in routing.yml, Zeus keeps the last 2 sessions for that agent and discards older ones. This prevents stale context from accumulating.