@mrciphersmith/keryx 0.2.9

package/src/gdskills/bundled/rules/core/security-baseline.mdc

@@ -0,0 +1,155 @@
+---
+description: "Security baseline: no secrets in code, parameterized queries, input validation at boundaries, dependency hygiene. Use when writing any code that handles user input, credentials, or external data."
+alwaysApply: false
+---
+
+# Security Baseline
+
+## Purpose
+Prevent the most common and highest-impact security vulnerabilities: hardcoded secrets, SQL injection, missing input validation, and exposed sensitive data.
+
+## When To Apply
+Apply when handling user input, writing queries, managing authentication, reading/writing files, or calling external services.
+
+---
+
+## Rules
+
+### Rule 1: No Secrets in Code or Version Control
+
+**FORBIDDEN in any committed file:**
+- Passwords, API keys, tokens, connection strings
+- Private keys (RSA, EC, SSH)
+- JWT secrets, session secrets
+- Webhook secrets
+- Database credentials
+
+```typescript
+// BAD — secret hardcoded
+const client = new S3Client({ credentials: { accessKeyId: 'AKIAIOSFODNN7EXAMPLE', secretAccessKey: 'wJalrXUtn...' } });
+
+// GOOD — read from environment
+const client = new S3Client({
+  credentials: {
+    accessKeyId: process.env.AWS_ACCESS_KEY_ID!,
+    secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY!,
+  },
+});
+```
+
+**Required:**
+- All secrets via environment variables or secret manager (Vault, AWS SSM, etc.)
+- `.env` files listed in `.gitignore` before any credential is added
+- `process.env.SECRET` access guarded with startup validation (fail-fast if missing)
+
+### Rule 2: Parameterized Queries — No String Interpolation
+SQL injection is the #1 critical vulnerability. Never build queries by string concatenation.
+
+```typescript
+// BAD — SQL injection
+const result = await db.query(`SELECT * FROM users WHERE id = '${userId}'`);
+
+// GOOD — parameterized
+const result = await db.query('SELECT * FROM users WHERE id = $1', [userId]);
+
+// GOOD with ORM
+const user = await User.findOne({ where: { id: userId } });
+```
+
+The same rule applies to NoSQL queries: never use `$where` with interpolated strings in MongoDB, never eval-based queries.
+
+### Rule 3: Validate All External Input
+
+Every value from HTTP requests, CLI args, environment variables, and file reads is untrusted. Validate at the boundary before it enters the application:
+
+```typescript
+// Bad — raw body passed to domain
+app.post('/users', async (req, res) => {
+  await createUser(req.body); // unvalidated
+});
+
+// Good — validate schema at boundary
+import { z } from 'zod';
+const CreateUserSchema = z.object({
+  name: z.string().min(1).max(100),
+  email: z.string().email(),
+  age: z.number().int().min(0).max(150),
+});
+
+app.post('/users', async (req, res) => {
+  const result = CreateUserSchema.safeParse(req.body);
+  if (!result.success) return res.status(400).json({ errors: result.error.issues });
+  await createUser(result.data); // typed, validated
+});
+```
+
+**Validation requirements:**
+- Type coercion is not validation — validate types AND constraints
+- Validate string length bounds (prevent oversized payloads)
+- Validate numeric ranges (prevent overflow attacks)
+- Sanitize HTML if any user input is ever rendered in a browser
+
+### Rule 4: Least Privilege for Database Access
+- Application database user has only the permissions it needs (no `DROP TABLE`, no `CREATE DATABASE`)
+- Separate read and write credentials where possible
+- Never use `root` or `admin` database user in application code
+
+### Rule 5: Never Log Sensitive Data
+
+```typescript
+// BAD
+logger.info('User login', { user, password: req.body.password });
+logger.debug('Payment processed', { card: payment.cardNumber });
+
+// GOOD — log identifiers, not secrets
+logger.info('User login', { userId: user.id, email: user.email });
+logger.debug('Payment processed', { paymentId: payment.id, last4: payment.cardLast4 });
+```
+
+**Never log:** passwords, tokens, full credit card numbers, SSNs, private keys, full session cookies.
+
+### Rule 6: Dependency Hygiene
+- Run `npm audit` / `bun audit` before shipping any new dependency
+- Pin major versions in `package.json` (no `*` or `latest`)
+- Prefer dependencies with active maintenance (last commit < 1 year)
+- Minimize dependency tree — if you can implement it in 10 lines, don't add a package
+
+### Rule 7: Secure Defaults for HTTP
+Every HTTP API must have:
+- Rate limiting on authentication endpoints
+- CORS configured explicitly (not `*` in production)
+- Security headers: `X-Content-Type-Options`, `X-Frame-Options`, `Strict-Transport-Security`
+- Request size limits (prevent DoS via oversized payloads)
+
+---
+
+## Pre-Commit Security Check
+
+Before committing, verify:
+- [ ] No API keys, tokens, or passwords in diff
+- [ ] No `console.log` with sensitive data
+- [ ] New environment variables documented in `.env.example`
+- [ ] No `eval()`, `new Function()`, or dynamic `require()` with user input
+- [ ] No `dangerouslySetInnerHTML` with unescaped user input (React)
+
+---
+
+## Iron Laws
+
+**IRON LAW 1: A hardcoded secret in source code is a production security incident the moment it is committed.**
+**IRON LAW 2: String interpolation in SQL queries is forbidden. No exceptions for "internal" data.**
+**IRON LAW 3: External input that reaches the database, filesystem, or shell without validation is an attack surface.**
+
+---
+
+## Red Flags — Stop and re-read this rule if you are thinking:
+
+| Rationalization | Why it's wrong |
+|---|---|
+| "It's just a dev key, I'll replace it before production" | Dev keys get forgotten in repos — automated secret scanners find them in minutes after push |
+| "The input comes from our own frontend, so it's trusted" | Frontends can be bypassed — always validate at the server boundary |
+| "SQL injection requires a specific pattern, my query is safe" | Every string-interpolated query is vulnerable — parameterize unconditionally |
+| "Logging the token is fine, our logs are private" | Logs are exfiltrated in breaches — sensitive data in logs amplifies every incident |
+| "This package has a known CVE but it's not on the attack path" | "Not on the attack path" is an assumption that changes when the system evolves |
+
+**IRON LAW: SECURITY VULNERABILITIES DO NOT WAIT FOR CONVENIENT TIMING TO BE EXPLOITED.**

