opencastle 0.35.2 → 0.35.3

package/src/orchestrator/skills/react-development/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: react-development
-description: "Enforces naming conventions, prop typing patterns, file structure, and test coverage standards. Use when creating or modifying React components, custom hooks, or component tests. Trigger terms: React app, .tsx files, testing library, custom hooks, functional components"
+description: "Enforces React-specific patterns: functional components with hooks, TypeScript prop interfaces, CSS Modules co-location, React Testing Library behavioral tests. Use when creating React components, writing custom hooks, structuring component folders, applying RTL test patterns, or wiring TypeScript prop types. Trigger terms: React, .tsx, component, hook, RTL, jsx, useState, useEffect, prop interface"
 ---
 
 # React Development Standards
@@ -9,7 +9,7 @@ description: "Enforces naming conventions, prop typing patterns, file structure,
 
 ## New Component Workflow
 
-1. **Create file** — `ComponentName.tsx` in the feature folder; co-locate `ComponentName.module.scss` and `ComponentName.test.tsx`
+1. **Create file** — `ComponentName.tsx` in feature folder; co-locate `ComponentName.module.scss`, `ComponentName.test.tsx`
 2. **Define interface** — export `ComponentNameProps` with TypeScript; destructure in function signature
 3. **Implement** — functional component with hooks; use CSS Modules for styling
 4. **Test** — RTL behavioral tests; cover render, interaction, edge cases, accessibility
@@ -17,7 +17,7 @@ description: "Enforces naming conventions, prop typing patterns, file structure,
 
 ## Architecture & Components (concise)
 
-- Functional components with hooks. Follow domain/feature folder structure and co-locate tests/styles with components.
+- Functional components with hooks. Follow domain/feature folder structure; co-locate tests/styles with components.
 - PascalCase names; destructure props; use TypeScript interfaces for props.
 
 ```tsx
@@ -34,7 +34,7 @@ export function UserCard({ name, role }: UserCardProps) {
 
 ## TypeScript
 
-- Use interfaces for props and shared types; keep strict mode enabled in `tsconfig.json`. See [REFERENCE.md](REFERENCE.md) for detailed TypeScript patterns.
+- Use interfaces for props, shared types; keep strict mode enabled in `tsconfig.json`. Generic constraints: `<T extends Record<string, unknown>>`. Discriminated unions for variant props. Avoid `as` casts.
 
 ## Styling
 
@@ -47,8 +47,8 @@ export function UserCard({ name, role }: UserCardProps) {
 ## Testing
 
 - React Testing Library (behavior, not implementation); Jest runner.
-- Co-locate tests next to components; mock external deps and API calls.
-- Test accessibility and keyboard navigation; verify component public surface via unit tests.
+- Co-locate tests next to components; mock external deps, API calls.
+- Test accessibility, keyboard navigation; verify component public surface via unit tests.
 
 ```tsx
 import { render, screen } from '@testing-library/react';
@@ -72,8 +72,8 @@ pnpm test        # rerun failing tests with `pnpm test -- -t <name>`
 pnpm build       # ensure production build succeeds
 ```
 
-If `lint` fails: run `pnpm lint --fix` and re-run. If `typecheck` fails: inspect reported files; add missing types. If tests fail: run with `--runInBand` to collect stack traces and reproduce locally.
+If `lint` fails: run `pnpm lint --fix`; re-run. If `typecheck` fails: inspect reported files; add missing types. If tests fail: run with `--runInBand` to collect stack traces; reproduce locally.
 
 ## Security
 
-- Follow project conventions for input sanitization, secret handling, and CSP. See **api-patterns** for validation patterns.
+- Sanitize user-supplied HTML before rendering (e.g. `dompurify`); never trust client validation alone — validate server-side. See **api-patterns** skill for server validation patterns.

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

@@ -1,6 +1,6 @@
 ---
 name: security-hardening
-description: "Security architecture including authentication, authorization, RLS policies, CSP, input validation, and API security. Use when implementing auth flows, writing RLS policies, configuring CSP/headers, validating inputs, or auditing security. Trigger terms: RLS, CSP, Server Actions, Zod, auth flow"
+description: "Security architecture: authentication, authorization, RLS policies, CSP, input validation, API security. Use when implementing auth flows, writing RLS policies, configuring CSP/headers, validating inputs, or auditing security. Trigger terms: RLS, CSP, Server Actions, Zod, auth flow"
 ---
 
 # Security Hardening
@@ -33,7 +33,7 @@ Auth provider with Server Actions pattern. Resolve library via **database** capa
 
 ## CSP
 
-Principle of least privilege. External domains are project-specific (see deployment customization).
+Least privilege. External domains are project-specific (see deployment customization).
 
 - `default-src 'self'` — deny by default
 - `object-src 'none'` — block plugins
@@ -43,7 +43,7 @@ Principle of least privilege. External domains are project-specific (see deploym
 
 **Note:** `'unsafe-inline'`/`'unsafe-eval'` may be required in dev mode — use nonces/hashes in production.
 
-**Examples** — Next.js `next.config.js` headers and middleware pattern:
+**Examples** — Next.js `next.config.js` headers + middleware:
 
 ```js
 // next.config.js
