oh-my-customcodex 0.1.0

package/templates/.claude/skills/action-validator/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: action-validator
+description: Pre-action boundary checking — validates agent tool calls against declared capabilities and task contracts
+scope: core
+user-invocable: false
+---
+
+# Action Validator Skill
+
+## Purpose
+
+Advisory pre-action validation layer that checks agent tool calls against declared capabilities, file access scope (R002), and task contracts before execution. Inspired by AutoHarness (Google DeepMind) — enforcing action-space legality at agent boundaries.
+
+This skill does NOT block actions (R021 advisory-first model). It emits warnings when agents attempt operations outside their declared scope.
+
+## Validation Checks
+
+| Check | What | Against |
+|-------|------|---------|
+| Tool scope | Tool being called | Agent's `tools` frontmatter list |
+| File scope | File path in Write/Edit | R002 file access rules |
+| Domain scope | Target file extension | Agent's `domain` frontmatter |
+| Task contract | Operation type | Task description constraints |
+
+## Advisory Format
+
+```
+--- [Action Validator] Scope warning ---
+  Agent: {agent-name}
+  Tool: {tool-name}
+  Target: {file-path}
+  Issue: {description}
+  Declared scope: {agent's declared tools/domain}
+  💡 Suggestion: {recommended action}
+---
+```
+
+## Integration Points
+
+| System | How |
+|--------|-----|
+| PreToolUse hooks | Optional hook to check tool calls (advisory only) |
+| pipeline-guards | Complements pipeline stage gates |
+| adversarial-review | Provides action-space-legality criterion |
+| R002 (Permissions) | Validates against declared file access rules |
+| R010 (Orchestrator) | Orchestrator validates subagent scope claims |
+
+## Policy Cache Pattern
+
+For high-repetition agents (e.g., mgr-gitnerd commit workflows), capture validated decision paths as reusable policies:
+
+```yaml
+policy_cache:
+  agent: mgr-gitnerd
+  action: git-commit
+  validated_steps:
+    - tool: Bash
+      pattern: "git add *"
+      verdict: allow
+    - tool: Bash
+      pattern: "git commit *"
+      verdict: allow
+    - tool: Bash
+      pattern: "git push *"
+      verdict: warn_confirm
+```
+
+Policy caching reduces redundant LLM calls for well-understood workflows. Policies are advisory — the orchestrator may override.
+
+## Code Harness Integration (AutoHarness)
+
+When a synthesized harness exists for an agent (`.codex/outputs/harnesses/{agent-name}-*.yaml`), action-validator can use it for enhanced validation:
+
+| Mode | Source | Behavior |
+|------|--------|----------|
+| Advisory (default) | Prompt-based checks | Emit warnings only |
+| Code-verified | harness-synthesizer output | Run harness validation code, emit advisory results |
+| Hard-enforce (opt-in) | harness-synthesizer `--hard-enforce` | Block invalid actions (requires explicit opt-in, see R021) |
+
+To generate a harness for an agent: `/harness-synthesizer --agent {name} --mode verifier`
+
+Code harness validation is additive — it supplements prompt-based checks, not replaces them.
+
+## Scope
+
+This skill is an advisory layer, not a hard enforcement mechanism:
+- **Does**: Emit warnings, log scope violations, suggest corrections
+- **Does NOT**: Block tool execution, modify agent behavior, override R021
+- **Future**: May integrate with PreToolUse hooks for automated checking (see R021 promotion criteria)

package/templates/.claude/skills/adaptive-harness/SKILL.md