package/src/gdskills/bundled/rules/core/shared-definitions.mdc

@@ -0,0 +1,79 @@
+---
+description: "When two places must agree on a format, pattern, protocol or constant, connect them with an import — not with a comment saying they agree."
+alwaysApply: false
+---
+
+# Shared Definitions
+
+## Purpose
+
+Stop one piece of knowledge from living in several places and quietly
+diverging. A comment asserting that two modules agree is not a mechanism: it
+is a claim, it is not checked, and it is read by its author as what they meant
+rather than as what the code does.
+
+## When To Apply
+
+Three situations:
+
+1. A comment refers to another module by name — "the same signals X uses",
+   "matches Y", "as Z does".
+2. A regular expression, format string or constant is added that already
+   exists somewhere in the project.
+3. Something is extracted into a shared module — in which case the question is
+   not only "does the new home work" but "is every old copy gone".
+
+## Mandatory Behavior
+
+1. **If two places must agree, connect them with an import.** One definition,
+   both consumers referencing it. This is the default and it removes the
+   possibility rather than warning about it.
+2. **If an import is genuinely impossible** — different runtime, different
+   package, a protocol shared with something outside the repository — the
+   claim needs a test that fails when the two diverge. The test names both
+   sides.
+3. **A comment is not sufficient.** Do not write "same as <module>" and stop
+   there. Either the import or the test must exist alongside it.
+4. **When extracting, search for the copies you are replacing** and remove
+   them in the same change. An extraction that leaves a second consumer on the
+   old copy has made the divergence more likely, not less: the shared version
+   will now be maintained and the leftover will not.
+5. **When a shared definition is edited, check every consumer** rather than
+   assuming the import list is the whole story — a copy that was never
+   imported will not appear in it.
+
+## Why This Is A Rule And Not Advice
+
+Review does not reliably catch it. The copies are outside the diff, so a
+reviewer reading the change sees the new shared version and not the old one
+left behind. In one repository this rule came from, a duplicated pattern
+survived eight review rounds specifically about that pattern, and was found in
+one run of a mechanical search.
+
+The failure is also quiet. Two copies that agree today behave identically, so
+nothing surfaces until one of them is edited — usually long after, by someone
+who does not know the other exists.
+
+## Output Contract
+
+When reporting on work that touched a shared definition, state:
+
+- where the single definition now lives;
+- which consumers import it;
+- for any place that could not import it, the test that pins the agreement.
+
+## Example
+
+Two modules must recognise the same terminal prompt.
+
+```ts
+// Wrong — a claim, unchecked. Four attempts to restate this rule from a
+// reading of the other module each got it wrong in a different way.
+/** Same signals scripts/watchdog.ts uses. */
+const SIGNAL = /do you want to proceed\?/i;
+```
+
+```ts
+// Right — there is no second copy to get wrong.
+import { isPermissionPrompt } from "../utils/permission-prompt.ts";
+```