@@ -97,7 +97,7 @@ WHERE relname = 'your_table_name';
 
 `relrowsecurity = true` indicates RLS enabled.
 
-2. Test pattern: verify a user without privileges cannot read rows.
+2. Test pattern: verify user without privileges cannot read rows.
 
 ```sql
 -- As owner (create test row)
@@ -109,7 +109,7 @@ SELECT * FROM your_table_name WHERE id = 1;
 -- expected: 0 rows
 ```
 
-Automate this check in CI: run the enabling query and a simple positive/negative test as part of the security gate.
+Automate this check in CI: run the enabling query + positive/negative test as part of the security gate.
 
 ## Server Action Zod example
 
@@ -141,7 +141,7 @@ if (!authHeader || authHeader !== `Bearer ${process.env.CRON_SECRET}`) {
 
 Generate secret: `openssl rand -hex 32`. Rotate quarterly.
 
-Input: Zod schemas in all Server Actions and route handlers; React Hook Form client-side.
+Input: Zod schemas in all Server Actions, route handlers; React Hook Form client-side.
 
 ## Critical Rules
 
@@ -154,10 +154,10 @@ Input: Zod schemas in all Server Actions and route handlers; React Hook Form cli
 7. Rotate secrets quarterly.
 
 ## Implementation checklist
-1. Enable RLS on tables and add an automated enablement check in CI (example: `SELECT relrowsecurity FROM pg_class WHERE relname = 'your_table'`).
-2. Configure authentication and session middleware; verify via an integration smoke test against a protected endpoint (e.g., `/api/me`).
-3. Add CSP and security headers in `next.config.js` or middleware; validate headers with `curl -I` against a preview URL.
-4. Add Zod validation to all Server Actions and route handlers (see Zod example above).
-5. Run a security audit (RLS positive/negative tests, header validation, and input fuzzing) and block merges on failing gates.
+1. Enable RLS on tables, add automated enablement check in CI (example: `SELECT relrowsecurity FROM pg_class WHERE relname = 'your_table'`).
+2. Configure authentication + session middleware; verify via integration smoke test against protected endpoint (e.g., `/api/me`).
+3. Add CSP + security headers in `next.config.js` or middleware; validate with `curl -I` against preview URL.
+4. Add Zod validation to all Server Actions, route handlers (see Zod example above).
+5. Run security audit (RLS positive/negative tests, header validation, input fuzzing); block merges on failing gates.
 
-Cross-reference: see [api-patterns/SKILL.md](../api-patterns/SKILL.md#architecture) for Server Action patterns and [session-checkpoints/SKILL.md](../session-checkpoints/SKILL.md) for checkpointing security-sensitive work.
+Cross-reference: [api-patterns/SKILL.md](../api-patterns/SKILL.md#architecture) for Server Action patterns; [session-checkpoints/SKILL.md](../session-checkpoints/SKILL.md) for checkpointing security-sensitive work.

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

@@ -1,13 +1,13 @@
 ---
 name: self-improvement
-description: "Appends new entries to LESSONS-LEARNED.md via the opencastle lesson CLI, searches past lessons for matching errors, and proposes skill updates when retry patterns exceed thresholds. Use when consulting or updating LESSONS-LEARNED.md, after task failures, when capturing retrospective insights, or when a retry succeeds."
+description: "Appends new entries to LESSONS-LEARNED.md via opencastle lesson CLI; searches past lessons for matching errors; proposes skill updates when retry patterns exceed thresholds. Use when consulting or updating LESSONS-LEARNED.md, after task failures, when capturing retrospective insights, or when a retry succeeds."
 ---
 
 # Self-Improvement Protocol
 
 ## Core Rule
 
-**Retry with a different approach and it works → document the lesson immediately.** File: `.opencastle/LESSONS-LEARNED.md`
+**Retry with different approach and it works → document lesson immediately.** File: `.opencastle/LESSONS-LEARNED.md`
 
 ## Writing a Lesson
 
@@ -21,16 +21,16 @@ opencastle lesson --title "Short descriptive title" --category general --severit
 
 Required: `--title`, `--category`, `--severity`, `--problem` · Optional: `--wrong`, `--correct`, `--why`
 
-After writing: if the lesson reveals a gap in a skill/instruction file, update that file too (prevents the pitfall at source).
+After writing: if lesson reveals gap in skill/instruction file, update that file too (prevents pitfall at source).
 
 ## Workflow
 
 1. Search LESSONS-LEARNED.md for matching entries or similar errors.
-2. Attempt the task with conservative flags/options informed by lessons.
-3. On failure: retry with modified approach (up to threshold), capture error details and context.
-4. On success: run `opencastle lesson` to record the working approach.
-5. Verify: `tail -1 .opencastle/LESSONS-LEARNED.md` — confirm entry has title, category, and severity. If malformed → re-run with corrected flags.
-6. If the lesson indicates a needed skill/instruction update: draft that change and propose a PR.
+2. Attempt task with conservative flags/options informed by lessons.
+3. On failure: retry with modified approach (up to threshold); capture error details, context.
+4. On success: run `opencastle lesson` to record working approach.
+5. Verify: `tail -1 .opencastle/LESSONS-LEARNED.md` — confirm entry has title, category, severity. If malformed → re-run with corrected flags.
+6. If lesson indicates needed skill/instruction update: draft change; propose a PR.
 
 Quick search example:
 
@@ -40,11 +40,11 @@ rg "missing CRON_SECRET" .opencastle/LESSONS-LEARNED.md || true
 
 ## Categories & Severity
 
-Category and severity tables moved to [LESSON-CATEGORIES.md](LESSON-CATEGORIES.md). Use that file when tagging lessons.
+Category, severity tables moved to [LESSON-CATEGORIES.md](LESSON-CATEGORIES.md). Use that file when tagging lessons.
 
 ## Quality Rules
 
-- Include exact error messages, commands, and tool parameters
+- Include exact error messages, commands, tool parameters
 - Show wrong **and** correct approaches — the contrast is actionable
 - Explain why (root cause)
 - One lesson per entry; code blocks mandatory for commands
@@ -55,4 +55,4 @@ Never skip reading lessons · Never fix without documenting · Never write vague
 
 ## Agent Memory
 
-For expertise tracking and cross-session knowledge graphs, load the **agent-memory** skill.
+For expertise tracking, cross-session knowledge graphs, load **agent-memory** skill.

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

@@ -1,28 +1,27 @@
 ---
 name: seo-patterns
-description: "Implements technical SEO: meta tags, JSON-LD structured data, sitemaps, and crawlability fixes. Use when adding schema markup, JSON-LD, robots.txt updates, canonical URLs, Open Graph tags, or improving crawlability."
+description: "Implements technical SEO: meta tags, JSON-LD structured data, sitemaps, crawlability fixes. Use when adding schema markup, JSON-LD, robots.txt updates, canonical URLs, Open Graph tags, or improving crawlability."
 ---
 
 # SEO Patterns
 
 ## Core Principles
 
-- Every public page MUST have a unique `<title>` and `<meta name="description">`.
-- Structured data MUST validate against Google's Rich Results Test before shipping.
-- Server-render all content critical for indexing.
-- Canonical URLs are mandatory on every page.
+- Unique `<title>` + `<meta name="description">` per public page
+- Structured data MUST pass Google's Rich Results Test before shipping
+- Server-render indexable content; canonical URL on every page
 
 ## Implementation Workflow
 
-1. Add meta tags and canonical URLs in server-rendered HTML.
-  - Checkpoint: every page has unique `<title>` and `<meta name="description">`.
-2. Add structured data (JSON-LD) for the page type and keep blocks server-rendered.
-  - Checkpoint: Rich Results Test passes with zero errors.
-3. Generate / update sitemap and reference it from `robots.txt`.
-  - Checkpoint: sitemap URL present in `robots.txt` and accessible.
-4. Verify robots.txt rules and ensure public pages are allowed.
-  - Recovery: remove accidental `Disallow:` entries and re-submit sitemap.
-5. Monitor Search Console for warnings and enhancement reports post-deploy.
+1. Add meta tags + canonical URLs in server-rendered HTML.
+   - Checkpoint: every page has unique `<title>` + description.
+2. Add JSON-LD for page type (server-rendered).
+   - Checkpoint: Rich Results Test → 0 errors.
+3. Generate sitemap + reference from `robots.txt`.
+   - Checkpoint: sitemap URL accessible, listed in `robots.txt`.
+4. Verify `robots.txt` allows public pages.
+   - Recovery: remove accidental `Disallow:` entries; resubmit sitemap.
+5. Monitor Search Console for warnings post-deploy.
 
 ## Meta Tags & Open Graph
 
@@ -43,14 +42,38 @@ export const metadata: Metadata = {
 };
 ```
 
-**Checklist:** unique title (50-60 chars) · unique description (150-160 chars) · canonical URL · `og:title/description/image` (1200×630 px) · `og:type` · `twitter:card/title/image` · `noindex` only on admin/draft pages.
+**Constraints:** title 50–60 chars · description 150–160 chars · OG image 1200×630 px · `noindex` only on admin/draft pages.
 
-## Structured Data & Crawlability
-For structured data reference examples and detailed anti-patterns see [REFERENCE.md](./REFERENCE.md).
+## Structured Data (JSON-LD)
 
-- Generate XML sitemap dynamically from your data source (CMS, DB, filesystem).
-- Use a **sitemap index** when >50,000 URLs or >50 MB.
-- Include `<lastmod>` only if accurate; submit via Google Search Console and reference in `robots.txt`.
+```tsx
+function StructuredData({ breadcrumbs, article }: Props) {
+  const breadcrumbLd = {
+    '@context': 'https://schema.org', '@type': 'BreadcrumbList',
+    itemListElement: breadcrumbs.map((crumb, i) => ({ '@type': 'ListItem', position: i + 1, name: crumb.label, item: crumb.url })),
+  };
+  const articleLd = {
+    '@context': 'https://schema.org', '@type': 'Article',
+    headline: article.title, description: article.summary,
+    image: article.imageUrl, datePublished: article.publishedAt,
+    dateModified: article.updatedAt, author: { '@type': 'Person', name: article.author },
+  };
+  return (
+    <>
+      <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(breadcrumbLd) }} />
+      <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(articleLd) }} />
+    </>
+  );
+}
+```
+
+**Validate:** `curl -s https://example.com/page | pup 'script[type=application/ld+json] text{}' | jq .` then run Google's Rich Results Test (https://search.google.com/test/rich-results).
+
+## Sitemap & robots.txt
+
+- Generate XML sitemap dynamically from your data source (CMS, DB, filesystem)
+- Use **sitemap index** when >50,000 URLs or >50 MB
+- Include `<lastmod>` only if accurate
 
 ```txt
 User-agent: *
@@ -61,7 +84,10 @@ Disallow: /preview/
 Sitemap: https://example.com/sitemap.xml
 ```
 