@@ -0,0 +1,335 @@
+---
+name: omcodex:adaptive-harness
+description: Auto-detect project context and optimize harness — deactivate unused agents/skills, suggest missing experts, generate project profile
+scope: harness
+version: 1.0.0
+user-invocable: true
+argument-hint: "[--optimize|--scan|--learn|--export|--import|--dry-run] [target-dir]"
+effort: high
+---
+
+# Adaptive Harness Self-Customization Skill
+
+Automatically detects project context and optimizes the oh-my-customcodex harness (agents, skills, rules) to fit the project. Generates a persistent project profile that drives agent activation decisions and records learned patterns over time.
+
+## Usage
+
+```
+/omcodex:adaptive-harness              # Full scan + optimize
+/omcodex:adaptive-harness --scan       # Scan only (generate/update project profile)
+/omcodex:adaptive-harness --optimize   # Deactivate unused, suggest missing
+/omcodex:adaptive-harness --learn      # Analyze failure patterns, update profile
+/omcodex:adaptive-harness --export     # Export profile as portable bundle
+/omcodex:adaptive-harness --import <path>  # Import profile from another project
+/omcodex:adaptive-harness --dry-run    # Show what would change without modifying
+```
+
+Default (no flag): runs `--scan` then `--optimize` in sequence.
+
+## Project Profile Format
+
+The skill generates and maintains `.codex/project-profile.yaml`. Manual edits to this file are preserved across runs — the skill merges new detections with existing content rather than overwriting.
+
+```yaml
+# Auto-generated by adaptive-harness. Manual edits will be preserved.
+project:
+  name: detected-project-name
+  scanned_at: "2026-04-12T10:00:00Z"
+
+tech_stack:
+  languages: [python, typescript]
+  frameworks: [fastapi, next.js]
+  databases: [postgres, redis]
+  infra: [docker, aws]
+
+detection_evidence:
+  - indicator: "requirements.txt found"
+    confidence: high
+    suggests: [lang-python-expert, be-fastapi-expert]
+  - indicator: "package.json with next dependency"
+    confidence: high
+    suggests: [lang-typescript-expert, fe-vercel-agent]
+
+active_agents:
+  - lang-python-expert
+  - be-fastapi-expert
+  - lang-typescript-expert
+  - fe-vercel-agent
+  - db-postgres-expert
+  - db-redis-expert
+  - infra-docker-expert
+  - infra-aws-expert
+  # manager agents always active
+  - mgr-creator
+  - mgr-gitnerd
+  - mgr-sauron
+  - mgr-supplier
+  - mgr-updater
+  - mgr-claude-code-bible
+
+inactive_agents:
+  - lang-golang-expert    # no Go files detected
+  - lang-rust-expert      # no Rust files detected
+
+usage_stats:
+  most_used_agents: []     # populated by --learn
+  failure_patterns: []     # populated by --learn
+
+overrides:
+  rules: {}                # e.g., R009: { max_parallel: 5 }
+
+last_optimized: "2026-04-12T10:00:00Z"
+```
+
+## Workflow: --scan
+
+Scans the TARGET project (the project using oh-my-customcodex, not the harness itself) and generates or updates the project profile. Uses Read, Glob, and Grep only — no side effects.
+
+### Step 1: Detect Tech Stack
+
+Check for language manifest files and framework indicators:
+
+| Indicator Files | Tech | Suggests Agents |
+|----------------|------|-----------------|
+| `go.mod`, `*.go` | Go | lang-golang-expert, be-go-backend-expert |
+| `Cargo.toml`, `*.rs` | Rust | lang-rust-expert |
+| `requirements.txt`, `pyproject.toml`, `*.py` | Python | lang-python-expert |
+| `fastapi` in deps/imports | FastAPI | be-fastapi-expert |
+| `django` in deps/imports | Django | be-django-expert |
+| `package.json`, `tsconfig.json`, `*.ts`, `*.tsx` | TypeScript | lang-typescript-expert |
+| `next` in package.json deps | Next.js | fe-vercel-agent |
+| `vue` in package.json deps | Vue.js | fe-vuejs-agent |
+| `svelte.config.*`, `*.svelte` | Svelte | fe-svelte-agent |
+| `pubspec.yaml`, `*.dart` | Flutter | fe-flutter-agent |
+| `*.kt`, `build.gradle.kts` | Kotlin | lang-kotlin-expert |
+| `*.java`, `pom.xml` | Java | lang-java21-expert |
+| `spring-boot` in deps | Spring Boot | be-springboot-expert |
+| `express` in package.json deps | Express | be-express-expert |
+| `@nestjs` in package.json deps | NestJS | be-nestjs-expert |
+| `Dockerfile`, `docker-compose.*` | Docker | infra-docker-expert |
+| `cdk.json`, `template.yaml`, `.aws/` | AWS | infra-aws-expert |
+| `terraform/`, `*.tf` | Terraform | infra-aws-expert |
+| `.github/workflows/` | CI/CD | mgr-gitnerd |
+| `*.sql`, `alembic/`, `pg` in deps | PostgreSQL | db-postgres-expert |
+| `redis` in deps/config | Redis | db-redis-expert |
+| `supabase` in deps/config | Supabase | db-supabase-expert |
+| `prisma/`, `drizzle/` | ORM | db-postgres-expert |
+| `dags/*.py`, `airflow` in deps | Airflow | de-airflow-expert |
+| `dbt_project.yml` | dbt | de-dbt-expert |
+| `kafka` in deps/config | Kafka | de-kafka-expert |
+| `spark` in deps/config | Spark | de-spark-expert |
+| `snowflake` in deps/config | Snowflake | de-snowflake-expert |
+
+### Step 2: Build Detection Evidence
+
+For each indicator found, record:
+- `indicator`: human-readable description of what was found
+- `confidence`: `high` (direct manifest file) | `medium` (dependency reference) | `low` (indirect signal)
+- `suggests`: list of agent names this indicator implies
+
+### Step 3: Write Project Profile
+
+Delegate write to a subagent (R010). Merge with existing profile if present — preserve `overrides`, `usage_stats`, and any manual entries.
+
+Output format:
+
+```
+[adaptive-harness --scan] Target: /path/to/project
+
+Tech Stack Detected:
+  - Python     (requirements.txt + pyproject.toml found)      [confidence: high]
+  - FastAPI    ("fastapi" in requirements.txt)                [confidence: high]
+  - TypeScript (tsconfig.json found)                          [confidence: high]
+  - Next.js    ("next" in package.json deps)                  [confidence: high]
+  - Docker     (Dockerfile found)                             [confidence: high]
+  - PostgreSQL ("psycopg2" in requirements.txt)               [confidence: medium]
+  - Redis      ("redis" in requirements.txt)                  [confidence: medium]
+  - AWS        (cdk.json found)                               [confidence: high]
+
+Active agents identified: 8
+Profile written: .codex/project-profile.yaml
+```
+
+## Workflow: --optimize
+
+Reads the project profile and adjusts which agent files are active.
+
+### Step 1: Load Profile
+
+Read `.codex/project-profile.yaml`. If the profile does not exist, run `--scan` first.
+
+### Step 2: Identify Inactive Agents
+
+Compare all agent files in `.codex/agents/*.md` against `active_agents` list from the profile. Agents not in the active list (and not in the always-active set below) are candidates for deactivation.
+
+### Always-Active Agents (never deactivate)
+
+```
+mgr-creator, mgr-gitnerd, mgr-sauron, mgr-supplier, mgr-updater, mgr-claude-code-bible
+sys-memory-keeper, sys-naggy
+arch-documenter, arch-speckit-agent
+```
+
+### Step 3: Move Inactive Agents
+
+Delegate to subagent (R010):
+- Create `.codex/agents/.inactive/` directory if it does not exist
+- Move inactive agent `.md` files to `.codex/agents/.inactive/`
+- Update `inactive_agents` list in project profile
+
+### Step 4: Detect Gaps
+
+Check `active_agents` list against files actually present in `.codex/agents/`. If an active agent file is missing, flag it as a gap and suggest `mgr-creator` to fill it.
+
+### Step 5: Log Adaptations
+
+Append a record to `.codex/outputs/harness-adaptations/YYYY-MM-DD.md`:
+
+```markdown
+## Optimization Run — 2026-04-12T10:00:00Z
+
+Deactivated (moved to .inactive/):
+  - lang-golang-expert
+  - lang-rust-expert
+  - de-airflow-expert
+
+Gaps detected (agents needed but missing):
+  - (none)
+
+Profile: .codex/project-profile.yaml
+```
+
+### Restore
+
+Run `--optimize --restore` to move all files from `.codex/agents/.inactive/` back to `.codex/agents/`. This reverses the last optimization.
+
+Output format:
+
+```
+[adaptive-harness --optimize]
+
+Always-active agents: 10 (protected)
+Active per profile:   8
+Candidates for deactivation: 29
+
+Deactivated:
+  - lang-golang-expert      → .codex/agents/.inactive/
+  - lang-rust-expert        → .codex/agents/.inactive/
+  - de-airflow-expert       → .codex/agents/.inactive/
+  ... (26 more)
+
+Gaps detected: 0
+
+Log: .codex/outputs/harness-adaptations/2026-04-12.md
+Summary: 29 deactivated, 18 active, 0 gaps
+```
+
+**--dry-run** mode outputs `[would deactivate]` / `[would restore]` without moving any files.
+
+## Workflow: --learn
+
+Analyzes session history and eval-core data to populate `usage_stats` and `failure_patterns` in the project profile.
+
+### Step 1: Collect Data Sources
+
+- `.codex/outputs/` — session artifacts and eval results
+- `.codex/agent-memory/` — agent memory files with usage patterns
+- Any harness eval output from `/omcodex:harness-eval`
+
+### Step 2: Extract Patterns
+
+```
+Most-used agents:   Count agent invocations across outputs
+Failure patterns:   Identify agents that frequently retried or errored
+Unused agents:      Active agents with zero invocations in recent N sessions
+```
+
+### Step 3: Update Profile
+
+Merge findings into `usage_stats` and `failure_patterns` sections of the project profile. Preserve existing entries; append new ones.
+
+### Step 4: Generate Suggestions
+
+Based on failure patterns, suggest:
+- Rule overrides (e.g., increase `max_parallel` if timeout patterns detected)
+- Agent replacements (e.g., suggest escalation to `opus` model for frequently failing tasks)
+- Additional skills that may reduce failure rate
+
+Output format:
+
+```
+[adaptive-harness --learn]
+
+Sessions analyzed: 12
+Agent invocations found: 847
+
+Most-used agents (top 5):
+  1. lang-python-expert    (312 invocations)
+  2. be-fastapi-expert     (189 invocations)
+  3. mgr-gitnerd           (97 invocations)
+  4. db-postgres-expert    (84 invocations)
+  5. lang-typescript-expert (71 invocations)
+
+Failure patterns:
+  - db-postgres-expert: 3 retries in session 2026-04-10 (timeout pattern)
+  
+Suggestions:
+  - db-postgres-expert: consider effort: high for complex query generation
+  - de-kafka-expert: 0 invocations — candidate for deactivation
+
+Profile updated: .codex/project-profile.yaml
+```
+
+## Workflow: --export / --import
+
+### Export
+
+Bundles the project profile and active agent list for sharing with another project or team member.
+
+Output: `.codex/outputs/harness-bundle-YYYY-MM-DD.json`
+
+```json
+{
+  "version": "1.0.0",
+  "exported_at": "2026-04-12T10:00:00Z",
+  "source_project": "detected-project-name",
+  "profile": { ... },
+  "active_agent_names": [ ... ]
+}
+```
+
+### Import
+
+```
+/omcodex:adaptive-harness --import .codex/outputs/harness-bundle-2026-04-12.json
+```
+
+Reads the bundle and applies the `active_agents` list to the current project by running `--optimize` with the imported profile. Does not overwrite `usage_stats` or `failure_patterns` from the current project.
+
+## Execution Rules
+
+- `--scan` uses Read, Glob, Grep only — no writes, safe to run anytime
+- All file writes (profile, logs, agent moves) are delegated to subagents (R010)
+- `--dry-run` suppresses all writes; outputs `[would ...]` for every action
+- Profile changes are always logged to `.codex/outputs/harness-adaptations/` for auditability
+- When profile already exists, the skill merges new detections rather than overwriting
+- Parallel Glob/Grep calls are used during `--scan` for performance (R009)
+
+## Integration
+
+| Component | Interaction |
+|-----------|-------------|
+| `/omcodex:analysis` | Calls adaptive-harness `--scan` after initial tech stack detection to persist the profile |
+| `SessionStart` hook | Lightweight profile existence check only — no full scan at startup |
+| `mgr-creator` | Invoked when gaps are detected during `--optimize` to create missing agent files |
+| `R016` (Continuous Improvement) | Failure patterns from `--learn` may trigger rule updates |
+| `eval-core` | Primary data source for `--learn` invocation and usage pattern extraction |
+| `mgr-sauron` | Run after `--optimize` to verify structural integrity (R017) |
+
+## Notes
+
+- Always run `--dry-run` first on a new project to preview deactivation scope
+- `--optimize --restore` is the safe exit if deactivation causes unexpected routing failures
+- The `.inactive/` directory is git-tracked so deactivation decisions are visible in history
+- Manager and system agents are unconditionally protected from deactivation
+- Target directory defaults to the project root of the current GPT Codex + OMX session, not the child-package source directory