package/src/gdskills/bundled/rules/core/skill-lifecycle.mdc

@@ -0,0 +1,55 @@
+---
+description: "When and how agents verify and re-learn project-skills during implementation and review. Verify/learn live in the agent loop, not in git hooks."
+alwaysApply: false
+---
+
+# Skill Lifecycle — verify & learn in the loop
+
+Project-skills (`.metaproject/project-skills/<module>/<entity>/`) capture how a
+module/component/store/service actually works. They drift as code changes.
+Keeping them true is an **agent-loop** responsibility: the implementer, reviewer,
+or orchestrator who is already in the code catches drift at the right moment,
+with context. It is NOT a git hook — the `gdskills` post-commit hook only runs
+`skills verify --all --dry-run` as an advisory staleness signal and never
+mutates.
+
+## Verify — cheap, inline, before you trust a skill
+
+Whoever is about to rely on a project-skill verifies it first:
+
+- Find it: `keryx skills route <target>`.
+- Check freshness: `keryx skills verify <module>/<skill>` (or
+  `skill-verify-skill`). It classifies the skill `fresh | stale | needs-review |
+  blocked` against current code, graph, wiki, health, memory, and tests.
+- If not `fresh`: do NOT follow it blindly — verify each claim against the code
+  and record the drift so it feeds the learn step below.
+
+Verification is read-only and inline; it does not need a subagent.
+
+## Learn — triggered by drift, produces a proposal, applied with review
+
+Trigger `learn` when drift is **confirmed**, not on every commit:
+
+- a reviewer finds a recurring issue a project-skill should have prevented;
+- an implementer's work diverged from what a skill documents;
+- `verify` reported `stale` / `needs-review` for a skill in scope.
+
+Flow:
+
+1. `keryx skills learn --from-review <report> --skill <m>/<s>` (or
+   `--from-health` / `--from-test` / `--from-failure` / `--from-memory`) — writes
+   a **proposal** (JSON). Nothing is mutated yet.
+2. Read the proposal, then `keryx skills learn apply <proposal.json>`
+   (version bump + `skill-changelog.md` with provenance, respects manual
+   sections, file-locked).
+
+`learn` is bounded, mechanical synthesis. **Dispatch it as a subagent; if a
+cheaper / non-flagship model is available in this environment, use it
+(see `model-selection.mdc`), otherwise use the session model.** The flagship's
+only job here is to review the proposal before apply.
+
+## Never
+
+- Do not put `learn` (or any mutation) in a hook.
+- Do not `apply` a proposal without reading it.
+- Do not trust a `stale` / `needs-review` skill as ground truth.

package/src/gdskills/bundled/rules/core/skills-storage-workflow.mdc