-**Crawlability checklist:** robots.txt allows public pages · blocks admin/API/preview · XML sitemap auto-generated · referenced in robots.txt · no orphan pages · primary content in initial HTML · unique `<h1>` with keyword · structured data in SSR HTML · descriptive `alt` on images · no stray `noindex` · page load < 3s.
+## Anti-Patterns
 
-## Anti-Patterns & Structured Data Reference
-See `REFERENCE.md` for detailed structured data examples, validation commands, and a trimmed anti-pattern checklist.
+- Duplicate titles across pages
+- Missing canonical URL → duplicate content
+- Client-only rendered primary content → not indexed
+- Unvalidated structured data shipped to prod
+- Page load >3s on mobile

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

@@ -1,6 +1,6 @@
 ---
 name: session-checkpoints
-description: "Saves and restores session state including task progress, file changes, and delegation history. Use when saving progress, resuming interrupted work, picking up where you left off, or checkpointing current work."
+description: "Saves, restores session state including task progress, file changes, delegation history. Use when saving progress, resuming interrupted work, picking up where you left off, or checkpointing current work."
 ---
 
 # Skill: Session Checkpoints
@@ -17,14 +17,14 @@ description: "Saves and restores session state including task progress, file cha
 
 ## Checkpoint Template
 
-The full checkpoint template has been moved to `CHECKPOINT-TEMPLATE.md` in this directory for progressive disclosure. Use that file as the canonical, copy-pasteable checkpoint document.
+Full checkpoint template moved to `CHECKPOINT-TEMPLATE.md` in this directory for progressive disclosure. Use that file as canonical, copy-pasteable checkpoint document.
 
