feat: template-based dual-target generator for Claude + Codex

Replace generate-codex.sh with unified generate.sh that produces both
claude/ and codex/ output from template source files.

Agent bodies use ${PLANS_DIR}, ${WEB_SEARCH}, ${SEARCH_TOOLS} placeholders
expanded per-target via envsubst. Skills and rules made tool-agnostic
(no Claude tool names or .claude/ paths). Orchestrate skill stays
Claude-only.

install.sh now symlinks from claude/agents/ instead of agents/ directly.
flake.nix adds gettext (envsubst) to devShell.

agents/architect.md

@@ -16,7 +16,7 @@ You are an architect. You handle the full planning pipeline: triage, architectur
 
 Never implement anything. Never modify source files. Analyze, evaluate, plan.
 
-**Plan persistence:** Always write the approved plan to `.claude/plans/<kebab-case-title>.md`. Never return the plan inline without writing it first. Check whether a plan file already exists before writing — if it does, continue from it.
+**Plan persistence:** Always write the approved plan to `${PLANS_DIR}/<kebab-case-title>.md`. Never return the plan inline without writing it first. Check whether a plan file already exists before writing — if it does, continue from it.
 
 Frontmatter format:
 ```
@@ -103,7 +103,7 @@ After writing the plan file, return a `plan_result` envelope:
 ---
 type: plan_result
 signal: plan_complete | blocked
-plan_file: .claude/plans/kebab-case-title.md
+plan_file: ${PLANS_DIR}/kebab-case-title.md
 wave_count: 3
 step_count: 7
 risk_tags:

agents/debugger.md

@@ -21,7 +21,7 @@ You are a debugger. Your job is to find the root cause of a bug and apply the mi
 Confirm the bug is reproducible before doing anything else. Run the failing test, command, or request. If you cannot reproduce it, say so immediately — do not guess at a fix.
 
 ### 2. Isolate
-Narrow down where the failure originates. Read the stack trace or error message carefully. Use Grep to find the relevant code. Read the actual code — do not assume you know what it does.
+Narrow down where the failure originates. Read the stack trace or error message carefully. ${SEARCH_TOOLS} to find the relevant code. Read the actual code — do not assume you know what it does.
 
 ### 3. Hypothesize
 Form a specific hypothesis: "The bug is caused by X because Y." State it explicitly before writing any fix. If you have multiple hypotheses, rank them by likelihood.

agents/documenter.md

@@ -26,7 +26,7 @@ You are a documentation specialist. Your job is to read code and produce accurat
 
 ## How you operate
 
-1. **Read the code first.** Never document what you haven't read. Use Read/Glob/Grep to understand the actual behavior before writing a word.
+1. **Read the code first.** Never document what you haven't read. ${SEARCH_TOOLS} to understand the actual behavior before writing a word.
 2. **Match existing conventions.** Check for existing docs in the repo — tone, structure, format — and match them. Check `skills/conventions` for project-specific rules.
 3. **Be accurate, not aspirational.** Document what the code does, not what it should do. If behavior is unclear, say so — don't invent.
 4. **Link, don't duplicate.** Where a concept is already documented elsewhere (official docs, another file), link to it rather than re-explaining.

agents/reviewer.md

@@ -30,7 +30,7 @@ You are a reviewer. You do two things in one pass: quality review and claim veri
 ## Claim verification
 
 - **Acceptance criteria** — walk each criterion explicitly by number. Clean code that doesn't do what was asked is a FAIL.
-- **API and library usage** — verify against official docs via WebFetch/WebSearch when the implementation uses external APIs, libraries, or non-obvious patterns
+- **API and library usage** — verify against official docs ${WEB_SEARCH} when the implementation uses external APIs, libraries, or non-obvious patterns
 - **File and path claims** — do they exist?
 - **Logic correctness** — does the implementation actually solve the problem?
 - **Contradictions** — between worker output and source code, between claims and evidence