@@ -0,0 +1,88 @@
+---
+description: "Skill authoring, storage, and sync workflow for Cursor, Codex, Zed, and OpenCode."
+alwaysApply: false
+---
+
+# Skills Storage Workflow
+
+## Purpose
+Keep skill definitions consistent across master source and global agent directories.
+
+## Trigger
+Apply when user asks to create, update, or sync a skill.
+
+## Mandatory Clarification Step
+Before creating or editing a skill, ask and confirm:
+1. Target location
+2. Skill folder name
+3. Agent profile scope (`Cursor`, `Codex`, `Zed`, `OpenCode`, or all)
+
+## Source of Truth
+`.metaproject/skills/gdskills/<skill-name>/`
+
+## Required Source Layout
+- `SKILL.md` — canonical source of truth
+- `SKILL.cursor.md` — Cursor-specific variant (optional; falls back to SKILL.md)
+- `SKILL.codex.md` — Codex-specific variant (optional; falls back to SKILL.md)
+- `SKILL.zed.md` — Zed-specific variant (optional; falls back to SKILL.md)
+- `SKILL.opencode.md` — OpenCode-specific variant (optional; falls back to SKILL.md)
+
+`SKILL.md` is always required. Platform variants are optional — if absent, `keryx update` installs `SKILL.md` as fallback.
+
+## Global Sync Mapping
+- `SKILL.cursor.md` (or `SKILL.md`) → `~/.cursor/skills/<skill-name>/SKILL.md`
+- `SKILL.codex.md` (or `SKILL.md`) → `${CODEX_HOME:-~/.codex}/skills/<skill-name>/SKILL.md`
+- `SKILL.antigravity.md` (or `SKILL.md`) → `~/.antigravity/skills/<skill-name>/SKILL.md`
+- `SKILL.zed.md` (or `SKILL.md`) → `~/.config/zed/skills/<skill-name>/SKILL.md`
+- `SKILL.opencode.md` (or `SKILL.md`) → `~/.config/opencode/skills/<skill-name>/SKILL.md`
+
+## Mandatory Behavior
+1. Always create/update `SKILL.md` as the canonical source.
+2. Create platform variants only when platform-specific adaptations are needed; otherwise `SKILL.md` serves all platforms via fallback.
+3. Keep all profiles aligned in structure and intent.
+3. Validate skills before sync.
+4. Sync both global destinations after source update.
+5. Ensure `agents/openai.yaml` exists where required by the target agent UI.
+6. For create/update/sync workflows, produce a machine-readable final result for orchestrators.
+
+## Machine-Readable Contract
+Use canonical schema:
+- `.metaproject/rules/schemas/skill-workflow-result.schema.json`
+
+Contract requirements:
+- One top-level JSON object only.
+- Stable required keys.
+- Closed objects (`additionalProperties: false`).
+- `contract_version` in semver.
+- `timestamp_utc` in RFC 3339 UTC.
+
+### Decision Mapping for Orchestrator
+- `status=needs_input` -> `decision=ask_clarification`
+- `status=ready_for_implementation` -> `decision=proceed_to_implementation`
+- `status=implemented` -> `decision=proceed_to_sync` or `stop`
+- `status=blocked|failed` -> `decision=stop`
+
+## Pre-Sync Validation (Mandatory)
+Run before syncing skills:
+
+```bash
+keryx skills verify --all
+```
+
+Then run sync:
+
+```bash
+keryx update
+```
+
+If validation fails, do not sync.
+
+## Naming
+- `skill-name` must be lowercase with numbers/hyphens only.
+- Keep names semantic and stable.
+
+## Forbidden
+- Do not create skills in `~/.cursor/skills-cursor/`.
+
+## Apply Changes Workflow
+Changes under `.metaproject/skills/gdskills/*` should be synced to tool directories using `keryx update`.

package/src/gdskills/bundled/rules/core/solid-principles.mdc