-See the Decomposition Flow in the `decomposition` skill for when to create checkpoints: [decomposition](../../skills/decomposition/SKILL.md).
+See Decomposition Flow in `decomposition` skill for when to create checkpoints: [decomposition](../../skills/decomposition/SKILL.md).
 ## Checkpoint creation (quick)
 
-1. Create `.opencastle/SESSION-CHECKPOINT.md` from the example below.
-2. Commit checkpoint or save to workspace and attach to the tracker issue.
-3. Verify: `cat .opencastle/SESSION-CHECKPOINT.md` and confirm listed files exist.
+1. Create `.opencastle/SESSION-CHECKPOINT.md` from example below.
+2. Commit checkpoint or save to workspace; attach to tracker issue.
+3. Verify: `cat .opencastle/SESSION-CHECKPOINT.md`; confirm listed files exist.
 
 ```markdown
 # Session Checkpoint — 2026-04-01
@@ -48,20 +48,20 @@ Implementing search filters — unit tests passing, E2E pending.
 3. Continue TASK-13: write E2E tests for filter interactions
 ```
 
-For the complete copy-pasteable template, see [CHECKPOINT-TEMPLATE.md](./CHECKPOINT-TEMPLATE.md).
+For complete copy-pasteable template, see [CHECKPOINT-TEMPLATE.md](./CHECKPOINT-TEMPLATE.md).
 
 ## Resuming
 
 1. Read `.opencastle/SESSION-CHECKPOINT.md`
