opencastle 0.5.1 → 0.7.0

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

@@ -3,26 +3,26 @@ name: security-hardening
 description: "Security architecture including authentication, authorization, RLS policies, security headers, CSP, input validation, API security, and OAuth patterns. Use when implementing auth flows, writing RLS policies, configuring security headers, validating inputs, or auditing security."
 ---
 
-<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the customizations/ directory instead. -->
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .github/customizations/ directory instead. -->
 
 # Security Hardening
 
 ## Security Architecture
 
 ```
-Vercel Edge Network (WAF, DDoS)
-  → Security Headers (next.config.js: HSTS, CSP, X-Frame-Options)
-    → Middleware (proxy.ts: session refresh)
-      → Server Actions (Supabase Auth: CSRF protection)
+Edge Network (WAF, DDoS)
+  → Security Headers (framework config: HSTS, CSP, X-Frame-Options)
+    → Middleware (session refresh)
+      → Server Actions (Auth: CSRF protection)
         → RLS Policies (row-level authorization)
 ```
 
-| Layer | Technology | Protection |
-|-------|-----------|------------|
-| Edge | Vercel WAF | DDoS, bot detection |
-| Headers | Next.js config | HSTS, CSP, XSS protection |
-| Middleware | proxy.ts | Session management |
-| Server Actions | Supabase Auth | Authentication, CSRF |
+| Layer | Role | Protection |
+|-------|------|------------|
+| Edge | WAF / CDN | DDoS, bot detection |
+| Headers | Framework config | HSTS, CSP, XSS protection |
+| Middleware | Proxy / middleware layer | Session management |
+| Server Actions | Auth provider | Authentication, CSRF |
 | Database | RLS Policies | Row-level authorization |
 | API Routes | CRON_SECRET | Cron job authorization |
 | Input | Zod | Schema validation |
@@ -30,38 +30,38 @@ Vercel Edge Network (WAF, DDoS)
 
 ## Authentication
 
-**Platform:** Supabase Auth with Server Actions pattern.
+**Platform:** Auth provider with Server Actions pattern. Resolve specific auth library and configuration via the **database** capability slot in the skill matrix.
 
 - **Server Actions** for sign in/up/out, session management.
 - **Middleware** for session refresh, protected routes.
-- **RLS Policies** in Postgres.
-- **OAuth providers:** Google, Facebook (configured in Supabase dashboard)
-- **User roles:** `user`, `moderator`, `admin` (stored in `profiles.roles TEXT[]`)
-- **Key auth files:** `libs/supabase-auth/src/actions/auth.ts`, `apps/*/proxy.ts`
+- **RLS Policies** in the database.
+- **OAuth providers:** Configured in the auth provider's dashboard.
+- **User roles:** Stored in the user profiles table (e.g., `profiles.roles TEXT[]`).
+- **Key auth files:** Resolve via project-specific customization files.
 - **Cron authorization:** `CRON_SECRET` env var, `Bearer` token in `authorization` header
 
 ### Server Actions Pattern Benefits
 
-- Automatic CSRF protection (Next.js POST-only Server Actions).
+- Automatic CSRF protection (POST-only Server Actions).
 - No exposed API endpoints for auth.
 - Server-side session management.
 
 ### Session Management
 
-- HTTP-only cookies (Supabase client managed).
+- HTTP-only cookies (auth client managed).
 - Automatic refresh via middleware (`updateSession()`).
 - Sign out clears cookie and invalidates session.
 
 ## Content Security Policy
 
-### Allowed External Domains (`next.config.js`)
+### Allowed External Domains (framework config)
 
 | Purpose | Domains |
 |---------|--------|
-| Scripts | `challenges.cloudflare.com`, `cdn.jsdelivr.net`, `cdn.sanity.io`, `maps.googleapis.com` |
-| Styles | `cdn.jsdelivr.net`, `fonts.googleapis.com` |
-| Fonts | `fonts.gstatic.com` |
-| Frames | `challenges.cloudflare.com` |
+| Scripts | Project-specific — see deployment customization |
+| Styles | Project-specific — see deployment customization |
+| Fonts | Project-specific — see deployment customization |
+| Frames | Project-specific — see deployment customization |
 
 ### Directives
 