@@ -0,0 +1,149 @@
+---
+description: "SOLID principles for agent-generated code — focus on Single Responsibility, Open/Closed, and Dependency Inversion as the most commonly violated. Use when designing classes, modules, or service interfaces."
+alwaysApply: false
+---
+
+# SOLID Principles
+
+## Purpose
+Prevent the three most common SOLID violations in AI-generated code: god classes, hardcoded dependencies, and modification-on-every-change designs.
+
+## When To Apply
+Apply when creating new classes, services, or modules; when adding logic to an existing class; when wiring up dependencies.
+
+---
+
+## S — Single Responsibility Principle
+
+**One class/module = one reason to change.**
+
+### Rules
+- A class that does more than one thing must be split
+- A function that is longer than ~30 lines almost certainly has multiple responsibilities
+- Mixins of data-fetching + business logic + rendering are always a violation
+- If you cannot name a class in ≤3 words without "and", it has too many responsibilities
+
+### Signals of violation
+- Class name contains "Manager", "Handler", "Util", "Helper" (often catch-alls)
+- Constructor receives >5 dependencies
+- File is longer than 300 lines and is not a config or generated file
+- Method count exceeds 10 on a non-entity class
+
+### Correct pattern
+```typescript
+// BAD — does everything
+class UserService {
+  fetchUser() { /* HTTP */ }
+  validateUser() { /* domain logic */ }
+  formatUserForUI() { /* presentation */ }
+  saveToCache() { /* infrastructure */ }
+}
+
+// GOOD — each class has one job
+class UserRepository { fetchUser() {} }
+class UserValidator { validate() {} }
+class UserPresenter { format() {} }
+class UserCache { save() {} }
+```
+
+---
+
+## O — Open/Closed Principle
+
+**Open for extension, closed for modification.**
+
+### Rules
+- New behaviour must be addable without editing existing classes
+- Use polymorphism, strategy pattern, or configuration — not if/else chains
+- Every time you add an `else if` to handle a new variant, ask: "should this be a new strategy?"
+- Enums as switch-statement keys are the canonical violation — add a new enum value → touch N files
+
+### Signals of violation
+- Switch/if-else over a type enum with 3+ cases
+- Adding a new payment provider / notification channel / export format requires editing core logic
+- A "type" field drives behaviour throughout the codebase
+
+### Correct pattern
+```typescript
+// BAD — every new type requires editing this function
+function notify(type: string, msg: string) {
+  if (type === 'email') sendEmail(msg);
+  else if (type === 'sms') sendSMS(msg);
+  else if (type === 'push') sendPush(msg);
+}
+
+// GOOD — new channels added without touching existing code
+interface Notifier { send(msg: string): Promise<void>; }
+class EmailNotifier implements Notifier { send() {} }
+class SMSNotifier implements Notifier { send() {} }
+// registry → inject the right one
+```
+
+---
+
+## D — Dependency Inversion Principle
+
+**Depend on abstractions, not concretions.**
+
+### Rules
+- High-level modules must not import low-level modules directly
+- Dependencies are injected, not constructed inside the class
+- `new ConcreteService()` inside a business-logic class is always a violation
+- Tests become trivially easy when DIP is followed — if mocking is hard, DIP is violated
+
+### Signals of violation
+- `new` keyword used inside a service or use-case class body
+- Direct imports of `axios`, `prisma`, `fetch` in business logic layers
+- Constructor creates its own dependencies instead of receiving them
+- Testing requires monkey-patching module imports
+
+### Correct pattern
+```typescript
+// BAD — hard dependency on concrete HTTP client
+class OrderService {
+  async createOrder(data: OrderDTO) {
+    const client = new HttpClient(); // ← violation
+    return client.post('/orders', data);
+  }
+}
+
+// GOOD — depends on abstraction, injected externally
+interface HttpClient { post(url: string, body: unknown): Promise<unknown>; }
+
+class OrderService {
+  constructor(private readonly http: HttpClient) {}
+  async createOrder(data: OrderDTO) {
+    return this.http.post('/orders', data);
+  }
+}
+```
+
+---
+
+## L & I (Brief Notes)
+
+**Liskov Substitution (L):** A subclass must be usable wherever the parent is expected. If overriding a method throws where the parent would not — that is a violation.
+
+**Interface Segregation (I):** Prefer small, focused interfaces. A class should not be forced to implement methods it does not use. Split fat interfaces into role interfaces.
+
+---
+
+## Iron Laws
+
+**IRON LAW 1: A class with a name ending in "Manager", "Helper", or "Utils" MUST be reviewed for SRP before committing.**
+**IRON LAW 2: `new ConcreteClass()` inside business logic is forbidden. Pass dependencies via constructor.**
+**IRON LAW 3: Adding a new variant must not require editing more than 1 existing file. If it does, refactor first.**
+
+---
+
+## Red Flags — Stop and re-read this rule if you are thinking:
+
+| Rationalization | Why it's wrong |
+|---|---|
+| "It's just one extra method, I'll add it here" | Each small addition is how god classes are built — one method at a time |
+| "I'll inject it later, for now I'll just `new` it" | "Later" never comes; the hard dependency ships to production |
+| "An interface is overkill for this simple case" | Interfaces cost nothing at compile time and enable testing at zero extra effort |
+| "I'll use a switch, there are only 3 cases" | 3 cases becomes 10 over time — the OCP violation compounds |
+| "The constructor is getting long but refactoring is risky" | A long constructor is a signal the class has too many responsibilities — refactor now, not later |
+
+**IRON LAW: CODE THAT CANNOT BE TESTED WITHOUT MOCKING FILESYSTEM OR NETWORK IN BUSINESS LOGIC HAS A DIP VIOLATION.**

package/src/gdskills/bundled/rules/core/storybook-guidelines.mdc

@@ -0,0 +1,36 @@
+---
+description: "Storybook setup, story authoring, and review checklist."
+alwaysApply: false
+globs:
+  - ".storybook/**"
+  - "**/*.stories.tsx"
+---
+
+# Storybook Guidelines
+
+## Purpose
+Standardize story creation, validation, and visual regression readiness.
+
+## When To Apply
+Apply when creating, reviewing, or updating Storybook stories (`*.stories.tsx`).
+
+## Run Commands
+- Local: `npm run storybook`
+- Clean restart: `npm run storybook:clean`
+- Static build: `npm run build-storybook`
+- Static preview: `npm run storybook:preview`
+
+## Story Authoring Rules
+- Use `*.stories.tsx` with `Meta` and `StoryObj` typing.
+- Prefer `args` for state variants.
+- Use `fn()` from `@storybook/test` for actions.
+- Use decorators for providers/context.
+
+## Review Checklist
+- Cover key states: default/loading/error/empty.
+- Avoid side effects during render.
+- Respect global theme/locale decorators.
+- Update screenshot tests when visual behavior changes.
+
+## Output Contract
+- Story examples in responses must be fenced Markdown code blocks.