-2. Run `git status` and `git branch` — confirm you are on the correct branch
+2. Run `git status`, `git branch` — confirm you are on correct branch
 3. Check In Progress tasks — if stale (>1 session old), verify files match expected state
 4. Check Pending Approvals — remove rows for questions answered via VS Code chat
-5. Read tracker issues for any tasks marked In Progress or Todo
-6. Follow the Resume Instructions section in the checkpoint
+5. Read tracker issues for tasks marked In Progress or Todo
+6. Follow Resume Instructions section in checkpoint
 7. Update checkpoint progress after each completed task
 
-**If checkpoint is missing or corrupt:** Rebuild from `git log --oneline -20` and tracker state.
+**If checkpoint missing or corrupt:** Rebuild from `git log --oneline -20`, tracker state.
 
 ## Cleanup & Team Lead
 
-When all issues Done: archive to tracker, delete `.opencastle/SESSION-CHECKPOINT.md`.
+When all issues Done: archive to tracker; delete `.opencastle/SESSION-CHECKPOINT.md`.

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

@@ -1,6 +1,6 @@
 ---
 name: team-lead-reference
-description: "Provides model routing rules, validates delegation prerequisites, supplies cost tracking templates, and defines dead-letter queue formats for Team Lead orchestration. Load when assigning tasks to agents, choosing model tiers, starting a delegation session, running a multi-agent workflow, delegating work, choosing which model to use, or assigning tasks."
+description: "Provides model routing rules, validates delegation prerequisites, supplies cost tracking templates, defines dead-letter queue formats for Team Lead orchestration. Load when assigning tasks to agents, choosing model tiers, starting delegation session, running multi-agent workflow, delegating work, choosing which model to use, or assigning tasks."
 ---
 
 # Team Lead Reference
@@ -15,7 +15,7 @@ description: "Provides model routing rules, validates delegation prerequisites,
 6. **Handle** output per Status Handling table
 7. **Log** via **observability-logging** skill
 
