[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CAXFSG0YRPT6BDF28NCHW6":3,"skill-same:01M6CAXFSG0YRPT6BDF28NCHW6":299},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":36,"publishedAt":66,"linkOnly":67,"markdownContent":68,"markdownBody":69,"frontMatter":70,"refName":112,"commitSha":113,"skillDirectory":114,"forksCount":115,"repositoryHtmlUrl":116,"repositoryHomepageUrl":6,"ownerHtmlUrl":117,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":118,"install":119,"resources":132},"01M6CAXFSG0YRPT6BDF28NCHW6","worldarchitect-campaign-tier-redesign",null,"Redesign Your Project campaign-tier mechanics — recurring work on the god\u002Fmultiverse\u002Fdivine\u002Fsovereign\u002Flevel-up systems in $GITHUB_REPOSITORY. Triggers: 'redesign X tier', 'rework god mode', 'campaigns less challenging', 'disable tier X', 'no campaign hardcoding except Dragon Knight', 'generate mysteries', 'mysteries not revealed', 'backstories not revealed to the player', 'unrevealed secrets in the plot', 'internal-drive plot arcs', 'MBTI internal', 'add a new campaign overlay', or any tier name (mortal\u002Fdivine\u002Fsovereign\u002Fcelestial\u002Fdemonic\u002Fetc.). Covers `$PROJECT_ROOT\u002Fprompts\u002F{mortal,divine,multiverse,shared}\u002F` + `$PROJECT_ROOT\u002F{campaign_divine,god_mode_level_up}.py`. Not for one-off bugs (`\u002Frepro`), Firestore export (`download-campaign`), or prod-data queries (`wa-prod-data-query`).","jleechanorg\u002Fjleechan-skills","jleechanorg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F221404966?v=4","01M6C1VJ99XG950X1DWPEBCBGX","01M6C1VJDK5YVDNT3362RT5WSB",6,"MIT","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fworldarchitect\u002Fworldarchitect-campaign-tier-redesign\u002FSKILL.md",[17,22,25,28,33],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":23,"categoryName":24,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000019","营销推广",{"categoryNo":26,"categoryName":27,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":29,"categoryName":30,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000035","市场营销","PROFESSION","适用职业",{"categoryNo":34,"categoryName":35,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000037","律师与法务",[37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65],"worldarchitect campaign tier redesign","redesign","worldarchitect","campaign","power","api test","overlays","mode","which","re","worker","project","shared","local","files","repro","testing","discipline","dialog","branch","stack","open","server","search","generate","architecture","slack","MCP","design","2026-11-10 10:12:30",false,"---\nname: worldarchitect-campaign-tier-redesign\ndescription: \"Redesign Your Project campaign-tier mechanics — recurring work on the god\u002Fmultiverse\u002Fdivine\u002Fsovereign\u002Flevel-up systems in $GITHUB_REPOSITORY. Triggers: 'redesign X tier', 'rework god mode', 'campaigns less challenging', 'disable tier X', 'no campaign hardcoding except Dragon Knight', 'generate mysteries', 'mysteries not revealed', 'backstories not revealed to the player', 'unrevealed secrets in the plot', 'internal-drive plot arcs', 'MBTI internal', 'add a new campaign overlay', or any tier name (mortal\u002Fdivine\u002Fsovereign\u002Fcelestial\u002Fdemonic\u002Fetc.). Covers `$PROJECT_ROOT\u002Fprompts\u002F{mortal,divine,multiverse,shared}\u002F` + `$PROJECT_ROOT\u002F{campaign_divine,god_mode_level_up}.py`. Not for one-off bugs (`\u002Frepro`), Firestore export (`download-campaign`), or prod-data queries (`wa-prod-data-query`).\"\nversion: 0.6.0\nauthor: Hermes Agent\nlicense: MIT\nplatforms: [macos, linux]\nmetadata:\n  hermes:\n    tags: [worldarchitect, god-mode, divine, sovereign, multiverse, campaign-tier, mechanics-redesign, level-up, es-evidence-protocol, ao-spawn-preflight, no-campaign-hardcoding, shared-prompts, ai-mystery, internal-drive-plot, mbti-internal, open-pr-preflight, discovery-first]\n    related_skills: [download-campaign, wa-campaign-content-analysis, wa-green-gate-pr-shape, finish-the-job, workflow\u002Falways-pr-never-local-edit, agento, ao-spawn-minimax-worker, worldai-campaign-to-google-doc, llm-wiki]\n    changelog:\n      - \"0.6.0 (2026-07-28): OPEN-PR PREFLIGHT + DISCOVERY-FIRST. (a) Added Phase -1 'Open-PR preflight' subsection — always run BEFORE Phase 0 inventory. REST-call recipe (`gh api search\u002Fissues`) that catches the common failure mode: agent proposes a new PR when an existing open PR (e.g. #8662 'AI mystery\u002Finternal-drive arcs') already covers the ask. Decision matrix covers 4 cases (amend existing \u002F add rule to umbrella \u002F push to umbrella-not-campaign-PR \u002F open new). (b) Added Pitfall #19 'Don't open a new PR or rewrite a contract before running Phase -1 open-PR preflight' — verified 2026-07-28 on the 'add mysteries to the plot' user request which mapped to PR #8662. (c) Expanded description + trigger phrases to cover the user's natural-language phrasings: 'mysteries not revealed', 'backstories not revealed to the player', 'unrevealed secrets in the plot', 'encourage creation of mysteries in the plot line'. (d) New reference doc `references\u002Fopen-pr-preflight-recipe.md` with the full REST-call recipe, decision matrix, and the 2026-07-28 PR #8662 case study.\"\n      - \"0.5.0 (2026-07-28): NO-CAMPAIGN-HARDCODE RULE + AI-MYSTERY\u002FINTERNAL-DRIVE DESIGN PATTERN. (a) Added Phase 2.5 'AI-Generated Mysteries + Internal-Drive Plot Architecture' subsection — the canonical 3-suspect template (red herring \u002F partial truth \u002F real answer), the hidden-fact → clue-trail mechanic, the per-act growth\u002Finsecurity\u002Freframe requirement, and the MBTI internal-only contract reference (PR #8539). (b) Added Pitfall #18 'Don't hardcode a single campaign's prompt type\u002Fpath\u002Fdirectory to `$PROJECT_ROOT\u002Fagent_prompts.py` \u002F `$PROJECT_ROOT\u002Fconstants.py` \u002F `$PROJECT_ROOT\u002Fagents.py` \u002F `$PROJECT_ROOT\u002Fprompts\u002F\u003Ccampaign>\u002F` — except for the Dragon Knight fast-path. Use the `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F` + `custom_campaign_state.campaign_overlays` generic gate pattern.' (c) New trigger phrases: 'no campaign hardcoding except Dragon Knight', 'generate mysteries', 'internal-drive plot arcs', 'MBTI internal', 'add a new campaign overlay'. Verified 2026-07-28 on PR #8661 (Spellblade Valeria) — user comment 3670171626 + Slack `C0AUXSVFSA2` thread: 'I never want anything hardcoded to a single campaign except Dragon Knight' + the 5 CodeRabbit blockers (P1: 'Load the Spellblade overlay for opted-in campaigns' on agent_prompts.py:177; P2: rule lives in combat prompt but is a dialog rule; P2: NPC goals can't evolve under any circumstance; P2: hidden_power_charges never decrement; P2: mirrored rules duplicate shared canonical). Companion PR-A: `feat\u002Fshared-contracts-mbti-internal-drive` adds the 6 generic shared contracts + the campaign_overlays loader gate + AGENTS.md 'no campaign hardcoding' rule.\"\n      - \"0.4.0 (2026-07-23): ES EVIDENCE PROTOCOL + AO SPAWN MODEL-PREFLIGHT. Added Phase 3 subsection 'PR B evidence — real \u002Fes local-server + real LLM is mandatory for prompt-only mvp_site changes' (forces testing_mcp real-API test, BQ raw-request verification, rejects unit-only stand-ins) + 2 new pitfalls (#16 prompt-only is NOT a \u002Fes carveout; #17 MiniMax-M3 AO worker preflight + early-kill discipline — Codex usage-limit banner appears before first tool call; if no commit lands within 60-90s, kill + respawn on a different harness with explicit mid-tier). Verified this session's god-mode-generic-mechanics PR (issue #8538, AO session wa-3389): worker tried to substitute `python -m unittest` for real \u002Fes, required a steering nudge mid-run, real gunicorn+Gemini 3.5 run is what produces durable evidence.\"\n      - \"0.3.0 (2026-07-21): PR B delivery shape — PROMPT-ONLY MECHANICS + SPLIT PROMPT STRUCTURE. Added Phase 3 subsection 'PR B delivery shape' + 6 new pitfalls (#10 ZFC: no god-mechanics Python helpers; #11 don't jam mechanics into ceremony prompt, audit existing files first; #12 setting-agnostic contract — no D&D entities leak; #13 push-race on shared branch recovery; #14 green-gate PR body schema; #15 general vs setting-specific split). Verified PR #8488 (V2 god-mechanics) — reviewer feedback from jleechan2015 (inline r3618945602: 'This is wrong and violating \u002Fzfc i think. It should just stay as prompt only') and user feedback ('I dont think everything should be in the ceremony prompt? There should be a ceremony\u002Fupgrade prompt and a general god mechanics prompt?' + 'I think there's already another mechanics prompt? what else is in divine\u002F folder?').\"\n      - \"0.2.0 (2026-07-21): PR A disable contract — SINGLE-SWITCH CENTRALIZATION. Added the 'one flag + 3-helper registry' pattern + test contract + the 'runtime-flags-do-not-update-import-time-thresholds' pitfall. Anti-pattern (the trap I fell into on PR #8485 v1): 5-file scattered disable with hardcoded `return False` and commented-out blocks. Correct shape: `MULTIVERSE_TIER_ENABLED` + `get_allowed_campaign_tiers()` \u002F `get_upgrade_complete_tiers()` \u002F `is_multiverse_tier_enabled()` in `constants.py`. Re-enabling is now one boolean flip. Verified PR #8485 v2 (review feedback from $USER: 'centralize this code better, control it with existence of this enum vs all these other code changes so easier to turn back on later').\"\n      - \"0.1.0 (2026-07-20): Initial umbrella covering the design-and-disable cycle on the tier stack.\"\n---\n\n# worldarchitect-campaign-tier-redesign\n\nCanonical home for \"the user wants to redesign \u002F disable \u002F revisit a campaign tier\" work in $GITHUB_REPOSITORY. This is a **class-level umbrella** that covers the recurring design cycle:\n\n1. **Audit current state** — read the prompt files + Python detection code + tests + prior art in `world_reference\u002F`.\n2. **Search prior campaigns** — what god\u002Fdivine\u002Fsovereign\u002Ftyranny campaigns has the user already played? Which mechanics did they like? (`download-campaign` for Firestore, `gog drive search` for Google Docs.)\n3. **Identify regressions** — why do newer campaigns feel less challenging than older ones? Root cause in prompt layer first, never in backend enforcement.\n4. **Propose a redesign** — setting-agnostic mechanics that explicitly reference what made the older work.\n5. **Disable \u002F ship \u002F measure** — small disable PR first, then the redesign PR, then verify on new scenes.\n\n## When to use\n\nTrigger phrases (any one):\n\n- \"Redesign all the god \u002F divine \u002F multiverse \u002F sovereign mechanics\"\n- \"Disable sovereign \u002F multiverse \u002F [tier X] for now\"\n- \"Revisit the divine \u002F [tier Y] campaigns\"\n- \"The god campaigns got less challenging \u002F mechanics weren't great\"\n- \"Make the new god campaign more like my older [Aizen \u002F Nocturne \u002F etc.] one\"\n- \"I want a new tier progression\" \u002F \"add a celestial tier\"\n- \"Disable tier X \u002F the [tier] prompt\"\n- \"Add mysteries to the plot\" \u002F \"mysteries not revealed\" \u002F \"backstories not revealed to the player\" \u002F \"unrevealed secrets in the plot\" \u002F \"encourage creation of mysteries in the plot line\" — these map to the AI-mystery shared contract in `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002Fai_generated_mystery_and_internal_drive_plot_arc.md` (see Phase 2.5). **Before designing a new PR, run Phase -1 to check if [PR #8662](https:\u002F\u002Fgithub.com\u002F$GITHUB_REPOSITORY\u002Fpull\u002F8662) (or its successor) already covers this** — that PR introduced the 3-suspect mystery template, hidden fact, clue trail, red herring \u002F partial truth \u002F real answer, and personal-cost reveals.\n- \"Use the MBTI stuff as background material\" \u002F \"internal-drive plot arcs\" \u002F \"challenge their insecurities\" — maps to the internal-drive plot arc contract, MBTI internal-only (PR #8539 invariant).\n\nAnti-triggers (don't load this skill):\n\n- \"Fix this specific god-mode bug\" → `\u002Frepro`\n- \"Pull this specific campaign from Firestore\" → `download-campaign`\n- \"Audit prompt changes across N campaigns\" → `wa-campaign-content-analysis`\n- \"Diagnose why my last Cloud Run deploy failed\" → `wa-cloud-run-deploy-failure-debug`\n- \"Bring this PR to green\" → `finish-the-job` + `drive-pr-to-green`\n\n## Class-level lesson (verified 2026-07-20)\n\nJeffrey's prior god-campaign work has a **quantified-stat-table pattern** that the current production system lost when it generalized. The local `world_reference\u002Faizen_god_mechanics.md` (11,449 bytes, replicated across ~50 worktrees) defined a Nascent Greater Deity with hard numbers — DR 750, DAC 25, DPP 825\u002Fday, DAIR Mod +31, DLR 4, Primary Damage 80 + (1d20×5) — that the LLM could ground its output in. The current `$PROJECT_ROOT\u002Fprompts\u002Fdivine\u002Fdivine_leverage_system.md` replaces these with **Dissonance × Safe Limit × Risk Multiplier** formulas that are harder for the LLM to produce concrete combat output from. See `references\u002Faizen-god-mechanics-pattern.md` for the full reconciliation.\n\nThree documented root causes of \"newer god campaigns feel less challenging\":\n\n1. **Two conflicting three-layer framings** — production is \"Mask (L0) \u002F Persona (L1) \u002F Source (L2)\" (mortal-face outward); Aizen is \"Ambiguous (L1) \u002F Projected (L2) \u002F Cover-story (L3)\" (all deception layers). Numbering + semantics diverge. Pick one.\n2. **DPP (Divine Power Points) is overloaded** — finite pool in the ascension ceremony (5\u002F5), \"Dissonance IS the cost\" (no pool) in the leverage rules, daily-replenishing 825\u002Fday in Aizen. Pick one.\n3. **No quantified divine stat table** — production uses Risk-Multiplier formulas; Aizen has the DR\u002FDAC\u002FDPP\u002FDAIR\u002FDLR\u002FPrimary-Damage table. LLM combat output is better grounded by the table.\n\n## Phase -1 — Open-PR preflight (always; takes \u003C30s, runs BEFORE Phase 0)\n\n**Always run this before designing anything.** It catches the most common failure mode: the agent proposes \"open a new PR\" or \"rewrite the contract\" when an existing open PR already covers the ask. Verified 2026-07-28 on the \"add mysteries to the plot\" user request — the agent had to discover [PR #8662](https:\u002F\u002Fgithub.com\u002F$GITHUB_REPOSITORY\u002Fpull\u002F8662) (which introduced `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002Fai_generated_mystery_and_internal_drive_plot_arc.md` with the 3-suspect template + personal-cost reveals) after multiple tool calls. The preflight would have surfaced this in one REST call.\n\n### Recipe\n\n```bash\ncd ~\u002Fprojects\u002Fyour-project.com && git fetch origin 2>&1 | tail -3\n\n# 1. List every feat\u002F* branch on origin (covers branches with or without PRs)\ngit branch -r | grep -E 'origin\u002Ffeat\u002F' | sort -u\n\n# 2. Search open PRs by keyword (REST, not GraphQL — bypasses rate limits)\ngh api 'search\u002Fissues?q=repo:$GITHUB_REPOSITORY+is:pr+is:open+mystery+OR+secret+OR+reveal+OR+plot+OR+foreshadow' \\\n  --jq '.items[] | {number,state,title,url,head_ref:.head.ref}' 2>&1\n\n# 3. Search by shared-contracts keyword (catches the v0.5.0 umbrella PRs)\ngh api 'search\u002Fissues?q=repo:$GITHUB_REPOSITORY+is:pr+is:open+shared-contracts+OR+internal-drive+OR+mbti+OR+overlays' \\\n  --jq '.items[] | {number,state,title,url,head_ref:.head.ref}' 2>&1\n\n# 4. For each candidate branch, check whether it already contains a\n#    `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002Fai_generated_mystery_and_internal_drive_plot_arc.md`\n#    (or whatever contract the user's ask maps to) — saves re-reading the diff\ngit ls-tree -r origin\u002F\u003Cbranch> -- $PROJECT_ROOT\u002Fprompts\u002Fshared\u002F 2>&1 | grep -E 'mystery|internal_drive|plot_arc'\n```\n\n### Decision matrix\n\n| What the preflight found | Action |\n|---|---|\n| Open PR already has the contract file | **Strengthen \u002F amend that PR** — push to the same branch. Don't open a new PR. |\n| Open PR covers a related ask (e.g. shared contracts umbrella) but missing the specific rule | **Add the rule to that PR** as a new commit on the same branch. Reference the umbrella PR's compatibility section. |\n| Multiple candidate branches (umbrella PR + companion campaign PR like #8662 + #8661) | **Push to the umbrella PR** (the shared contract), not the campaign-specific PR. Per `no-campaign-hardcoding` rule, the contract belongs in `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F`. |\n| No matching open PR | **Proceed to Phase 0** inventory + Phase 2 proposal. Branch from `origin\u002Fmain`. |\n\n### Anti-pattern\n\n- **Don't propose a new PR** before running Phase -1. The user's \"make a new PR or add this so an existing PR that fits\" (verified 2026-07-28 Slack phrasing) explicitly invites the agent to join an existing PR when one fits — default to that path.\n- **Don't skip the preflight even if the user's ask sounds new.** Mystery\u002Fsecrets\u002Fplot phrasing in 2026-07-28 mapped to PR #8662 verbatim; future phrasings (\"add foreshadowing\", \"add plot twists\", \"keep the player guessing\") will likely map to the same contract.\n- **Don't re-inventory Phase 0 items just because Phase -1 found an existing PR.** Phase 0 is for designing new work; if you're amending an existing PR, read its current diff and identify the gap, not start over.\n\n## Phase 0 — Inventory (always; takes \u003C5 min)\n\nBefore designing anything, run the inventory. This is the **delivery contract** — see the `memory-search` skill for the parallel-fan-out pattern.\n\nThree parallel `delegate_task` calls:\n\n| Task | Sources | Returns |\n|---|---|---|\n| **A — file audit** | `$PROJECT_ROOT\u002Fprompts\u002F{tier}\u002F*.md`, `$PROJECT_ROOT\u002Fcampaign_divine.py`, `$PROJECT_ROOT\u002Fgod_mode_level_up.py`, `world_reference\u002F*.md`, `wiki\u002Fsources\u002F{tier}-*.md` | Structured audit: every file, summary, mechanical rules verbatim, JSON state shapes, cross-references |\n| **B — 9-store memory search** | `\u002Fms` fan-out with 3-5 fused queries (e.g. \"sovereign multiverse disable\", \"Aizen god tyranny\", \"divine ascension ceremony\") | 9-section report: ~\u002Froadmap \u002F beads \u002F claude memories \u002F hermes sqlite \u002F briefings \u002F MEMORY.md \u002F wiki \u002F history \u002F slack |\n| **C — campaign corpus** | `gog drive search \"Aizen\" \"god\" \"campaign\"` for Google Docs at $USER@gmail.com + `download-campaign` for Firestore-resident god campaigns + `find ~\u002Frepos\u002Fjleechanorg -name \"*aizen*\" -o -name \"*god*\"` for local copies | Inventory table: doc ID, name, mimeType, modifiedTime, size, first-paragraph, 1-sentence \"why this matters\" |\n\n**Cache the 3 outputs at `\u002Ftmp\u002Fredesign_task{0,1,2}.md`** for re-reading in chunks (read_file truncates at ~50K chars inline).\n\n## Phase 1 — Diagnose root causes\n\nThree regression patterns to look for, in priority order:\n\n1. **Quantification loss** — does the current system have hard numbers the LLM can use in combat output? Or only formula-derived values? If formula-only, the redesign needs a quantified-stat table (Aizen pattern).\n2. **Three-layer framing duplication** — are there 2+ different layer schemes in different files that the LLM has to reconcile per-scene? If yes, collapse to one canonical scheme + cite the losing scheme as historical context.\n3. **Trigger ambiguity** — does the upgrade detector use multiple thresholds (level + divine_potential + explicit flag)? Is there a default order (e.g. \"multiverse takes priority regardless of tier\") that lets a player ascend past the intended point? If yes, document the canonical trigger order and make the priority explicit.\n\n## Phase 2 — Proposal\n\nWrite a design doc at `world_reference\u002F{tier}_mechanics_redesign_v2.md`. Format:\n\n1. **Goal** — what this redesign is fixing (cite Phase 1 root causes).\n2. **Prior art** — which old campaign\u002Fcampaigns this draws from (cite real doc IDs from Phase 0 inventory).\n3. **Setting-agnostic core** — explicit remapping from D&D-specific terms to generic-Apex-Powers terminology. The user has explicitly asked for \"general, not Faerun\u002FD&D\" mechanics — respect that. Ao → Prime Mover, Pantheon → Apex Powers, Weave → reality fabric, Divine Rank → Power Tier.\n4. **Mechanics** — quantified stat table (Aizen-pattern), trigger conditions, advancement formula.\n5. **3-Generation Power Lineage** — the G0 architect \u002F G1 rejecter \u002F G2 NEW-choice fork pattern from `world_reference\u002Fcampaign_module_god_of_murder.md` (verified 2026-07-20 in PR #8483).\n6. **What stays \u002F what goes** — explicit list of removed mechanics with the regression they caused.\n7. **Verification plan** — what scenes prove the redesign landed (per `wa-campaign-content-analysis` Phase 6 verification recipe).\n\n## Phase 2.5 — AI-Generated Mysteries + Internal-Drive Plot Architecture (verified 2026-07-28)\n\nWhen the user asks for \"mystery-driven campaigns,\" \"internal-drive plot arcs,\" \"character growth arcs that challenge insecurities,\" or \"use the MBTI stuff as background material,\" the design documentation MUST include the following architecture. This is a recurring pattern across the user's god\u002Fdivine\u002FSpellblade work; the canonical contracts above (one-rule-one-authoritative-file in `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F`) and the **canonical contract pinning** in PR #8539 (MBTI internal-only, NEVER in player-facing text) are the two upstream invariants this phase assumes.\n\n### Mystery template (mandatory for mystery-driven campaigns)\n\nEvery campaign the user wants to feel \"mystery-driven\" must include at least one active mystery with this structure:\n\n```\nmystery_state: {\n  active: [\n    {\n      id: \"mystery_1\",\n      hidden_fact: \"The fact nobody knows yet\",  # ONE fact, not 3\n      clue_trail: [\n        {\"scene\": N, \"clue\": \"...\", \"red_herring_weight\": 0.3},\n        {\"scene\": N+k, \"clue\": \"...\", \"red_herring_weight\": 0.5},\n        {\"scene\": N+k+j, \"clue\": \"...\", \"red_herring_weight\": 0.1},\n      ],\n      # Exactly 3 suspect branches — the LLM must seed ALL THREE.\n      # The player (or the campaign) picks the real answer; the LLM never overrides.\n      suspect_branches: [\n        {\"id\": \"red_herring\", \"presentation\": \"...\", \"weight\": 0.4},\n        {\"id\": \"partial_truth\", \"presentation\": \"...\", \"weight\": 0.4},\n        {\"id\": \"real_answer\", \"presentation\": \"...\", \"weight\": 0.2},\n      ],\n      # The mystery must HIT a character's vulnerability — see MBTI internal-only contract.\n      hits_vulnerability: \"campaign:npc_faction:character_id\",  # which NPC's internal drive this challenges\n      resolved: false,\n    },\n  ],\n  resolved: [{\"id\": \"mystery_0\", \"real_answer\": \"...\", \"victim_or_beneficiary\": \"...\"}],\n}\n```\n\n**Three mechanical rules:**\n\n1. **AI must seed mysteries proactively**, not wait for the player to ask. The opening scene must include at least one clue of an active mystery (Phase 9 \u002F Step 10's \"A\u002FB\u002FC choice\" should ALSO surface the first clue).\n2. **Three suspect branches are non-negotiable.** A mystery with only one path is not a mystery; it's a tutorial. The branches must be plausible (no \"obviously the butler did it\" branches). The weights are guidance, not destiny — player choices can shift real_answer confidence.\n3. **`hits_vulnerability` must reference a character's MBTI-internal vulnerability** under the canonical contract from PR #8539 — the LLM uses internal-only data (`mbti`, `attachment_style`, `insecurity_axes`, `stress_arc_target`) to design the mystery so it lands on the character, not on the player.\n\n### Internal-drive plot arc — the per-act requirement\n\nEvery campaign Act (1, 2, 3) MUST do at least one of:\n\n- **(a) Advance the character's growth direction** — what they need to learn, heal, or confront (see `campaign-creation` v1.2.0 `Phase 11.VI Personal-Growth Direction` for the data structure).\n- **(b) Confront an insecurity** — the MBTI stress-arc pattern (e.g. INFJ under stress → withdrawal + hyper-critical; ESTJ under stress → controlling micromanagement).\n- **(c) Reframe a long-held Want in light of new evidence** — the character's explicit Want is re-evaluated when the campaign surfaces a reason it can no longer be pursued unchanged.\n\nAnti-pattern: a campaign arc that doesn't grow the character is a series of unconnected scenes. Even if the user wants \"tight plot,\" the act breaks above still apply — the character's growth is the through-line.\n\n### MBTI internal-only contract — the upstream invariant\n\nThe MBTI architecture (Want \u002F Fear \u002F Boundary trifecta + stress arcs + personal-growth direction) is **LLM-input only**. Per PR #8539's canonical contract:\n\n- MBTI type codes (`INTJ`, `ISTJ`, etc.) are NEVER in player-facing text.\n- D&D alignment labels are NEVER in player-facing text.\n- Big Five scores are NEVER in player-facing text.\n- Personality categories are NEVER in player-facing text.\n- The wiki pages at `~\u002Fllm_wiki\u002Fwiki\u002Fconcepts\u002Fmbti\u002F*.md` are AI-background material only — sourced from the 16 personalitypage.com pages (verified 2026-07-28 wiki ingest).\n\nThe wiki ingest companion: `~\u002F.hermes\u002Fskills\u002Fllm-wiki` is the canonical authoring skill. The 16 raw HTML pages at `~\u002Fllm_wiki\u002Fraw\u002Farticles\u002Fmbti\u002F*.html` are sha256-stamped for re-ingest drift detection.\n\n### Verification rule for mystery\u002Fint-drive PRs\n\nA PR that adds AI-mystery infrastructure or internal-drive plot arcs to `$PROJECT_ROOT\u002Fprompts\u002F` MUST include:\n\n1. A focused test that asserts the new shared contract file exists in `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F`, contains the canonical keywords, and is registered in `PATH_MAP`.\n2. A test that asserts the contract is wired into `StoryModeAgent` \u002F `CombatAgent` \u002F `DialogAgent` `REQUIRED_PROMPT_ORDER` (or `OPTIONAL_PROMPTS` if conditional).\n3. A non-test reference in the PR body's `## Known Limitations` section explaining that the mystery\u002Fint-drive architecture is prompt-only — the state tracking (`mystery_state`) is the campaign-side LLM's responsibility, not backend enforcement.\n\n## Phase 3 — Ship\n\nTwo-PR sequence (recommended):\n\n- **PR A (small, fast): disable** — flip the trigger threshold to a sentinel (`UNIVERSE_CONTROL_THRESHOLD = 99999`), short-circuit `is_multiverse_upgrade_available()` to always `False`, add `disallow: {tier}` to the prompt loader, tag the disabled wiki sources with `disabled: true` frontmatter. One commit. Pure disable, no redesign. Branches from `origin\u002Fmain`. Per `workflow\u002Falways-pr-never-local-edit`.\n- **PR B (the redesign)** — ship the new prompt + setting-agnostic code + test coverage + a wiki source page + an update to the campaign module if applicable. Branches from `origin\u002Fmain`. Per `finish-the-job`.\n\nBoth PRs MUST be pushed (per SOUL.md `push-pr-donot-stop-halfway`) and both MUST pass the 7-green gate per `~\u002F.claude\u002Fskills\u002Fzero-touch.md`.\n\n### PR B delivery shape — PROMPT-ONLY MECHANICS + SPLIT PROMPT STRUCTURE (verified PR #8488, 2026-07-21)\n\n**Default: PR B is a prompt-only delivery.** No new Python helpers, no new constants, no new test files for backend code. The mechanics live as LLM instructions in the prompt markdown.\n\n**Why prompt-only (ZFC + root-cause-first):** Semantic decisions about god-tier transitions, multipliers, reputation bands, god-class biases, deicide-cost, etc. belong to the LLM, not to backend routing code. Pure-function helpers are dead code that misleads future readers. The reviewer on PR #8488 (`jleechan2015` inline comment r3618945602) explicitly called this out: *\"This is wrong and violating \u002Fzfc i think. It should just stay as prompt only.\"*\n\n**When to escalate to backend enforcement (rare):** Only after documenting why prompt correction is insufficient. Even then, the enforcement should be a **narrow, logged invariant** (e.g. \"no command may exceed L46+ without approval\"), not a `compute_v2_divine_stats()` helper.\n\n### PR B evidence — REAL \u002Fes LOCAL SERVER + REAL LLM IS MANDATORY for prompt-only `$PROJECT_ROOT\u002F**` changes (verified 2026-07-23, issue #8538)\n\nThis is the most-frequently-violated gate and the one AO workers try hardest to substitute around. The pitfall is real: a prompt-only `$PROJECT_ROOT\u002Fagent_prompts.py` change \"doesn't add new behavior, just text\" feels like it should be exempt from \u002Fes. It is **not**. Per the your-project.com repo's AGENTS.md and the Green Gate workflow:\n\n> *\"Any non-test change under `$PROJECT_ROOT\u002F**` requires `\u002Fes` evidence before the work is complete. ... If the changed code can touch LLM, agent routing, game state, rewards, persistence, streaming, APIs, or server behavior, `\u002Fes` must use a real local server with real services, including real LLM calls where that path uses an LLM.\"*\n\nA prompt-only change to `$PROJECT_ROOT\u002Fagent_prompts.py` (e.g. adding a new section to `build_god_mode_directives_block()`) **does** touch LLM agent routing and game state — the prompt is what the model sees at runtime. Therefore the carve-out that applies to \"pure comments \u002F docs \u002F formatting \u002F type hints\" **does NOT apply**. The evidence bundle MUST include:\n\n1. **Real local server.** Spawn `gunicorn mvp_site.main:app --bind 0.0.0.0:\u003Cport>` (typically a free high port) with `TESTING_AUTH_BYPASS=true ALLOW_TEST_AUTH_BYPASS=true WORLDAI_DEV_MODE=true MCP_TEST_MODE=real MOCK_SERVICES_MODE=false GOOGLE_APPLICATION_CREDENTIALS=…`. Verify it's live by curling `\u002Fhealth` or `\u002Fapi\u002Fhealth` before driving any LLM call.\n2. **Real LLM call(s).** Exercise the changed path end-to-end — for god-mode mechanics that's typically a `GOD MODE:` chat-turn input that triggers the directive-loader. The turn must be an actual `GodModeAgent` invocation, not a mocked fixture.\n3. **BQ-observable request trace.** Per `~\u002F.hermes\u002Fskills\u002Fworldarchitect\u002Freferences\u002Feval-god-mode.md` (and `.claude\u002Fskills\u002Fbq-evidence-reading.md`), the gateway logs the `gemini_provider.stream.request_json` payload to BQ. Verify the new directive text appears verbatim in `gemini_provider.stream.request_json.contents[].parts[].text` for the god-mode agent on the turn that exercises the new mechanic. The `GodModeAgent.response_text` for the same turn should be referenced for \"did the model follow the new directive\" — but the *delivery* evidence is in the request, not the response.\n4. **A `testing_mcp\u002Ftest_\u003Cmechanic>_contract_real_api.py` script.** Uses `MCPTestBase` + a real local server + real LLM (NOT mocks). The script should:\n   - seed the new directive via `GOD_MODE_UPDATE_STATE:` to load it into `custom_campaign_state`,\n   - trigger a god-mode chat turn that must invoke the changed `build_god_mode_directives_block()`,\n   - parse the captured LLM request JSONL (`llm_request_responses.jsonl` \u002F `provider_http_request_responses.jsonl` \u002F `request_responses.jsonl`) and assert the literal text of the new mechanic appears (use a case-insensitive substring scan over ALL string fields, not just `system` role text — the directive may live under different keys depending on the request shape).\n5. **The agent's behavior delta.** Capture the `GodModeAgent.response_text` from BQ (via `bq query` per `.claude\u002Fskills\u002Fbq-evidence-reading.md`) for the same turn — the response should show the model applying the new mechanic, not falling back to the prior path.\n\n**Three common substitutes the AO worker will try, and why each fails:**\n\n| Substitute | Why it fails |\n|---|---|\n| `python -m unittest $PROJECT_ROOT\u002Ftests\u002Ftest_\u003Cx>.py` | Unit tests prove the helper function renders the new text correctly. They DO NOT prove the LLM actually receives it at runtime. Green Gate gate 6 requires real-server + real-LLM proof. |\n| `bash scripts\u002Fgenerate_evidence_bundle.sh \u003Ctest_name>` | That script runs unit tests + captures stdout. It does not start a server, does not drive an LLM call, and the captured stdout does not include the LLM request payload. It satisfies the \"evidence exists\" requirement formally but not substantively. |\n| \"Pure prompt exception — no runtime behavior changed\" | The AGENTS.md carve-out explicitly excludes prompt-layer changes. Adding or rewording a directive IS a behavior change at the model-decision boundary. |\n\n**The diagnostic recipe when a worker submits a unit-test-only evidence bundle:**\n\n1. `git diff origin\u002Fmain..HEAD --stat` — confirm only test files + prompt\u002Fagent_prompts files changed.\n2. `cat \u002Ftmp\u002Fwa-NNNN\u002Ffeat\u002F\u003Cbranch>\u002F\u003Ctest_name>\u002Flatest\u002F*.err 2>\u002Fdev\u002Fnull` (or wherever the evidence bundle landed) — look for the captured LLM request payload.\n3. If the bundle contains `python -m unittest` output and NO captured HTTP \u002F request JSONL → reject as not-real-evidence. Reply: *\"STOP: unit-only evidence violates the explicit brief and repo AGENTS.md. This non-test mvp_site change REQUIRES real \u002Fes local server + real services + real LLM. ...\"*\n4. Use `ao send \u003Csession>` to steer the worker mid-run (do not kill and respawn — the worker is usually mid-implementation, just on the wrong evidence path).\n\n**Companion reference:** `references\u002Fes-evidence-protocol-prompt-only-mvp-site.md` (this skill) has the canonical copy-paste steering nudge, the BQ query for verifying the request payload, the `testing_mcp` template skeleton, and the verified full transcript from issue #8538's god-mode-generic-mechanics PR.\n\n**Split prompt structure — ceremony vs. mechanics are SEPARATE files:**\n\n| File | Role | Size (typical) |\n|---|---|---|\n| `$PROJECT_ROOT\u002Fprompts\u002F{tier}\u002F{tier}_ascension_ceremony.md` | Trigger + ceremony phases (Recognition → State Updates) — runs ONCE per character | 100-150 lines |\n| `$PROJECT_ROOT\u002Fprompts\u002F{tier}\u002F{tier}_leverage_system.md` (or `divine_god_mechanics.md` for non-ascension tiers) | Per-turn mechanics — runs on every divine-tier turn after ascension | 500-800 lines (V1 + V2 overlays stacked) |\n\nThe ceremony prompt cross-references the leverage prompt: *\"Post-ceremony: also load `divine_leverage_system.md` for all subsequent divine-tier turns.\"*\n\n**Audit existing files BEFORE creating new ones.** Before adding `divine_god_mechanics.md` or similar, `ls` the `prompts\u002F{tier}\u002F` folder. The general-mechanics file likely already exists — `divine_leverage_system.md` for the divine tier, etc. Adding a redundant file is wasted work and confuses the LLM (which prompt to load?).\n\n**V2 overlay insertion pattern:** Insert V2 sections at the **bottom** of the leverage prompt, BEFORE the Setting Adaptation Appendix. The appendix stays the only setting-specific content at the end of the file. The V2 overlay inherits the existing setting-agnostic preamble.\n\n### PR A disable contract — SINGLE-SWITCH CENTRALIZATION (verified PR #8485 v2, 2026-07-21)\n\n**Anti-pattern (the trap I fell into on PR #8485 v1):** disable scattered across 5 files — `campaign_divine.is_multiverse_upgrade_available()` hardcoded `return False`, `agent_prompts._append_campaign_tier_prompts()` had `elif False: pass`, `_CAMPAIGN_UPGRADE_COMPLETE_TIERS` dropped SOVEREIGN via inline comment, `agents.CampaignUpgradeAgent` had a defense-in-depth warning fallback, `constants.UNIVERSE_CONTROL_THRESHOLD` was a hardcoded sentinel. Five files to flip to re-enable. The user's review feedback was direct: *\"centralize this code better, control it with existence of this enum vs all these other code changes so easier to turn back on later.\"*\n\n**Correct shape — single switch + small registry in `constants.py`:**\n\n```python\n# The single switch\nMULTIVERSE_TIER_ENABLED = False\n\n# Import-time-computed sentinel-vs-historical threshold (no other file needs to flip)\nUNIVERSE_CONTROL_THRESHOLD = 999999 if not MULTIVERSE_TIER_ENABLED else 70\n\n# Three registry helpers — every call site reads these instead of hand-rolling sets\ndef get_allowed_campaign_tiers() -> frozenset[str]:\n    tiers = [CAMPAIGN_TIER_MORTAL, CAMPAIGN_TIER_DIVINE, CAMPAIGN_TIER_SOVEREIGN]\n    return frozenset(tiers)  # keeps SOVEREIGN in allowlist for legacy Firestore data\n\ndef get_upgrade_complete_tiers() -> frozenset[str]:\n    tiers = {CAMPAIGN_TIER_DIVINE}\n    if MULTIVERSE_TIER_ENABLED:\n        tiers = {CAMPAIGN_TIER_DIVINE, CAMPAIGN_TIER_SOVEREIGN}\n    return frozenset(tiers)\n\ndef is_multiverse_tier_enabled() -> bool:\n    return MULTIVERSE_TIER_ENABLED\n```\n\nThen every call site reads the flag:\n\n| Site | Reads |\n|---|---|\n| `campaign_divine.is_multiverse_upgrade_available()` | `if not constants.is_multiverse_tier_enabled(): return False; else original_trigger_logic` |\n| `campaign_upgrade._CAMPAIGN_UPGRADE_COMPLETE_TIERS` | `constants.get_upgrade_complete_tiers()` |\n| `agent_prompts.PATH_MAP` sovereign entries | `if constants.is_multiverse_tier_enabled(): PATH_MAP.update({SOVEREIGN_*: PATH})` |\n| `agent_prompts._append_campaign_tier_prompts()` | `elif constants.is_multiverse_tier_enabled() and campaign_tier == CAMPAIGN_TIER_SOVEREIGN:` |\n| `agents.CampaignUpgradeAgent` | `if self._upgrade_type == \"multiverse\" and not constants.is_multiverse_tier_enabled(): fallback_to_divine_with_warning; elif self._upgrade_type == \"multiverse\": load SOVEREIGN_ASCENSION` |\n| `game_state.allowed_tiers` + `rewards_engine.valid_campaign_tiers` | `constants.get_allowed_campaign_tiers()` |\n\n**To re-enable the tier:** flip `MULTIVERSE_TIER_ENABLED = True` and redeploy. No other file changes needed.\n\n**Critical contract when designing the disable:** the body of every call site must STAY RUNTIME-IDENTICAL when the flag is False. The original pre-disable logic should be the \"flag=True\" branch — never delete the implementation, just gate it. This is the difference between \"temporary disable\" and \"permanent deletion\". The user's review feedback makes this an explicit hard rule.\n\n**Test contract for the single switch:**\n\n- 13+ tests proving the registry helpers reflect the flag in both states (`patch.object(constants, \"MULTIVERSE_TIER_ENABLED\", True\u002FFalse)`)\n- `test_returns_false_when_flag_disabled` + `test_returns_true_when_flag_enabled_and_triggers_met` for each gated function\n- `test_import_time_threshold_matches_disabled_flag` for the computed threshold (since `UNIVERSE_CONTROL_THRESHOLD` captures at import time, runtime flag flips don't reach it — that's correct, you re-deploy not runtime-toggle)\n- The original disable tests still pass unchanged (they prove the flag-False runtime is identical to the previous \"hardcoded disable\" runtime)\n\n**Why the registry needs three helpers, not one `is_tier_enabled(tier)`:** the SOVEREIGN entry legitimately stays in `get_allowed_campaign_tiers()` even when disabled (legacy Firestore documents with `campaign_tier=\"sovereign\"` still need to validate; no NEW campaign transitions INTO sovereign while disabled). But it drops out of `get_upgrade_complete_tiers()` and `is_multiverse_tier_enabled()` returns False. Conflating these two states in a single helper breaks legacy-data compatibility.\n\n**Pitfall — `UNIVERSE_CONTROL_THRESHOLD` is import-time-computed, not runtime-flip-able:**\n\n```python\n# CORRECT — one flip, then redeploy\nMULTIVERSE_TIER_ENABLED = True  # was False\n# UNIVERSE_CONTROL_THRESHOLD auto-recomputes to 70 on next import\n```\n\n```python\n# WRONG — runtime flag flip does NOT update the threshold\nimport mvp_site.constants as c\nc.MULTIVERSE_TIER_ENABLED = True\nprint(c.UNIVERSE_CONTROL_THRESHOLD)  # still 999999 — it was captured at module load\n```\n\nIf you ever need runtime-toggle for A\u002FB testing or staged rollout, extract the comparison into a helper instead:\n\n```python\ndef is_universe_control_at_threshold(universe_control: int) -> bool:\n    threshold = 70 if MULTIVERSE_TIER_ENABLED else 999999\n    return universe_control >= threshold\n```\n\nFor PR A disable work, the import-time semantics are correct — re-deploying to flip the flag is the right blast radius.\n\n## Phase 4 — Verify\n\nAfter PR B merges, run `wa-campaign-content-analysis` Phase 6 (prompt-fix-effectiveness-verification) on the next 5 god-tier scenes the user plays. Quantified-stat-table presence in combat output, three-layer-framing consistency, trigger-ambiguity regression check. Report findings as pre\u002Fpost delta + the 5-cause taxonomy if the LLM isn't following the new prompt.\n\n## Pitfalls (this list IS the skill — review before running)\n\n1. **Don't propose a redesign without first running Phase 0 inventory.** The \"receipts-first\" contract is non-negotiable. The user has been bitten by agents that propose redesigns without grounding them in real prior campaigns.\n2. **Don't replace the quantified-stat-table with formula-only.** The LLM produces worse combat output when it has to derive divine stats from Risk Multipliers every turn. Use the Aizen pattern (DR\u002FDAC\u002FDPP\u002FDAIR\u002FDLR\u002FPrimary Damage table) even if the production system prefers formulas.\n3. **Don't keep both three-layer framings in different files.** Pick one. The losing scheme gets a wiki \"Historical context\" section, not active prompts.\n4. **Don't let \"multiverse takes priority over divine regardless of tier\" survive a redesign.** This is the bug from PR #7883 \u002F issue #7882 (roadmap\u002F2026-06-24). Either document the canonical priority or remove the upgrade entirely.\n5. **Don't ship a redesign that is still Faerun\u002FD&D-specific when the user asked for general.** Ao → Prime Mover, Pantheon → Apex Powers, Weave → reality fabric. Setting-specific examples stay only in the canon-attribution section.\n6. **Don't disable a tier by deleting the prompt file.** Move it to `$PROJECT_ROOT\u002Fprompts\u002F{tier}_disabled\u002F` so the work is recoverable. Wiki sources get `disabled: true` frontmatter so the next agent doesn't re-enable by accident.\n7. **Don't skip the 5-minute inventory.** The temptation is \"I already know the code, let me just write the fix.\" That bypasses the user's actual ask (\"read all my older campaigns first\"). Inventory is the work, not a prelude to it.\n8. **Don't `clarify` for next-step scope before delivering Phase 0 receipts.** User said \"Status on this and did you truly find and read aizen campaign and all the others I asked?\" mid-redesign on 2026-07-20 — the inventory table was the deliverable; the `clarify` came too early.\n9. **Don't scatter the disable across multiple files with hardcoded `return False` + commented-out blocks.** This was my PR #8485 v1 anti-pattern. Centralize into `MULTIVERSE_TIER_ENABLED` + a 3-helper registry in `constants.py` (see Phase 3 \"PR A disable contract\" above). Every call site reads the flag — re-enabling is one boolean flip, not a 5-file refactor. The user will catch this on review and ask you to redo it. Verify locally with the test contract above before pushing.\n10. **Don't add god-mechanics Python helpers (`get_v2_god_tier`, `compute_v2_divine_stats`, `v2_reputation_band`, etc.) to `$PROJECT_ROOT\u002Fcampaign_divine.py` or `$PROJECT_ROOT\u002Fconstants.py`.** Semantic decisions about god-tier transitions, multipliers, reputation bands, god-class biases, deicide-cost, etc. belong to the **LLM prompt**, NOT to backend routing code. This was the actual review feedback on PR #8488 (`jleechan2015` inline comment r3618945602 on `$PROJECT_ROOT\u002Fcampaign_divine.py:208`: *\"This is wrong and violating \u002Fzfc i think. It should just stay as prompt only\"*). The pure-function helpers are a feature-creep violation of **Zero-Framework Cognition (ZFC)** + **root-cause-first** principles: encode semantic decisions in the LLM prompt, not in backend code. If you must add backend enforcement later, do it as a narrow, logged invariant after documenting why prompt correction is insufficient. Default: **prompt-only.**\n11. **Don't jam mechanics content into the ceremony\u002Fupgrade prompt.** The `divine_ascension_ceremony.md` (or equivalent) prompt handles the upgrade moment ONLY. Per-tier mechanics (god-class biases, multipliers, bands, per-dawn menu, combat ladder, roll cap, deicide-cost) live in the per-turn general-mechanics prompt (`divine_leverage_system.md` or equivalent). The user explicitly said: *\"I dont think everything should be in the ceremony prompt? There should be a ceremony\u002Fugprade prompt and a general god mechanics prompt?\"* (Slack 2026-07-21). Also: before creating a new prompt file like `divine_god_mechanics.md`, **audit the existing `divine\u002F` (or equivalent) folder** — `divine_leverage_system.md` likely already exists as the canonical general-mechanics file. The user said: *\"I think there's already another mechanics prompt? what else is in divine\u002F folder?\"* before I realized the redundancy.\n12. **Don't break the setting-agnostic contract.** `$PROJECT_ROOT\u002Ftests\u002Ftest_divine_prompts_setting_agnostic.py` enforces that no D&D entity names (Mystra, Helm, Ao, Bhaal, Netheril, Kelemvor, Bane, Shar, \"Forgotten Realms\", \"Dale Reckoning\", \"Karsus\") leak into the **default text** of any divine prompt. Setting-specific names only belong in the explicit `Setting Adaptation` \u002F `D&D Forgotten Realms Adaptation Appendix` at the bottom of the leverage prompt. V2 overlays must be written with **generic placeholders** (\"war deity of the setting's pantheon\", \"arcane \u002F weave deity\", \"death \u002F underworld deity\") — never with named Faerûn deities, even in column examples. Also: the `SETTING-AGNOSTIC SYSTEM (CRITICAL)` header must remain in the **first 20 lines** of any ascension-ceremony prompt (test `test_setting_agnostic_header_is_prominent`). Run `TESTING_AUTH_BYPASS=true python3 -m pytest $PROJECT_ROOT\u002Ftests\u002Ftest_divine_prompts_setting_agnostic.py` before pushing. See `references\u002Fsetting-agnostic-contract.md` for the full diagnostic.\n13. **Don't push onto a shared branch without checking who owns it.** The `feat\u002Fgod-mechanics-v2` branch was being concurrently advanced by `jleechan2015` (PR #8485 merged in via `git fetch origin feat\u002Fgod-mechanics-v2`). When you go to `git push origin feat\u002Fgod-mechanics-v2`, the remote may have force-advanced to a SHA you don't have locally. **Correct recovery** (per `SOUL.md` `never-push-onto-someone-elses-pr-head`): `git fetch origin feat\u002Fgod-mechanics-v2 && git reset --hard FETCH_HEAD && git cherry-pick \u003Cyour-local-sha>` — never force-push. Then `git push origin feat\u002Fgod-mechanics-v2` (now fast-forward). Verify with `git rev-parse origin\u002Ffeat\u002Fgod-mechanics-v2` returning your new SHA. If the new commit is purely additive (e.g. moving content between two prompt files), cherry-pick is clean; if it touches the same lines the other party edited, expect a manual merge.\n14. **Don't skip the green-gate PR body schema.** The Green Gate workflow (`.github\u002Fworkflows\u002Fgreen-gate.yml`, ~1542 lines) fails with \"PR description gate rejected PR body\" if the PR description is missing **any** of these section headers (case-sensitive, must be `##` heading level): `## Summary`, `## Production Code Changes`, `## Test Changes`, `## Known Limitations`, `## Unit Test Evidence`, `## Non-Unit Test Evidence`, `## Real LLM Evidence`, `## Evidence`. For a code PR that touches `$PROJECT_ROOT\u002F**.py` outside tests, the gate also requires **non-empty real LLM response payload** in `## Non-Unit Test Evidence` (or `\u002Fend2end-testing` response\u002Fpayload) — the \"Real LLM Evidence\" carveout only applies to docs-only\u002Fconfig-only PRs. The gate runs on the commit SHA, so a PR body update alone does NOT re-trigger the gate — you must push a new commit (or trigger via `gh workflow run`) to re-evaluate. Use the `wa-green-gate-pr-shape` skill for full diagnostic + fix patterns.\n15. **Don't conflate general god-mechanics with Nocturne\u002FFaerûn-specific design.** Per user direction (Slack 2026-07-21): \"the chosen PR for world_reference should have EVERYTHING we discussed in this thread for the murder god campaign and all the god mechanics, self-contained.\" But: keep the $PROJECT_ROOT\u002Fprompt overlay **setting-agnostic** (Pitfall 12), and split the `world_reference\u002F` design doc into (a) **general god-mechanics** (system-agnostic, works for any setting — D&D \u002F Cyberpunk \u002F Wuxia \u002F Marvel \u002F Naruto) and (b) **Nocturne \u002F D&D Faerûn-specific** (the protagonist, the Faerûn pantheon integration, the BG3 setting). Two files, one general + one specific. The general file is the source of truth for any future god-mechanics work; the specific file is the campaign module. See `references\u002Fgeneral-vs-setting-specific-split.md` for the canonical split pattern.\n16. **Don't claim prompt-only mvp_site changes are exempt from \u002Fes.** A non-test edit to `$PROJECT_ROOT\u002Fagent_prompts.py` (or any `$PROJECT_ROOT\u002F**` file that contributes to the LLM prompt payload) MUST ship with real \u002Fes local-server + real-LLM evidence — not a unit-test green run, not a `generate_evidence_bundle.sh` script output, not \"the diff is text-only\". The AGENTS.md \u002Fes carve-out for \"pure comments \u002F docs \u002F formatting \u002F type hints \u002F import-order-only\" does NOT include prompt-layer changes; a new directive is a behavior change at the model-decision boundary and Green Gate gate 6 will reject a unit-only evidence bundle. Verified 2026-07-23 on the god-mode-generic-mechanics PR (issue #8538, AO session wa-3389): the worker tried to substitute `python -m unittest` after the unit tests passed, the gateway rejected the bundle, and a steering nudge to write a `testing_mcp\u002Ftest_*_contract_real_api.py` was required mid-run. The diagnostic recipe (when a worker hands you a unit-test-only evidence bundle) and the canonical copy-paste nudge are in `references\u002Fes-evidence-protocol-prompt-only-mvp-site.md`. Cross-ref Phase 3 \"PR B evidence\" subsection above.\n17. **Don't dispatch a MiniMax-M3 AO worker without a preflight heartbeat and a 60–90s early-kill window.** Verified pattern from `agento\u002Freferences\u002Fspawn-model-preflight.md` + the 2026-07-20 incident (`C0AH3RY3DK6\u002F1782336926`): Codex usage-limit banner can appear **before the worker's first tool call**, so by the time you notice from the AO session log the worker is already idle \u002F dead. Current recovery guidance (updated 2026-09-13):\n    1. **Preflight before spawn.** Run a low-timeout heartbeat against the planned model (e.g. `agy --print --model \u003Cname> --new-project --print-timeout 60s --prompt-interactive \"pong\"`). Confirm the model returns a real response within 60s before spawning the AO worker. If it hangs or errors → switch to a cheaper tier that responded in that preflight (Codex Luna \u002F Gemini 3.5 Flash High \u002F Claude Haiku); do NOT retry the same model that just timed out.\n    2. **60–90s early-kill window.** After `ao spawn`, monitor the worker's first two output blocks. If the worker has produced zero task code (no file edits, no git status change beyond the worktree scaffold) within 60–90s, kill the session (`ao session kill \u003Cid>`) and respawn on a different harness. Don't wait — workers that idle on their first command tend to stay idle; the cost of respawning is much lower than babysitting a stuck worker for 30+ minutes.\n    3. **Explicit mid-tier in the brief.** When the model is mid-tier (Codex Luna, Gemini 3.5 Flash High, Claude Sonnet\u002FCodex Luna), declare it explicitly in the spawn `--task` text (\"Explicit mid-tier: MiniMax-M3\" \u002F \"Explicit mid-tier: Gemini 3.5 Flash High\"). The model-name field on the AO harness defaults to top-tier if left empty, which both violates SOUL.md `subagent model routing (mandatory, 2026-07-14)` and burns budget on a model that may be the one that just timed out.\n    4. **Wrap `ao spawn` with `--agent \u003Cprovider>` for known harness:** for AO sessions targeting the worldarchitect project, prefer `--agent minimax` (MiniMax-M3, mid-tier, the verified mid-tier for prompt-only work) or `--agent antigravity` (Gemini 3.5 Flash High, mid-tier, the verified fallback). Don't use `--agent codex` without a verified Codex usage-limit budget for the day.\n    Cross-ref `agento\u002Freferences\u002Fspawn-model-preflight.md` (canonical reference) and `ao-spawn-minimax-worker` skill (the spawn-time mid-tier plumbing). Verified this session: wa-3382 (MiniMax-M3) was killed after 8+ minutes idle on its 3rd preflight command; wa-3384 (Antigravity\u002FGemini 3.5 Flash) was the working lane; wa-3389 (MiniMax-M3 mid-tier) eventually landed the PR after a steer nudge for \u002Fes.\n18. **Don't hardcode a single campaign's prompt type\u002Fpath\u002Fdirectory to `$PROJECT_ROOT\u002Fagent_prompts.py` \u002F `$PROJECT_ROOT\u002Fconstants.py` \u002F `$PROJECT_ROOT\u002Fagents.py` \u002F `$PROJECT_ROOT\u002Fprompts\u002F\u003Ccampaign>\u002F`** — except for the Dragon Knight fast-path. Use the `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F` + `custom_campaign_state.campaign_overlays` generic gate pattern. See `references\u002Fno-campaign-hardcoding-and-shared-prompts.md`. Verified PR #8661 (Spellblade Valeria) — 5 CodeRabbit blockers + user comment 3670171626 (\"No I dont want anything hardcoded to a single campaign\") all stemmed from this single anti-pattern.\n19. **Don't open a new PR or rewrite a contract before running Phase -1 open-PR preflight.** Verified 2026-07-28: user asked \"modify the prompts to encourage creation of mysteries in the plot line... either make a new PR or add this so an existing PR that fits.\" The agent loaded skill inventory first and discovered [PR #8662](https:\u002F\u002Fgithub.com\u002F$GITHUB_REPOSITORY\u002Fpull\u002F8662) (`feat(prompts): generic shared contracts + AI mystery\u002Finternal-drive arcs + campaign_overlays loader`, open at the time) already contained `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002Fai_generated_mystery_and_internal_drive_plot_arc.md` with the 3-suspect mystery template, hidden fact, clue trail, red herring \u002F partial truth \u002F real answer, and personal-cost reveals. The right answer was **amend PR #8662**, not open a new one. Phase -1 surfaces this in one REST call (`gh api 'search\u002Fissues?q=...'`) and 30 seconds; skipping it leads to a multi-tool archaeology pass that the user has to wait through. The user's verbatim phrasing is the canonical trigger for this pitfall — when they say \"new PR OR existing PR that fits,\" they want the agent to do that fit-check before responding.\n\n## Related\n\n- `~\u002F.hermes\u002Fskills\u002Fdownload-campaign\u002F` — Firestore → disk campaign export. Use for in-Firestore god-tier campaigns.\n- `~\u002F.hermes\u002Fskills\u002Fworldarchitect\u002Fwa-campaign-content-analysis\u002F` — in-place campaign analysis with agent attribution. Use for \"did the redesign actually land in new scenes?\"\n- `~\u002F.hermes\u002Fskills\u002Ffinish-the-job\u002F` — push-PR-and-merge discipline.\n- `~\u002F.hermes\u002Fskills\u002Fworkflow\u002Falways-pr-never-local-edit\u002F` — never just make local edits and stop.\n- `~\u002F.hermes\u002Fskills\u002Fmemory-search\u002F` — 9-store fan-out (the inventory phase uses this).\n- `references\u002Faizen-god-mechanics-pattern.md` — full quantified-stat-table + 3-layer reconciliation + DPP-overload analysis.\n- `references\u002Fcampaign-tier-inventory-2026-07-20.md` — the canonical inventory from the first session that used this skill.\n- `references\u002Fpr8485-v2-disable-centralization.md` — full PR #8485 v2 transcript: original 5-file scattered disable → user review feedback → single-switch refactor → 13-test registry contract. Use as the canonical reference when designing ANY feature-disable PR (tier, prompt, capability, prompt-loader entry, etc.).\n- `references\u002Fes-evidence-protocol-prompt-only-mvp-site.md` — **v0.4.0 evidence protocol.** Why \"prompt-only mvp_site change is exempt from \u002Fes\" is wrong; canonical copy-paste steering nudge for the AO worker; BQ query for verifying the new directive in the request payload; `testing_mcp\u002Ftest_\u003Cmechanic>_contract_real_api.py` skeleton; full verified transcript from issue #8538 (god-mode-generic-mechanics PR) showing the worker's three failed substitutes (unit tests, generate_evidence_bundle.sh, \"pure prompt exception\") and the steering nudge that unblocked it.\n- `references\u002Fno-campaign-hardcoding-and-shared-prompts.md` — **v0.5.0 canonical reference.** Full PR #8661 review thread (5 CodeRabbit blockers + user comment 3670171626 + the user's \"no campaign hardcoding except Dragon Knight\" preference) + the canonical solution shape (6 shared contracts at `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F` + the `custom_campaign_state.campaign_overlays` generic gate + the AGENTS.md \"no campaign hardcoding\" rule). Use this when answering \"can I add a new campaign X to `$PROJECT_ROOT\u002Fprompts\u002F`?\" — the answer is now always: layered as shared\u002Fgeneric + state-keyed overlay, never as a top-level `$PROJECT_ROOT\u002Fprompts\u002F\u003Ccampaign>\u002F` directory. Companion to the v0.5.0 Phase 2.5 (AI-mystery\u002Fint-drive architecture) and Pitfall #18.\n- `references\u002Fai-mystery-internal-drive-plot-recipe.md` — **v0.5.0 design recipe.** The 3-suspect template (red herring \u002F partial truth \u002F real answer) + the hidden-fact → clue-trail mechanic + the per-act growth\u002Finsecurity\u002Freframe requirement + the MBTI internal-only contract reference. Use when the user asks for \"mystery-driven campaigns,\" \"internal-drive plot arcs,\" \"character growth arcs that challenge insecurities,\" or any other phrasing that maps to the Phase 2.5 architecture. Verifies the wiki pages at `~\u002Fllm_wiki\u002Fwiki\u002Fconcepts\u002Fmbti\u002F*.md` are the AI-background source.\n- `references\u002Fopen-pr-preflight-recipe.md` — **v0.6.0 preflight recipe.** The 4-step REST-call recipe (`git branch -r` + 2× `gh api search\u002Fissues` + `git ls-tree`) that runs BEFORE Phase 0 inventory. Catches the most common failure mode: agent proposes a new PR when an existing open PR already covers the ask. Verified 2026-07-28 on the \"add mysteries to the plot\" user request which mapped verbatim to [PR #8662](https:\u002F\u002Fgithub.com\u002F$GITHUB_REPOSITORY\u002Fpull\u002F8662). Includes the decision matrix (amend existing \u002F add rule to umbrella \u002F push to umbrella-not-campaign-PR \u002F open new) + the PR #8662 case study (1 commit, 13 files, +1473\u002F-16 — the AI mystery + internal-drive + campaign_overlays loader umbrella).\n\n## Tests\n\n- `tests\u002Ftest_disable_sequence.py` — verify PR A disable actually flips `is_multiverse_upgrade_available()` to False and the prompt loader doesn't load the disabled file.\n- `tests\u002Ftest_disable_registry.py` — NEW v0.2.0 — verify `MULTIVERSE_TIER_ENABLED` + 3-helper registry contract: flag default, `get_upgrade_complete_tiers()` reflects the flag in both states, `is_multiverse_upgrade_available()` returns True under flag-on + triggers-met, `_CAMPAIGN_UPGRADE_COMPLETE_TIERS` mirrors the registry, import-time threshold is the sentinel when flag is False.\n- `tests\u002Ftest_setting_agnostic_remap.py` — verify the new prompt has no Faerun-specific terms in the core rules section (Ao\u002FPantheon\u002FWeave remapped to Prime Mover \u002F Apex Powers \u002F reality fabric).\n- `tests\u002Ftest_three_layer_canonical.py` — verify only ONE three-layer framing exists across all loaded prompts (production Aizen-style, never both).\n- `tests\u002Ftest_no_campaign_hardcoding.py` — NEW v0.5.0 — verify (a) no `$PROJECT_ROOT\u002Fprompts\u002F\u003Ccampaign>\u002F` subdirectory exists for any campaign name that isn't Dragon Knight, (b) no `PROMPT_TYPE_*_CAMPAIGN` constant in `$PROJECT_ROOT\u002Fconstants.py` (Dragon Knight's fast-path constants excluded by name), (c) no `$PROJECT_ROOT\u002Fprompts\u002F\u003Ccampaign>\u002F` referenced from `PATH_MAP` keys, (d) the `campaign_overlays` generic gate is exercised by at least one focused test. Companion to PR-A's `test_shared_contracts_and_internal_drive_mysteries.py`.\n\nRun: `cd ~\u002F.hermes\u002Fskills\u002Fworldarchitect-campaign-tier-redesign && python3 -m unittest discover -s tests`\n","# worldarchitect-campaign-tier-redesign\n\nCanonical home for \"the user wants to redesign \u002F disable \u002F revisit a campaign tier\" work in $GITHUB_REPOSITORY. This is a **class-level umbrella** that covers the recurring design cycle:\n\n1. **Audit current state** — read the prompt files + Python detection code + tests + prior art in `world_reference\u002F`.\n2. **Search prior campaigns** — what god\u002Fdivine\u002Fsovereign\u002Ftyranny campaigns has the user already played? Which mechanics did they like? (`download-campaign` for Firestore, `gog drive search` for Google Docs.)\n3. **Identify regressions** — why do newer campaigns feel less challenging than older ones? Root cause in prompt layer first, never in backend enforcement.\n4. **Propose a redesign** — setting-agnostic mechanics that explicitly reference what made the older work.\n5. **Disable \u002F ship \u002F measure** — small disable PR first, then the redesign PR, then verify on new scenes.\n\n## When to use\n\nTrigger phrases (any one):\n\n- \"Redesign all the god \u002F divine \u002F multiverse \u002F sovereign mechanics\"\n- \"Disable sovereign \u002F multiverse \u002F [tier X] for now\"\n- \"Revisit the divine \u002F [tier Y] campaigns\"\n- \"The god campaigns got less challenging \u002F mechanics weren't great\"\n- \"Make the new god campaign more like my older [Aizen \u002F Nocturne \u002F etc.] one\"\n- \"I want a new tier progression\" \u002F \"add a celestial tier\"\n- \"Disable tier X \u002F the [tier] prompt\"\n- \"Add mysteries to the plot\" \u002F \"mysteries not revealed\" \u002F \"backstories not revealed to the player\" \u002F \"unrevealed secrets in the plot\" \u002F \"encourage creation of mysteries in the plot line\" — these map to the AI-mystery shared contract in `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002Fai_generated_mystery_and_internal_drive_plot_arc.md` (see Phase 2.5). **Before designing a new PR, run Phase -1 to check if [PR #8662](https:\u002F\u002Fgithub.com\u002F$GITHUB_REPOSITORY\u002Fpull\u002F8662) (or its successor) already covers this** — that PR introduced the 3-suspect mystery template, hidden fact, clue trail, red herring \u002F partial truth \u002F real answer, and personal-cost reveals.\n- \"Use the MBTI stuff as background material\" \u002F \"internal-drive plot arcs\" \u002F \"challenge their insecurities\" — maps to the internal-drive plot arc contract, MBTI internal-only (PR #8539 invariant).\n\nAnti-triggers (don't load this skill):\n\n- \"Fix this specific god-mode bug\" → `\u002Frepro`\n- \"Pull this specific campaign from Firestore\" → `download-campaign`\n- \"Audit prompt changes across N campaigns\" → `wa-campaign-content-analysis`\n- \"Diagnose why my last Cloud Run deploy failed\" → `wa-cloud-run-deploy-failure-debug`\n- \"Bring this PR to green\" → `finish-the-job` + `drive-pr-to-green`\n\n## Class-level lesson (verified 2026-07-20)\n\nJeffrey's prior god-campaign work has a **quantified-stat-table pattern** that the current production system lost when it generalized. The local `world_reference\u002Faizen_god_mechanics.md` (11,449 bytes, replicated across ~50 worktrees) defined a Nascent Greater Deity with hard numbers — DR 750, DAC 25, DPP 825\u002Fday, DAIR Mod +31, DLR 4, Primary Damage 80 + (1d20×5) — that the LLM could ground its output in. The current `$PROJECT_ROOT\u002Fprompts\u002Fdivine\u002Fdivine_leverage_system.md` replaces these with **Dissonance × Safe Limit × Risk Multiplier** formulas that are harder for the LLM to produce concrete combat output from. See `references\u002Faizen-god-mechanics-pattern.md` for the full reconciliation.\n\nThree documented root causes of \"newer god campaigns feel less challenging\":\n\n1. **Two conflicting three-layer framings** — production is \"Mask (L0) \u002F Persona (L1) \u002F Source (L2)\" (mortal-face outward); Aizen is \"Ambiguous (L1) \u002F Projected (L2) \u002F Cover-story (L3)\" (all deception layers). Numbering + semantics diverge. Pick one.\n2. **DPP (Divine Power Points) is overloaded** — finite pool in the ascension ceremony (5\u002F5), \"Dissonance IS the cost\" (no pool) in the leverage rules, daily-replenishing 825\u002Fday in Aizen. Pick one.\n3. **No quantified divine stat table** — production uses Risk-Multiplier formulas; Aizen has the DR\u002FDAC\u002FDPP\u002FDAIR\u002FDLR\u002FPrimary-Damage table. LLM combat output is better grounded by the table.\n\n## Phase -1 — Open-PR preflight (always; takes \u003C30s, runs BEFORE Phase 0)\n\n**Always run this before designing anything.** It catches the most common failure mode: the agent proposes \"open a new PR\" or \"rewrite the contract\" when an existing open PR already covers the ask. Verified 2026-07-28 on the \"add mysteries to the plot\" user request — the agent had to discover [PR #8662](https:\u002F\u002Fgithub.com\u002F$GITHUB_REPOSITORY\u002Fpull\u002F8662) (which introduced `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002Fai_generated_mystery_and_internal_drive_plot_arc.md` with the 3-suspect template + personal-cost reveals) after multiple tool calls. The preflight would have surfaced this in one REST call.\n\n### Recipe\n\n```bash\ncd ~\u002Fprojects\u002Fyour-project.com && git fetch origin 2>&1 | tail -3\n\n# 1. List every feat\u002F* branch on origin (covers branches with or without PRs)\ngit branch -r | grep -E 'origin\u002Ffeat\u002F' | sort -u\n\n# 2. Search open PRs by keyword (REST, not GraphQL — bypasses rate limits)\ngh api 'search\u002Fissues?q=repo:$GITHUB_REPOSITORY+is:pr+is:open+mystery+OR+secret+OR+reveal+OR+plot+OR+foreshadow' \\\n  --jq '.items[] | {number,state,title,url,head_ref:.head.ref}' 2>&1\n\n# 3. Search by shared-contracts keyword (catches the v0.5.0 umbrella PRs)\ngh api 'search\u002Fissues?q=repo:$GITHUB_REPOSITORY+is:pr+is:open+shared-contracts+OR+internal-drive+OR+mbti+OR+overlays' \\\n  --jq '.items[] | {number,state,title,url,head_ref:.head.ref}' 2>&1\n\n# 4. For each candidate branch, check whether it already contains a\n#    `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002Fai_generated_mystery_and_internal_drive_plot_arc.md`\n#    (or whatever contract the user's ask maps to) — saves re-reading the diff\ngit ls-tree -r origin\u002F\u003Cbranch> -- $PROJECT_ROOT\u002Fprompts\u002Fshared\u002F 2>&1 | grep -E 'mystery|internal_drive|plot_arc'\n```\n\n### Decision matrix\n\n| What the preflight found | Action |\n|---|---|\n| Open PR already has the contract file | **Strengthen \u002F amend that PR** — push to the same branch. Don't open a new PR. |\n| Open PR covers a related ask (e.g. shared contracts umbrella) but missing the specific rule | **Add the rule to that PR** as a new commit on the same branch. Reference the umbrella PR's compatibility section. |\n| Multiple candidate branches (umbrella PR + companion campaign PR like #8662 + #8661) | **Push to the umbrella PR** (the shared contract), not the campaign-specific PR. Per `no-campaign-hardcoding` rule, the contract belongs in `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F`. |\n| No matching open PR | **Proceed to Phase 0** inventory + Phase 2 proposal. Branch from `origin\u002Fmain`. |\n\n### Anti-pattern\n\n- **Don't propose a new PR** before running Phase -1. The user's \"make a new PR or add this so an existing PR that fits\" (verified 2026-07-28 Slack phrasing) explicitly invites the agent to join an existing PR when one fits — default to that path.\n- **Don't skip the preflight even if the user's ask sounds new.** Mystery\u002Fsecrets\u002Fplot phrasing in 2026-07-28 mapped to PR #8662 verbatim; future phrasings (\"add foreshadowing\", \"add plot twists\", \"keep the player guessing\") will likely map to the same contract.\n- **Don't re-inventory Phase 0 items just because Phase -1 found an existing PR.** Phase 0 is for designing new work; if you're amending an existing PR, read its current diff and identify the gap, not start over.\n\n## Phase 0 — Inventory (always; takes \u003C5 min)\n\nBefore designing anything, run the inventory. This is the **delivery contract** — see the `memory-search` skill for the parallel-fan-out pattern.\n\nThree parallel `delegate_task` calls:\n\n| Task | Sources | Returns |\n|---|---|---|\n| **A — file audit** | `$PROJECT_ROOT\u002Fprompts\u002F{tier}\u002F*.md`, `$PROJECT_ROOT\u002Fcampaign_divine.py`, `$PROJECT_ROOT\u002Fgod_mode_level_up.py`, `world_reference\u002F*.md`, `wiki\u002Fsources\u002F{tier}-*.md` | Structured audit: every file, summary, mechanical rules verbatim, JSON state shapes, cross-references |\n| **B — 9-store memory search** | `\u002Fms` fan-out with 3-5 fused queries (e.g. \"sovereign multiverse disable\", \"Aizen god tyranny\", \"divine ascension ceremony\") | 9-section report: ~\u002Froadmap \u002F beads \u002F claude memories \u002F hermes sqlite \u002F briefings \u002F MEMORY.md \u002F wiki \u002F history \u002F slack |\n| **C — campaign corpus** | `gog drive search \"Aizen\" \"god\" \"campaign\"` for Google Docs at $USER@gmail.com + `download-campaign` for Firestore-resident god campaigns + `find ~\u002Frepos\u002Fjleechanorg -name \"*aizen*\" -o -name \"*god*\"` for local copies | Inventory table: doc ID, name, mimeType, modifiedTime, size, first-paragraph, 1-sentence \"why this matters\" |\n\n**Cache the 3 outputs at `\u002Ftmp\u002Fredesign_task{0,1,2}.md`** for re-reading in chunks (read_file truncates at ~50K chars inline).\n\n## Phase 1 — Diagnose root causes\n\nThree regression patterns to look for, in priority order:\n\n1. **Quantification loss** — does the current system have hard numbers the LLM can use in combat output? Or only formula-derived values? If formula-only, the redesign needs a quantified-stat table (Aizen pattern).\n2. **Three-layer framing duplication** — are there 2+ different layer schemes in different files that the LLM has to reconcile per-scene? If yes, collapse to one canonical scheme + cite the losing scheme as historical context.\n3. **Trigger ambiguity** — does the upgrade detector use multiple thresholds (level + divine_potential + explicit flag)? Is there a default order (e.g. \"multiverse takes priority regardless of tier\") that lets a player ascend past the intended point? If yes, document the canonical trigger order and make the priority explicit.\n\n## Phase 2 — Proposal\n\nWrite a design doc at `world_reference\u002F{tier}_mechanics_redesign_v2.md`. Format:\n\n1. **Goal** — what this redesign is fixing (cite Phase 1 root causes).\n2. **Prior art** — which old campaign\u002Fcampaigns this draws from (cite real doc IDs from Phase 0 inventory).\n3. **Setting-agnostic core** — explicit remapping from D&D-specific terms to generic-Apex-Powers terminology. The user has explicitly asked for \"general, not Faerun\u002FD&D\" mechanics — respect that. Ao → Prime Mover, Pantheon → Apex Powers, Weave → reality fabric, Divine Rank → Power Tier.\n4. **Mechanics** — quantified stat table (Aizen-pattern), trigger conditions, advancement formula.\n5. **3-Generation Power Lineage** — the G0 architect \u002F G1 rejecter \u002F G2 NEW-choice fork pattern from `world_reference\u002Fcampaign_module_god_of_murder.md` (verified 2026-07-20 in PR #8483).\n6. **What stays \u002F what goes** — explicit list of removed mechanics with the regression they caused.\n7. **Verification plan** — what scenes prove the redesign landed (per `wa-campaign-content-analysis` Phase 6 verification recipe).\n\n## Phase 2.5 — AI-Generated Mysteries + Internal-Drive Plot Architecture (verified 2026-07-28)\n\nWhen the user asks for \"mystery-driven campaigns,\" \"internal-drive plot arcs,\" \"character growth arcs that challenge insecurities,\" or \"use the MBTI stuff as background material,\" the design documentation MUST include the following architecture. This is a recurring pattern across the user's god\u002Fdivine\u002FSpellblade work; the canonical contracts above (one-rule-one-authoritative-file in `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F`) and the **canonical contract pinning** in PR #8539 (MBTI internal-only, NEVER in player-facing text) are the two upstream invariants this phase assumes.\n\n### Mystery template (mandatory for mystery-driven campaigns)\n\nEvery campaign the user wants to feel \"mystery-driven\" must include at least one active mystery with this structure:\n\n```\nmystery_state: {\n  active: [\n    {\n      id: \"mystery_1\",\n      hidden_fact: \"The fact nobody knows yet\",  # ONE fact, not 3\n      clue_trail: [\n        {\"scene\": N, \"clue\": \"...\", \"red_herring_weight\": 0.3},\n        {\"scene\": N+k, \"clue\": \"...\", \"red_herring_weight\": 0.5},\n        {\"scene\": N+k+j, \"clue\": \"...\", \"red_herring_weight\": 0.1},\n      ],\n      # Exactly 3 suspect branches — the LLM must seed ALL THREE.\n      # The player (or the campaign) picks the real answer; the LLM never overrides.\n      suspect_branches: [\n        {\"id\": \"red_herring\", \"presentation\": \"...\", \"weight\": 0.4},\n        {\"id\": \"partial_truth\", \"presentation\": \"...\", \"weight\": 0.4},\n        {\"id\": \"real_answer\", \"presentation\": \"...\", \"weight\": 0.2},\n      ],\n      # The mystery must HIT a character's vulnerability — see MBTI internal-only contract.\n      hits_vulnerability: \"campaign:npc_faction:character_id\",  # which NPC's internal drive this challenges\n      resolved: false,\n    },\n  ],\n  resolved: [{\"id\": \"mystery_0\", \"real_answer\": \"...\", \"victim_or_beneficiary\": \"...\"}],\n}\n```\n\n**Three mechanical rules:**\n\n1. **AI must seed mysteries proactively**, not wait for the player to ask. The opening scene must include at least one clue of an active mystery (Phase 9 \u002F Step 10's \"A\u002FB\u002FC choice\" should ALSO surface the first clue).\n2. **Three suspect branches are non-negotiable.** A mystery with only one path is not a mystery; it's a tutorial. The branches must be plausible (no \"obviously the butler did it\" branches). The weights are guidance, not destiny — player choices can shift real_answer confidence.\n3. **`hits_vulnerability` must reference a character's MBTI-internal vulnerability** under the canonical contract from PR #8539 — the LLM uses internal-only data (`mbti`, `attachment_style`, `insecurity_axes`, `stress_arc_target`) to design the mystery so it lands on the character, not on the player.\n\n### Internal-drive plot arc — the per-act requirement\n\nEvery campaign Act (1, 2, 3) MUST do at least one of:\n\n- **(a) Advance the character's growth direction** — what they need to learn, heal, or confront (see `campaign-creation` v1.2.0 `Phase 11.VI Personal-Growth Direction` for the data structure).\n- **(b) Confront an insecurity** — the MBTI stress-arc pattern (e.g. INFJ under stress → withdrawal + hyper-critical; ESTJ under stress → controlling micromanagement).\n- **(c) Reframe a long-held Want in light of new evidence** — the character's explicit Want is re-evaluated when the campaign surfaces a reason it can no longer be pursued unchanged.\n\nAnti-pattern: a campaign arc that doesn't grow the character is a series of unconnected scenes. Even if the user wants \"tight plot,\" the act breaks above still apply — the character's growth is the through-line.\n\n### MBTI internal-only contract — the upstream invariant\n\nThe MBTI architecture (Want \u002F Fear \u002F Boundary trifecta + stress arcs + personal-growth direction) is **LLM-input only**. Per PR #8539's canonical contract:\n\n- MBTI type codes (`INTJ`, `ISTJ`, etc.) are NEVER in player-facing text.\n- D&D alignment labels are NEVER in player-facing text.\n- Big Five scores are NEVER in player-facing text.\n- Personality categories are NEVER in player-facing text.\n- The wiki pages at `~\u002Fllm_wiki\u002Fwiki\u002Fconcepts\u002Fmbti\u002F*.md` are AI-background material only — sourced from the 16 personalitypage.com pages (verified 2026-07-28 wiki ingest).\n\nThe wiki ingest companion: `~\u002F.hermes\u002Fskills\u002Fllm-wiki` is the canonical authoring skill. The 16 raw HTML pages at `~\u002Fllm_wiki\u002Fraw\u002Farticles\u002Fmbti\u002F*.html` are sha256-stamped for re-ingest drift detection.\n\n### Verification rule for mystery\u002Fint-drive PRs\n\nA PR that adds AI-mystery infrastructure or internal-drive plot arcs to `$PROJECT_ROOT\u002Fprompts\u002F` MUST include:\n\n1. A focused test that asserts the new shared contract file exists in `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F`, contains the canonical keywords, and is registered in `PATH_MAP`.\n2. A test that asserts the contract is wired into `StoryModeAgent` \u002F `CombatAgent` \u002F `DialogAgent` `REQUIRED_PROMPT_ORDER` (or `OPTIONAL_PROMPTS` if conditional).\n3. A non-test reference in the PR body's `## Known Limitations` section explaining that the mystery\u002Fint-drive architecture is prompt-only — the state tracking (`mystery_state`) is the campaign-side LLM's responsibility, not backend enforcement.\n\n## Phase 3 — Ship\n\nTwo-PR sequence (recommended):\n\n- **PR A (small, fast): disable** — flip the trigger threshold to a sentinel (`UNIVERSE_CONTROL_THRESHOLD = 99999`), short-circuit `is_multiverse_upgrade_available()` to always `False`, add `disallow: {tier}` to the prompt loader, tag the disabled wiki sources with `disabled: true` frontmatter. One commit. Pure disable, no redesign. Branches from `origin\u002Fmain`. Per `workflow\u002Falways-pr-never-local-edit`.\n- **PR B (the redesign)** — ship the new prompt + setting-agnostic code + test coverage + a wiki source page + an update to the campaign module if applicable. Branches from `origin\u002Fmain`. Per `finish-the-job`.\n\nBoth PRs MUST be pushed (per SOUL.md `push-pr-donot-stop-halfway`) and both MUST pass the 7-green gate per `~\u002F.claude\u002Fskills\u002Fzero-touch.md`.\n\n### PR B delivery shape — PROMPT-ONLY MECHANICS + SPLIT PROMPT STRUCTURE (verified PR #8488, 2026-07-21)\n\n**Default: PR B is a prompt-only delivery.** No new Python helpers, no new constants, no new test files for backend code. The mechanics live as LLM instructions in the prompt markdown.\n\n**Why prompt-only (ZFC + root-cause-first):** Semantic decisions about god-tier transitions, multipliers, reputation bands, god-class biases, deicide-cost, etc. belong to the LLM, not to backend routing code. Pure-function helpers are dead code that misleads future readers. The reviewer on PR #8488 (`jleechan2015` inline comment r3618945602) explicitly called this out: *\"This is wrong and violating \u002Fzfc i think. It should just stay as prompt only.\"*\n\n**When to escalate to backend enforcement (rare):** Only after documenting why prompt correction is insufficient. Even then, the enforcement should be a **narrow, logged invariant** (e.g. \"no command may exceed L46+ without approval\"), not a `compute_v2_divine_stats()` helper.\n\n### PR B evidence — REAL \u002Fes LOCAL SERVER + REAL LLM IS MANDATORY for prompt-only `$PROJECT_ROOT\u002F**` changes (verified 2026-07-23, issue #8538)\n\nThis is the most-frequently-violated gate and the one AO workers try hardest to substitute around. The pitfall is real: a prompt-only `$PROJECT_ROOT\u002Fagent_prompts.py` change \"doesn't add new behavior, just text\" feels like it should be exempt from \u002Fes. It is **not**. Per the your-project.com repo's AGENTS.md and the Green Gate workflow:\n\n> *\"Any non-test change under `$PROJECT_ROOT\u002F**` requires `\u002Fes` evidence before the work is complete. ... If the changed code can touch LLM, agent routing, game state, rewards, persistence, streaming, APIs, or server behavior, `\u002Fes` must use a real local server with real services, including real LLM calls where that path uses an LLM.\"*\n\nA prompt-only change to `$PROJECT_ROOT\u002Fagent_prompts.py` (e.g. adding a new section to `build_god_mode_directives_block()`) **does** touch LLM agent routing and game state — the prompt is what the model sees at runtime. Therefore the carve-out that applies to \"pure comments \u002F docs \u002F formatting \u002F type hints\" **does NOT apply**. The evidence bundle MUST include:\n\n1. **Real local server.** Spawn `gunicorn mvp_site.main:app --bind 0.0.0.0:\u003Cport>` (typically a free high port) with `TESTING_AUTH_BYPASS=true ALLOW_TEST_AUTH_BYPASS=true WORLDAI_DEV_MODE=true MCP_TEST_MODE=real MOCK_SERVICES_MODE=false GOOGLE_APPLICATION_CREDENTIALS=…`. Verify it's live by curling `\u002Fhealth` or `\u002Fapi\u002Fhealth` before driving any LLM call.\n2. **Real LLM call(s).** Exercise the changed path end-to-end — for god-mode mechanics that's typically a `GOD MODE:` chat-turn input that triggers the directive-loader. The turn must be an actual `GodModeAgent` invocation, not a mocked fixture.\n3. **BQ-observable request trace.** Per `~\u002F.hermes\u002Fskills\u002Fworldarchitect\u002Freferences\u002Feval-god-mode.md` (and `.claude\u002Fskills\u002Fbq-evidence-reading.md`), the gateway logs the `gemini_provider.stream.request_json` payload to BQ. Verify the new directive text appears verbatim in `gemini_provider.stream.request_json.contents[].parts[].text` for the god-mode agent on the turn that exercises the new mechanic. The `GodModeAgent.response_text` for the same turn should be referenced for \"did the model follow the new directive\" — but the *delivery* evidence is in the request, not the response.\n4. **A `testing_mcp\u002Ftest_\u003Cmechanic>_contract_real_api.py` script.** Uses `MCPTestBase` + a real local server + real LLM (NOT mocks). The script should:\n   - seed the new directive via `GOD_MODE_UPDATE_STATE:` to load it into `custom_campaign_state`,\n   - trigger a god-mode chat turn that must invoke the changed `build_god_mode_directives_block()`,\n   - parse the captured LLM request JSONL (`llm_request_responses.jsonl` \u002F `provider_http_request_responses.jsonl` \u002F `request_responses.jsonl`) and assert the literal text of the new mechanic appears (use a case-insensitive substring scan over ALL string fields, not just `system` role text — the directive may live under different keys depending on the request shape).\n5. **The agent's behavior delta.** Capture the `GodModeAgent.response_text` from BQ (via `bq query` per `.claude\u002Fskills\u002Fbq-evidence-reading.md`) for the same turn — the response should show the model applying the new mechanic, not falling back to the prior path.\n\n**Three common substitutes the AO worker will try, and why each fails:**\n\n| Substitute | Why it fails |\n|---|---|\n| `python -m unittest $PROJECT_ROOT\u002Ftests\u002Ftest_\u003Cx>.py` | Unit tests prove the helper function renders the new text correctly. They DO NOT prove the LLM actually receives it at runtime. Green Gate gate 6 requires real-server + real-LLM proof. |\n| `bash scripts\u002Fgenerate_evidence_bundle.sh \u003Ctest_name>` | That script runs unit tests + captures stdout. It does not start a server, does not drive an LLM call, and the captured stdout does not include the LLM request payload. It satisfies the \"evidence exists\" requirement formally but not substantively. |\n| \"Pure prompt exception — no runtime behavior changed\" | The AGENTS.md carve-out explicitly excludes prompt-layer changes. Adding or rewording a directive IS a behavior change at the model-decision boundary. |\n\n**The diagnostic recipe when a worker submits a unit-test-only evidence bundle:**\n\n1. `git diff origin\u002Fmain..HEAD --stat` — confirm only test files + prompt\u002Fagent_prompts files changed.\n2. `cat \u002Ftmp\u002Fwa-NNNN\u002Ffeat\u002F\u003Cbranch>\u002F\u003Ctest_name>\u002Flatest\u002F*.err 2>\u002Fdev\u002Fnull` (or wherever the evidence bundle landed) — look for the captured LLM request payload.\n3. If the bundle contains `python -m unittest` output and NO captured HTTP \u002F request JSONL → reject as not-real-evidence. Reply: *\"STOP: unit-only evidence violates the explicit brief and repo AGENTS.md. This non-test mvp_site change REQUIRES real \u002Fes local server + real services + real LLM. ...\"*\n4. Use `ao send \u003Csession>` to steer the worker mid-run (do not kill and respawn — the worker is usually mid-implementation, just on the wrong evidence path).\n\n**Companion reference:** `references\u002Fes-evidence-protocol-prompt-only-mvp-site.md` (this skill) has the canonical copy-paste steering nudge, the BQ query for verifying the request payload, the `testing_mcp` template skeleton, and the verified full transcript from issue #8538's god-mode-generic-mechanics PR.\n\n**Split prompt structure — ceremony vs. mechanics are SEPARATE files:**\n\n| File | Role | Size (typical) |\n|---|---|---|\n| `$PROJECT_ROOT\u002Fprompts\u002F{tier}\u002F{tier}_ascension_ceremony.md` | Trigger + ceremony phases (Recognition → State Updates) — runs ONCE per character | 100-150 lines |\n| `$PROJECT_ROOT\u002Fprompts\u002F{tier}\u002F{tier}_leverage_system.md` (or `divine_god_mechanics.md` for non-ascension tiers) | Per-turn mechanics — runs on every divine-tier turn after ascension | 500-800 lines (V1 + V2 overlays stacked) |\n\nThe ceremony prompt cross-references the leverage prompt: *\"Post-ceremony: also load `divine_leverage_system.md` for all subsequent divine-tier turns.\"*\n\n**Audit existing files BEFORE creating new ones.** Before adding `divine_god_mechanics.md` or similar, `ls` the `prompts\u002F{tier}\u002F` folder. The general-mechanics file likely already exists — `divine_leverage_system.md` for the divine tier, etc. Adding a redundant file is wasted work and confuses the LLM (which prompt to load?).\n\n**V2 overlay insertion pattern:** Insert V2 sections at the **bottom** of the leverage prompt, BEFORE the Setting Adaptation Appendix. The appendix stays the only setting-specific content at the end of the file. The V2 overlay inherits the existing setting-agnostic preamble.\n\n### PR A disable contract — SINGLE-SWITCH CENTRALIZATION (verified PR #8485 v2, 2026-07-21)\n\n**Anti-pattern (the trap I fell into on PR #8485 v1):** disable scattered across 5 files — `campaign_divine.is_multiverse_upgrade_available()` hardcoded `return False`, `agent_prompts._append_campaign_tier_prompts()` had `elif False: pass`, `_CAMPAIGN_UPGRADE_COMPLETE_TIERS` dropped SOVEREIGN via inline comment, `agents.CampaignUpgradeAgent` had a defense-in-depth warning fallback, `constants.UNIVERSE_CONTROL_THRESHOLD` was a hardcoded sentinel. Five files to flip to re-enable. The user's review feedback was direct: *\"centralize this code better, control it with existence of this enum vs all these other code changes so easier to turn back on later.\"*\n\n**Correct shape — single switch + small registry in `constants.py`:**\n\n```python\n# The single switch\nMULTIVERSE_TIER_ENABLED = False\n\n# Import-time-computed sentinel-vs-historical threshold (no other file needs to flip)\nUNIVERSE_CONTROL_THRESHOLD = 999999 if not MULTIVERSE_TIER_ENABLED else 70\n\n# Three registry helpers — every call site reads these instead of hand-rolling sets\ndef get_allowed_campaign_tiers() -> frozenset[str]:\n    tiers = [CAMPAIGN_TIER_MORTAL, CAMPAIGN_TIER_DIVINE, CAMPAIGN_TIER_SOVEREIGN]\n    return frozenset(tiers)  # keeps SOVEREIGN in allowlist for legacy Firestore data\n\ndef get_upgrade_complete_tiers() -> frozenset[str]:\n    tiers = {CAMPAIGN_TIER_DIVINE}\n    if MULTIVERSE_TIER_ENABLED:\n        tiers = {CAMPAIGN_TIER_DIVINE, CAMPAIGN_TIER_SOVEREIGN}\n    return frozenset(tiers)\n\ndef is_multiverse_tier_enabled() -> bool:\n    return MULTIVERSE_TIER_ENABLED\n```\n\nThen every call site reads the flag:\n\n| Site | Reads |\n|---|---|\n| `campaign_divine.is_multiverse_upgrade_available()` | `if not constants.is_multiverse_tier_enabled(): return False; else original_trigger_logic` |\n| `campaign_upgrade._CAMPAIGN_UPGRADE_COMPLETE_TIERS` | `constants.get_upgrade_complete_tiers()` |\n| `agent_prompts.PATH_MAP` sovereign entries | `if constants.is_multiverse_tier_enabled(): PATH_MAP.update({SOVEREIGN_*: PATH})` |\n| `agent_prompts._append_campaign_tier_prompts()` | `elif constants.is_multiverse_tier_enabled() and campaign_tier == CAMPAIGN_TIER_SOVEREIGN:` |\n| `agents.CampaignUpgradeAgent` | `if self._upgrade_type == \"multiverse\" and not constants.is_multiverse_tier_enabled(): fallback_to_divine_with_warning; elif self._upgrade_type == \"multiverse\": load SOVEREIGN_ASCENSION` |\n| `game_state.allowed_tiers` + `rewards_engine.valid_campaign_tiers` | `constants.get_allowed_campaign_tiers()` |\n\n**To re-enable the tier:** flip `MULTIVERSE_TIER_ENABLED = True` and redeploy. No other file changes needed.\n\n**Critical contract when designing the disable:** the body of every call site must STAY RUNTIME-IDENTICAL when the flag is False. The original pre-disable logic should be the \"flag=True\" branch — never delete the implementation, just gate it. This is the difference between \"temporary disable\" and \"permanent deletion\". The user's review feedback makes this an explicit hard rule.\n\n**Test contract for the single switch:**\n\n- 13+ tests proving the registry helpers reflect the flag in both states (`patch.object(constants, \"MULTIVERSE_TIER_ENABLED\", True\u002FFalse)`)\n- `test_returns_false_when_flag_disabled` + `test_returns_true_when_flag_enabled_and_triggers_met` for each gated function\n- `test_import_time_threshold_matches_disabled_flag` for the computed threshold (since `UNIVERSE_CONTROL_THRESHOLD` captures at import time, runtime flag flips don't reach it — that's correct, you re-deploy not runtime-toggle)\n- The original disable tests still pass unchanged (they prove the flag-False runtime is identical to the previous \"hardcoded disable\" runtime)\n\n**Why the registry needs three helpers, not one `is_tier_enabled(tier)`:** the SOVEREIGN entry legitimately stays in `get_allowed_campaign_tiers()` even when disabled (legacy Firestore documents with `campaign_tier=\"sovereign\"` still need to validate; no NEW campaign transitions INTO sovereign while disabled). But it drops out of `get_upgrade_complete_tiers()` and `is_multiverse_tier_enabled()` returns False. Conflating these two states in a single helper breaks legacy-data compatibility.\n\n**Pitfall — `UNIVERSE_CONTROL_THRESHOLD` is import-time-computed, not runtime-flip-able:**\n\n```python\n# CORRECT — one flip, then redeploy\nMULTIVERSE_TIER_ENABLED = True  # was False\n# UNIVERSE_CONTROL_THRESHOLD auto-recomputes to 70 on next import\n```\n\n```python\n# WRONG — runtime flag flip does NOT update the threshold\nimport mvp_site.constants as c\nc.MULTIVERSE_TIER_ENABLED = True\nprint(c.UNIVERSE_CONTROL_THRESHOLD)  # still 999999 — it was captured at module load\n```\n\nIf you ever need runtime-toggle for A\u002FB testing or staged rollout, extract the comparison into a helper instead:\n\n```python\ndef is_universe_control_at_threshold(universe_control: int) -> bool:\n    threshold = 70 if MULTIVERSE_TIER_ENABLED else 999999\n    return universe_control >= threshold\n```\n\nFor PR A disable work, the import-time semantics are correct — re-deploying to flip the flag is the right blast radius.\n\n## Phase 4 — Verify\n\nAfter PR B merges, run `wa-campaign-content-analysis` Phase 6 (prompt-fix-effectiveness-verification) on the next 5 god-tier scenes the user plays. Quantified-stat-table presence in combat output, three-layer-framing consistency, trigger-ambiguity regression check. Report findings as pre\u002Fpost delta + the 5-cause taxonomy if the LLM isn't following the new prompt.\n\n## Pitfalls (this list IS the skill — review before running)\n\n1. **Don't propose a redesign without first running Phase 0 inventory.** The \"receipts-first\" contract is non-negotiable. The user has been bitten by agents that propose redesigns without grounding them in real prior campaigns.\n2. **Don't replace the quantified-stat-table with formula-only.** The LLM produces worse combat output when it has to derive divine stats from Risk Multipliers every turn. Use the Aizen pattern (DR\u002FDAC\u002FDPP\u002FDAIR\u002FDLR\u002FPrimary Damage table) even if the production system prefers formulas.\n3. **Don't keep both three-layer framings in different files.** Pick one. The losing scheme gets a wiki \"Historical context\" section, not active prompts.\n4. **Don't let \"multiverse takes priority over divine regardless of tier\" survive a redesign.** This is the bug from PR #7883 \u002F issue #7882 (roadmap\u002F2026-06-24). Either document the canonical priority or remove the upgrade entirely.\n5. **Don't ship a redesign that is still Faerun\u002FD&D-specific when the user asked for general.** Ao → Prime Mover, Pantheon → Apex Powers, Weave → reality fabric. Setting-specific examples stay only in the canon-attribution section.\n6. **Don't disable a tier by deleting the prompt file.** Move it to `$PROJECT_ROOT\u002Fprompts\u002F{tier}_disabled\u002F` so the work is recoverable. Wiki sources get `disabled: true` frontmatter so the next agent doesn't re-enable by accident.\n7. **Don't skip the 5-minute inventory.** The temptation is \"I already know the code, let me just write the fix.\" That bypasses the user's actual ask (\"read all my older campaigns first\"). Inventory is the work, not a prelude to it.\n8. **Don't `clarify` for next-step scope before delivering Phase 0 receipts.** User said \"Status on this and did you truly find and read aizen campaign and all the others I asked?\" mid-redesign on 2026-07-20 — the inventory table was the deliverable; the `clarify` came too early.\n9. **Don't scatter the disable across multiple files with hardcoded `return False` + commented-out blocks.** This was my PR #8485 v1 anti-pattern. Centralize into `MULTIVERSE_TIER_ENABLED` + a 3-helper registry in `constants.py` (see Phase 3 \"PR A disable contract\" above). Every call site reads the flag — re-enabling is one boolean flip, not a 5-file refactor. The user will catch this on review and ask you to redo it. Verify locally with the test contract above before pushing.\n10. **Don't add god-mechanics Python helpers (`get_v2_god_tier`, `compute_v2_divine_stats`, `v2_reputation_band`, etc.) to `$PROJECT_ROOT\u002Fcampaign_divine.py` or `$PROJECT_ROOT\u002Fconstants.py`.** Semantic decisions about god-tier transitions, multipliers, reputation bands, god-class biases, deicide-cost, etc. belong to the **LLM prompt**, NOT to backend routing code. This was the actual review feedback on PR #8488 (`jleechan2015` inline comment r3618945602 on `$PROJECT_ROOT\u002Fcampaign_divine.py:208`: *\"This is wrong and violating \u002Fzfc i think. It should just stay as prompt only\"*). The pure-function helpers are a feature-creep violation of **Zero-Framework Cognition (ZFC)** + **root-cause-first** principles: encode semantic decisions in the LLM prompt, not in backend code. If you must add backend enforcement later, do it as a narrow, logged invariant after documenting why prompt correction is insufficient. Default: **prompt-only.**\n11. **Don't jam mechanics content into the ceremony\u002Fupgrade prompt.** The `divine_ascension_ceremony.md` (or equivalent) prompt handles the upgrade moment ONLY. Per-tier mechanics (god-class biases, multipliers, bands, per-dawn menu, combat ladder, roll cap, deicide-cost) live in the per-turn general-mechanics prompt (`divine_leverage_system.md` or equivalent). The user explicitly said: *\"I dont think everything should be in the ceremony prompt? There should be a ceremony\u002Fugprade prompt and a general god mechanics prompt?\"* (Slack 2026-07-21). Also: before creating a new prompt file like `divine_god_mechanics.md`, **audit the existing `divine\u002F` (or equivalent) folder** — `divine_leverage_system.md` likely already exists as the canonical general-mechanics file. The user said: *\"I think there's already another mechanics prompt? what else is in divine\u002F folder?\"* before I realized the redundancy.\n12. **Don't break the setting-agnostic contract.** `$PROJECT_ROOT\u002Ftests\u002Ftest_divine_prompts_setting_agnostic.py` enforces that no D&D entity names (Mystra, Helm, Ao, Bhaal, Netheril, Kelemvor, Bane, Shar, \"Forgotten Realms\", \"Dale Reckoning\", \"Karsus\") leak into the **default text** of any divine prompt. Setting-specific names only belong in the explicit `Setting Adaptation` \u002F `D&D Forgotten Realms Adaptation Appendix` at the bottom of the leverage prompt. V2 overlays must be written with **generic placeholders** (\"war deity of the setting's pantheon\", \"arcane \u002F weave deity\", \"death \u002F underworld deity\") — never with named Faerûn deities, even in column examples. Also: the `SETTING-AGNOSTIC SYSTEM (CRITICAL)` header must remain in the **first 20 lines** of any ascension-ceremony prompt (test `test_setting_agnostic_header_is_prominent`). Run `TESTING_AUTH_BYPASS=true python3 -m pytest $PROJECT_ROOT\u002Ftests\u002Ftest_divine_prompts_setting_agnostic.py` before pushing. See `references\u002Fsetting-agnostic-contract.md` for the full diagnostic.\n13. **Don't push onto a shared branch without checking who owns it.** The `feat\u002Fgod-mechanics-v2` branch was being concurrently advanced by `jleechan2015` (PR #8485 merged in via `git fetch origin feat\u002Fgod-mechanics-v2`). When you go to `git push origin feat\u002Fgod-mechanics-v2`, the remote may have force-advanced to a SHA you don't have locally. **Correct recovery** (per `SOUL.md` `never-push-onto-someone-elses-pr-head`): `git fetch origin feat\u002Fgod-mechanics-v2 && git reset --hard FETCH_HEAD && git cherry-pick \u003Cyour-local-sha>` — never force-push. Then `git push origin feat\u002Fgod-mechanics-v2` (now fast-forward). Verify with `git rev-parse origin\u002Ffeat\u002Fgod-mechanics-v2` returning your new SHA. If the new commit is purely additive (e.g. moving content between two prompt files), cherry-pick is clean; if it touches the same lines the other party edited, expect a manual merge.\n14. **Don't skip the green-gate PR body schema.** The Green Gate workflow (`.github\u002Fworkflows\u002Fgreen-gate.yml`, ~1542 lines) fails with \"PR description gate rejected PR body\" if the PR description is missing **any** of these section headers (case-sensitive, must be `##` heading level): `## Summary`, `## Production Code Changes`, `## Test Changes`, `## Known Limitations`, `## Unit Test Evidence`, `## Non-Unit Test Evidence`, `## Real LLM Evidence`, `## Evidence`. For a code PR that touches `$PROJECT_ROOT\u002F**.py` outside tests, the gate also requires **non-empty real LLM response payload** in `## Non-Unit Test Evidence` (or `\u002Fend2end-testing` response\u002Fpayload) — the \"Real LLM Evidence\" carveout only applies to docs-only\u002Fconfig-only PRs. The gate runs on the commit SHA, so a PR body update alone does NOT re-trigger the gate — you must push a new commit (or trigger via `gh workflow run`) to re-evaluate. Use the `wa-green-gate-pr-shape` skill for full diagnostic + fix patterns.\n15. **Don't conflate general god-mechanics with Nocturne\u002FFaerûn-specific design.** Per user direction (Slack 2026-07-21): \"the chosen PR for world_reference should have EVERYTHING we discussed in this thread for the murder god campaign and all the god mechanics, self-contained.\" But: keep the $PROJECT_ROOT\u002Fprompt overlay **setting-agnostic** (Pitfall 12), and split the `world_reference\u002F` design doc into (a) **general god-mechanics** (system-agnostic, works for any setting — D&D \u002F Cyberpunk \u002F Wuxia \u002F Marvel \u002F Naruto) and (b) **Nocturne \u002F D&D Faerûn-specific** (the protagonist, the Faerûn pantheon integration, the BG3 setting). Two files, one general + one specific. The general file is the source of truth for any future god-mechanics work; the specific file is the campaign module. See `references\u002Fgeneral-vs-setting-specific-split.md` for the canonical split pattern.\n16. **Don't claim prompt-only mvp_site changes are exempt from \u002Fes.** A non-test edit to `$PROJECT_ROOT\u002Fagent_prompts.py` (or any `$PROJECT_ROOT\u002F**` file that contributes to the LLM prompt payload) MUST ship with real \u002Fes local-server + real-LLM evidence — not a unit-test green run, not a `generate_evidence_bundle.sh` script output, not \"the diff is text-only\". The AGENTS.md \u002Fes carve-out for \"pure comments \u002F docs \u002F formatting \u002F type hints \u002F import-order-only\" does NOT include prompt-layer changes; a new directive is a behavior change at the model-decision boundary and Green Gate gate 6 will reject a unit-only evidence bundle. Verified 2026-07-23 on the god-mode-generic-mechanics PR (issue #8538, AO session wa-3389): the worker tried to substitute `python -m unittest` after the unit tests passed, the gateway rejected the bundle, and a steering nudge to write a `testing_mcp\u002Ftest_*_contract_real_api.py` was required mid-run. The diagnostic recipe (when a worker hands you a unit-test-only evidence bundle) and the canonical copy-paste nudge are in `references\u002Fes-evidence-protocol-prompt-only-mvp-site.md`. Cross-ref Phase 3 \"PR B evidence\" subsection above.\n17. **Don't dispatch a MiniMax-M3 AO worker without a preflight heartbeat and a 60–90s early-kill window.** Verified pattern from `agento\u002Freferences\u002Fspawn-model-preflight.md` + the 2026-07-20 incident (`C0AH3RY3DK6\u002F1782336926`): Codex usage-limit banner can appear **before the worker's first tool call**, so by the time you notice from the AO session log the worker is already idle \u002F dead. Current recovery guidance (updated 2026-09-13):\n    1. **Preflight before spawn.** Run a low-timeout heartbeat against the planned model (e.g. `agy --print --model \u003Cname> --new-project --print-timeout 60s --prompt-interactive \"pong\"`). Confirm the model returns a real response within 60s before spawning the AO worker. If it hangs or errors → switch to a cheaper tier that responded in that preflight (Codex Luna \u002F Gemini 3.5 Flash High \u002F Claude Haiku); do NOT retry the same model that just timed out.\n    2. **60–90s early-kill window.** After `ao spawn`, monitor the worker's first two output blocks. If the worker has produced zero task code (no file edits, no git status change beyond the worktree scaffold) within 60–90s, kill the session (`ao session kill \u003Cid>`) and respawn on a different harness. Don't wait — workers that idle on their first command tend to stay idle; the cost of respawning is much lower than babysitting a stuck worker for 30+ minutes.\n    3. **Explicit mid-tier in the brief.** When the model is mid-tier (Codex Luna, Gemini 3.5 Flash High, Claude Sonnet\u002FCodex Luna), declare it explicitly in the spawn `--task` text (\"Explicit mid-tier: MiniMax-M3\" \u002F \"Explicit mid-tier: Gemini 3.5 Flash High\"). The model-name field on the AO harness defaults to top-tier if left empty, which both violates SOUL.md `subagent model routing (mandatory, 2026-07-14)` and burns budget on a model that may be the one that just timed out.\n    4. **Wrap `ao spawn` with `--agent \u003Cprovider>` for known harness:** for AO sessions targeting the worldarchitect project, prefer `--agent minimax` (MiniMax-M3, mid-tier, the verified mid-tier for prompt-only work) or `--agent antigravity` (Gemini 3.5 Flash High, mid-tier, the verified fallback). Don't use `--agent codex` without a verified Codex usage-limit budget for the day.\n    Cross-ref `agento\u002Freferences\u002Fspawn-model-preflight.md` (canonical reference) and `ao-spawn-minimax-worker` skill (the spawn-time mid-tier plumbing). Verified this session: wa-3382 (MiniMax-M3) was killed after 8+ minutes idle on its 3rd preflight command; wa-3384 (Antigravity\u002FGemini 3.5 Flash) was the working lane; wa-3389 (MiniMax-M3 mid-tier) eventually landed the PR after a steer nudge for \u002Fes.\n18. **Don't hardcode a single campaign's prompt type\u002Fpath\u002Fdirectory to `$PROJECT_ROOT\u002Fagent_prompts.py` \u002F `$PROJECT_ROOT\u002Fconstants.py` \u002F `$PROJECT_ROOT\u002Fagents.py` \u002F `$PROJECT_ROOT\u002Fprompts\u002F\u003Ccampaign>\u002F`** — except for the Dragon Knight fast-path. Use the `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F` + `custom_campaign_state.campaign_overlays` generic gate pattern. See `references\u002Fno-campaign-hardcoding-and-shared-prompts.md`. Verified PR #8661 (Spellblade Valeria) — 5 CodeRabbit blockers + user comment 3670171626 (\"No I dont want anything hardcoded to a single campaign\") all stemmed from this single anti-pattern.\n19. **Don't open a new PR or rewrite a contract before running Phase -1 open-PR preflight.** Verified 2026-07-28: user asked \"modify the prompts to encourage creation of mysteries in the plot line... either make a new PR or add this so an existing PR that fits.\" The agent loaded skill inventory first and discovered [PR #8662](https:\u002F\u002Fgithub.com\u002F$GITHUB_REPOSITORY\u002Fpull\u002F8662) (`feat(prompts): generic shared contracts + AI mystery\u002Finternal-drive arcs + campaign_overlays loader`, open at the time) already contained `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002Fai_generated_mystery_and_internal_drive_plot_arc.md` with the 3-suspect mystery template, hidden fact, clue trail, red herring \u002F partial truth \u002F real answer, and personal-cost reveals. The right answer was **amend PR #8662**, not open a new one. Phase -1 surfaces this in one REST call (`gh api 'search\u002Fissues?q=...'`) and 30 seconds; skipping it leads to a multi-tool archaeology pass that the user has to wait through. The user's verbatim phrasing is the canonical trigger for this pitfall — when they say \"new PR OR existing PR that fits,\" they want the agent to do that fit-check before responding.\n\n## Related\n\n- `~\u002F.hermes\u002Fskills\u002Fdownload-campaign\u002F` — Firestore → disk campaign export. Use for in-Firestore god-tier campaigns.\n- `~\u002F.hermes\u002Fskills\u002Fworldarchitect\u002Fwa-campaign-content-analysis\u002F` — in-place campaign analysis with agent attribution. Use for \"did the redesign actually land in new scenes?\"\n- `~\u002F.hermes\u002Fskills\u002Ffinish-the-job\u002F` — push-PR-and-merge discipline.\n- `~\u002F.hermes\u002Fskills\u002Fworkflow\u002Falways-pr-never-local-edit\u002F` — never just make local edits and stop.\n- `~\u002F.hermes\u002Fskills\u002Fmemory-search\u002F` — 9-store fan-out (the inventory phase uses this).\n- `references\u002Faizen-god-mechanics-pattern.md` — full quantified-stat-table + 3-layer reconciliation + DPP-overload analysis.\n- `references\u002Fcampaign-tier-inventory-2026-07-20.md` — the canonical inventory from the first session that used this skill.\n- `references\u002Fpr8485-v2-disable-centralization.md` — full PR #8485 v2 transcript: original 5-file scattered disable → user review feedback → single-switch refactor → 13-test registry contract. Use as the canonical reference when designing ANY feature-disable PR (tier, prompt, capability, prompt-loader entry, etc.).\n- `references\u002Fes-evidence-protocol-prompt-only-mvp-site.md` — **v0.4.0 evidence protocol.** Why \"prompt-only mvp_site change is exempt from \u002Fes\" is wrong; canonical copy-paste steering nudge for the AO worker; BQ query for verifying the new directive in the request payload; `testing_mcp\u002Ftest_\u003Cmechanic>_contract_real_api.py` skeleton; full verified transcript from issue #8538 (god-mode-generic-mechanics PR) showing the worker's three failed substitutes (unit tests, generate_evidence_bundle.sh, \"pure prompt exception\") and the steering nudge that unblocked it.\n- `references\u002Fno-campaign-hardcoding-and-shared-prompts.md` — **v0.5.0 canonical reference.** Full PR #8661 review thread (5 CodeRabbit blockers + user comment 3670171626 + the user's \"no campaign hardcoding except Dragon Knight\" preference) + the canonical solution shape (6 shared contracts at `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F` + the `custom_campaign_state.campaign_overlays` generic gate + the AGENTS.md \"no campaign hardcoding\" rule). Use this when answering \"can I add a new campaign X to `$PROJECT_ROOT\u002Fprompts\u002F`?\" — the answer is now always: layered as shared\u002Fgeneric + state-keyed overlay, never as a top-level `$PROJECT_ROOT\u002Fprompts\u002F\u003Ccampaign>\u002F` directory. Companion to the v0.5.0 Phase 2.5 (AI-mystery\u002Fint-drive architecture) and Pitfall #18.\n- `references\u002Fai-mystery-internal-drive-plot-recipe.md` — **v0.5.0 design recipe.** The 3-suspect template (red herring \u002F partial truth \u002F real answer) + the hidden-fact → clue-trail mechanic + the per-act growth\u002Finsecurity\u002Freframe requirement + the MBTI internal-only contract reference. Use when the user asks for \"mystery-driven campaigns,\" \"internal-drive plot arcs,\" \"character growth arcs that challenge insecurities,\" or any other phrasing that maps to the Phase 2.5 architecture. Verifies the wiki pages at `~\u002Fllm_wiki\u002Fwiki\u002Fconcepts\u002Fmbti\u002F*.md` are the AI-background source.\n- `references\u002Fopen-pr-preflight-recipe.md` — **v0.6.0 preflight recipe.** The 4-step REST-call recipe (`git branch -r` + 2× `gh api search\u002Fissues` + `git ls-tree`) that runs BEFORE Phase 0 inventory. Catches the most common failure mode: agent proposes a new PR when an existing open PR already covers the ask. Verified 2026-07-28 on the \"add mysteries to the plot\" user request which mapped verbatim to [PR #8662](https:\u002F\u002Fgithub.com\u002F$GITHUB_REPOSITORY\u002Fpull\u002F8662). Includes the decision matrix (amend existing \u002F add rule to umbrella \u002F push to umbrella-not-campaign-PR \u002F open new) + the PR #8662 case study (1 commit, 13 files, +1473\u002F-16 — the AI mystery + internal-drive + campaign_overlays loader umbrella).\n\n## Tests\n\n- `tests\u002Ftest_disable_sequence.py` — verify PR A disable actually flips `is_multiverse_upgrade_available()` to False and the prompt loader doesn't load the disabled file.\n- `tests\u002Ftest_disable_registry.py` — NEW v0.2.0 — verify `MULTIVERSE_TIER_ENABLED` + 3-helper registry contract: flag default, `get_upgrade_complete_tiers()` reflects the flag in both states, `is_multiverse_upgrade_available()` returns True under flag-on + triggers-met, `_CAMPAIGN_UPGRADE_COMPLETE_TIERS` mirrors the registry, import-time threshold is the sentinel when flag is False.\n- `tests\u002Ftest_setting_agnostic_remap.py` — verify the new prompt has no Faerun-specific terms in the core rules section (Ao\u002FPantheon\u002FWeave remapped to Prime Mover \u002F Apex Powers \u002F reality fabric).\n- `tests\u002Ftest_three_layer_canonical.py` — verify only ONE three-layer framing exists across all loaded prompts (production Aizen-style, never both).\n- `tests\u002Ftest_no_campaign_hardcoding.py` — NEW v0.5.0 — verify (a) no `$PROJECT_ROOT\u002Fprompts\u002F\u003Ccampaign>\u002F` subdirectory exists for any campaign name that isn't Dragon Knight, (b) no `PROMPT_TYPE_*_CAMPAIGN` constant in `$PROJECT_ROOT\u002Fconstants.py` (Dragon Knight's fast-path constants excluded by name), (c) no `$PROJECT_ROOT\u002Fprompts\u002F\u003Ccampaign>\u002F` referenced from `PATH_MAP` keys, (d) the `campaign_overlays` generic gate is exercised by at least one focused test. Companion to PR-A's `test_shared_contracts_and_internal_drive_mysteries.py`.\n\nRun: `cd ~\u002F.hermes\u002Fskills\u002Fworldarchitect-campaign-tier-redesign && python3 -m unittest discover -s tests`\n",{"name":5,"author":71,"license":14,"version":72,"metadata":73,"platforms":109,"description":7},"Hermes Agent","0.6.0",{"hermes":74},{"tags":75,"changelog":92,"related_skills":99},[39,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91],"god-mode","divine","sovereign","multiverse","campaign-tier","mechanics-redesign","level-up","es-evidence-protocol","ao-spawn-preflight","no-campaign-hardcoding","shared-prompts","ai-mystery","internal-drive-plot","mbti-internal","open-pr-preflight","discovery-first",[93,94,95,96,97,98],"0.6.0 (2026-07-28): OPEN-PR PREFLIGHT + DISCOVERY-FIRST. (a) Added Phase -1 'Open-PR preflight' subsection — always run BEFORE Phase 0 inventory. REST-call recipe (`gh api search\u002Fissues`) that catches the common failure mode: agent proposes a new PR when an existing open PR (e.g. #8662 'AI mystery\u002Finternal-drive arcs') already covers the ask. Decision matrix covers 4 cases (amend existing \u002F add rule to umbrella \u002F push to umbrella-not-campaign-PR \u002F open new). (b) Added Pitfall #19 'Don't open a new PR or rewrite a contract before running Phase -1 open-PR preflight' — verified 2026-07-28 on the 'add mysteries to the plot' user request which mapped to PR #8662. (c) Expanded description + trigger phrases to cover the user's natural-language phrasings: 'mysteries not revealed', 'backstories not revealed to the player', 'unrevealed secrets in the plot', 'encourage creation of mysteries in the plot line'. (d) New reference doc `references\u002Fopen-pr-preflight-recipe.md` with the full REST-call recipe, decision matrix, and the 2026-07-28 PR #8662 case study.","0.5.0 (2026-07-28): NO-CAMPAIGN-HARDCODE RULE + AI-MYSTERY\u002FINTERNAL-DRIVE DESIGN PATTERN. (a) Added Phase 2.5 'AI-Generated Mysteries + Internal-Drive Plot Architecture' subsection — the canonical 3-suspect template (red herring \u002F partial truth \u002F real answer), the hidden-fact → clue-trail mechanic, the per-act growth\u002Finsecurity\u002Freframe requirement, and the MBTI internal-only contract reference (PR #8539). (b) Added Pitfall #18 'Don't hardcode a single campaign's prompt type\u002Fpath\u002Fdirectory to `$PROJECT_ROOT\u002Fagent_prompts.py` \u002F `$PROJECT_ROOT\u002Fconstants.py` \u002F `$PROJECT_ROOT\u002Fagents.py` \u002F `$PROJECT_ROOT\u002Fprompts\u002F\u003Ccampaign>\u002F` — except for the Dragon Knight fast-path. Use the `$PROJECT_ROOT\u002Fprompts\u002Fshared\u002F` + `custom_campaign_state.campaign_overlays` generic gate pattern.' (c) New trigger phrases: 'no campaign hardcoding except Dragon Knight', 'generate mysteries', 'internal-drive plot arcs', 'MBTI internal', 'add a new campaign overlay'. Verified 2026-07-28 on PR #8661 (Spellblade Valeria) — user comment 3670171626 + Slack `C0AUXSVFSA2` thread: 'I never want anything hardcoded to a single campaign except Dragon Knight' + the 5 CodeRabbit blockers (P1: 'Load the Spellblade overlay for opted-in campaigns' on agent_prompts.py:177; P2: rule lives in combat prompt but is a dialog rule; P2: NPC goals can't evolve under any circumstance; P2: hidden_power_charges never decrement; P2: mirrored rules duplicate shared canonical). Companion PR-A: `feat\u002Fshared-contracts-mbti-internal-drive` adds the 6 generic shared contracts + the campaign_overlays loader gate + AGENTS.md 'no campaign hardcoding' rule.","0.4.0 (2026-07-23): ES EVIDENCE PROTOCOL + AO SPAWN MODEL-PREFLIGHT. Added Phase 3 subsection 'PR B evidence — real \u002Fes local-server + real LLM is mandatory for prompt-only mvp_site changes' (forces testing_mcp real-API test, BQ raw-request verification, rejects unit-only stand-ins) + 2 new pitfalls (#16 prompt-only is NOT a \u002Fes carveout; #17 MiniMax-M3 AO worker preflight + early-kill discipline — Codex usage-limit banner appears before first tool call; if no commit lands within 60-90s, kill + respawn on a different harness with explicit mid-tier). Verified this session's god-mode-generic-mechanics PR (issue #8538, AO session wa-3389): worker tried to substitute `python -m unittest` for real \u002Fes, required a steering nudge mid-run, real gunicorn+Gemini 3.5 run is what produces durable evidence.","0.3.0 (2026-07-21): PR B delivery shape — PROMPT-ONLY MECHANICS + SPLIT PROMPT STRUCTURE. Added Phase 3 subsection 'PR B delivery shape' + 6 new pitfalls (#10 ZFC: no god-mechanics Python helpers; #11 don't jam mechanics into ceremony prompt, audit existing files first; #12 setting-agnostic contract — no D&D entities leak; #13 push-race on shared branch recovery; #14 green-gate PR body schema; #15 general vs setting-specific split). Verified PR #8488 (V2 god-mechanics) — reviewer feedback from jleechan2015 (inline r3618945602: 'This is wrong and violating \u002Fzfc i think. It should just stay as prompt only') and user feedback ('I dont think everything should be in the ceremony prompt? There should be a ceremony\u002Fupgrade prompt and a general god mechanics prompt?' + 'I think there's already another mechanics prompt? what else is in divine\u002F folder?').","0.2.0 (2026-07-21): PR A disable contract — SINGLE-SWITCH CENTRALIZATION. Added the 'one flag + 3-helper registry' pattern + test contract + the 'runtime-flags-do-not-update-import-time-thresholds' pitfall. Anti-pattern (the trap I fell into on PR #8485 v1): 5-file scattered disable with hardcoded `return False` and commented-out blocks. Correct shape: `MULTIVERSE_TIER_ENABLED` + `get_allowed_campaign_tiers()` \u002F `get_upgrade_complete_tiers()` \u002F `is_multiverse_tier_enabled()` in `constants.py`. Re-enabling is now one boolean flip. Verified PR #8485 v2 (review feedback from $USER: 'centralize this code better, control it with existence of this enum vs all these other code changes so easier to turn back on later').","0.1.0 (2026-07-20): Initial umbrella covering the design-and-disable cycle on the tier stack.",[100,101,102,103,104,105,106,107,108],"download-campaign","wa-campaign-content-analysis","wa-green-gate-pr-shape","finish-the-job","workflow\u002Falways-pr-never-local-edit","agento","ao-spawn-minimax-worker","worldai-campaign-to-google-doc","llm-wiki",[110,111],"macos","linux","main","05df7380981a2c4af868ce0fa57962ae0eea62a9","hermes\u002Fskills\u002Fworldarchitect\u002Fworldarchitect-campaign-tier-redesign",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-11 09:18:40",{"source":8,"skillName":5,"commands":120,"prompt":130,"zipAvailable":131},[121,124,127],{"tool":122,"command":123},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill worldarchitect-campaign-tier-redesign",{"tool":125,"command":126},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill worldarchitect-campaign-tier-redesign",{"tool":128,"command":129},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill worldarchitect-campaign-tier-redesign","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fworldarchitect\u002Fworldarchitect-campaign-tier-redesign\u002FSKILL.md",true,[133,139,143,147,151,155,159,163,167,171,175,179,183,187,191,195,199,203,207,211,217,221,225,229,233,237,241,245,249,253,257,261,265,269,273,277,281,285,289,293],{"path":134,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":137,"sourceHtmlUrl":138},"assets\u002Fatx\u002Ftd_ingress-nginx-lbc\u002Fdocument_references\u002Fnavigating-nginx-ingress-retirement.md","ASSET","资产文件",15893,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fatx\u002Ftd_ingress-nginx-lbc\u002Fdocument_references\u002Fnavigating-nginx-ingress-retirement.md",{"path":140,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":141,"sourceHtmlUrl":142},"assets\u002Fatx\u002Ftd_ingress-nginx-lbc\u002Fsummaries.md",1269,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fatx\u002Ftd_ingress-nginx-lbc\u002Fsummaries.md",{"path":144,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":145,"sourceHtmlUrl":146},"assets\u002Fatx\u002Ftd_ingress-nginx-lbc\u002Ftransformation_definition.md",8383,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fatx\u002Ftd_ingress-nginx-lbc\u002Ftransformation_definition.md",{"path":148,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":149,"sourceHtmlUrl":150},"assets\u002Fsamples\u002Falb\u002F01-basic-rewrite-ingress.yaml",1090,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Falb\u002F01-basic-rewrite-ingress.yaml",{"path":152,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":153,"sourceHtmlUrl":154},"assets\u002Fsamples\u002Falb\u002F02-tls-rewrite-ingress.yaml",1384,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Falb\u002F02-tls-rewrite-ingress.yaml",{"path":156,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":157,"sourceHtmlUrl":158},"assets\u002Fsamples\u002Falb\u002F03-multi-path-ingress.yaml",2164,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Falb\u002F03-multi-path-ingress.yaml",{"path":160,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":161,"sourceHtmlUrl":162},"assets\u002Fsamples\u002Falb\u002F04-cors-auth-ingress.yaml",2949,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Falb\u002F04-cors-auth-ingress.yaml",{"path":164,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":165,"sourceHtmlUrl":166},"assets\u002Fsamples\u002Falb\u002F05-deprecated-class-annotation.yaml",1114,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Falb\u002F05-deprecated-class-annotation.yaml",{"path":168,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":169,"sourceHtmlUrl":170},"assets\u002Fsamples\u002Falb\u002F06-multi-host-tls-ingress.yaml",2474,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Falb\u002F06-multi-host-tls-ingress.yaml",{"path":172,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":173,"sourceHtmlUrl":174},"assets\u002Fsamples\u002Falb\u002F07-simple-no-rewrite-ingress.yaml",1149,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Falb\u002F07-simple-no-rewrite-ingress.yaml",{"path":176,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":177,"sourceHtmlUrl":178},"assets\u002Fsamples\u002Falb\u002F08-internal-ingress.yaml",1424,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Falb\u002F08-internal-ingress.yaml",{"path":180,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":181,"sourceHtmlUrl":182},"assets\u002Fsamples\u002Fnginx\u002F01-basic-rewrite-ingress.yaml",877,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Fnginx\u002F01-basic-rewrite-ingress.yaml",{"path":184,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":185,"sourceHtmlUrl":186},"assets\u002Fsamples\u002Fnginx\u002F02-tls-rewrite-ingress.yaml",1193,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Fnginx\u002F02-tls-rewrite-ingress.yaml",{"path":188,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":189,"sourceHtmlUrl":190},"assets\u002Fsamples\u002Fnginx\u002F03-multi-path-ingress.yaml",1539,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Fnginx\u002F03-multi-path-ingress.yaml",{"path":192,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":193,"sourceHtmlUrl":194},"assets\u002Fsamples\u002Fnginx\u002F04-cors-auth-ingress.yaml",1415,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Fnginx\u002F04-cors-auth-ingress.yaml",{"path":196,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":197,"sourceHtmlUrl":198},"assets\u002Fsamples\u002Fnginx\u002F05-deprecated-class-annotation.yaml",924,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Fnginx\u002F05-deprecated-class-annotation.yaml",{"path":200,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":201,"sourceHtmlUrl":202},"assets\u002Fsamples\u002Fnginx\u002F06-multi-host-tls-ingress.yaml",2182,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Fnginx\u002F06-multi-host-tls-ingress.yaml",{"path":204,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":205,"sourceHtmlUrl":206},"assets\u002Fsamples\u002Fnginx\u002F07-simple-no-rewrite-ingress.yaml",912,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Fnginx\u002F07-simple-no-rewrite-ingress.yaml",{"path":208,"resourceType":135,"resourceTypeDesc":136,"sizeBytes":209,"sourceHtmlUrl":210},"assets\u002Fsamples\u002Fnginx\u002F08-internal-ingress.yaml",1225,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Fassets\u002Fsamples\u002Fnginx\u002F08-internal-ingress.yaml",{"path":212,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":215,"sourceHtmlUrl":216},"references\u002Fai-mystery-internal-drive-plot-recipe.md","REFERENCE","参考文档",8967,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fworldarchitect\u002Fworldarchitect-campaign-tier-redesign\u002Freferences\u002Fai-mystery-internal-drive-plot-recipe.md",{"path":218,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":219,"sourceHtmlUrl":220},"references\u002Faizen-god-mechanics-pattern.md",8201,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fworldarchitect\u002Fworldarchitect-campaign-tier-redesign\u002Freferences\u002Faizen-god-mechanics-pattern.md",{"path":222,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":223,"sourceHtmlUrl":224},"references\u002Falb-migration.md",23773,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Falb-migration.md",{"path":226,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":227,"sourceHtmlUrl":228},"references\u002Fatx-guide.md",12736,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Fatx-guide.md",{"path":230,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":231,"sourceHtmlUrl":232},"references\u002Fcampaign-tier-inventory-2026-07-20.md",7893,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fworldarchitect\u002Fworldarchitect-campaign-tier-redesign\u002Freferences\u002Fcampaign-tier-inventory-2026-07-20.md",{"path":234,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":235,"sourceHtmlUrl":236},"references\u002Fdns-certificates.md",6008,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Fdns-certificates.md",{"path":238,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":239,"sourceHtmlUrl":240},"references\u002Fgateway-api.md",7436,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Fgateway-api.md",{"path":242,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":243,"sourceHtmlUrl":244},"references\u002Fiam-policy.json",1525,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Fiam-policy.json",{"path":246,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":247,"sourceHtmlUrl":248},"references\u002Fingress-discovery.md",27547,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Fingress-discovery.md",{"path":250,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":251,"sourceHtmlUrl":252},"references\u002Fingress-resources.md",7532,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Fingress-resources.md",{"path":254,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":255,"sourceHtmlUrl":256},"references\u002Flbc-migrate-toolkit.md",17680,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Flbc-migrate-toolkit.md",{"path":258,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":259,"sourceHtmlUrl":260},"references\u002Fmigration-plan.md",14180,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Fmigration-plan.md",{"path":262,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":263,"sourceHtmlUrl":264},"references\u002Fmigration-risk.md",5974,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Fmigration-risk.md",{"path":266,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":267,"sourceHtmlUrl":268},"references\u002Fno-campaign-hardcoding-and-shared-prompts.md",8733,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fworldarchitect\u002Fworldarchitect-campaign-tier-redesign\u002Freferences\u002Fno-campaign-hardcoding-and-shared-prompts.md",{"path":270,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":271,"sourceHtmlUrl":272},"references\u002Fopen-pr-preflight-recipe.md",8327,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fworldarchitect\u002Fworldarchitect-campaign-tier-redesign\u002Freferences\u002Fopen-pr-preflight-recipe.md",{"path":274,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":275,"sourceHtmlUrl":276},"references\u002Fporting-notes.md",26134,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Fporting-notes.md",{"path":278,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":279,"sourceHtmlUrl":280},"references\u002Freport-generation.md",68839,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Freport-generation.md",{"path":282,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":283,"sourceHtmlUrl":284},"references\u002Fsetting-agnostic-contract.md",2999,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fworldarchitect\u002Fworldarchitect-campaign-tier-redesign\u002Freferences\u002Fsetting-agnostic-contract.md",{"path":286,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":287,"sourceHtmlUrl":288},"references\u002Fsupplementary-rbac.md",4486,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Fsupplementary-rbac.md",{"path":290,"resourceType":213,"resourceTypeDesc":214,"sizeBytes":291,"sourceHtmlUrl":292},"references\u002Ftraffic-routing.md",9080,"https:\u002F\u002Fgithub.com\u002Faws-samples\u002Fsample-apex-skills\u002Fblob\u002Fmain\u002Fdevops-agent\u002Feks-ingress-migration\u002Freferences\u002Ftraffic-routing.md",{"path":294,"resourceType":295,"resourceTypeDesc":296,"sizeBytes":297,"sourceHtmlUrl":298},"scripts\u002Fverify_disable.py","SCRIPT","脚本",5160,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fworldarchitect\u002Fworldarchitect-campaign-tier-redesign\u002Fscripts\u002Fverify_disable.py",[300,318,338,351,365,381],{"skillNo":301,"name":302,"nameZh":6,"description":303,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":304,"categories":305,"keywords":306,"publishedAt":66},"01M716Y5MTJ6GYJZ2ATXCJK8G4","instinct","Use when the user invokes \u002Finstinct or \u002Fin, or asks to \"message Instinct\", \"ask Instinct\", \"tell Instinct\", \"check Instinct\", or read replies from the configured peer assistant. iMessage first, WhatsApp Web as fallback.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finstinct\u002FSKILL.md",[],[302,307,308,309,310,311,312,313,314,315,316,317],"user","when","replies","check","use","identity","whatsapp","gmail","read","message","ask",{"skillNo":319,"name":320,"nameZh":6,"description":321,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":322,"categories":323,"keywords":327,"publishedAt":66},"01M716Y4HF7FVVMJSA2CCVN5VF","hr","Compatibility alias for history-resume; produce the same fresh-state, provenance-aware resume briefing.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhr\u002FSKILL.md",[324],{"categoryNo":325,"categoryName":326,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000038","人力资源",[320,328,329,330,331,332,333,334,335,336,337],"resume","compatibility","provenance","for","history","produce","alias","briefing","state","fresh",{"skillNo":339,"name":340,"nameZh":6,"description":341,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":342,"categories":343,"keywords":345,"publishedAt":66},"01M716Y1FFNFKFJYYKF8HQA6T8","history-resume","Resume briefing for the current repository branch or worktree using fresh state and admitted history sources.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhistory-resume\u002FSKILL.md",[344],{"categoryNo":325,"categoryName":326,"taxonomyType":31,"taxonomyTypeDesc":32},[332,328,346,56,307,347,335,348,331,349,350,336,337],"history resume","analysis","repository","worktree","sources",{"skillNo":352,"name":353,"nameZh":6,"description":354,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":355,"categories":356,"keywords":357,"publishedAt":66},"01M716XWXJ8EPHK4RH9T14TR85","grok","Alias for the canonical grokbot browser conversation workflow; \u002Fgrok talks to the Grok bot the same way \u002Fdot talks to Dot.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgrok\u002FSKILL.md",[],[353,358,359,360,331,361,334,362,363,364],"dot","bot","workflow","canonical","conversation","browser","grokbot",{"skillNo":366,"name":367,"nameZh":6,"description":368,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":369,"categories":370,"keywords":371,"publishedAt":66},"01M70N9Q07DTE0EW5KFXMMMSJ0","codexa-bench","Compare `codexa` and normal `codex` on a fair split of comparable work by default; use `--strict` for duplicate runs of the exact same task.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodexa-bench\u002FSKILL.md",[],[372,373,374,311,375,331,376,377,378,379,380],"codexa bench","work","split","default","duplicate","task","compare","normal","codex",{"skillNo":382,"name":383,"nameZh":6,"description":384,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":385,"licenseFileUrl":386,"sourceHtmlUrl":387,"categories":388,"keywords":398,"publishedAt":66},"01M6C24S2X60SP8BBFGAEKPEGW","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[389,392,395],{"categoryNo":390,"categoryName":391,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":393,"categoryName":394,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":396,"categoryName":397,"taxonomyType":31,"taxonomyTypeDesc":32},"01JBSEEDCAT000000000000032","设计师",[399,65,400,311,401,402,403,307,404,405,406,407,408,409,410,411,412,413,414,415,416,417,418,419,420,421,308,422],"frontend","frontend design","generic","ui design","react","html","components","code","artifacts","ui","aesthetics","Production","web components","landing","applications","quality","web","css","create","examples","with","react components","web ui","pages"]