fix(plugin): fix hooks and add missing skills for reliable skill invocation (#227)

* fix: overhaul Claude Code plugin for correctness and spec compliance

- Fix critical bugs: coder-agent name (CoderAgent→coder-agent), manifest
  path in session-start.sh, /oac:setup ghost command replaced with /install-context
- Fix hooks.json: add timeout/async, add description, restore matcher
- Fix session-start.sh: dual-format output (Claude Code + Cursor/OpenCode),
  remove invalid JSON escapes for $ and backtick
- Fix agent spec compliance: disallowedTools on read-only agents, WebFetch
  on external-scout, haiku model on context-scout, example blocks on 3 agents
- Fix skill descriptions: triggering conditions only (no workflow summaries)
  per superpowers empirical testing — prevents Claude shortcutting skill content
- Add Red Flags + Rationalization tables to 4 discipline skills
- Add install-context skill + command replacing oac-setup/oac-plan/oac-add-context
- Add cleanup-tmp.sh (was missing, broke /oac:cleanup)
- Add TypeScript installer (install-context.ts/js) with profile-based download
- Update plugin.json: keywords, homepage for marketplace discoverability
- Update README: correct skill count, fix structure diagram, remove stale refs
- Remove obsolete files: FIRST-TIME-SETUP.md, INSTALL.md, QUICK-START.md,
  download-context.sh, verify-context.sh, load-config.sh, context-manager skill,
  oac-setup/oac-plan/oac-add-context commands

* add TypeScript and OpenCode context standards files

Adds three new context files covering universal TypeScript patterns,
OpenCode-specific patterns (fn() wrapper, namespaces, Instance.state()),
and context-system-specific TypeScript coding standards.

* fix(plugin): fix hooks and add missing skills for reliable skill invocation

- Rewrite using-oac skill with always-on skill-check rule (was conditional on dev task detection)
- Update session-start.sh to dynamically inject full skill catalogue at session start
- Add brainstorming skill: intercepts creative/build work before any implementation
- Add systematic-debugging skill: 4-phase root cause process before any fix
- Add verification-before-completion skill: evidence-before-claims gate
- Add /brainstorm and /debug slash commands as pure skill shortcuts
- Fix oac-help to use disable-model-invocation:true (pure shortcut, not self-rendering)
- Fix oac-status to be simpler bash-based status check

.opencode/context/core/standards/typescript.md

@@ -0,0 +1,624 @@
+<!-- Context: core/standards | Priority: critical | Version: 1.0 | Updated: 2026-02-16 -->
+
+# Universal TypeScript Standards
+
+**Purpose**: Universal TypeScript patterns applicable to any TypeScript project  
+**Scope**: Language-level patterns, not framework-specific  
+**Last Updated**: 2026-02-16
+
+---
+
+## Table of Contents
+
+1. [Function Patterns](#1-function-patterns)
+2. [Type Safety](#2-type-safety)
+3. [Array Operations](#3-array-operations)
+4. [Async Patterns](#4-async-patterns)
+5. [Control Flow](#5-control-flow)
+6. [Code Organization](#6-code-organization)
+7. [Testing Principles](#7-testing-principles)
+8. [Variable Naming](#8-variable-naming)
+
+---
+
+## 1. Function Patterns
+
+### 1.1 Naming Convention
+
+**Rule: Prefer single-word function names**
+
+```typescript
+// ✅ GOOD - Single-word names
+export function create() {...}
+export function fork() {...}
+export function touch() {...}
+export function get() {...}
+export async function stream(input: StreamInput) {...}
+
+// ✅ ACCEPTABLE - Multi-word only when necessary
+export function isDefaultTitle(title: string) {...}      // Boolean predicate
+export function assertNotBusy(sessionID: string) {...}   // Assertion pattern
+export async function createNext(input) {...}            // Version disambiguation
+export async function resolvePromptParts(template) {...} // Complex operation needs clarity
+
+// ❌ AVOID - Unnecessary multi-word names
+function prepareJournal(dir: string) {}  // Use: journal()
+function getUserData(id: string) {}      // Use: user()
+function processFileContent(path) {}     // Use: process()
+```
+
+### 1.2 Pure Functions
+
+**Rule: Prefer pure functions when possible**
+
+```typescript
+// ✅ GOOD - Pure function
+function calculateTotal(items: Item[]): number {
+  return items.reduce((sum, item) => sum + item.price, 0)
+}
+
+// ❌ AVOID - Side effects
+let total = 0
+function addToTotal(item: Item) {
+  total += item.price  // Mutates external state
+}
+```
+
+### 1.3 Function Composition
+
+```typescript
+// ✅ GOOD - Functional composition with pipes
+const filtered = agents
+  .filter((a) => a.mode !== "primary")
+  .filter((a) => hasPermission(a, caller))
+  .map((a) => a.name)
+
+// ✅ GOOD - Higher-order functions
+export function withRetry<T>(fn: () => Promise<T>, maxRetries: number): Promise<T> {
+  return fn().catch((error) => {
+    if (maxRetries > 0) {
+      return withRetry(fn, maxRetries - 1)
+    }
+    throw error
+  })
+}
+```
+
+---
+
+## 2. Type Safety
+
+### 2.1 TypeScript Types
+
+**Rule: Use TypeScript's type system, avoid `any`**
+
+```typescript
+// ✅ GOOD - Explicit types
+interface User {
+  id: string
+  name: string
+  email: string
+}
+
+function getUser(id: string): User {
+  // Implementation
+}
+
+// ❌ AVOID - any type
+function getUser(id: any): any {
+  // Loses all type safety
+}
+```
+
+### 2.2 Type Inference
+
+**Rule: Let TypeScript infer when obvious**
+
+```typescript
+// ✅ GOOD - Inference works
+const count = 42  // TypeScript knows this is number
+const users = await fetchUsers()  // Type inferred from return type
+
+// ❌ AVOID - Redundant annotations
+const count: number = 42
+const users: User[] = await fetchUsers()
+```
+
+### 2.3 Type Guards
+
+**Rule: Use type guards for runtime type checking**
+
+```typescript
+// ✅ GOOD - Type guard
+function isUser(value: unknown): value is User {
+  return (
+    typeof value === "object" &&
+    value !== null &&
+    "id" in value &&
+    "name" in value
+  )
+}
+
+// Usage
+if (isUser(data)) {
+  console.log(data.name)  // TypeScript knows data is User
+}
+```
+
+### 2.4 Avoid Any
+
+**Rule: Use `unknown` instead of `any` when type is truly unknown**
+
+```typescript
+// ✅ GOOD - unknown requires type checking
+function processData(data: unknown) {
+  if (typeof data === "string") {
+    return data.toUpperCase()
+  }
+  throw new Error("Invalid data")
+}
+
+// ❌ AVOID - any bypasses type checking
+function processData(data: any) {
+  return data.toUpperCase()  // No compile-time safety
+}
+```
+
+---
+
+## 3. Array Operations
+
+### 3.1 Functional Methods (Preferred)
+
+**Rule: Prefer map/filter/reduce over for-loops**
+
+```typescript
+// ✅ GOOD - Functional chain with type inference
+const files = messages
+  .flatMap((x) => x.parts)
+  .filter((x): x is Patch => x.type === "patch")
+  .flatMap((x) => x.files)
+  .map((x) => path.relative(worktree, x))
+
+// ✅ GOOD - Parallel async operations
+const results = await Promise.all(
+  toolCalls.map(async (call) => {
+    return executeCall(call)
+  }),
+)
+
+// ✅ GOOD - Reduce for aggregation
+const totalAdditions = diffs.reduce((sum, x) => sum + x.additions, 0)
+
+// ✅ GOOD - Unique values
+const uniqueNames = Array.from(new Set(items.map((x) => x.name)))
+
+// ✅ GOOD - Sorting
+const sorted = items.toSorted((a, b) => a.timestamp - b.timestamp)
+```
+
+### 3.2 For-Loops (When Necessary)
+
+**Rule: Use for-loops only for:**
+1. Algorithm complexity (DP, graph traversal)
+2. Early exit requirements
+3. Sequential side effects
+4. Performance-critical iteration
+
+```typescript
+// ✅ GOOD - Early exit
+const patches = []
+for (const msg of all) {
+  if (msg.info.id === targetID) break
+  for (const part of msg.parts) {
+    if (part.type === "patch") {
+      patches.push(part)
+    }
+  }
+}
+
+// ✅ GOOD - Sequential mutations
+for (const key of Object.keys(tools)) {
+  if (disabled.has(key)) {
+    delete tools[key]
+  }
+}
+```
+
+### 3.3 Type Guards on Filter
+
+**Rule: Use type guards to maintain type inference downstream**
+
+```typescript
+// ✅ GOOD - Type guard preserves type information
+const patches = messages
+  .flatMap((msg) => msg.parts)
+  .filter((part): part is PatchPart => part.type === "patch")
+// patches is now PatchPart[], not Part[]
+
+// ❌ BAD - Loses type information
+const patches = messages
+  .flatMap((msg) => msg.parts)
+  .filter((part) => part.type === "patch")
+// patches is still Part[], requires casting later
+```
+
+---
+
+## 4. Async Patterns
+
+### 4.1 Parallel Execution (Default Pattern)
+
+**Rule: Use `Promise.all` for independent operations**
+
+```typescript
+// ✅ GOOD - Parallel independent operations
+const [language, cfg, provider, auth] = await Promise.all([
+  getLanguage(model),
+  getConfig(),
+  getProvider(model.providerID),
+  getAuth(model.providerID),
+])
+
+// ✅ GOOD - Parallel array processing
+const results = await Promise.all(
+  items.map(async (item) => {
+    return processItem(item)
+  }),
+)
+
+// ❌ BAD - Sequential when independent
+const language = await getLanguage(model)
+const cfg = await getConfig()  // Could run in parallel!
+const provider = await getProvider(model.providerID)
+```
+
+### 4.2 Sequential Operations
+
+**Rule: Chain when operations depend on previous results**
+
+```typescript
+// ✅ GOOD - Sequential dependency chain
+const session = await createSession({ title: "New" })
+const message = await addMessage(session.id, { content: "Hello" })
+const response = await processMessage(message.id)
+
+// ✅ GOOD - Promise chain for clarity
+const result = await createSession({ title: "New" })
+  .then((session) => addMessage(session.id, { content: "Hello" }))
+  .then((message) => processMessage(message.id))
+```
+
+### 4.3 Error Handling in Async
+
+**Rule: Prefer `.catch()` over try/catch when possible**
+
+```typescript
+// ✅ GOOD - Catch at call site
+const result = await operation().catch((error) => {
+  console.error("Operation failed", error)
+  return defaultValue
+})
+
+// ✅ GOOD - Promise.all with error handling
+const results = await Promise.all(
+  items.map(async (item) => {
+    return processItem(item).catch((error) => {
+      console.error("Item failed", { item, error })
+      return null
+    })
+  }),
+)
+
+// ✅ ACCEPTABLE - try/catch for multiple operations
+try {
+  const session = await createSession(input)
+  await addMessage(session.id, message)
+  await publishEvent({ session })
+  return session
+} catch (error) {
+  console.error("Session creation failed", error)
+  throw error
+}
+
+// ❌ AVOID - try/catch for single operation
+try {
+  const result = await operation()
+  return result
+} catch (error) {
+  console.error(error)
+  throw error
+}
+// Better:
+const result = await operation().catch((error) => {
+  console.error(error)
+  throw error
+})
+```
+
+---
+
+## 5. Control Flow
+
+### 5.1 Early Returns
+
+**Rule: Avoid `else` statements, use early returns**
+
+```typescript
+// ✅ GOOD - Early returns
+function getStatus(session: Session) {
+  if (!session) return "not_found"
+  if (session.busy) return "busy"
+  if (session.error) return "error"
+  return "ready"
+}
+
+async function process(id: string) {
+  const session = await getSession(id)
+  if (!session) return { error: "Not found" }
+
+  const result = await execute(session)
+  if (!result.success) return { error: result.message }
+
+  return { data: result.data }
+}
+
+// ❌ BAD - Else statements
+function getStatus(session: Session) {
+  if (!session) {
+    return "not_found"
+  } else {
+    if (session.busy) {
+      return "busy"
+    } else {
+      if (session.error) {
+        return "error"
+      } else {
+        return "ready"
+      }
+    }
+  }
+}
+```
+
+### 5.2 Guard Clauses
+
+```typescript
+// ✅ GOOD - Guard clauses at function start
+async function updateSession(id: string, data: UpdateData) {
+  if (!id) throw new Error("ID required")
+  if (!data) throw new Error("Data required")
+  if (data.title && data.title.length > 100) throw new Error("Title too long")
+
+  // Main logic here
+  const session = await getSession(id)
+  await update(id, data)
+  return session
+}
+```
+
+### 5.3 Switch Statements
+
+**Rule: Use exhaustive switch with default case**
+
+```typescript
+// ✅ GOOD - Exhaustive switch
+function handleEvent(event: Event) {
+  switch (event.type) {
+    case "start":
+      return handleStart(event)
+    
+    case "update":
+      return handleUpdate(event)
+    
+    case "complete":
+      return handleComplete(event)
+    
+    default:
+      const _exhaustive: never = event
+      throw new Error(`Unhandled event type: ${(event as any).type}`)
+  }
+}
+```
+
+---
+
+## 6. Code Organization
+
+### 6.1 Import Order
+
+**Rule: Organize imports by source**
+
+```typescript
+// ✅ GOOD - Organized imports
+// 1. Node built-ins
+import path from "path"
+import fs from "fs/promises"
+
+// 2. External packages
+import { z } from "zod"
+import express from "express"
+
+// 3. Internal modules
+import { User } from "./types"
+import { getConfig } from "./config"
+```
+
+### 6.2 Naming Conventions
+
+```typescript
+// ✅ GOOD - Clear naming
+const session = await getSession(id)
+const user = await getCurrentUser()
+const messages = await getMessages({ sessionID })
+
+// ❌ BAD - Unnecessary verbosity
+const currentSession = await getSession(id)
+const currentlyAuthenticatedUser = await getCurrentUser()
+const sessionMessagesList = await getMessages({ sessionID })
+
+// ✅ GOOD - Multi-word when single word is ambiguous
+const sessionID = params.id
+const userAgent = req.headers["user-agent"]
+const maxRetries = config.retries
+```
+
+### 6.3 File Structure
+
+**Rule: One primary export per file**
+
+```typescript
+// user.ts
+export interface User {
+  id: string
+  name: string
+}
+
+export async function getUser(id: string): Promise<User> {
+  // Implementation
+}
+
+export async function createUser(data: CreateUserInput): Promise<User> {
+  // Implementation
+}
+```
+
+---
+
+## 7. Testing Principles
+
+### 7.1 Test Structure
+
+**Rule: Follow Arrange-Act-Assert pattern**
+
+```typescript
+// ✅ GOOD - AAA pattern
+test("creates user with valid data", async () => {
+  // Arrange
+  const userData = { name: "Alice", email: "alice@example.com" }
+  
+  // Act
+  const user = await createUser(userData)
+  
+  // Assert
+  expect(user.name).toBe("Alice")
+  expect(user.email).toBe("alice@example.com")
+})
+```
+
+### 7.2 Coverage Goals
+
+**Rule: Test both success and failure cases**
+
+```typescript
+// ✅ GOOD - Both positive and negative tests
+describe("createUser", () => {
+  test("creates user with valid data", async () => {
+    const user = await createUser({ name: "Alice", email: "alice@example.com" })
+    expect(user).toBeDefined()
+  })
+  
+  test("throws error with invalid email", async () => {
+    await expect(
+      createUser({ name: "Alice", email: "invalid" })
+    ).rejects.toThrow("Invalid email")
+  })
+})
+```
+
+### 7.3 Mock External Dependencies
+
+**Rule: Mock all external dependencies**
+
+```typescript
+// ✅ GOOD - Mocked dependencies
+test("fetches user data", async () => {
+  const mockFetch = vi.fn().mockResolvedValue({
+    json: () => Promise.resolve({ id: "1", name: "Alice" })
+  })
+  
+  global.fetch = mockFetch
+  
+  const user = await fetchUser("1")
+  expect(user.name).toBe("Alice")
+})
+```
+
+---
+
+## 8. Variable Naming
+
+### 8.1 Variable Declaration
+
+**Rule: Prefer `const` over `let`**
+
+```typescript
+// ✅ GOOD - Immutable with ternary
+const foo = condition ? 1 : 2
+const result = await (isValid ? processValid() : processInvalid())
+
+// ❌ BAD - Reassignment
+let foo
+if (condition) {
+  foo = 1
+} else {
+  foo = 2
+}
+
+// ✅ GOOD - Early return instead of reassignment
+function getValue(condition: boolean) {
+  if (condition) return 1
+  return 2
+}
+
+// ✅ ACCEPTABLE - let when mutation is necessary
+let accumulator = 0
+for (const item of items) {
+  accumulator += item.value
+}
+```
+
+### 8.2 Destructuring
+
+**Rule: Avoid unnecessary destructuring, preserve context with dot notation**
+
+```typescript
+// ✅ GOOD - Preserve context
+function process(session: Session) {
+  console.log("processing", { id: session.id, title: session.title })
+  return {
+    id: session.id,
+    status: session.status,
+    owner: session.owner
+  }
+}
+
+// ❌ BAD - Loses context, harder to read
+function process(session: Session) {
+  const { id, title, status, owner } = session
+  console.log("processing", { id, title })
+  return { id, status, owner }
+}
+
+// ✅ ACCEPTABLE - Destructuring when improving readability
+function renderUser({ name, email, avatar }: User) {
+  return `<div>${name} (${email})</div>`
+}
+
+// ✅ ACCEPTABLE - Destructuring array returns
+const [language, cfg, provider] = await Promise.all([...])
+```
+
+---
+
+## Related Standards
+
+- **OpenCode TypeScript**: `.opencode/context/openagents-repo/standards/opencode-typescript.md` (framework-specific patterns)
+- **Code Quality**: `.opencode/context/core/standards/code-quality.md` (general quality standards)
+- **Test Coverage**: `.opencode/context/core/standards/test-coverage.md` (testing standards)
+
+---
+
+**Version**: 1.0.0  
+**Last Updated**: 2026-02-16  
+**Maintainer**: OpenAgents Control Team

plugins/claude-code/commands/brainstorm.md

@@ -0,0 +1,6 @@
+---
+description: "You MUST use this before any creative work — creating features, building components, adding functionality, or modifying behavior."
+disable-model-invocation: true
+---
+
+Invoke the oac:brainstorming skill and follow it exactly as presented to you

plugins/claude-code/commands/debug.md

@@ -0,0 +1,6 @@
+---
+description: "Use when encountering any bug, test failure, or unexpected behavior — before proposing any fixes."
+disable-model-invocation: true
+---
+
+Invoke the oac:systematic-debugging skill and follow it exactly as presented to you

plugins/claude-code/commands/oac-help.md

@@ -1,434 +1,6 @@
 ---
-name: oac:help
-description: Show usage guide for OpenAgents Control workflow, skills, and commands
-argument-hint: [skill-name]
+description: "Show OAC workflow overview and available skills"
+disable-model-invocation: true
 ---
 
-# OpenAgents Control - Help Guide
-
-$ARGUMENTS
-
-## 🎯 Overview
-
-OpenAgents Control (OAC) brings intelligent multi-agent orchestration to Claude Code with a 6-stage workflow for context-aware development.
-
-## 🏗️ How Everything Works Together
-
-### Architecture Flow
-
-```
-User Request
-    ↓
-┌─────────────────────────────────────────────────────────────┐
-│ using-oac skill (6-stage workflow)                          │
-│                                                              │
-│  Stage 1: Analyze & Discover                                │
-│      ↓                                                       │
-│      └─→ /context-discovery → context-scout subagent        │
-│                                                              │
-│  Stage 2: Plan & Approve                                    │
-│      ↓                                                       │
-│      └─→ Present plan → REQUEST USER APPROVAL               │
-│                                                              │
-│  Stage 3: LoadContext                                       │
-│      ↓                                                       │
-│      ├─→ Read discovered context files                      │
-│      └─→ /external-scout (if external packages needed)      │
-│                                                              │
-│  Stage 4: Execute                                           │
-│      ↓                                                       │
-│      ├─→ Simple: Direct implementation                      │
-│      └─→ Complex: /task-breakdown → task-manager subagent   │
-│           ↓                                                  │
-│           ├─→ /code-execution → coder-agent subagent        │
-│           ├─→ /test-generation → test-engineer subagent     │
-│           └─→ /code-review → code-reviewer subagent         │
-│                                                              │
-│  Stage 5: Validate                                          │
-│      ↓                                                       │
-│      └─→ Run tests, verify acceptance criteria              │
-│                                                              │
-│  Stage 6: Complete                                          │
-│      ↓                                                       │
-│      └─→ Update docs, summarize changes                     │
-└─────────────────────────────────────────────────────────────┘
-    ↓
-Deliverables returned to user
-```
-
-### Skill → Subagent Mapping
-
-| Skill | Invokes | Primary Tools | Purpose |
-|-------|---------|---------------|---------|
-| `/using-oac` | N/A (orchestrator) | All | Main workflow orchestration through 6 stages |
-| `/context-discovery` | `context-scout` | Read, Glob, Grep | Discover relevant context files and standards |
-| `/install-context` | N/A (script runner) | Bash | Download context files from GitHub repository |
-| `/task-breakdown` | `task-manager` | Read, Write, Bash | Break complex features into atomic subtasks |
-| `/code-execution` | `coder-agent` | Read, Write, Edit, Bash | Implement code following discovered standards |
-| `/test-generation` | `test-engineer` | Read, Write, Bash | Generate comprehensive tests using TDD |
-| `/code-review` | `code-reviewer` | Read, Grep, Bash | Perform security and quality code review |
-| `/external-scout` | N/A (direct API) | WebFetch, Context7 | Fetch live documentation for external packages |
-
-### Configuration Hierarchy
-
-OAC uses a layered configuration system with the following priority:
-
-```
-1. .oac (current directory)
-   ↓ Project-specific settings
-   ↓ Overrides global and built-in defaults
-   ↓
-2. ~/.oac (home directory)
-   ↓ Personal defaults across all projects
-   ↓ Overrides built-in defaults
-   ↓
-3. Built-in defaults (plugins/claude-code/.oac.example)
-   ↓ Fallback when no custom config exists
-```
-
-**Configuration sections**:
-- `context.*` - Context download and caching behavior
-- `cleanup.*` - Temporary file cleanup settings
-- `workflow.*` - Workflow automation preferences
-- `external_scout.*` - External documentation fetching
-
-**Example**: If you set `workflow.auto_approve: true` in `~/.oac`, it applies to all projects unless a specific project's `.oac` overrides it.
-
-## 📋 6-Stage Workflow
-
-The OAC workflow ensures context-aware, high-quality code delivery:
-
-### Stage 1: Analyze & Discover
-- Understand requirements and scope
-- Invoke `/context-discovery` to find relevant context files
-- Identify project standards, patterns, and conventions
-
-### Stage 2: Plan & Approve
-- Present implementation plan
-- **REQUEST APPROVAL** before proceeding
-- Confirm approach with user
-
-### Stage 3: LoadContext
-- Read all discovered context files
-- Load coding standards, security patterns, naming conventions
-- Pre-load context for execution stage
-
-### Stage 4: Execute
-- **Simple tasks**: Direct implementation
-- **Complex tasks**: Invoke `/task-breakdown` to decompose into subtasks
-- Follow loaded standards and patterns
-
-### Stage 5: Validate
-- Run tests and validation
-- **STOP on failure** - fix before proceeding
-- Verify acceptance criteria met
-
-### Stage 6: Complete
-- Update documentation
-- Summarize changes
-- Return results
-
-## 🤖 Available Subagents
-
-OAC provides specialized subagents for different tasks:
-
-### task-manager
-Break down complex features into atomic, verifiable subtasks with dependency tracking.
-
-**When to use**: Complex features requiring multiple steps, parallel execution, or dependency management.
-
-**Example**:
-```
-Use the task-manager subagent to break down this feature:
-"Add user authentication with JWT tokens"
-```
-
-### context-scout
-Discover relevant context files, standards, and patterns for your task.
-
-**When to use**: Before implementing any feature, to find coding standards, security patterns, and conventions.
-
-**Example**:
-```
-Use the context-scout subagent to find:
-- TypeScript coding standards
-- Security patterns for authentication
-- API design conventions
-```
-
-### coder-agent
-Execute coding subtasks with full context awareness and self-review.
-
-**When to use**: Implementing specific features or subtasks following discovered standards.
-
-**Example**:
-```
-Use the coder-agent subagent to implement:
-- JWT authentication service
-- Following security patterns from context
-```
-
-### test-engineer
-Generate comprehensive tests using TDD principles.
-
-**When to use**: Creating tests for new features or existing code.
-
-**Example**:
-```
-Use the test-engineer subagent to create tests for:
-- Authentication service
-- Following test standards from context
-```
-
-### code-reviewer
-Perform thorough code review with security and quality analysis.
-
-**When to use**: Reviewing code changes before committing.
-
-**Example**:
-```
-Use the code-reviewer subagent to review:
-- Recent authentication changes
-- Check security patterns and code quality
-```
-
-### context-manager
-Manage context files, discover context roots, validate structure, and organize project context.
-
-**When to use**: Adding context from GitHub/worktrees, validating context files, or organizing context structure.
-
-**Example**:
-```
-Use the context-manager subagent to:
-- Add context from GitHub: github:acme-corp/standards
-- Add context from worktree: worktree:../team-context
-- Validate existing context files
-- Update navigation for discoverability
-```
-
-## 🎨 Available Skills
-
-Skills guide the main agent through specific workflows:
-
-### /using-oac
-Main workflow orchestrator implementing the 6-stage process.
-
-**Auto-invoked**: When you start a development task.
-
-### /context-discovery
-Guide for discovering and loading relevant context files.
-
-**Usage**: `/context-discovery authentication feature`
-
-### /task-breakdown
-Guide for breaking down complex features into subtasks.
-
-**Usage**: `/task-breakdown user authentication system`
-
-### /code-execution
-Guide for executing coding tasks with context awareness.
-
-**Usage**: `/code-execution implement JWT service`
-
-### /test-generation
-Guide for generating comprehensive tests.
-
-**Usage**: `/test-generation authentication service`
-
-### /code-review
-Guide for performing thorough code reviews.
-
-**Usage**: `/code-review src/auth/`
-
-## 📝 Available Commands
-
-### /install-context
-Download context files from the OpenAgents Control registry with interactive profile selection.
-
-**Usage**: `/install-context [--profile=<profile>] [--force] [--dry-run]`
-
-**Profiles**: `essential`, `standard` (recommended), `extended`, `specialized`, `all`
-
-**What it does**:
-- Asks which profile to install
-- Downloads context files from GitHub registry
-- Creates `.context-manifest.json`
-
-### /oac:help
-Show this usage guide (you're reading it now!).
-
-**Usage**: 
-- `/oac:help` - Show general help
-- `/oac:help <skill-name>` - Show help for specific skill
-
-### /oac:status
-Show plugin status and installed context.
-
-**Usage**: `/oac:status`
-
-**What it shows**:
-- Plugin version
-- Installed context version
-- Available subagents and skills
-- Context file count
-
-### /oac:cleanup
-Clean up old temporary files with approval.
-
-**Usage**: `/oac:cleanup`
-
-**What it does**:
-- Finds old session files (>7 days)
-- Finds old task files (>30 days)
-- Finds old external cache (>7 days)
-- Requests approval before deletion
-
-## ⚙️ Configuration Setup
-
-### First-Time Setup
-
-1. **Download context files** (required):
-   ```
-   /install-context --profile=essential
-   ```
-   This downloads coding standards, security patterns, and conventions.
-
-2. **Create configuration** (optional):
-   ```bash
-   # For project-specific settings
-   cp plugins/claude-code/.oac.example .oac
-   
-   # For global settings
-   cp plugins/claude-code/.oac.example ~/.oac
-   ```
-
-3. **Customize settings**:
-   Edit `.oac` to configure:
-   - Auto-download context updates
-   - Cleanup schedules
-   - Workflow preferences
-   - External documentation sources
-
-### Configuration Options
-
-**Context settings**:
-- `context.auto_download: true/false` - Auto-download context on first use
-- `context.categories: core,openagents-repo` - Which context categories to load
-- `context.update_check: true/false` - Check for context updates on startup
-- `context.cache_days: 7` - How long to cache context before suggesting update
-
-**Cleanup settings**:
-- `cleanup.auto_prompt: true/false` - Prompt to clean old temporary files
-- `cleanup.session_days: 7` - Days before session files are considered old
-- `cleanup.task_days: 30` - Days before completed tasks are considered old
-- `cleanup.external_days: 7` - Days before external cache is considered old
-
-**Workflow settings**:
-- `workflow.auto_approve: false` - **WARNING**: Skips approval gates (not recommended)
-- `workflow.verbose: false` - Show detailed workflow progress
-
-**External scout settings**:
-- `external_scout.enabled: true/false` - Enable external documentation fetching
-- `external_scout.cache_enabled: true/false` - Cache external docs locally
-- `external_scout.sources: context7` - Documentation sources to use
-
-## 🚀 Quick Start Examples
-
-### Example 1: Simple Feature
-```
-User: "Add a login endpoint"
-
-Claude (using-oac skill):
-1. Analyze: Understand login requirements
-2. Plan: Present implementation approach → REQUEST APPROVAL
-3. LoadContext: Read API standards, security patterns
-4. Execute: Implement endpoint directly
-5. Validate: Run tests
-6. Complete: Update API docs
-```
-
-### Example 2: Complex Feature
-```
-User: "Build a complete authentication system"
-
-Claude (using-oac skill):
-1. Analyze: Understand auth requirements
-2. Plan: Present high-level approach → REQUEST APPROVAL
-3. LoadContext: Read security patterns, API standards
-4. Execute: Invoke /task-breakdown
-   - Subtask 1: JWT service
-   - Subtask 2: Auth middleware
-   - Subtask 3: Login endpoint
-   - Subtask 4: Refresh token logic
-5. Validate: Run integration tests
-6. Complete: Update docs, summarize
-```
-
-### Example 3: Using Subagents Directly
-```
-# Discover context first
-Use the context-scout subagent to find TypeScript and security patterns.
-
-# Break down complex task
-Use the task-manager subagent to break down the authentication system.
-
-# Implement subtask
-Use the coder-agent subagent to implement JWT service following discovered patterns.
-
-# Generate tests
-Use the test-engineer subagent to create tests for the JWT service.
-
-# Review code
-Use the code-reviewer subagent to review all authentication changes.
-```
-
-## 🔑 Key Principles
-
-### Context First, Code Second
-Always discover and load context before implementing. This ensures your code follows project standards.
-
-### Approval Gates
-OAC requests approval before execution. This prevents unwanted changes and ensures alignment.
-
-### Atomic Tasks
-Complex features are broken into 1-2 hour subtasks with clear acceptance criteria.
-
-### Self-Review
-Every deliverable passes validation before completion (types, imports, anti-patterns, acceptance criteria).
-
-### No Nested Calls
-In Claude Code, only the main agent can invoke subagents. Skills orchestrate the workflow, subagents execute specialized tasks.
-
-## 📚 Learn More
-
-- **Installation & Quick Start**: See `README.md` for full setup guide
-- **Architecture**: See `README.md` for system overview
-- **Context System**: Explore `context/` directory for standards and patterns
-
-## 🆘 Troubleshooting
-
-### "Context files not found"
-Run `/install-context` to download context from GitHub.
-
-### "Subagent not available"
-Verify plugin installation with `/oac:status`.
-
-### "Approval not requested"
-This is a bug - OAC should always request approval before execution. Please report.
-
-### "Nested subagent call error"
-Claude Code doesn't support nested calls. Use skills to orchestrate, not subagents calling subagents.
-
-## 💡 Tips
-
-1. **Start with /install-context** - Download context files first
-2. **Let the workflow guide you** - The using-oac skill handles orchestration
-3. **Use context-scout early** - Discover standards before coding
-4. **Break down complex tasks** - Use task-manager for multi-step features
-5. **Review before committing** - Use code-reviewer for quality checks
-
----
-
-**Version**: 1.0.0  
-**Plugin**: oac  
-**Last Updated**: 2026-02-16
+Invoke the oac:using-oac skill and follow it exactly as presented to you. Then provide a brief summary of available skills and commands.

plugins/claude-code/commands/oac-status.md

@@ -1,110 +1,15 @@
 ---
 name: oac:status
-description: Show OpenAgents Control plugin installation status and context
+description: Show OAC plugin status, installed context, and available skills
 ---
 
-# OpenAgents Control Status
+Show the current OAC plugin status by running:
 
-## Plugin Information
+!ls -la .opencode/context/ 2>/dev/null && echo "Context installed" || echo "No context installed — run /install-context"
+!cat .context-manifest.json 2>/dev/null | head -20 || echo "No manifest found"
 
-**Plugin**: OpenAgents Control (OAC)
-**Version**: !`jq -r '.version' ${CLAUDE_PLUGIN_ROOT}/.claude-plugin/plugin.json 2>/dev/null || cat ${CLAUDE_PLUGIN_ROOT}/.claude-plugin/plugin.json | grep '"version"' | sed 's/.*: "\(.*\)".*/\1/'`
-**Repository**: https://github.com/darrenhinde/OpenAgentsControl
-
----
-
-## Context Installation Status
-
-!`PLUGIN_CONTEXT="${CLAUDE_PLUGIN_ROOT}/context"
-MANIFEST="${CLAUDE_PLUGIN_ROOT}/.context-manifest.json"
-if [ -f "$MANIFEST" ]; then
-  echo "✅ **Context Installed**"
-  echo ""
-  echo "### Manifest Details"
-  cat "$MANIFEST" | sed 's/^/    /'
-  echo ""
-  echo "### Installed Context Files"
-  if [ -d "$PLUGIN_CONTEXT" ]; then
-    echo ""
-    echo "**Core Context**:"
-    find "$PLUGIN_CONTEXT/core" -type f -name "*.md" 2>/dev/null | wc -l | xargs -I {} echo "  - {} files"
-    echo ""
-    echo "**Categories**:"
-    find "$PLUGIN_CONTEXT" -type d -mindepth 1 -maxdepth 1 2>/dev/null | xargs -I {} basename {} | sed 's/^/  - /'
-  fi
-else
-  echo "❌ **Context Not Installed**"
-  echo ""
-  echo "Run \`/install-context\` to download context files from GitHub."
-fi`
-
----
-
-## Active Sessions
-
-!`if [ -d ".tmp/sessions" ]; then
-  SESSION_COUNT=$(find .tmp/sessions -maxdepth 1 -type d ! -path .tmp/sessions | wc -l | tr -d ' ')
-  if [ "$SESSION_COUNT" -gt 0 ]; then
-    echo "**Active Sessions**: $SESSION_COUNT"
-    echo ""
-    find .tmp/sessions -maxdepth 1 -type d ! -path .tmp/sessions -exec basename {} \; | sed 's/^/  - /'
-  else
-    echo "**Active Sessions**: None"
-  fi
-else
-  echo "**Active Sessions**: None"
-fi`
-
----
-
-## Available Components
-
-### Custom Subagents
-- `task-manager` - Break down complex features into atomic subtasks
-- `context-scout` - Discover relevant context files for tasks
-- `coder-agent` - Execute coding subtasks with context awareness
-- `test-engineer` - Generate comprehensive test suites
-- `code-reviewer` - Review code for quality and standards
-
-### Skills
-- `/using-oac` - Main 6-stage workflow orchestrator
-- `/context-discovery` - Guide context discovery process
-- `/task-breakdown` - Guide task breakdown process
-- `/code-execution` - Guide code execution process
-- `/test-generation` - Guide test generation process
-- `/code-review` - Guide code review process
-
-### Commands
-- `/install-context` - Download context files from GitHub
-- `/oac:help` - Show usage guide and available skills
-- `/oac:status` - Show this status information
-- `/oac:cleanup` - Clean up old temporary files
-
----
-
-## Recommendations
-
-!`if [ ! -f "${CLAUDE_PLUGIN_ROOT}/.context-manifest.json" ]; then
-  echo "⚠️  **Action Required**: Run \`/install-context\` to install context files"
-elif [ -d ".tmp/sessions" ]; then
-  SESSION_COUNT=$(find .tmp/sessions -maxdepth 1 -type d ! -path .tmp/sessions | wc -l | tr -d ' ')
-  if [ "$SESSION_COUNT" -gt 5 ]; then
-    echo "💡 **Cleanup Suggested**: You have $SESSION_COUNT active sessions. Consider cleaning up old sessions in \`.tmp/sessions/\`"
-  else
-    echo "✅ **All Good**: Plugin is properly configured and ready to use"
-  fi
-else
-  echo "✅ **All Good**: Plugin is properly configured and ready to use"
-fi`
-
----
-
-## Quick Start
-
-To start using OpenAgents Control:
-
-1. **Ensure context is installed**: Run `/install-context` if not already done
-2. **Invoke the main workflow**: Use `/using-oac` or let Claude auto-invoke it
-3. **Get help**: Run `/oac:help` for detailed usage guide
-
-For more information, see the [README](../README.md) or visit the [repository](https://github.com/darrenhinde/OpenAgentsControl).
+Then report:
+- Plugin version: 1.0.0
+- Context status (installed/not installed)
+- Available skills: brainstorming, context-discovery, systematic-debugging, verification-before-completion, task-breakdown, code-execution, test-generation, code-review, external-scout, parallel-execution
+- Available subagents: context-scout, task-manager, coder-agent, test-engineer, code-reviewer, context-manager, external-scout

plugins/claude-code/hooks/session-start.sh

@@ -12,18 +12,7 @@ SKILL_FILE="${PLUGIN_ROOT}/skills/using-oac/SKILL.md"
 using_oac_content=$(cat "${SKILL_FILE}" 2>&1 || echo "Error reading using-oac skill")
 
 # Escape string for JSON embedding
-# SECURITY: This function prevents command injection attacks from malicious SKILL.md files
-# Previous implementation was vulnerable to:
-# - $(command) injection via unescaped dollar signs
-# - `command` injection via unescaped backticks
-# - Control character injection
-#
-# We now escape ALL dangerous characters in the correct order:
-# 1. Backslashes FIRST (to avoid double-escaping)
-# 2. Double quotes (JSON string delimiter)
-# 3. Dollar signs (prevent variable expansion and $(cmd) injection)
-# 4. Backticks (prevent `cmd` command substitution)
-# 5. Newlines, carriage returns, tabs (JSON control characters)
+# SECURITY: Prevents command injection attacks from malicious SKILL.md files
 escape_for_json() {
     local s="$1"
     # Escape backslashes FIRST - order matters!
@@ -39,16 +28,35 @@ escape_for_json() {
 
 using_oac_escaped=$(escape_for_json "$using_oac_content")
 
+# Build skill catalogue from skills directory
+skill_catalogue=""
+if [ -d "${PLUGIN_ROOT}/skills" ]; then
+    for skill_dir in "${PLUGIN_ROOT}/skills"/*/; do
+        skill_name=$(basename "$skill_dir")
+        skill_file="${skill_dir}SKILL.md"
+        if [ -f "$skill_file" ]; then
+            # Extract description from frontmatter
+            description=$(grep -m1 '^description:' "$skill_file" 2>/dev/null | sed 's/^description: *//;s/^"//;s/"$//' || echo "")
+            if [ -n "$description" ]; then
+                skill_catalogue="${skill_catalogue}\n- oac:${skill_name} — ${description}"
+            else
+                skill_catalogue="${skill_catalogue}\n- oac:${skill_name}"
+            fi
+        fi
+    done
+fi
+
 # Build warning message for first-time users
 warning_message=""
-if [[ ! -f "${PLUGIN_ROOT}/.context-manifest.json" ]]; then
-    warning_message="\n\n<important-reminder>IN YOUR FIRST REPLY AFTER SEEING THIS MESSAGE YOU MUST TELL THE USER:👋 **Welcome to OpenAgents Control!** To get started, run /install-context to download context files. Then use /oac:help to learn the 6-stage workflow.</important-reminder>"
+if [[ ! -f "${PLUGIN_ROOT}/.context-manifest.json" ]] && [[ ! -f "$(pwd)/.context-manifest.json" ]]; then
+    warning_message="\n\n<important-reminder>IN YOUR FIRST REPLY AFTER SEEING THIS MESSAGE YOU MUST TELL THE USER:👋 **Welcome to OpenAgents Control!** To get started, run /install-context to download context files. Then use /brainstorm before building anything.</important-reminder>"
 fi
 
 warning_escaped=$(escape_for_json "$warning_message")
+skill_catalogue_escaped=$(escape_for_json "$skill_catalogue")
 
-# Build context string once, reuse in both output formats
-OAC_CONTEXT="<EXTREMELY_IMPORTANT>\nYou are using OpenAgents Control (OAC).\n\nIN YOUR VERY FIRST REPLY you MUST start with exactly this line (no exceptions):\n🤖 **OAC Active** — 6-stage workflow enabled. Type /oac:help for commands.\n\n**Below is the full content of your 'using-oac' skill - your guide to the 6-stage workflow. For all other skills, use the 'Skill' tool:**\n\n${using_oac_escaped}\n\n${warning_escaped}\n</EXTREMELY_IMPORTANT>"
+# Build context string
+OAC_CONTEXT="<EXTREMELY_IMPORTANT>\nYou have OAC (OpenAgents Control) superpowers.\n\n**Below is the full content of your 'oac:using-oac' skill — your introduction to using OAC skills. For all other skills, use the 'Skill' tool:**\n\n${using_oac_escaped}\n\n## Available OAC Skills (invoke with the Skill tool):\n${skill_catalogue_escaped}\n\n${warning_escaped}\n</EXTREMELY_IMPORTANT>"
 
 # Output dual-format JSON for cross-tool compatibility
 # - additionalContext: Claude Code (hookSpecificOutput)

plugins/claude-code/skills/brainstorming/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: brainstorming
+description: "You MUST use this before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores requirements and design before implementation."
+---
+
+# Brainstorming Ideas Into Designs
+
+## Overview
+
+Help turn ideas into fully formed designs and specs through natural collaborative dialogue.
+
+Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
+
+<HARD-GATE>
+Do NOT write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
+</HARD-GATE>
+
+## Anti-Pattern: "This Is Too Simple To Need A Design"
+
+Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+
+## Checklist
+
+You MUST create a task for each of these items and complete them in order:
+
+1. **Explore project context** — check files, docs, recent commits
+2. **Ask clarifying questions** — one at a time, understand purpose/constraints/success criteria
+3. **Propose 2-3 approaches** — with trade-offs and your recommendation
+4. **Present design** — in sections scaled to their complexity, get user approval after each section
+5. **Transition to implementation** — invoke `oac:context-discovery` to find relevant standards, then proceed with the OAC 6-stage workflow
+
+## Process Flow
+
+```dot
+digraph brainstorming {
+    "Explore project context" [shape=box];
+    "Ask clarifying questions" [shape=box];
+    "Propose 2-3 approaches" [shape=box];
+    "Present design sections" [shape=box];
+    "User approves design?" [shape=diamond];
+    "Invoke oac:context-discovery" [shape=doublecircle];
+
+    "Explore project context" -> "Ask clarifying questions";
+    "Ask clarifying questions" -> "Propose 2-3 approaches";
+    "Propose 2-3 approaches" -> "Present design sections";
+    "Present design sections" -> "User approves design?";
+    "User approves design?" -> "Present design sections" [label="no, revise"];
+    "User approves design?" -> "Invoke oac:context-discovery" [label="yes"];
+}
+```
+
+**The terminal state is invoking context-discovery.** Do NOT write code until context is loaded and the OAC workflow is followed.
+
+## The Process
+
+**Understanding the idea:**
+- Check out the current project state first (files, docs, recent commits)
+- Ask questions one at a time to refine the idea
+- Prefer multiple choice questions when possible, but open-ended is fine too
+- Only one question per message — if a topic needs more exploration, break it into multiple questions
+- Focus on understanding: purpose, constraints, success criteria
+
+**Exploring approaches:**
+- Propose 2-3 different approaches with trade-offs
+- Present options conversationally with your recommendation and reasoning
+- Lead with your recommended option and explain why
+
+**Presenting the design:**
+- Once you believe you understand what you're building, present the design
+- Scale each section to its complexity: a few sentences if straightforward, up to 200-300 words if nuanced
+- Ask after each section whether it looks right so far
+- Cover: architecture, components, data flow, error handling, testing
+- Be ready to go back and clarify if something doesn't make sense
+
+## After the Design
+
+**Implementation:**
+- Invoke `oac:context-discovery` to find relevant context files and standards
+- Then follow the OAC 6-stage workflow (Stage 1 is already done — you have the design)
+
+## Key Principles
+
+- **One question at a time** — Don't overwhelm with multiple questions
+- **Multiple choice preferred** — Easier to answer than open-ended when possible
+- **YAGNI ruthlessly** — Remove unnecessary features from all designs
+- **Explore alternatives** — Always propose 2-3 approaches before settling
+- **Incremental validation** — Present design, get approval before moving on
+- **Be flexible** — Go back and clarify when something doesn't make sense

plugins/claude-code/skills/systematic-debugging/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: systematic-debugging
+description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
+---
+
+# Systematic Debugging
+
+## Overview
+
+Random fixes waste time and create new bugs. Quick patches mask underlying issues.
+
+**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
+
+**Violating the letter of this process is violating the spirit of debugging.**
+
+## The Iron Law
+
+```
+NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+```
+
+If you haven't completed Phase 1, you cannot propose fixes.
+
+## When to Use
+
+Use for ANY technical issue:
+- Test failures
+- Bugs in production
+- Unexpected behavior
+- Performance problems
+- Build failures
+- Integration issues
+
+**Use this ESPECIALLY when:**
+- Under time pressure (emergencies make guessing tempting)
+- "Just one quick fix" seems obvious
+- You've already tried multiple fixes
+- Previous fix didn't work
+- You don't fully understand the issue
+
+**Don't skip when:**
+- Issue seems simple (simple bugs have root causes too)
+- You're in a hurry (rushing guarantees rework)
+
+## The Four Phases
+
+You MUST complete each phase before proceeding to the next.
+
+### Phase 1: Root Cause Investigation
+
+**BEFORE attempting ANY fix:**
+
+1. **Read Error Messages Carefully**
+   - Don't skip past errors or warnings
+   - They often contain the exact solution
+   - Read stack traces completely
+   - Note line numbers, file paths, error codes
+
+2. **Reproduce Consistently**
+   - Can you trigger it reliably?
+   - What are the exact steps?
+   - Does it happen every time?
+   - If not reproducible → gather more data, don't guess
+
+3. **Check Recent Changes**
+   - What changed that could cause this?
+   - Git diff, recent commits
+   - New dependencies, config changes
+   - Environmental differences
+
+4. **Gather Evidence in Multi-Component Systems**
+
+   **WHEN system has multiple components:**
+
+   **BEFORE proposing fixes, add diagnostic instrumentation:**
+   ```
+   For EACH component boundary:
+     - Log what data enters component
+     - Log what data exits component
+     - Verify environment/config propagation
+     - Check state at each layer
+
+   Run once to gather evidence showing WHERE it breaks
+   THEN analyze evidence to identify failing component
+   THEN investigate that specific component
+   ```
+
+5. **Trace Data Flow**
+   - Where does bad value originate?
+   - What called this with bad value?
+   - Keep tracing up until you find the source
+   - Fix at source, not at symptom
+
+### Phase 2: Pattern Analysis
+
+**Find the pattern before fixing:**
+
+1. **Find Working Examples** — Locate similar working code in same codebase
+2. **Compare Against References** — Read reference implementation COMPLETELY
+3. **Identify Differences** — List every difference, however small
+4. **Understand Dependencies** — What other components does this need?
+
+### Phase 3: Hypothesis and Testing
+
+**Scientific method:**
+
+1. **Form Single Hypothesis** — "I think X is the root cause because Y"
+2. **Test Minimally** — Make the SMALLEST possible change to test hypothesis
+3. **Verify Before Continuing** — Did it work? Yes → Phase 4. No → form NEW hypothesis
+4. **When You Don't Know** — Say "I don't understand X". Don't pretend to know.
+
+### Phase 4: Implementation
+
+**Fix the root cause, not the symptom:**
+
+1. **Create Failing Test Case** — Simplest possible reproduction. MUST have before fixing.
+2. **Implement Single Fix** — Address the root cause. ONE change at a time.
+3. **Verify Fix** — Test passes? No other tests broken? Issue actually resolved?
+4. **If Fix Doesn't Work** — STOP. Count fixes tried. If ≥ 3: question the architecture.
+
+5. **If 3+ Fixes Failed: Question Architecture**
+   - Is this pattern fundamentally sound?
+   - Should we refactor architecture vs. continue fixing symptoms?
+   - Discuss with user before attempting more fixes
+
+## Red Flags — STOP and Follow Process
+
+If you catch yourself thinking:
+- "Quick fix for now, investigate later"
+- "Just try changing X and see if it works"
+- "Add multiple changes, run tests"
+- "It's probably X, let me fix that"
+- "I don't fully understand but this might work"
+- "One more fix attempt" (when already tried 2+)
+
+**ALL of these mean: STOP. Return to Phase 1.**
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "Issue is simple, don't need process" | Simple issues have root causes too. |
+| "Emergency, no time for process" | Systematic debugging is FASTER than guess-and-check. |
+| "Just try this first, then investigate" | First fix sets the pattern. Do it right from the start. |
+| "Multiple fixes at once saves time" | Can't isolate what worked. Causes new bugs. |
+| "I see the problem, let me fix it" | Seeing symptoms ≠ understanding root cause. |
+| "One more fix attempt" (after 2+ failures) | 3+ failures = architectural problem. |
+
+## Quick Reference
+
+| Phase | Key Activities | Success Criteria |
+|-------|---------------|------------------|
+| **1. Root Cause** | Read errors, reproduce, check changes, gather evidence | Understand WHAT and WHY |
+| **2. Pattern** | Find working examples, compare | Identify differences |
+| **3. Hypothesis** | Form theory, test minimally | Confirmed or new hypothesis |
+| **4. Implementation** | Create test, fix, verify | Bug resolved, tests pass |
+
+**Related skills:**
+- `oac:verification-before-completion` — Verify fix worked before claiming success
+- `oac:test-generation` — For creating failing test cases (Phase 4, Step 1)

plugins/claude-code/skills/using-oac/SKILL.md

@@ -1,440 +1,109 @@
 ---
 name: using-oac
-description: "Use when starting any development task — building a feature, fixing a bug, refactoring, or making any code change."
+description: "Use when starting any conversation — establishes how to find and use OAC skills, requiring Skill tool invocation BEFORE ANY response including clarifying questions"
 ---
 
 <EXTREMELY-IMPORTANT>
-IF you are starting ANY development task, you MUST use this workflow.
+If you think there is even a 1% chance an OAC skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.
 
-This is not negotiable. This is not optional. "Simple" tasks are where skipping stages causes the most wasted work.
+IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
 
-EVERY task follows all 6 stages. NO EXCEPTIONS.
+This is not negotiable. This is not optional. You cannot rationalize your way out of this.
 </EXTREMELY-IMPORTANT>
 
-# OpenAgents Control (OAC) Workflow
+## How to Access Skills
 
-## Overview
+**In Claude Code:** Use the `Skill` tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files.
 
-Context-first parallel execution with 6 mandatory stages and 2 approval gates.
+# Using OAC Skills
 
-**Terminal state:** Stage 6 Complete (task documented and summarized)
+## The Rule
 
-**Core value:** **5x faster feature development through parallel multi-agent execution**
-
----
-
-## Anti-Pattern: "This Is Too Simple for the Full Workflow"
-
-Every task goes through all 6 stages. A "simple" email validation, a config change, a "quick fix" — all of them.
-
-"Simple" tasks are where unexamined assumptions cause the most wasted work:
-- No context → implement wrong pattern → code review feedback → rework (30+ min wasted)
-- No approval → build wrong thing → user rejects → start over (hours wasted)
-- No validation → tests fail in CI → debug → fix → re-deploy (hours wasted)
-
-The workflow is fast for simple tasks (5-10 minutes). Skipping it costs 30+ minutes in rework.
-
----
-
-## The Iron Law
-
-```
-CONTEXT FIRST, CODE SECOND
-
-Stage 1 → 2 → APPROVAL GATE → 3 → 4 → 5 → VALIDATION GATE → 6
-            ↑                              ↑
-         APPROVAL                    VALIDATION
-          GATE                          GATE
-```
-
-NO skipping stages. NO coding before approval. NO completion before validation.
-
----
-
-## Workflow Diagram
+**Invoke relevant or requested skills BEFORE any response or action.** Even a 1% chance a skill might apply means that you should invoke the skill to check. If an invoked skill turns out to be wrong for the situation, you don't need to use it.
 
 ```dot
-digraph oac {
-    rankdir=LR;
-    node [shape=box, style=rounded];
-    
-    s1 [label="Stage 1\nDiscover"];
-    s2 [label="Stage 2\nPlan"];
-    approval [label="User\nApproval?", shape=diamond];
-    s3 [label="Stage 3\nLoad Context"];
-    s4 [label="Stage 4\nExecute"];
-    s5 [label="Stage 5\nValidate"];
-    validation [label="Validation\nPassed?", shape=diamond];
-    s6 [label="Stage 6\nComplete", shape=doublecircle];
-
-    s1 -> s2;
-    s2 -> approval;
-    approval -> s3 [label="yes"];
-    approval -> s2 [label="no\nrevise"];
-    s3 -> s4;
-    s4 -> s5;
-    s5 -> validation;
-    validation -> s6 [label="yes"];
-    validation -> s4 [label="no\nfix"];
+digraph skill_flow {
+    "User message received" [shape=doublecircle];
+    "About to build/create something?" [shape=doublecircle];
+    "Already brainstormed?" [shape=diamond];
+    "Invoke oac:brainstorming skill" [shape=box];
+    "Might any OAC skill apply?" [shape=diamond];
+    "Invoke Skill tool" [shape=box];
+    "Announce: 'Using [skill] to [purpose]'" [shape=box];
+    "Has checklist?" [shape=diamond];
+    "Create TodoWrite todo per item" [shape=box];
+    "Follow skill exactly" [shape=box];
+    "Respond (including clarifications)" [shape=doublecircle];
+
+    "About to build/create something?" -> "Already brainstormed?";
+    "Already brainstormed?" -> "Invoke oac:brainstorming skill" [label="no"];
+    "Already brainstormed?" -> "Might any OAC skill apply?" [label="yes"];
+    "Invoke oac:brainstorming skill" -> "Might any OAC skill apply?";
+
+    "User message received" -> "Might any OAC skill apply?";
+    "Might any OAC skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
+    "Might any OAC skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
+    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
+    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
+    "Has checklist?" -> "Create TodoWrite todo per item" [label="yes"];
+    "Has checklist?" -> "Follow skill exactly" [label="no"];
+    "Create TodoWrite todo per item" -> "Follow skill exactly";
 }
 ```
 
----
-
-## Checklist
-
-Create TodoWrite items for each stage:
-
-1. **Stage 1: Discover** — Invoke `/context-discovery`, get context file list
-2. **Stage 2: Plan** — Create plan (simple: approach, complex: use `/task-breakdown`), present to user
-3. **APPROVAL GATE** — Wait for user confirmation
-4. **Stage 3: LoadContext** — Read ALL discovered context files
-5. **Stage 4: Execute** — Implement (simple: direct, complex: parallel via BatchExecutor)
-6. **Stage 5: Validate** — Run tests, verify criteria, STOP if failed
-7. **VALIDATION GATE** — All tests pass, all criteria met
-8. **Stage 6: Complete** — Update docs, summarize, cleanup
-
----
-
-## The Stages
-
-### Stage 1: Discover
-
-**Goal:** Understand task + find context files
-
-**Actions:**
-1. Analyze request: What to build, scope, risks
-2. Invoke `/context-discovery [task description]`
-3. Capture returned context file list (Critical → High → Medium priority)
-
-**Output:** Context file list
-
----
-
-### Stage 2: Plan
-
-**Goal:** Create execution plan + get approval
-
-**Actions:**
-
-**Simple tasks (1-3 files, <30 min):**
-- Direct implementation approach
-- Files to create/modify
-- Key technical decisions
-
-**Complex tasks (4+ files, >30 min):**
-- High-level breakdown into phases
-- Dependencies between components
-- Use `/task-breakdown` for detailed subtasks
-- **Parallel execution**: TaskManager identifies which subtasks can run in parallel
-
-**Present plan:**
-- Summary of approach
-- Files to be created/modified
-- Context files to be loaded
-- Estimated complexity
-- **Parallel batches** (if complex task)
-
-<HARD-GATE>
-REQUEST APPROVAL. Wait for user confirmation.
-
-DO NOT proceed to Stage 3 without explicit user approval.
-
-This applies to EVERY task, regardless of:
-- Perceived simplicity
-- "Obvious" requirements
-- Time pressure
-- Previous similar approvals
-
-If you think "this is too simple to need approval", STOP. You are rationalizing.
-</HARD-GATE>
-
-**Output:** Approved plan
-
----
-
-### Stage 3: LoadContext
-
-**Goal:** Pre-load ALL discovered context files for parallel execution
-
-**Actions:**
-1. Read EVERY context file from Stage 1:
-   - Use Read tool for each file
-   - Load in priority order (Critical → High → Medium)
-   - DON'T skip any files
-2. Internalize context:
-   - Coding standards
-   - Security patterns
-   - Naming conventions
-   - Architecture constraints
-3. If external libraries involved, invoke `/external-scout [library] [topic]`
-
-**Why this matters for parallel execution:**
-
-Pre-loading prevents race conditions when multiple agents execute in parallel:
-
-```
-WITHOUT pre-loading (race condition):
-CoderAgent 1 (10:00:00) → calls ContextScout → gets standards v1
-CoderAgent 2 (10:00:05) → calls ContextScout → gets standards v2
-Result: Inconsistent implementations ❌
-
-WITH pre-loading (consistent):
-Stage 3 (10:00:00) → Load standards once → Store in session
-CoderAgent 1 (10:01:00) → Uses pre-loaded standards
-CoderAgent 2 (10:01:00) → Uses same pre-loaded standards
-Result: Consistent implementations ✓
-```
-
-**Output:** All context loaded and ready for parallel execution
-
----
-
-### Stage 4: Execute
-
-**Goal:** Implement following loaded context
-
-**Simple tasks (direct execution):**
-1. Implement directly
-2. Follow loaded standards
-3. Apply security patterns
-4. Create tests if required
-5. Self-review before completion
-
-**Complex tasks (parallel execution via BatchExecutor):**
-1. Invoke `/task-breakdown` → TaskManager creates subtasks with `parallel: true` flags
-2. BatchExecutor groups parallelizable subtasks into batches
-3. Execute batches in parallel:
-   ```
-   Batch 1: [Subtask 01, Subtask 02, Subtask 03] ──┐
-                                                     ├─ All run simultaneously
-   Batch 2: [Subtask 04, Subtask 05] ───────────────┘
-   ```
-4. Each parallel agent uses pre-loaded context from Stage 3
-5. Track progress through subtask completion
-
-**Time savings example:**
-- Sequential: 5 subtasks × 30 min = 150 minutes
-- Parallel: 5 subtasks in 2 batches = 60 minutes (2.5x faster)
-
-**Output:** Implementation complete
-
----
-
-### Stage 5: Validate
-
-**Goal:** Verify implementation works
-
-**Actions:**
-1. Run tests (if they exist)
-2. Validate against acceptance criteria
-3. **For parallel execution**: Verify consistency across parallel implementations
-
-<HARD-GATE>
-STOP if validation fails:
-- Tests fail → fix issues before proceeding
-- Criteria unmet → complete implementation
-- Standards violated → refactor to comply
-- **Parallel conflicts** → resolve inconsistencies
-
-DO NOT proceed to Stage 6 until validation passes.
-</HARD-GATE>
-
-**Output:** Validated, working implementation
-
----
-
-### Stage 6: Complete
-
-**Goal:** Finalize with docs and cleanup
-
-**Actions:**
-1. Update documentation (if needed)
-2. Summarize what was done:
-   - Files created/modified
-   - Key technical decisions
-   - **Parallel execution metrics** (if applicable): time saved, batches executed
-   - Follow-up tasks needed
-3. Cleanup (if applicable):
-   - Remove temporary files
-   - Archive session files
-4. Present completion summary to user
-
-**Output:** Task complete, documented, summarized
-
----
-
-## Red Flags - STOP and Follow Workflow
-
-If you catch yourself thinking:
-- "Quick fix, skip context discovery"
-- "Obvious what they want, skip approval"
-- "It's working, skip validation"
-- "Too simple for full workflow"
-- "Context will slow me down"
-- "I'll load context as needed"
-- "Validation is just a formality"
-- "Parallel execution is overkill"
-
-**All of these mean: STOP. Follow the workflow from Stage 1.**
-
-You are rationalizing. The workflow is non-negotiable.
-
----
-
-## Common Rationalizations
-
-| Excuse | Reality |
-|--------|---------|
-| "Too simple for full workflow" | Simple tasks are where skipping stages costs most (30+ min rework) |
-| "I know what they want" | Assumptions cause misalignment. Get approval. (Saves hours) |
-| "Context will slow me down" | Context load = 2 min. Rework = 30+ min. |
-| "Validation is formality" | Skipping validation = bugs in production = emergency fixes |
-| "I'll load context as needed" | Causes race conditions in parallel execution |
-| "Parallel is overkill" | 5x speedup for complex features is not overkill |
-
----
-
-## Key Principles
-
-### Flat Delegation Hierarchy
-
-**Rule**: Only the main agent can invoke subagents. Subagents never call other subagents.
-
-**Correct pattern:**
-```
-Main Agent → /context-discovery → ContextScout
-Main Agent → /task-breakdown → TaskManager
-Main Agent → /code-execution → CoderAgent (multiple in parallel)
-```
-
-**Incorrect pattern (NOT supported):**
-```
-Main Agent → TaskManager → CoderAgent → ContextScout ❌
-```
+## Available OAC Skills
 
-### Context Pre-Loading for Parallel Execution
+| Skill | When to invoke |
+|-------|---------------|
+| `oac:using-oac` | This skill — loaded at session start |
+| `oac:brainstorming` | BEFORE any creative work, building features, adding functionality |
+| `oac:context-discovery` | BEFORE implementing anything — find standards and patterns |
+| `oac:task-breakdown` | When breaking complex features into subtasks |
+| `oac:code-execution` | When implementing code subtasks |
+| `oac:test-generation` | When creating tests |
+| `oac:code-review` | When reviewing code changes |
+| `oac:external-scout` | When working with external libraries/packages |
+| `oac:parallel-execution` | When running multiple agents in parallel |
+| `oac:systematic-debugging` | BEFORE proposing any fix for a bug or test failure |
+| `oac:verification-before-completion` | BEFORE claiming any work is complete or tests pass |
 
-**Why**: Prevents race conditions when multiple agents execute simultaneously
+## Skill Priority
 
-**How**: Stage 3 loads ALL context once, stored in session file, shared across all parallel agents
+When multiple skills could apply, use this order:
 
-### Approval Gates
+1. **Process skills first** (brainstorming, debugging) — these determine HOW to approach the task
+2. **Implementation skills second** (context-discovery, task-breakdown, code-execution) — these guide execution
 
-**Critical checkpoints:**
-- **Stage 2 → 3**: User must approve plan
-- **Stage 5 → 6**: Validation must pass
+"Let's build X" → brainstorming first, then context-discovery, then implementation skills.
+"Fix this bug" → systematic-debugging first, then verification-before-completion.
 
-**Never skip approval** - prevents wasted work and ensures alignment
+## Red Flags
 
-### Parallel Execution (Complex Tasks)
+These thoughts mean STOP — you're rationalizing:
 
-**When**: Complex tasks (4+ files, >30 min) with parallelizable subtasks
+| Thought | Reality |
+|---------|---------|
+| "This is just a simple question" | Questions are tasks. Check for skills. |
+| "I need more context first" | Skill check comes BEFORE clarifying questions. |
+| "Let me explore the codebase first" | Skills tell you HOW to explore. Check first. |
+| "I can check git/files quickly" | Files lack conversation context. Check for skills. |
+| "Let me gather information first" | Skills tell you HOW to gather information. |
+| "This doesn't need a formal skill" | If a skill exists, use it. |
+| "I remember this skill" | Skills evolve. Read current version. |
+| "This doesn't count as a task" | Action = task. Check for skills. |
+| "The skill is overkill" | Simple things become complex. Use it. |
+| "I'll just do this one thing first" | Check BEFORE doing anything. |
+| "This feels productive" | Undisciplined action wastes time. Skills prevent this. |
+| "I know what that means" | Knowing the concept ≠ using the skill. Invoke it. |
 
-**How**: 
-1. TaskManager identifies parallel subtasks (`parallel: true`)
-2. BatchExecutor groups into batches
-3. Multiple CoderAgents execute simultaneously
-4. All use same pre-loaded context (Stage 3)
+## Skill Types
 
-**Benefit**: 5x faster for complex features
+**Rigid** (systematic-debugging, verification-before-completion): Follow exactly. Don't adapt away discipline.
 
----
+**Flexible** (brainstorming, context-discovery): Adapt principles to context.
 
-## Skill Invocations
-
-| Skill | Stage | Purpose |
-|-------|-------|---------|
-| `/context-discovery` | 1 | Find context files |
-| `/external-scout` | 3 | Fetch external library docs |
-| `/task-breakdown` | 2 (complex) | Create detailed subtasks with parallel flags |
-| `/code-execution` | 4 | Implement code subtasks (multiple in parallel) |
-| `/test-generation` | 4 | Create test subtasks |
-| `/code-review` | 4 | Review code subtasks |
-
----
-
-## Examples
-
-### Simple Task: Add email validation
-
-**Stage 1:** Discover validation patterns, security standards  
-**Stage 2:** Plan "Add regex to endpoint", get approval  
-**Stage 3:** Load patterns, standards  
-**Stage 4:** Implement validation + tests, self-review  
-**Stage 5:** Run tests, verify criteria  
-**Stage 6:** Update API docs, summarize  
-
-**Time:** ~10 minutes
-
----
-
-### Complex Task: Build authentication system
-
-**Stage 1:** Discover auth patterns, security standards, architecture guides  
-**Stage 2:** Plan "Multi-phase: JWT service, middleware, endpoints, tests", get approval  
-**Stage 3:** Load all discovered files (shared across parallel agents)  
-**Stage 4:** Parallel execution via BatchExecutor:
-```
-Batch 1 (parallel):
-├─ CoderAgent 1 → JWT service
-├─ CoderAgent 2 → Auth middleware  
-└─ CoderAgent 3 → Login endpoint
-
-Batch 2 (parallel):
-├─ CoderAgent 4 → Password reset
-└─ TestEngineer → Test suite
-```
-**Stage 5:** Run full test suite, verify all criteria, check consistency  
-**Stage 6:** Update docs, summarize, show time saved (5x faster)  
-
-**Time:** ~60 minutes (vs 300 minutes sequential = 5x faster)
-
----
-
-## Session Management (Complex Tasks)
-
-**Location**: `.tmp/sessions/{session-id}/`
-
-**Files**:
-- `context.md` - Shared context for all parallel agents
-- `subtasks/` - Individual subtask definitions
-- `.manifest.json` - Parallel execution state tracking
-
-**Cleanup**: After Stage 6, ask user if session files should be deleted
-
----
-
-## OAC vs Sequential Workflows
-
-| Aspect | Sequential (Superpowers) | Parallel (OAC) |
-|--------|--------------------------|----------------|
-| **Model** | 1 agent, sequential | Multiple agents, parallel |
-| **Best for** | Simple tasks (< 1 hour) | Complex features (> 4 hours) |
-| **Speed** | Fast for simple | **5x faster for complex** |
-| **Use case** | "Fix typo" | "Build auth system" |
-
-**When to use OAC**: Multi-component features, complex refactors, large features (4+ hours)
-
----
-
-## Related Skills
-
-- `context-discovery` - Stage 1 context discovery
-- `external-scout` - Stage 3 external library documentation
-- `task-breakdown` - Stage 4 complex task delegation with parallel flags
-- `code-execution` - Stage 4 code implementation (parallel capable)
-- `test-generation` - Stage 4 test creation
-- `code-review` - Stage 4 code review
-
----
+The skill itself tells you which.
 
-## Success Criteria
+## User Instructions
 
-✅ Every task follows all 6 stages in order  
-✅ Context discovered before execution  
-✅ User approval obtained before implementation  
-✅ All context pre-loaded (prevents race conditions in parallel execution)  
-✅ Validation passes before completion  
-✅ Documentation updated and task summarized  
-✅ **Parallel execution used for complex tasks (5x speedup)**  
+Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.

plugins/claude-code/skills/verification-before-completion/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: verification-before-completion
+description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs — requires running verification commands and confirming output before making any success claims; evidence before assertions always
+---
+
+# Verification Before Completion
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags — STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Agent said success" | Verify independently |
+| "Partial check is enough" | Partial proves nothing |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.