-For the specialist agent registry and model assignments, see [agent-registry.md](../../.opencastle/agents/agent-registry.md).
+For specialist agent registry, model assignments, see [agent-registry.md](../../.opencastle/agents/agent-registry.md).
 
 ## Cost-Aware Model Routing
 
@@ -56,7 +56,7 @@ For the specialist agent registry and model assignments, see [agent-registry.md]
 | 3–5 subtasks, mixed | Quick deepen — single Researcher sub-agent |
 | 6+ subtasks, unfamiliar | Full deepen — parallel Researcher sub-agents |
 
-**Quick deepen:** Fire one Researcher for exact file paths & line numbers, patterns to follow (file:line examples), relevant lessons from `LESSONS-LEARNED.md`, and risks/blockers per subtask.
+**Quick deepen:** Fire one Researcher for exact file paths & line numbers, patterns to follow (file:line examples), relevant lessons from `LESSONS-LEARNED.md`, risks/blockers per subtask.
 **Full deepen:** Split by domain into parallel Researchers. See [agent-registry.md](../../.opencastle/agents/agent-registry.md) for scope examples.
 
 | Field | Before Deepen | After Deepen |
@@ -79,8 +79,8 @@ For the specialist agent registry and model assignments, see [agent-registry.md]
 ## Pre-Delegation Policy Checks
 
 1. Tracker issue exists for this task
-2. File partition is clean (no overlap with parallel agents)
-3. All dependency tasks are Done
+2. File partition clean (no overlap with parallel agents)
+3. All dependency tasks Done
 4. Delegation prompt has file paths + acceptance criteria
 5. Self-improvement reminder included (`Read LESSONS-LEARNED.md first`)
 
@@ -115,7 +115,7 @@ Entry (`DLQ-XXX: Short description`): **Date**, **Agent**, **Tracker Issue**, **
 
 ## Error Recovery
 
-For common failure modes and recovery procedures, load the **orchestration-protocols** skill.
+For common failure modes, recovery procedures, load **orchestration-protocols** skill.
 
 ## Dispute Protocol
 

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

@@ -1,6 +1,6 @@
 ---
 name: testing-workflow
-description: "Generates test plans, writes unit/integration/E2E test files, identifies coverage gaps, and flags common testing anti-patterns. Use when writing tests, creating test suites, planning test strategies, mocking dependencies, measuring code coverage, or test planning."
+description: "Generates test plans, writes unit/integration/E2E test files, identifies coverage gaps, flags common testing anti-patterns. Use when writing tests, creating test suites, planning test strategies, mocking dependencies, measuring code coverage, or test planning."
 ---
 
 # Testing Workflow
@@ -16,7 +16,7 @@ description: "Generates test plans, writes unit/integration/E2E test files, iden
 ## Core Rules
 
 - Validate every feature: happy paths, edge cases, error conditions, interactions.
-- **Mandatory**: Test in browser via the **e2e-testing** capability slot before marking complete.
+- **Mandatory**: Test in browser via **e2e-testing** capability slot before marking complete.
 
 ## E2E Context Limits
 
@@ -53,7 +53,7 @@ Suite files: see `.opencastle/project.instructions.md`.
 
 | Anti-Pattern | Correct Approach |
 |---|---|
-| Testing only initial page load | Test filter changes and different results |
+| Testing only initial page load | Test filter changes, different results |
 | Assuming filters work because they render | Verify each option changes results |
 | Client-side only | Verify server requests are triggered |
 | Single scenario | Test urban, rural, edge, out-of-range |

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

@@ -1,6 +1,6 @@
 ---
 name: validation-gates
-description: "Defines 10 sequential validation gates: secret scanning, lint/test/build checks, blast radius analysis, dependency auditing, browser testing, cache management, regression checks, and smoke tests. Use when running pre-deploy validation or CI checks, CI/CD pipelines, deployment pipeline validation, pre-merge checks, continuous integration, or pull request validation."
+description: "Defines 10 sequential validation gates: secret scanning, lint/test/build checks, blast radius analysis, dependency auditing, browser testing, cache management, regression checks, smoke tests. Use when running pre-deploy validation or CI checks, CI/CD pipelines, deployment pipeline validation, pre-merge checks, continuous integration, or pull request validation."
 ---
 
 # Validation Gates