package/templates/.claude/skills/adversarial-review/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: adversarial-review
+description: Adversarial code review using attacker mindset — trust boundary, attack surface, business logic, and defense evaluation
+scope: core
+argument-hint: "<file-or-directory> [--depth quick|thorough]"
+user-invocable: true
+---
+
+# Adversarial Code Review
+
+Review code from an attacker's perspective using STRIDE + OWASP frameworks.
+
+## 4-Phase Review Process
+
+### Phase 1: Trust Boundary Analysis
+Identify where trust transitions occur:
+- External input reaching internal logic without validation → **Tampering**
+- Implicit trust between services → **Elevation of Privilege**
+- Shared storage without isolation → **Information Disclosure**
+- Authentication boundaries not clearly marked → **Spoofing**
+
+Output: `[TRUST-BOUNDARY]` findings with location, threat type, and current validation level.
+
+### Phase 2: Attack Surface Mapping
+Map all entry points and exposure:
+- Public API endpoints and auth requirements
+- File upload/download paths → Path traversal risk
+- External system calls (URLs, queries) → SSRF/Injection
+- Event handlers and callbacks → Race conditions
+- Error message verbosity → Information Disclosure
+
+Output: `[ATTACK-SURFACE]` table with endpoint, exposure level, and mitigation status.
+
+### Phase 3: Business Logic Review
+Analyze logic flaws that static analysis misses:
+- State machine violations (skip steps, replay)
+- Authorization != authentication (authn ok but authz missing)
+- Race conditions in multi-step operations
+- Numeric overflow/underflow in financial calculations
+- Default-allow vs default-deny patterns
+
+Output: `[LOGIC-FLAW]` findings with exploitation scenario and impact.
+
+### Phase 4: Defense Evaluation
+Assess existing defense mechanisms:
+- Input validation completeness (allowlist vs blocklist)
+- Output encoding consistency
+- Rate limiting and abuse prevention
+- Logging coverage for security events
+- Secret management (hardcoded credentials, env leaks)
+
+Output: `[DEFENSE-GAP]` findings with recommendation.
+
+## Output Format
+
+For each finding:
+```
+[CATEGORY] Severity: HIGH|MEDIUM|LOW
+Location: file:line
+Finding: Description
+Attack: How an attacker would exploit this
+Fix: Recommended remediation
+```
+
+## Depth Modes
+- **quick**: Phase 1 + 2 only (trust boundaries + attack surface)
+- **thorough**: All 4 phases with detailed exploitation scenarios
+
+## Integration
+- Complements `dev-review` (best practices) with attacker perspective
+- Works with `sec-codeql-expert` for pattern-based + logic-based coverage
+- Can be chained: `dev-review` → `adversarial-review` for complete coverage
+- Works with `action-validator` for action-space legality checking
+
+### Action-Space Legality (AutoHarness Pattern)
+
+- [ ] Do agents only call tools within their declared `tools` frontmatter?
+- [ ] Do file operations stay within R002-declared access scope?
+- [ ] Are domain boundaries respected (backend agent not editing frontend files)?
+- [ ] Could an agent's task contract be tightened without losing functionality?

