Artifacts written by `evolve --generate` are inert: Claude Code (and every
spec-compliant Agent Skills client) injects only `name` + `description` at
startup and will not load an artifact missing them.
Today the generator writes:
- skills: `# {name}` with no frontmatter block at all
- commands: `# {cmd_name}` with no frontmatter block at all
- agents: `model`/`tools` only, no `name`, no `description`
So the whole evolve pipeline terminates in files that can never load. I hit
this on a real install: 12 generated artifacts across two projects, none of
which Claude Code had ever seen.
This adds a `_evolved_description()` helper and emits proper frontmatter for
all three artifact kinds. The description is sanitised for the two things that
break loaders: `: ` in an unquoted scalar (rejected by strict YAML parsers)
and `<`/`>` (system-prompt injection risk).
Adds two tests to tests/scripts/instinct-cli-evolve-generate.test.js. Both
fail against current main and pass with this change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude Code 2.1.233 removed the todo/task tools by default on Opus 4.8, Sonnet 5,
Fable 5, Mythos 5 and newer models (TodoWrite, TaskCreate/Get/Update/List).
CLAUDE_CODE_ENABLE_TODO_TOOLS=1 restores them, but that is a per-machine
environment setting that does not travel with a skill, so this skill cannot assume
its reader has a task list at all.
Three claims are wrong for most readers on a current version:
- "What Survives Compaction" listed "TodoWrite task list" unconditionally
- "Plan is in TodoWrite or a file" as the reason to compact at Planning→Implementation
- "Once plan is finalized in TodoWrite, compact to start fresh"
This is load-bearing advice rather than a cosmetic detail: "my todo list survives
compaction" is a reason to compact INSTEAD of writing state down. If the tools are
absent there is no list to survive, so the reader follows the advice, compacts, and
the plan is simply gone.
Changes:
- Promote "Files on disk" into the survives table — the claim that holds on every
version and model.
- Make the task-list row conditional and add a short caveat naming the version, the
env var, and the fact that it does not travel with the skill.
- Point readers at a file as the durable record before compacting.
- Reword the Decision Guide and Best Practices lines so neither depends on the tool
existing.
Applied identically to the Codex (.agents/) and Kiro (.kiro/) mirrors so the three
copies agree. Those mirrors have pre-existing drift from the main skill; this change
deliberately does not touch anything beyond the same three claims.
Verified locally: all eight scripts/ci/ validators pass (unicode-safety, skills,
agents, commands, rules, hooks, install-manifests, no-personal-paths), plus
catalog:check, command-registry:check, and harness-adapter-compliance (12 adapters).
No emoji in the added block, per check-unicode-safety.
Splice artifact from the previous commit — the replacement text ended with the same
anchor string it was spliced against, so the heading was emitted twice. Caught in review.
Both reviewers were right and the original guidance was self-contradictory: it said
attachments are charged to the context window, then told the report to exclude them
when stating remaining room.
Greptile's P1 is the sharper half — after a compaction, pre-compaction turns remain in
the JSONL while the model's active context holds only the summary, so counting
persisted bytes misreports headroom in the other direction too.
The section now says plainly that a transcript is a durable log, not a view of the
context window, and that remaining room must not be reported from its size. The
number is framed as a cost signal instead: scaffolding is rebuilt on every reconnect,
so trimming a component saves tokens once per reconnect rather than once per session.
Snippet fixes: emits an explicit >40% warning with one decimal place rather than
leaving the threshold in prose, guards a missing transcript, exits cleanly on an empty
one, counts bytes rather than characters, and treats a malformed line as conversation
instead of crashing. Verified against all four cases.
context-budget inventories components that load once at startup. On a reconnect the
app re-injects much of that inventory into the session transcript as attachment lines,
and that lands in the same context window.
Measured on a session that had reconnected once: 33,884 of 49,830 bytes was
scaffolding — skill_listing 14.6KB, mcp_instructions_delta 8.1KB, deferred_tools_delta
7.1KB, agent_listing_delta 2.6KB — against 15.9KB of actual conversation.
Adds a measure-it-yourself snippet, a >40% flag, and the consequence for the rest of
the skill: a trimmed skill or MCP server saves tokens once per reconnect, not once per
session. Also notes that transcript size is a poor proxy for context fullness unless
attachment lines are excluded.
Curated skill delegating to the canonical tasteforge package in
Ito-Markets/ito-video: taste interviews, style-pack validation, offline
distillation with measured grounding, deterministic cadence application to
local footage, EDL/FCPXML export, and generated-media provenance audits.
Provider (Fal) generation requires explicit separately authorized execution
and fails closed in ECC; local references never mean a saved provider
workflow. Registered in the opt-in media-generation install module, npm
files, and catalog counts via scripts/ci/catalog.js. Contract tests cover
frontmatter/triggers, the fail-closed boundary, manifest and npm-packed
discoverability (real tarball check opt-in via ECC_TEST_NPM_PACK=1).
* fix(continuous-learning-v2): warn when the observer never survives a hook invocation (#2489)
The observer is lazy-started from a hook process that exits immediately
afterwards. start-observer.sh's liveness check runs inside that still-living
process tree, so it always sees a healthy observer and prints "Observer
started (PID: N)". On native Windows (Git Bash/MSYS2) the reap happens later,
when the hook's Job Object closes, so no self-check placed in
start-observer.sh can ever observe the failure.
The next hook invocation is the only place the death is visible, and
_CHECK_OBSERVER_RUNNING already found it there -- then discarded it, deleting
the stale PID file and restarting silently, once per tool call, forever. Users
were left with an observer-start.log full of success lines and an observer
that never completed a single analysis cycle.
Record the "well-formed PID that is no longer alive" case, count consecutive
non-survivals in ${PROJECT_DIR}/.observer-nosurvive-count, and log one
explanatory warning when the streak reaches ECC_OBSERVER_NOSURVIVE_WARN_AFTER
(default 3). Warning fires on equality so a persistent failure logs once per
streak rather than once per tool call; finding the observer alive resets the
streak. The Windows-specific explanation is gated on uname so Linux/macOS
users are pointed at observer.log instead of a wrong diagnosis.
Counting happens in the caller, not inside _CHECK_OBSERVER_RUNNING, because
that function is invoked once per PID file and again under the start lock.
The PowerShell backgrounding rewrite is deliberately not included: it cannot
be exercised on a non-Windows machine, and untested process-spawning code is
a worse outcome than an accurate diagnostic.
* docs(continuous-learning-v2): state observer platform support and the new warn threshold
The observer's Windows limitation was only discoverable by hitting it. Record
it next to observer.enabled, where it is read before the flag is set, and
document ECC_OBSERVER_NOSURVIVE_WARN_AFTER so the knob added alongside the
warning does not repeat the undocumented-env-var problem tracked in #2573.
zh-TW is intentionally left alone: translation parity is not enforced here and
the repo rejects blind translation imports without translator review.
* fix(continuous-learning-v2): serialize the non-survival streak under the lazy-start lock
observe.sh runs on every tool call, so the streak read-modify-write could race
between concurrent invocations -- losing an increment or logging the warning
twice. That is the same class of bug the signal counter hit in #2296, and this
repo's rule is to never fall back to an unlocked read-modify-write.
Rather than add a second lock, move the increment into _START_OBSERVER_LOGGED.
All three of its call sites already run inside the lazy-start lock
(flock / lockfile / mkdir), so the update is serialized with no new machinery.
Counting at the restart instead of at detection also means N racing hooks
record one death rather than N.
The reset stays in the caller: it is an idempotent unlink, not a
read-modify-write, so it needs no lock.
Adds a regression case pinning the increment inside _START_OBSERVER_LOGGED and
asserting all three call sites remain locked.
* fix(continuous-learning-v2): harden the non-survival threshold and warning output
Three review findings on the #2489 diagnostic:
- An all-zero threshold silently disabled it. `00` passes a digits-only check
but compares as zero, and the streak only grows, so the warning could never
fire. Normalize with base-10 arithmetic and fall back to the default for
anything below 1. Base 10 is forced explicitly because a leading zero would
otherwise be read as octal, and `08` is an arithmetic error that would abort
the hook under `set -e`. The same normalization now guards the streak read.
- An unwritable log silently swallowed the diagnostic. Build the message once
and fall back to stderr when the append fails. This cannot spam: the block
runs once per streak, not once per tool call. The counter write keeps its
`|| true` -- observe.sh runs on every tool call and the repo rule is that
hooks exit 0 on non-critical errors, so a full disk must not break tool use.
- The live-PID test fixture used process.pid, which is 1 in a container and is
deliberately rejected by _CHECK_OBSERVER_RUNNING; the reset case would then
fail for the wrong reason. Use a spawned child and clean it up.
Adds a regression case for the all-zero threshold. Verified on bash 3.2 (the
macOS CI runner shell) as well as bash 5.
* fix(continuous-learning-v2): warn only on a persisted streak increment
If the counter write fails, the file stays below the threshold, so every later
hook invocation rereads it, re-increments in memory, hits the equality check
and warns again -- turning the once-per-streak diagnostic into once-per-tool-
call spam. That is worse in exactly the case the stderr fallback added in the
previous commit was meant to cover, since a disk that cannot take the log
usually cannot take the counter either.
Gate the warning on the write succeeding. The write stays non-fatal: it runs
as an `if` condition, so `set -e` is satisfied and an unwritable counter costs
a delayed diagnostic rather than a broken tool call.
Tests: an unwritable counter must stay silent across repeated invocations while
the hook still exits 0, and a leading-zero threshold ("08") must be read as
decimal -- "00" alone did not exercise the base-10 conversion, since it is zero
either way.
---------
Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
Two findings from the bot review.
The reusable payment client had no authorization boundary. The policy
validates one challenge at a time, so it cannot see a session total and
cannot ask a human anything — a long-lived wrapped client could pay
repeatedly, to any recipient, past any intended budget. This also
contradicted the skill's own Spending Controls section, which promises
per-session budgets and allowlisted recipients.
Adds an allowlist of recipients to the policy, and routes every paid call
through a boundary that asks for confirmation once and holds a session
ledger. Settlement responses carry no amount, so the ledger reserves the
per-call cap — a deliberate over-estimate that can stop early, never late.
The payment-enabled client stays private behind it.
The Solana recipient check was too loose. Scanning an owner's token
accounts proves only that some account exists for the mint; the exact-SVM
client targets the canonical ATA specifically, so an auxiliary account
would pass while settlement still fails. Now derives the ATA with
findAssociatedTokenPda and checks that exact address. Also corrects the
provisioning advice: a bare transfer does not create the account, only one
that includes the create instruction does.
Mirrored across en, ja-JP, and zh-CN.
Addresses the security review on #2575.
Enforce policy against the actual challenge. The previous example compared
a budget against a number the caller passed in, so a server quoting any
amount could still be paid. Replaces it with a PaymentPolicy registered on
the client, which filters the server-provided requirements before a
signature exists and validates all three fields — amount, asset, network.
Filtering everything out makes createPaymentPayload throw rather than fall
back to paying.
Testing this adversarially surfaced a bug in the guard itself: EVM
addresses are case-insensitive, so a server quoting lowercase USDC — the
same token — was dropped. Assets are now normalised before comparison,
lowercasing only 0x addresses, since Solana base58 is case-sensitive and
must not be folded. Also rejects negative amounts.
Verified against 12 cases: over-budget, wrong mint, wrong network,
case-flipped Solana mint, non-numeric and negative amounts all refuse;
checksummed, lowercase and uppercase EVM forms and the cap boundary all
pass.
Refresh the supported contract. Pins move 2.19.0 -> 2.22.0 (upstream
shipped 2.20, 2.21 and 2.22 since this branch opened). The documented
server and client APIs are unchanged across that range — re-ran the
seller middleware on 2.22.0 and it still returns a multi-network 402.
Keep facilitator guidance vendor-neutral. Self-facilitation and running
your own facilitator are now listed first, ahead of the testnet default
and hosted options, and the hosted paragraph points at the upstream
maintained list rather than naming a default. Adds an explicit disclosure
of the author's affiliation with one listed facilitator.
Mirrored across en, ja-JP, and zh-CN.
* fix(skills): move version into metadata and normalize to semver
29 skills declared `version` at the top level of their frontmatter. The
schema reads it from `metadata`, so tooling that follows the schema either
misses it or has to special-case the top level.
Three motion skills also declared `version: 1.0`, which is not a valid
semantic version; normalized to `1.0.0`.
No behavioral change — frontmatter metadata only.
* fix(skills): state activation triggers in skill descriptions
148 skills described what they cover but never named the situation that
should trigger them. Since the description is what Claude matches against
to decide whether to load a skill, a description without a trigger makes
activation guesswork — the skill is either missed or loaded at the wrong
time.
Added a "Use when ..." clause to each, derived from the skill's own body
(most already stated the trigger under "## When to Use" or in the opening
line; that intent is now reflected in the frontmatter where it is actually
read from).
Descriptions were only appended to; no existing wording was removed.
* fix(skills): sync activation triggers into the Codex skill mirror
10 of the skills whose descriptions changed are also mirrored under
`.agents/skills/`, where the description was previously a verbatim copy.
Left alone, the two surfaces would disagree about when the skill applies.
Only the description line is synced; the Codex copies keep their reduced
frontmatter, since that validator accepts only name, description,
metadata, license, and allowed-tools.
* fix(skills): correct three activation clauses from review
- autonomous-loops: the clause pulled new loop work into a skill that its
own body marks as a compatibility shim retained for one release. It now
points at the canonical continuous-agent-loop instead.
- continuous-learning: the description carried the v1 routing directive
twice; collapsed to one.
- homelab-pihole-dns: the clause fired on any broken home DNS. Narrowed to
tasks that actually involve Pi-hole.
* chore: retain current main lockfile
---------
Co-authored-by: Çağrı Solakoğlu <cagri.solakoglu@vtcenerji.com>
Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
Model-routing guidance across the rules, skills, and harness-steering docs
still recommends Sonnet 4.6 / Opus 4.5-4.6 by name. Readers on the current
generation have to map those onto Sonnet 5 / Opus 5 themselves, and the
recommendation reads as pinned to a superseded generation.
Renames the recommended models in guidance tables and updates two pinned
model IDs in code samples:
- rules/steering guidance: .cursor, .kiro, and the seven translated
performance.md copies (ja-JP, zh-CN, zh-TW, ko-KR, pt-BR, es, tr)
- skills/prompt-optimizer complexity-routing table (+ zh-CN copy)
- skills/cost-aware-llm-pipeline MODEL_SONNET constant (+ zh-CN, ja-JP)
- docs/examples project-guidelines template, which pinned the invalid ID
claude-sonnet-4-5-20250514 (+ zh-TW, ja-JP copies)
Deliberately left alone:
- The "Pricing Reference (2025-2026)" table in cost-aware-llm-pipeline.
Renaming those rows while keeping the existing per-token figures would
assert Claude 5 pricing this change has not verified.
- Executable model config (.opencode/opencode.json, agent.yaml). Those pins
change real agent behavior and belong in their own reviewed change.
- Historical and illustrative references: the-shortform-guide session
transcripts, the ECC-PRO roadmap log entry, gan-style-harness's
"Opus 4.5-class"/"Opus 4.6-class" capability tiers, and
strategic-compact's deliberately generic "400k Opus 4.x" example.
- docs/ATLAS-CLOUD-GUIDE.md, which lists a third-party provider's catalog.
Documentation wording only; no behavioral change.
Co-authored-by: Phumchai Tanonsi <274848436+phumchai1515-prog@users.noreply.github.com>
* feat: add council-multi-model skill (heterogeneous Codex review)
Rebased onto latest main to resolve the merge conflict (the branch had gone
DIRTY as main advanced). Trimmed to just the skill files (no top-level
README/AGENTS edits), mirroring the merged #2381. Previously reviewed
favorably by greptile/coderabbit/daltino.
* feat: add Entry B (independent parallel propose + aggregate, MoA-style) alongside Entry A (review)
Splits the skill into two entries depending on what already exists:
Entry A (unchanged) reviews an existing draft. New Entry B has every
voice (Claude x3 + Codex if available) answer the same question fully
independently and in parallel, then aggregates without collapsing
disagreement or blending incompatible approaches into one hybrid.
For the heaviest decisions the two chain: B first, then A's review
step on the aggregation -- with an explicit honesty caveat when Codex
already proposed in B and so cannot independently judge the result.
* feat: prefer Codex MCP tool over the SDK script when available
mcp__codex__codex is now the primary path for both Entry A's
heterogeneous review and Entry B's independent proposal -- zero relay,
talks directly to OpenAI's backend, no temp file or shell escaping
needed. The openai-codex SDK script becomes the fallback for sessions
without that MCP tool configured; behavior and guardrails (read-only,
verbatim quoting, explicit 'absent' labeling) are unchanged.
* fix: register council-multi-model install path
* docs: sync skill catalog count
* fix: publish council-multi-model skill
* fix: harden council multi-model fallback
* docs: sync remaining skill count
* fix: narrow multi-model council to bounded review
* fix: address council adapter review feedback
* fix(council-multi-model): enforce tool-less Codex review
* fix(council-multi-model): close Codex tool boundary
---------
Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
* feat(skills): add dev-team skill — multi-persona collaborative session
Adds skills/dev-team/SKILL.md, a community skill inspired by the
BMAD Method's "party mode": PM, Architect, Developer, and QA respond
to the same topic in parallel, then a synthesis step names tensions
explicitly instead of averaging them.
Reads PROJECT-CONTEXT.md from the repo root when present, and offers
to generate it when missing, folding in the closed project-context
skill's (#2310) generation workflow per affaan-m's review — that
skill's premise (every agent reads the file) wasn't implemented
anywhere, so the capability now lives directly in the one skill that
actually reads it.
Rebuilt on current upstream/main as a skill-only diff: the shared
format-code.ts Windows fix and github-coordination branch-coverage
tests that were previously bundled here (and duplicated across the
story-lifecycle and project-context sibling PRs) now live in #2459.
* fix(manifests): register dev-team skill in workflow-quality install module
* fix(docs): repair README lint errors and Windows hook-install path regression
Fixes CI inherited from the README 2.1 restructure (19b05476):
- MD058: blank lines around tables (delegation map, Codex role configs)
- MD001: Option A/B headings under Ecosystem Tools h2 jump to h4
- MD024: duplicate 'What's included' headings (Codex, Copilot sections)
- restore %USERPROFILE%\\.claude escaping required by
tests/scripts/manual-hook-install-docs.test.js
* feat(skills): address review — trust boundary, harness-neutral I/O, contract test
Address maintainer review on #2309:
- untrusted-context boundary now travels with every persona prompt:
inline label on the context section, personas marked analysis-only
with no state-changing tool use
- personas receive a bounded declarative summary (≤150 words, fixed
fields, secrets and imperative content stripped) — never the raw
PROJECT-CONTEXT.md
- context loading uses harness-native file tools; POSIX-only
'test -f && cat' removed
- all references resolve on main: story-lifecycle follow-up replaced
with /plan and epic-* commands, ecc:plan-prd corrected to the
/plan-prd command; boundary vs team-builder and council made explicit
- added tests/docs/dev-team-skill.test.js contract test (roles,
parallel dispatch, synthesis guardrails, trust boundary, registration)
* docs: refresh Turkish skill count
* ci: retrigger checks (flaky stop-hooks-stdout timeout on macos node20 npm cell)
---------
Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
* fix(quarkus-verification): use current ghcr.io/zaproxy/zaproxy:stable image
The owasp/zap2docker-* images are deprecated (ZAP left the OWASP org). The
current canonical image published by the ZAP project is
ghcr.io/zaproxy/zaproxy:stable; the packaged scan scripts (zap-api-scan.py)
are unchanged.
Applies to the source skill and the ja-JP, tr translated copies.
Refs: https://www.zaproxy.org/docs/docker/about/
* chore(quarkus-verification): bump GitHub Actions v3 -> v4
actions/checkout, actions/setup-java, actions/cache and codecov/codecov-action
were pinned at v3 (which runs on the deprecated Node 16 runtime). Bump to v4.
Applies to the source skill and the ja-JP, tr translated copies.
* docs(quarkus): finish current CI example refresh
---------
Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
* feat: add living-docs-governance skill (maintain-phase project doc system)
Rebased onto latest main to resolve the merge conflict (the branch had gone
DIRTY as main advanced). Trimmed to just the skill file (no top-level
README/AGENTS edits), mirroring the merged #2381. Previously approved by
@powershello before this rebase.
* fix: register living-docs-governance install path
* docs: sync skill catalog count
* fix: publish living-docs-governance skill
* fix: adopt existing docs before adding governance files
Feedback sent from the canvas only reached an agent through a live
/api/await long poll. When a turn ended with no await parked,
queueFeedback wrote the message to sessions.json and nothing ever
consumed it, so sending appeared to do nothing at all. The presence pill
made it worse: workingKeys had no expiry and the feedback handler never
broadcast presence, so it froze on "agent working" while nobody was
listening.
Delivery:
- Add the stop:plan-canvas-pending hook. It drains undelivered feedback
and blocks the Stop, handing the messages to the agent, so a canvas
message lands even when no await is running. Scoped to sessions under
cwd so parallel agents cannot swallow each other's feedback; set
ECC_PLAN_CANVAS_STOP_SCOPE=all to widen. Honors stop_hook_active and
fails open on every error path.
- run-with-flags.js did not await a hook's run(), so any async hook
silently degraded to pass-through. Fixed; plan-canvas-pending is the
only async hook today.
Presence and indicators:
- Presence is now ended/typing/thinking/listening/queued/waiting.
thinking and typing self-expire (90s/30s) and a 5s sweep pushes the
decay to an idle browser, so the pill can no longer stick.
- Broadcast presence when feedback is queued, and clear the activity
state when an agent reply lands.
- Add POST /api/session/:key/typing so agents can drive the indicator.
- Chat shows an animated dots bubble for thinking and typing, plus an
explicit note when a message is queued with nobody listening.
Respects prefers-reduced-motion.
- Send status reports what actually happened instead of always claiming
the agent will pick it up.
CLI and skill:
- Add `ecc-plan-canvas pending` and `typing <file> --state ...`.
- SKILL.md documents background await as the primary pattern and makes
replying in the canvas mandatory.
Tests: 6 new server cases covering queued presence, the typing endpoint,
state expiry and the sweep, plus a new hook suite covering delivery,
drain-once, stop_hook_active, cwd scoping and fail-open.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
`estimateCost` used `inputTokens` and `outputTokens` without validation.
A negative count yielded a negative cost, and a non-finite one yielded
NaN. That matters here specifically because this module backs the
cost-aware-llm-pipeline budget skill: `NaN > budget` is false, so a
corrupt token count silently passes the budget check it exists to
enforce. It now throws a RangeError naming the offending field.
The unknown-model fallback to sonnet rates deliberately stays fail-open:
that degrades an estimate, whereas these inputs corrupt one.
Separately, the estimator prices Fable and Mythos at $10/$50 per million
tokens, but all three pricing tables (the skill and its ja-JP and zh-CN
translations) listed only Haiku, Sonnet, and Opus, so a reader could not
budget for two supported model families. Added the missing row to each.
16 of the new assertions fail against the previous behaviour (23 passed,
16 failed) and all pass with the guard (39 passed).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KV43bDJpgyMPovT2CHAoba
Two ECC skills chaining off an ito-compute booking, per the Full-Stack Harness
Engineering Plan (2026-08-06):
- ito-inference: serve a model on booked GPUs via ecc ito serve (Layer 0.2).
- ito-training: run a staged, eval-gated training pipeline via ecc ito train
(Layer 0.3).
Both match the existing ito-compute skill: origin ECC, delegate to the canonical
CLI/backend, implement no parallel serving/training stack, chain off a completed
booking, and never book, reserve, or spend. They report the missing capability
while the desk serve-on-booking / training-run backends are scaffolds.
Co-authored-by: Affaan Mustafa <affaan@itomarkets.com>
codex login binds its callback server to container loopback, so the host
browser redirect to localhost:1455 is refused. Publish 127.0.0.1:1455 on
the opt-in networked service only and bridge it to loopback with a small
node relay. Document the flow, fresh-state retry, and token lifetime in
the hardened-harness skill.
Follow-up to #2625.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Completes the model re-tiering from #2442: the gan-planner, gan-generator,
and gan-evaluator agents were already re-pinned to sonnet, but the
gan-style-harness script and docs still defaulted GAN_PLANNER_MODEL,
GAN_GENERATOR_MODEL, and GAN_EVALUATOR_MODEL to opus. Align the script
defaults, skill docs (en/ja/zh), and example commands with the landed
agent tiers. Opus remains available via the existing env overrides.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Suliman Abdulrazzaq