@@ -28,7 +28,7 @@ Example tool: `gitleaks detect --source . --verbosity warn` (or CI equivalent)
 
 ## Gate 2: Deterministic Checks
 
-Run for every affected project (resolve exact commands via the **codebase-tool** skill): lint (with auto-fix), test, build. All must pass with zero errors.
+Run for every affected project (resolve exact commands via **codebase-tool** skill): lint (with auto-fix), test, build. All must pass with zero errors.
 
 Example (project with npm scripts):
 
@@ -59,7 +59,7 @@ npm run lint && npm test --silent && npm run build
 | Vulnerability | `npm audit --audit-level=moderate` | No new high/critical | BLOCK — use patched version or alternative |
 | Bundle size | `npx source-map-explorer dist/*.js` or `npx bundlesize` | Frontend pkgs ≤50KB gzipped (project policy) | SHOULD-FIX; blocking if >200KB |
 
-See [REFERENCE.md](REFERENCE.md) for the full dependency-audit checklist (license, duplicates, maintenance, and additional checks).
+See [REFERENCE.md](REFERENCE.md) for full dependency-audit checklist (license, duplicates, maintenance, additional checks).
 
 ## Gate 5: Fast Review
 
@@ -83,8 +83,8 @@ Additional options: see [REFERENCE.md](REFERENCE.md).
 ## Gate 8: Regression Testing
 
 1. `npm test -- --runInBand` for all affected projects
-2. Browser-test adjacent pages (navigation, routing, back-button). Identify adjacent pages by searching for route imports or links to the changed path (e.g., `rg "href=\"/changed-path|import .*from '@/components/changed'"`).
-3. Check consuming apps / packages that import the changed files: search the repo for the component or package name (e.g., `rg "from '@/components/PriceRange'|@my-org/ui-package"`) and run their tests or quick smoke builds.
+2. Browser-test adjacent pages (navigation, routing, back-button). Identify adjacent pages by searching for route imports or links to changed path (e.g., `rg "href=\"/changed-path|import .*from '@/components/changed'"`).
+3. Check consuming apps / packages importing changed files: search repo for component or package name (e.g., `rg "from '@/components/PriceRange'|@my-org/ui-package"`) and run their tests or quick smoke builds.
 
 ## Gate 9: Panel Review
 