package/templates/.claude/skills/agora/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: omcodex:agora
+description: "Multi-LLM adversarial consensus loop — 3+ LLMs compete to find flaws in designs/specs until unanimous agreement is reached"
+user-invocable: true
+argument-hint: "<document-path> [--rounds N] [--severity-threshold HIGH]"
+effort: max
+scope: core
+version: 1.0.0
+source:
+  type: external
+  origin: github
+  url: https://github.com/baekenough/baekenough-skills
+  version: 1.0.0
+---
+
+# Agora: Multi-LLM Adversarial Consensus
+
+3개 이상의 LLM(Claude, Codex/GPT, Gemini)이 경쟁적으로 설계/문서의 결함을 찾고, 만장일치 합의에 도달할 때까지 반복하는 적대적 교차 검증 스킬.
+
+## Prerequisites
+
+- `codex-exec` skill (Codex/GPT 호출)
+- `gemini-exec` skill (Gemini 호출)
+- Agent Teams enabled (`OMCODEX_AGENT_TEAMS=1`) or Agent tool available
+
+## Usage
+
+```
+/omcodex:agora docs/design.md                           # Default: 3 LLMs, unlimited rounds
+/omcodex:agora docs/design.md --rounds 10               # Max 10 rounds
+/omcodex:agora docs/design.md --severity-threshold HIGH # Exit when no HIGH+ findings
+/omcodex:agora docs/design.md --models claude,codex     # 2 LLMs only
+```
+
+## Workflow
+
+### Phase 1: Setup
+1. Read the target document
+2. Create Agent Team: `TeamCreate("agora-review")`
+3. Create review tasks per focus area
+
+### Phase 2: Spawn Reviewers (parallel)
+Spawn 3 reviewers as Agent Team members:
+
+```
+Agent(name: "claude-critic", model: opus, effort: max)
+  → 20-point deep adversarial review
+  
+Agent(name: "codex-critic", model: opus)
+  → Invoke Skill(codex-exec) for GPT perspective + independent Claude analysis
+  
+Agent(name: "gemini-critic", model: opus)  
+  → Invoke Skill(gemini-exec) for Gemini perspective + independent Claude analysis
+```
+
+### Phase 3: Independent Review
+Each reviewer performs adversarial review with this template:
+
+```
+For EACH review point:
+### Round N: [Topic]
+**Severity**: CRITICAL / HIGH / MEDIUM / LOW
+**Flaw**: [Specific, concrete problem description]
+**Evidence**: [Why this is real, not theoretical]
+**Impact**: [What happens if not addressed]
+**Counter-argument**: [Best case FOR the current design]
+**Verdict**: KEEP / MODIFY / REJECT
+```
+
+Review areas (adapt to document type):
+- Architecture fundamentals
+- Component/service design
+- Data architecture
+- Security & resilience
+- Feasibility & deployment
+- Testing strategy
+- Operational complexity
+
+### Phase 4: Cross-Review (Peer-to-Peer)
+Each reviewer sends findings to the other two via `SendMessage`.
+
+Counter-review template:
+1. Which findings do you **AGREE** with? (and why)
+2. Which findings do you **DISAGREE** with? (evidence-based rebuttal)
+3. What did they **MISS** that you caught?
+4. What did they catch that you **MISSED**?
+5. **SEVERITY** adjustments — upgrade or downgrade with justification
+
+### Phase 5: Synthesis
+Team lead aggregates all findings:
+
+```
+UNANIMOUS CRITICAL: [findings all 3 agreed on]
+STRONG AGREEMENT:   [findings 2/3 agreed on]
+SPLIT DECISIONS:    [findings with disagreement + resolution]
+```
+
+Determine verdict:
+- **BUILD**: No CRITICAL, no unresolved HIGH
+- **BUILD WITH CHANGES**: No CRITICAL, HIGH findings have accepted mitigations
+- **REDESIGN**: Any unresolved CRITICAL findings
+- **ABANDON**: Fundamental concept is flawed
+
+### Phase 6: Loop (if REDESIGN)
+1. Team lead produces/delegates redesign addressing ALL critical findings
+2. New version sent to ALL reviewers: `SendMessage(to: "*")`
+3. Reviewers re-review → GOTO Phase 4
+4. Repeat until EXIT criteria met
+
+### Phase 7: Exit (consensus reached)
+When ALL reviewers agree BUILD or BUILD WITH CHANGES:
+1. Produce final consensus report
+2. Write to `.codex/outputs/sessions/{date}/agora-{topic}-{time}.md`
+3. Shut down team: `SendMessage(to: "*", message: {type: "shutdown_request"})`
+
+## Reviewer Principles
+
+1. **NEUTRAL** — no reviewer has home team advantage
+2. **COMPETITIVE** — find flaws others missed
+3. **CRITICAL** — "fewer than 5 CRITICAL flaws = not looking hard enough"
+4. **EVIDENCE-BASED** — every finding cites specific evidence
+5. **CONSTRUCTIVE** — every flaw includes recommended fix
+6. **CONVERGENT** — goal is consensus, not endless disagreement
+
+## Consensus Criteria
+
+| Condition | Required |
+|-----------|----------|
+| CRITICAL findings resolved | ALL |
+| HIGH findings resolved or accepted | ALL |
+| All reviewers rate BUILD or BUILD WITH CHANGES | YES |
+| Cross-review disagreements resolved | ALL |
+
+## Output Format
+
+```markdown
+# Agora Consensus Report
+
+## Document: [path]
+## Rounds: [N]
+## Reviewers: [list with LLM models used]
+
+## Verdict: [BUILD / BUILD WITH CHANGES / REDESIGN]
+
+## Unanimous Findings
+| # | Finding | Severity | All 3 Agree |
+|---|---------|----------|-------------|
+
+## Required Changes Before Build
+1. [change with source reviewer]
+2. ...
+
+## Accepted Risks
+- [finding accepted with justification]
+
+## Unique Contributions Per Reviewer
+| Reviewer | Findings Others Missed |
+|----------|----------------------|
+
+## Process Metrics
+- Rounds: N
+- Total findings: N
+- Cross-adopted: N
+- Severity upgrades: N
+- Severity downgrades: N
+- Disagreements raised: N
+- Disagreements resolved: N/N
+```
+
+## Configuration
+
+```yaml
+# Default settings
+agora:
+  max_rounds: unlimited       # Set --rounds to limit
+  severity_threshold: HIGH    # EXIT when no findings >= threshold
+  models:
+    - claude (opus, max effort)
+    - codex (via codex-exec skill)
+    - gemini (via gemini-exec skill)
+  review_points: 20           # Per reviewer
+  cross_review: true          # Peer-to-peer sharing
+  auto_redesign: true         # Auto-produce redesign on REDESIGN verdict
+```
+
+## Anti-Patterns
+
+| Anti-Pattern | Why Wrong | Correct |
+|-------------|-----------|---------|
+| Single LLM review | Misses blind spots | 3+ LLMs find complementary flaws |
+| No cross-review | Reviewers don't challenge each other | Peer-to-peer sharing surfaces disagreements |
+| Accepting first BUILD | May miss edge cases | Loop until ALL agree |
+| Ignoring split decisions | Unresolved disagreements fester | Resolve every split with evidence |
+| Push for consensus too fast | Premature agreement | Let reviewers challenge freely |