Realign system-prompt overrides to CC 2.1.168 vocabulary

[dividedby]

What

Realign the placeholder vocabulary of system-prompt overrides to CC 2.1.168.

Launch-blockers (original scope):

• tool-description-askuserquestion.md — PROMPT_VAR_0/1 → ENTER_PLAN_MODE_TOOL_NAME / EXIT_PLAN_MODE_TOOL_NAME (ccVersion 2.1.156 → 2.1.168)
• agent-prompt-explore.md — PROMPT_VAR_0..5 → GLOB_TOOL_NAME, GREP_TOOL_NAME, READ_TOOL_NAME, SHELL_TOOL_NAME, IS_BASH_ENV_FN, USE_EMBEDDED_TOOLS_FN (ccVersion 2.1.118 → 2.1.168)

Remaining realigns (added in follow-up commit):

• agent-prompt-memory-synthesis.md — OPTIONAL_TAIL_NOTE → EMPTY_STRING (same trailing slot, renamed in 2.1.168 prompt data)
• tool-description-workflow.md — 5 clean renames (WORKFLOW_INVOCATION_QUALIFIER→WORKFLOW_TOOL_NAME, WORKFLOW_RESEND_NOTE→WORKFLOW_SCRIPT_PATH_NOTE, WORKFLOW_ISOLATION_TYPE→WORKFLOW_AGENT_ISOLATION_OPTION, WORKFLOW_WORKTREE_NOTE→WORKFLOW_AGENT_ISOLATION_NOTE, WORKFLOW_GROUP_GLYPH→WORKFLOW_GROUP_PREFIX)
• tool-description-croncreate.md — structural realign of the slot-bearing tail to the 2.1.168 shape (CRON_DURABILITY_SECTION, the IS_MONITOR_TOOL_ENABLED_FN()? ternary with CRON_CREATE_TOOL_NAME / MONITOR_TOOL_NAME, and CRON_DURABLE_RUNTIME_NOTE); dropped the stale CRON_DURABLE_FLAG and bogus CANCEL_TIMEFRAME_DAYS()? guard. Condensed prose preserved.

Prose is otherwise unchanged — these are vocabulary/structure realigns, not content edits.

Why

The extractor's identifierMap human-name vocabulary changed at 2.1.168 (positional PROMPT_VAR_N → semantic names). Overrides still referencing the old names made the name-keyed substitution find nothing to replace and emit ${PROMPT_VAR_0} verbatim into a cli.js template literal — a non-booting binary:

ReferenceError: PROMPT_VAR_0 is not defined
      at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:463:41)

The patcher-side robustness fix that makes such mismatches skip (keep CC's original blob) instead of producing invalid JS is in skrabe/tweakcc-fixed#4. This PR makes the prompts actually apply again on 2.1.168.

Cowork plugin docs — no content change needed

The two remaining skipped prompts (skill-cowork-plugin-authoring, data-cowork-plugin-component-schemas) reference \${CLAUDE_PLUGIN_ROOT} / \${VAR_NAME} as literal env-var documentation (empty identifierMap) and were already correctly backslash-escaped. They were being skipped by a guard false-positive that matched escaped \${NAME} as if it were an unresolved interpolation. Fixed patcher-side in skrabe/tweakcc-fixed#4 (the guard now ignores backslash-escaped placeholders) — no markdown change required here.

Verified

• No PROMPT_VAR_* placeholders remain.
• Every unescaped ${…} placeholder in all five touched files is a member of the CC 2.1.168 identifierMap for that prompt — all slots resolve.
• agent-prompt-explore.md and tool-description-croncreate.md checked against the reconstructed 2.1.168 prompt structure (pieces + identifierMap).
• End-to-end: --apply against CC 2.1.168 applies all five with zero skips; claude -p boots and responds.

🤖 Generated with Claude Code

[skrabe]

Thanks for this. First off, have you been running these against Piebald's tweakcc or upstream's prompt data? Every name in the diff matches Piebald's identifierMap exactly, which would explain the PROMPT_VAR_0 crash. They apply clean against our tweakcc-fixed, our dictionary still uses PROMPT_VAR_0 where upstream renamed it to GLOB_TOOL_NAME.

That's why I'm passing on 4 of the 5 (explore, askuserquestion, memory-synthesis, workflow). Checked each against our prompts-2.1.168.json: our identifiers array is byte-identical to upstream's and every slot is already named, so they resolve and boot clean for us today. applyIdentifierMapping substitutes by our human-name, so renaming the bodies to GLOB_TOOL_NAME/etc. leaves them unresolved → ${…} spliced into a template literal → the exact ReferenceError this is meant to prevent. Net-negative rename for us.

croncreate is the real one, good catch. Our identifierMap there names only 3 of the 7 slots, so ${CANCEL_TIMEFRAME_DAYS} binds to the wrong capture and resolves to the IS_MONITOR_TOOL_ENABLED function instead of the day-count value. Boots, so it slipped past apply + smoke. The fill has to happen in our prompt data, which can't come from this repo, so I'll take it on our side and reuse your realignment for the override half, crediting you.

If you are on upstream's data, the fix on your end is to run our tweakcc-fixed (it ships the matching names) or keep the renamed copies in your fork. Closing in favor of handling croncreate on our end. Thanks for digging in.