@@ -102,4 +102,4 @@ runSubagent({ agentName: 'Reviewer', prompt: `Panel review 1/3: ${criteria}` });
 npm run build && npm test && npx playwright test
 ```
 
-Full build + test from clean state → E2E browser walkthrough → cross-task integration check → responsive sweep (if UI). On failure: re-delegate the specific failing integration only.
+Full build + test from clean state → E2E browser walkthrough → cross-task integration check → responsive sweep (if UI). On failure: re-delegate specific failing integration only.

package/src/orchestrator/skills/backbone-scaffolding/EXAMPLES.md

@@ -1,16 +0,0 @@
-# backbone-scaffolding Examples
-
-## Convoy Scaffolding Task
-
-```json
-{
-  "id": "scaffolding",
-  "description": "Scaffold monorepo with backbone CLI",
-  "agent": "developer",
-  "complexity": 2,
-  "prompt": "Scaffold the project monorepo using the backbone CLI. Ensure Node.js >= 22.5.0 is available. Run: `npx @monkilabs/backbone my-project` and select the following options when prompted:\n- Monorepo: Turborepo\n- Framework: Next.js\n- Backend: Supabase\n- CMS: Sanity\n- Testing: Playwright\n- Deployment: Vercel\n- Mobile: None\n- Packages: Email Library, LLM Library\n- Payments: Stripe\n- Observability: Sentry\n\nAfter scaffolding completes, run `npm install` in the generated `my-project/` directory. Then run `npx turbo build` and verify it exits 0.",
-  "files": ["my-project/"]
-}
-```
-
-All subsequent tasks should declare `depends_on: ["scaffolding"]` and build on the generated structure.

package/src/orchestrator/skills/decomposition/REFERENCE.md

@@ -1,28 +0,0 @@
-> Parent: [SKILL.md](./SKILL.md)
-
-# Delegation Spec — Full Template
-
-## Delegation Spec: [Task Title]
-**Tracker Issue:** TAS-XX — [Title]
-**Complexity:** [score]/13 → [tier] tier
-**Agent:** [Agent Name]
-
-### Objective
-1-3 sentences: what to build/change and why.
-
-### Context
-- Key files: [list]
-- Related patterns: [file:line references]
-- Prior phase output: [compacted summary if applicable]
-- Relevant lessons: [LES-XXX from LESSONS-LEARNED.md]
-
-### Constraints
-- File partition: Only modify files under [paths]
-- Do NOT modify: [explicit exclusions]
-- Dependencies: Requires [TAS-XX] Done first
-
-### Acceptance Criteria
-- [ ] Criterion 1
-
-### Expected Output
-Files changed · Verification (lint/test/build) · AC status (✅/❌) · Discovered issues · Lessons applied

package/src/orchestrator/skills/memory-merger/REFERENCE.md

@@ -1,20 +0,0 @@
-> Parent: [SKILL.md](./SKILL.md)
-
-## Memory Merger Reference
-
-### Worked Example: LES-042 — MCP Tool Timeout
-
-**Lesson:** `LES-042: MCP tool timeout causes silent failures — always set explicit timeout and check return value` (cited 4×, severity high, 90 days old)
-
-**Draft:**
-```
-Lesson: LES-042 — MCP tool timeout
-Target: .github/skills/orchestration-protocols/SKILL.md
-Section: Error Recovery Playbook
-Edit: Add row: | **MCP timeout** | Tool returns null/undefined after delay | Set explicit timeout (30s); check return value; retry once; fall back to CLI; log to DLQ | <!-- Merged from LES-042 -->
-```
-
-**After merge in target file**, archive in LESSONS-LEARNED.md:
-```markdown
-### LES-042: MCP tool timeout → Merged to `.github/skills/orchestration-protocols/SKILL.md` on 2026-03-15
-```

package/src/orchestrator/skills/react-development/REFERENCE.md

@@ -1,7 +0,0 @@
-> Parent: [SKILL.md](./SKILL.md)
-
-Reference materials for React development guidance.
-
-- See `src/orchestrator/skills/react-development/SKILL.md` for concise rules and quick examples.
-
-Examples, deep-dive topics, and extended patterns (performance, forms, advanced typing) live here when needed.

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

@@ -1,54 +0,0 @@
-> Parent: [SKILL.md](./SKILL.md)
-
-# SEO Reference: Structured Data & Anti-Patterns
-
-## Structured Data Examples (JSON-LD)
-
-### Breadcrumb + Article example
-
-```tsx
-function StructuredData({ breadcrumbs, article }: Props) {
-  const breadcrumbLd = {
-    '@context': 'https://schema.org', '@type': 'BreadcrumbList',
-    itemListElement: breadcrumbs.map((crumb, i) => ({ '@type': 'ListItem', position: i + 1, name: crumb.label, item: crumb.url })),
-  };
-  const articleLd = {
-    '@context': 'https://schema.org', '@type': 'Article',
-    headline: article.title, description: article.summary,
-    image: article.imageUrl, datePublished: article.publishedAt,
-    dateModified: article.updatedAt, author: { '@type': 'Person', name: article.author },
-  };
-  return (
-    <>
-      <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(breadcrumbLd) }} />
-      <script type="application/ld+json" dangerouslySetInnerHTML={{ __html: JSON.stringify(articleLd) }} />
-    </>
-  );
-}
-```
-
-### FAQPage example (minimal)
-
-```json
-{
-  "@context": "https://schema.org",
-  "@type": "FAQPage",
-  "mainEntity": [
-    { "@type": "Question", "name": "Q?", "acceptedAnswer": { "@type": "Answer", "text": "A." } }
-  ]
-}
-```
-
-## Validation
-
-- Validate with Google's Rich Results Test: https://search.google.com/test/rich-results
-- CLI quick-check: `curl -s https://example.com/page | pup 'script[type=application/ld+json] text{}'` then `jq .`
-
-## Anti-Patterns (trimmed)
-
-- Duplicate titles across pages — produce unique, descriptive titles.
-- Missing canonical URLs — add `<link rel="canonical">` to avoid duplicate content.
-- Client-only rendered primary content — server-render or prerender indexable content.
-- Unvalidated structured data — validate before merge and include tests in PRs.
-
-Last Updated: 2026-03-31