package/src/gdskills/bundled/rules/core/subagent-context-construction.md

@@ -0,0 +1,107 @@
+---
+title: Subagent Context Construction
+category: orchestration
+applies_to: job-orchestrator, any orchestrator that dispatches subagents
+---
+
+# Subagent Context Construction
+
+## The Principle
+
+Every subagent dispatch must include an **explicitly constructed context block**. Subagents must not rely on inherited session history. The orchestrator constructs context — the subagent receives it, never retrieves it on its own.
+
+This is not a best practice. It is a hard requirement.
+
+---
+
+## Required Fields in Every Subagent Dispatch
+
+Every prompt sent to a subagent must contain all of the following fields:
+
+```
+## Task
+[Specific task — what exactly to do, no ambiguity]
+
+## Acceptance Criteria
+[List of criteria — when is this task considered done]
+
+## Context
+[Only relevant information — decisions made, constraints, background]
+
+## Files to read
+[Specific list of file paths the subagent must read before acting]
+
+## Constraints
+[What must NOT be done — files to avoid, patterns to not introduce, etc.]
+```
+
+**None of these fields may be omitted.** A dispatch without all five fields is incomplete.
+
+---
+
+## Principles of Context Construction
+
+### 1. Minimality
+Pass only what this specific task needs. Do not dump job state, prior agent output, or full conversation history into the prompt. Every extraneous token increases hallucination risk and degrades the subagent's focus.
+
+### 2. Explicitness
+Better to be overly explicit than implicit. If you think the subagent "obviously" knows something, spell it out anyway. The subagent has no session memory. It only knows what you give it.
+
+### 3. Isolation
+The subagent must not assume anything about the state of the world that you have not explicitly told it. It cannot see what previous agents did, what decisions were made in earlier phases, or what files were modified — unless you include that information in the prompt.
+
+### 4. Concreteness
+Use absolute file paths, not vague pointers. Write `.metaproject/skills/gdskills/orchestration/task-implementer/SKILL.md`, not "look in the skills directory". Write `src/store/PipelineStore.ts`, not "the store file".
+
+---
+
+## Template Dispatch Block
+
+Use this template for every subagent dispatch:
+
+```
+Task({
+  description: "<one-line summary for logs>",
+  subagent_type: "general",
+  prompt: |
+    ## Task
+    <Exactly what to do — no ambiguity>
+
+    ## Acceptance Criteria
+    - <criterion 1>
+    - <criterion 2>
+    - <criterion 3>
+
+    ## Context
+    <Relevant decisions, constraints, and background — only what matters for THIS task>
+
+    ## Files to read
+    - <absolute/path/to/file1.ts>
+    - <absolute/path/to/file2.ts>
+
+    ## Constraints
+    - Do NOT modify <file or pattern>
+    - Do NOT introduce <pattern>
+    - <other hard stops>
+})
+```
+
+---
+
+## Red Flags — Stop and fix your dispatch if you are thinking:
+
+| Rationalization | Why it's wrong |
+|---|---|
+| "The subagent will figure out what it needs" | BLOCKED — the subagent has no session context. It will hallucinate or produce generic output. |
+| "I'll pass the full conversation history" | Wastes the subagent's context window with irrelevant history and creates hallucination surface area. Pass only what is needed. |
+| "The task is obvious, minimal context needed" | Missing context = missing output. Obviousness to you (with full session context) means nothing to an isolated subagent. |
+| "Context from the previous subagent will carry over" | It won't. Each subagent starts fresh. The orchestrator bridges state between agents — explicitly. |
+| "I'll tell it to read state.json if it needs more context" | The subagent should not be retrieving orchestrator state. The orchestrator constructs context. The subagent receives it. |
+
+---
+
+## Iron Law
+
+**EVERY SUBAGENT DISPATCH MUST INCLUDE AN EXPLICITLY CONSTRUCTED CONTEXT BLOCK WITH ALL FIVE FIELDS: TASK, ACCEPTANCE CRITERIA, CONTEXT, FILES TO READ, AND CONSTRAINTS.**
+
+A dispatch that omits any of these five fields is invalid and must not be executed.