@@ -72,11 +72,11 @@ General CSP directives follow the principle of least privilege:
 - `frame-ancestors 'self'` — prevent clickjacking.
 - `upgrade-insecure-requests` — enforce HTTPS.
 
-**Known weaknesses:** `'unsafe-inline'` and `'unsafe-eval'` in script-src (required for Next.js dev mode). Consider nonces/hashes for production inline scripts.
+**Known weaknesses:** `'unsafe-inline'` and `'unsafe-eval'` in script-src (may be required for framework dev mode). Consider nonces/hashes for production inline scripts.
 
 ## RLS Policy Patterns
 
-> **Detailed RLS patterns and SQL examples:** See the **supabase-database** skill, which is the authoritative source for RLS policies, role systems, and migration rules.
+> **Detailed RLS patterns and SQL examples:** See the **database** skill (resolved via skill matrix), which is the authoritative source for RLS policies, role systems, and migration rules.
 
 ### Best Practices
 
@@ -111,10 +111,10 @@ export async function GET(request: NextRequest) {
 
 ## Critical Rules
 
-1. Never commit secrets — use Vercel environment variables.
+1. Never commit secrets — use deployment platform environment variables.
 2. Always use Server Actions for auth operations.
 3. Enable RLS on all tables — default-deny, explicit-allow.
 4. Validate all inputs with Zod before database operations.
 5. Sanitize user content — escape HTML in reviews/descriptions.
-6. Parameterized queries (Supabase client handles automatically).
+6. Parameterized queries (database client handles automatically).
 7. Rotate secrets regularly (quarterly).

package/src/orchestrator/skills/self-improvement/SKILL.md

@@ -3,7 +3,7 @@ name: self-improvement
 description: "Protocol for reading and updating the lessons-learned knowledge base. MUST be followed by ALL agents — read lessons before work, write lessons after retries. This makes the agent team self-improving across sessions."
 ---
 
-<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the customizations/ directory instead. -->
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .github/customizations/ directory instead. -->
 
 # Self-Improvement Protocol
 
@@ -44,7 +44,7 @@ A lesson MUST be written when **any** of these triggers occur:
 
 1. If you wrote any new lessons during execution, **update the Index by Category table** at the bottom of `.github/customizations/LESSONS-LEARNED.md` to include the new lesson IDs.
 
-2. **Log the session** — append one JSON line to `.github/customizations/logs/sessions.ndjson` with: `timestamp`, `agent`, `model`, `task`, `linear_issue`, `outcome` (success/partial/failed), `files_changed`, `retries`, `lessons_added`, `discoveries`. See `.github/customizations/logs/README.md` for the full schema.
+2. **Log the session** — append one JSON line to `.github/customizations/logs/sessions.ndjson` with: `timestamp`, `agent`, `model`, `task`, `tracker_issue`, `outcome` (success/partial/failed), `files_changed`, `retries`, `lessons_added`, `discoveries`. See `.github/customizations/logs/README.md` for the full schema.
 
    ```bash
    echo '{"timestamp":"'$(date -u +%Y-%m-%dT%H:%M:%SZ)'","agent":"Agent Name","model":"model-id","task":"Short description","outcome":"success","files_changed":N,"retries":0}' >> .github/customizations/logs/sessions.ndjson
@@ -89,24 +89,25 @@ Add the lesson ID to the appropriate category row in the `## Index by Category`
 If the lesson reveals a gap in existing instruction/skill files, **also update those files** to include the correct approach. This prevents the pitfall at the source level, not just as a retroactive note.
 
 Examples:
-- Lesson about Linear tool → update `task-management/SKILL.md`
-- Lesson about NX commands → update `nx-workspace/SKILL.md`
-- Lesson about Sanity queries → update `sanity-cms/SKILL.md`
-- Lesson about browser testing → update `browser-testing/SKILL.md`
+- Lesson about task tracker tools → update the skill mapped by the `task-management` slot in the skill matrix
+- Lesson about codebase-tool commands → update the skill mapped by the `codebase-tool` slot in the skill matrix
+- Lesson about CMS queries → update the skill mapped by the `cms` slot in the skill matrix
+- Lesson about browser testing → update the skill mapped by the `e2e-testing` slot in the skill matrix
 
 ## Categories
 
 | Category | Covers |
 |----------|--------|
-| `linear` | Linear MCP tools, issue management, workflow states |
+| `task-management` | Task tracker tools, issue management, workflow states |
+| `jira` | Jira MCP tools (Atlassian Rovo), issue management, workflows |
 | `mcp-tools` | Any MCP server tool quirks (deferred loading, parameters) |
-| `nx-commands` | NX CLI commands, task runner, caching |
+| `codebase-tool` | Task runner CLI commands, caching, build tools |
 | `terminal` | Shell commands, port management, process management |
-| `next-js` | Next.js App Router, build, dev server, SSR |
-| `sanity` | Sanity CMS, GROQ queries, schema deployment |
-| `supabase` | Supabase auth, migrations, RLS, SQL |
+| `framework` | App framework, build, dev server, SSR |
+| `cms` | CMS content queries, schema deployment |
+| `database` | Database auth, migrations, RLS, SQL |
 | `git` | Git operations, branching, merge conflicts |
-| `vercel` | Deployment, environment variables, edge config |
+| `deployment` | Deployment, environment variables, edge config |
 | `browser-testing` | E2E testing, screenshots, browser automation |
 | `general` | Anything that doesn't fit above |
 
@@ -130,7 +131,7 @@ Examples:
 
 - **Never skip reading lessons** before starting work — this is the #1 cause of repeated mistakes
 - **Never "fix it and move on"** without documenting — your fix dies with your session
-- **Never write vague lessons** like "Linear is tricky" — be specific about what fails and what works
+- **Never write vague lessons** like "the tracker is tricky" — be specific about what fails and what works
 - **Never duplicate existing lessons** — check the index first
 - **Never wait until the end of a session** to write lessons — write them immediately when the retry succeeds
 

package/src/orchestrator/skills/seo-patterns/SKILL.md

@@ -3,7 +3,7 @@ name: seo-patterns
 description: "Technical SEO patterns for meta tags, structured data, sitemaps, URL strategy, and rendering. Use when optimizing pages for search engines or implementing SEO features."
 ---
 
-<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the customizations/ directory instead. -->
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .github/customizations/ directory instead. -->
 
 # SEO Patterns
 

package/src/orchestrator/skills/session-checkpoints/SKILL.md

@@ -3,7 +3,7 @@ name: session-checkpoints
 description: "Protocol for saving and restoring session state across agent sessions. Enables replay, fork, and resume of interrupted work — inspired by Sandcastle Run Time Machine."
 ---
 
-<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the customizations/ directory instead. -->
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .github/customizations/ directory instead. -->
 
 # Skill: Session Checkpoints
 
@@ -21,7 +21,7 @@ Create a checkpoint:
 
 ## Checkpoint Format
 
-Create or update the file `docs/SESSION-CHECKPOINT.md` with this structure:
+Create or update the file `.github/customizations/SESSION-CHECKPOINT.md` with this structure:
 
 ```markdown
 # Session Checkpoint
@@ -29,7 +29,7 @@ Create or update the file `docs/SESSION-CHECKPOINT.md` with this structure:
 **Last Updated:** YYYY-MM-DD HH:MM
 **Feature:** Short feature name
 **Branch:** git branch name
-**Linear Issues:** TAS-XX, TAS-YY, TAS-ZZ
+**Tracker Issues:** TAS-XX, TAS-YY, TAS-ZZ
 
 ## Current Phase
 
@@ -37,21 +37,21 @@ Phase N of M — Brief description of what this phase does
 
 ## Completed Work
 
-| Task | Linear | Agent | Status | Files |
-|------|--------|-------|--------|-------|
+| Task | Tracker | Agent | Status | Files |
+|------|---------|-------|--------|-------|
 | Description | TAS-XX | Agent Name | ✅ Done | file1.ts, file2.ts |
 | Description | TAS-YY | Agent Name | ✅ Done | file3.ts |
 
 ## In Progress
 
-| Task | Linear | Agent | Status | Notes |
-|------|--------|-------|--------|-------|
+| Task | Tracker | Agent | Status | Notes |
+|------|---------|-------|--------|-------|
 | Description | TAS-ZZ | Agent Name | 🔄 In Progress | What's been done so far |
 
 ## Remaining Work
 
-| Task | Linear | Agent | Dependencies | Files |
-|------|--------|-------|-------------|-------|
+| Task | Tracker | Agent | Dependencies | Files |
+|------|---------|-------|-------------|-------|
 | Description | TAS-AA | Agent Name | TAS-ZZ | file4.ts, file5.ts |
 
 ## Pending Approvals
@@ -80,7 +80,7 @@ the row from this table — the approval was already resolved.
 
 Track each delegation to monitor budget and optimize future model assignments:
 
-| # | Agent | Linear | Model Tier | Est. Tokens | Duration | Status |
+| # | Agent | Tracker | Model Tier | Est. Tokens | Duration | Status |
 |---|-------|--------|------------|-------------|----------|--------|
 | 1 | Content Engineer | TAS-XX | Standard | ~20K | 8 min | ✅ Done |
 | 2 | DB Engineer | TAS-YY | Standard | ~25K | 12 min | ✅ Done |
@@ -93,7 +93,7 @@ Track each delegation to monitor budget and optimize future model assignments:
 ```
 Agent A: dir1/, dir2/
 Agent B: dir3/, dir4/
-Agent C: docs/
+Agent C: .github/customizations/
 ```
 
 ## Resume Instructions
@@ -101,7 +101,7 @@ Agent C: docs/
 Step-by-step instructions for a new session to pick up where this one left off:
 
 1. Check out branch `feat/xxx`
-2. Read Linear issues TAS-XX, TAS-YY for context
+2. Read tracker issues TAS-XX, TAS-YY for context
 3. Start Phase N+1: [specific instructions]
 ```
 
@@ -109,9 +109,9 @@ Step-by-step instructions for a new session to pick up where this one left off:
 
 When starting a new session:
 
-1. **Check for checkpoint** — Read `docs/SESSION-CHECKPOINT.md` if it exists
+1. **Check for checkpoint** — Read `.github/customizations/SESSION-CHECKPOINT.md` if it exists
 2. **Verify state** — Run `git status`, check branch, verify files match checkpoint
-3. **Check Linear** — List in-progress and todo issues for current feature
+3. **Check tracker** — List in-progress and todo issues for current feature
 4. **Follow resume instructions** — Execute the specific steps listed in the checkpoint
 5. **Update checkpoint** — After resuming, update the checkpoint with current progress
 
@@ -137,10 +137,10 @@ When a checkpoint reveals multiple possible paths forward, document them as fork
 
 ## Cleanup
 
-After a feature is fully complete (all Linear issues Done):
+After a feature is fully complete (all tracker issues Done):
 
-1. Archive the checkpoint content to the relevant Linear issue comments
-2. Delete `docs/SESSION-CHECKPOINT.md` to keep the workspace clean
+1. Archive the checkpoint content to the relevant tracker issue comments
+2. Delete `.github/customizations/SESSION-CHECKPOINT.md` to keep the workspace clean
 3. The next feature starts with a fresh checkpoint
 
 ## Integration with Team Lead
@@ -169,7 +169,7 @@ Add a `## Step Output Log` section to the checkpoint file:
 
 ### Step 1: [Short description]
 - **Agent:** [Agent Name]
-- **Linear:** TAS-XX
+- **Tracker:** TAS-XX
 - **Status:** ✅ Completed
 - **Duration:** ~X minutes
 - **Key Outputs:**
@@ -180,7 +180,7 @@ Add a `## Step Output Log` section to the checkpoint file:
 
 ### Step 2: [Short description]
 - **Agent:** [Agent Name]
-- **Linear:** TAS-YY
+- **Tracker:** TAS-YY
 - **Status:** ❌ Failed (attempt 1)
 - **Error:** [Specific error message or failure reason]
 - **Cached Context from Step 1:** [Reference what Step 1 produced]

package/src/orchestrator/skills/team-lead-reference/SKILL.md

@@ -3,7 +3,7 @@ name: team-lead-reference
 description: "Reference data for Team Lead orchestration — model routing, pre-delegation checks, cost tracking template, and DLQ format. Load when starting a delegation session."
 ---
 
-<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the customizations/ directory instead. -->
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .github/customizations/ directory instead. -->
 
 # Team Lead Reference
 
@@ -49,7 +49,7 @@ During decomposition, assign a **complexity score** (Fibonacci: 1, 2, 3, 5, 8, 1
 | Score | Tier | Examples |
 |-------|------|----------|
 | **1-2** | Economy/Utility | Docs update, config tweak, rename, simple test |
-| **3-5** | Standard | Component build, GROQ query, API route, migration |
+| **3-5** | Standard | Component build, CMS query, API route, migration |
 | **8** | Premium | Architecture decision, security audit, complex refactor |
 | **13** | Premium + Panel | DB migration with data transform, auth flow redesign |
 
@@ -117,7 +117,7 @@ Run these validation checks **before** delegating any subtask. Non-negotiable ga
 
 ### Mandatory Checks (before every delegation)
 
-1. **Linear issue exists** — The subtask has a tracked issue with acceptance criteria
+1. **Tracker issue exists** — The subtask has a tracked issue with acceptance criteria
 2. **File partition is clean** — No overlap with other active/parallel agents
 3. **Dependencies are met** — All prerequisite tasks are verified Done (not just claimed done)
 4. **Prompt is specific** — Contains: objective, file paths, acceptance criteria, patterns to follow
@@ -140,7 +140,7 @@ Before calling `runSubagent` or handing off to a background agent, mentally walk
 
 ## Cost Tracking Convention
 
-After completing a feature (all Linear issues Done), add a cost summary to the roadmap update:
+After completing a feature (all tracker issues Done), add a cost summary to the roadmap update:
 
 ```markdown
 **Cost Summary:**
@@ -165,11 +165,11 @@ When collecting results from multiple sub-agents or background agents, **tag eac
 ```markdown
 ### [Content Engineer] TAS-42 Schema
 - Created `schemas/review.ts` with star rating field
-- Deployed to Sanity Studio
+- Deployed to CMS studio
 - Verification: lint ✅, type-check ✅
 
 ### [DB Engineer] TAS-43 Migration
-- Created `supabase/migrations/20260227_add_reviews.sql`
+- Created migration file for reviews table
 - RLS policies for authenticated users
 - Verification: migration applied ✅, tests ✅
 ```
@@ -200,7 +200,7 @@ Log to `.github/customizations/AGENT-FAILURES.md` when:
 |-------|-------|
 | **Date** | YYYY-MM-DD |
 | **Agent** | Agent name |
-| **Linear Issue** | TAS-XX (if applicable) |
+| **Tracker Issue** | TAS-XX (if applicable) |
 | **Failure Type** | `verification-fail` / `tool-error` / `panel-block` / `timeout` / `scope-creep` |
 | **Attempts** | Number of attempts before logging |
 | **Est. Tokens Spent** | ~XXK across all attempts |
@@ -289,7 +289,7 @@ When automated resolution is exhausted (panel 3x BLOCK, approach conflicts, or c
 6. **Recommend an action** — Which option the Team Lead thinks is best, with specific next steps
 7. **Link artifacts** — Panel reports, review logs, changed files, DLQ entries
 8. **Log to disputes.ndjson** — Append a machine-readable record (see logs README)
-9. **Update the Linear issue** — Add the dispute ID and link to the dispute record
+9. **Update the tracker issue** — Add the dispute ID and link to the dispute record
 10. **Update the Index table** — Add the new dispute to the bottom of the Index
 
 ### After Human Resolution
@@ -298,7 +298,7 @@ When a human resolves a dispute:
 1. Update the dispute `Status` → `resolved` or `deferred`
 2. Record which option was chosen and any additional instructions
 3. If `resolved` → re-delegate the task with the human's decision as an explicit constraint
-4. If `deferred` → create a follow-up Linear issue and continue with other work
+4. If `deferred` → create a follow-up tracker issue and continue with other work
 5. Log the resolution in `disputes.ndjson` (update the existing record or append a resolution event)
 
 ### Session Start: Check Disputes

package/src/orchestrator/skills/testing-workflow/SKILL.md

@@ -3,7 +3,7 @@ name: testing-workflow
 description: "Comprehensive testing workflow including test planning, unit/integration/E2E testing patterns, coverage requirements, and common testing mistakes. Use when writing tests, planning test strategies, or validating feature completeness."
 ---
 
-<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the customizations/ directory instead. -->
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .github/customizations/ directory instead. -->
 
 # Testing Workflow
 
@@ -11,7 +11,7 @@ description: "Comprehensive testing workflow including test planning, unit/integ
 
 - Test implementations thoroughly before claiming completion.
 - Every feature must be validated through comprehensive testing covering happy paths, edge cases, error conditions, and user interactions.
-- **Mandatory**: Every feature implementation must be tested in the browser using Chrome DevTools MCP automation before marking as complete.
+- **Mandatory**: Every feature implementation must be tested in the browser using the project's E2E testing tool (resolved via the **e2e-testing** capability slot) before marking as complete.
 
 ## E2E Testing Context Management
 
@@ -22,11 +22,11 @@ description: "Comprehensive testing workflow including test planning, unit/integ
 2. **MAX 3 screenshots** per session.
 3. **Use `evaluate_script()` over `take_snapshot()`** — returns less data.
 4. **Reload between major test flows** to clear state.
-5. **Log results separately** — append to `docs/testing/E2E-RESULTS.md`.
+5. **Log results separately** — append to `.github/customizations/logs/e2e-results.md`.
 
 ### Suite Files
 
-See `project.instructions.md` for the full list of E2E test suite files.
+See `.github/customizations/project.instructions.md` for the full list of E2E test suite files.
 
 ## Pre-Implementation Test Plan
 
@@ -66,11 +66,11 @@ Before implementing any feature, create a plan covering:
 
 > **Detailed breakpoint definitions, resize commands, and per-breakpoint checklists:** See the **browser-testing** skill. The **validation-gates** skill (Gate 3) defines the mandatory testing protocol.
 
-**Anti-pattern:** Testing only at desktop (or only at the default browser width) and assuming responsive classes work. Tailwind classes can be incorrect — always verify visually at every breakpoint.
+**Anti-pattern:** Testing only at desktop (or only at the default browser width) and assuming responsive classes work. CSS utility classes can be incorrect — always verify visually at every breakpoint.
 
 ## Coverage Requirements
 
-### Unit Tests (Jest)
+### Unit Tests
 - **Minimum 95% coverage** for all new code.
 - All exported functions, React components, custom hooks.
 - Edge cases and error conditions. Input validation.
@@ -110,7 +110,7 @@ After completing any feature:
 
 1. Start dev server (see `project.instructions.md` for app/port details).
 2. Open browser to the dev URL.
-3. Test all critical user flows with Chrome DevTools MCP.
+3. Test all critical user flows with the project's E2E testing tool (see the **e2e-testing** skill).
 4. Test edge cases (empty results, max/min values, errors).
 5. Document results with screenshots.
 
@@ -128,9 +128,9 @@ After completing any feature:
 
 ## Commands
 
-```bash
-yarn nx run <project>:test                 # Run tests
-yarn nx run <project>:test --coverage      # With coverage
-yarn nx run <project>:test -u              # Update snapshots
-yarn nx affected -t test                   # Affected tests
-```
+Resolve exact test commands via the **codebase-tool** skill. Common tasks:
+
+- Run project tests
+- Run with coverage
+- Update snapshots
+- Run affected tests only

package/src/orchestrator/skills/validation-gates/SKILL.md

@@ -3,7 +3,7 @@ name: validation-gates
 description: "Shared validation gates for all orchestration workflows — deterministic checks, browser testing, cache management, regression checks. Referenced by prompt templates to maintain single source of truth."
 ---
 
-<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the customizations/ directory instead. -->
+<!-- ⚠️ This file is managed by OpenCastle. Edits will be overwritten on update. Customize in the .github/customizations/ directory instead. -->
 
 # Validation Gates
 
@@ -11,13 +11,11 @@ Canonical reference for validation gates shared across all orchestration workflo
 
 ## Gate 1: Deterministic Checks
 
-Run for every affected NX project:
+Run for every affected project (resolve exact commands via the **codebase-tool** skill):
 
-```bash
-yarn nx run <project>:lint --fix
-yarn nx run <project>:test
-yarn nx run <project>:build
-```
+- **Lint** (with auto-fix)
+- **Test**
+- **Build**
 
 All must pass with zero errors. Run for **every** project that consumed modified files, not just the primary project.
 
@@ -43,18 +41,13 @@ The reviewer validates: acceptance criteria met, file partition respected, no re
 
 **Always clear before testing.** Testing stale code wastes time and produces false results.
 
-```bash
-rm -rf apps/<app>/.next
-yarn nx reset
-```
-
-Run these commands before starting the dev server for browser testing.
+Clear framework caches and task runner caches before starting the dev server for browser testing. See the **codebase-tool** skill for cache-clearing commands.
 
 ## Gate 3: Browser Testing (MANDATORY for UI Changes)
 
 > **HARD GATE:** A task with UI changes is NOT done until you have screenshots in Chrome proving the feature works. "The code looks correct" is not proof. "Tests pass" is not proof. Only a screenshot of the working UI in Chrome is proof.
 
-1. **Start the dev server** — `yarn nx run <app>:serve` — wait for it to be ready
+1. **Start the dev server** — use the project's serve command (see the **codebase-tool** skill) — wait for it to be ready
 2. **Navigate to affected pages** — Verify the new feature renders correctly
 3. **Verify SPECIFIC features** — Check every feature listed in the acceptance criteria. If the criteria say "icons, groups, and AND/OR toggle", you must see all three in the browser
 4. **Test interactions** — Click buttons, fill forms, toggle filters, submit data
@@ -92,7 +85,7 @@ Use this checklist for any orchestration workflow:
 
 - [ ] Lint, test, and build pass for all affected projects
 - [ ] **Fast review passed** (mandatory — load **fast-review** skill)
-- [ ] Dev server started with **clean cache** (`rm -rf .next && yarn nx reset`)
+- [ ] Dev server started with **clean cache** (clear framework + task runner caches — see the **codebase-tool** skill)
 - [ ] UI changes verified in Chrome with screenshots at all breakpoints
 - [ ] Every acceptance criteria item visually confirmed — not just "page loads"
 - [ ] No regressions in adjacent functionality

package/src/orchestrator/mcp.json

@@ -1,61 +0,0 @@
-{
-  "servers": {
-    "Sanity": {
-      "url": "https://mcp.sanity.io",
-      "type": "http"
-    },
-    "Contentful": {
-      "url": "https://mcp.contentful.com/sse",
-      "type": "http"
-    },
-    "Strapi": {
-      "command": "npx",
-      "args": ["-y", "@strapi/mcp-server"],
-      "type": "stdio"
-    },
-    "Vercel": {
-      "url": "https://mcp.vercel.com",
-      "type": "http"
-    },
-    "Supabase": {
-      "type": "http",
-      "url": "https://mcp.supabase.com/mcp"
-    },
-    "Convex": {
-      "command": "npx",
-      "args": ["-y", "@anthropic-ai/convex-mcp-server"],
-      "type": "stdio"
-    },
-    "chrome-devtools": {
-      "command": "npx",
-      "args": ["-y", "chrome-devtools-mcp@latest"],
-      "type": "stdio"
-    },
-    "Linear": {
-      "type": "stdio",
-      "command": "npx",
-      "args": [
-        "-y",
-        "@mseep/linear-mcp"
-      ],
-      "envFile": "${workspaceFolder}/.env"
-    },
-    "Jira": {
-      "url": "https://mcp.atlassian.com/v2/sse",
-      "type": "http"
-    },
-    "Slack": {
-      "type": "stdio",
-      "command": "npx",
-      "args": ["-y", "@kazuph/mcp-slack"],
-      "envFile": "${workspaceFolder}/.env",
-      "env": {
-        "SLACK_MCP_ADD_MESSAGE_TOOL": "true"
-      }
-    },
-    "Teams": {
-      "url": "https://mcp.microsoft365.com/mcp",
-      "type": "http"
-    }
-  }
-}