{"id":"1e03a695-fafd-4fe2-9fc0-4ce9ec799f79","entityType":"agent","slug":"clawhub-drumrobot-fix","name":"fix","canonicalUrl":"https://www.xpersona.co/agent/clawhub-drumrobot-fix","canonicalPath":"/agent/clawhub-drumrobot-fix","generatedAt":"2026-10-09T14:53:05.700Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T11:39:25.681Z","emptyReason":null},"description":"User behavior correction skill. Triggered by \"fix:\" prefix feedback (e.g., \"fix: why didn't you commit?\"). Analyzes the mistake, improves the relevant prompt (skill/rule/agent/memory/hook) to prevent recurrence, then fixes the current issue. TodoWrite required for all steps. Use when \"fix:\", \"fix this\", \"correct\", \"why not\", \"why missing\", \"behavior fix\" is mentioned.","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 2.8K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s17ay1v6v88r2m102pvvc44gz183qcrm:fix","sourceUrl":"https://clawhub.ai/drumrobot/fix","homepage":"https://clawhub.ai/drumrobot/skills/fix","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/drumrobot/fix","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/drumrobot/skills/fix","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":41,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"fix technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T11:39:25.681Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T11:39:25.681Z","emptyReason":null},"stars":null,"forks":null,"downloads":2765,"packageName":null,"latestVersion":"0.7.1","tractionLabel":"2.8K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T11:39:25.681Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T11:39:25.681Z","lastCrawledAt":"2026-10-09T11:39:25.681Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T11:39:25.681Z","lastVerifiedAt":null,"highlights":[{"version":"0.7.1","createdAt":"2026-10-06T07:55:43.634Z","changelog":"**Summary:** Minor update with housekeeping and resource script changes. - Removed unnecessary documentation file: `skill-card.md`. - Updated behavior correction script: improved/modified `resources/fix-and-ambiguity-guard.sh`. - Updated changelog reference: `CHANGELOG.md` modified for this version.","fileCount":11,"zipByteSize":57755},{"version":"0.7.0","createdAt":"2026-09-30T14:21:01.403Z","changelog":"fix v0.7.0 - Updated documentation in CHANGELOG.md and SKILL.md for clearer usage instructions and stronger enforcement notes. - Removed outdated documentation file skill-card.md. - No functional or behavior logic changes; update is documentation/guide cleanup only.","fileCount":11,"zipByteSize":57353},{"version":"0.6.2","createdAt":"2026-09-18T15:53:12.226Z","changelog":"fix v0.6.2 - Removed unnecessary file: skill-card.md - Updated documentation in CHANGELOG.md - No core functionality changes; maintenance/cleanup release","fileCount":11,"zipByteSize":56746},{"version":"0.6.1","createdAt":"2026-09-10T05:56:00.582Z","changelog":"fix 0.6.1 - Updated documentation in SKILL.md and CHANGELOG.md. - Removed the obsolete skill-card.md file. - No changes to core skill logic; this is a documentation and cleanup release.","fileCount":11,"zipByteSize":56430},{"version":"0.6.0","createdAt":"2026-09-06T10:31:17.070Z","changelog":"fix 0.6.0 - Removed obsolete file: skill-card.md - Updated CHANGELOG.md to reflect recent changes - No changes to core logic or functionality","fileCount":11,"zipByteSize":55889},{"version":"0.5.0","createdAt":"2026-09-05T16:15:53.641Z","changelog":"fix 0.5.0 - Updated documentation in SKILL.md and CHANGELOG.md for accuracy and clarity. - Removed obsolete file: skill-card.md. - No changes to main logic; this is a documentation cleanup and alignment release.","fileCount":11,"zipByteSize":56002},{"version":"0.4.2","createdAt":"2026-08-30T11:13:19.268Z","changelog":"fix v0.4.2 - Updated documentation in CHANGELOG.md and SKILL.md for clarity and completeness. - skill-card.md file removed. - No changes to core logic or functionality.","fileCount":11,"zipByteSize":55463},{"version":"0.4.1","createdAt":"2026-08-26T17:25:44.796Z","changelog":"## fix skill v0.4.1 - Emphasized that `/fix` must fully resume and complete the original interrupted deliverable after correcting behavior, not just patch rules and stop. - Updated core description and procedure to clarify the two-phase workflow: Fix (root cause & improvement) βž” Resume (complete original work). - Minor clarifications and editorial enhancements for step breakdown and task management. - Added `scripts/detect-agent-env.sh` script. - Removed `skill-card.md` file.","fileCount":11,"zipByteSize":55168}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17ay1v6v88r2m102pvvc44gz183qcrm:fix","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s17ay1v6v88r2m102pvvc44gz183qcrm:fix` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/drumrobot/fix before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-fix/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-fix/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-fix/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-fix/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-fix/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-fix/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-09T14:53:05.697Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-fix/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-fix/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-fix/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-drumrobot-fix/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T11:39:25.681Z","emptyReason":null},"readme":"Skill: fix\n\nOwner: drumrobot\n\nSummary: User behavior correction skill. Triggered by \"fix:\" prefix feedback (e.g., \"fix: why didn't you commit?\"). Analyzes the mistake, improves the relevant prompt (skill/rule/agent/memory/hook) to prevent recurrence, then fixes the current issue. TodoWrite required for all steps. Use when \"fix:\", \"fix this\", \"correct\", \"why not\", \"why missing\", \"behavior fix\" is mentioned.\n\nTags: latest:0.7.1\n\nVersion history:\n\nv0.7.1 | 2026-10-06T07:55:43.634Z | auto\n\n**Summary:** Minor update with housekeeping and resource script changes.\n\n- Removed unnecessary documentation file: `skill-card.md`.\n- Updated behavior correction script: improved/modified `resources/fix-and-ambiguity-guard.sh`.\n- Updated changelog reference: `CHANGELOG.md` modified for this version.\n\nv0.7.0 | 2026-09-30T14:21:01.403Z | auto\n\nfix v0.7.0\n\n- Updated documentation in CHANGELOG.md and SKILL.md for clearer usage instructions and stronger enforcement notes.\n- Removed outdated documentation file skill-card.md.\n- No functional or behavior logic changes; update is documentation/guide cleanup only.\n\nv0.6.2 | 2026-09-18T15:53:12.226Z | auto\n\nfix v0.6.2\n\n- Removed unnecessary file: skill-card.md\n- Updated documentation in CHANGELOG.md\n- No core functionality changes; maintenance/cleanup release\n\nv0.6.1 | 2026-09-10T05:56:00.582Z | auto\n\nfix 0.6.1\n\n- Updated documentation in SKILL.md and CHANGELOG.md.\n- Removed the obsolete skill-card.md file.\n- No changes to core skill logic; this is a documentation and cleanup release.\n\nv0.6.0 | 2026-09-06T10:31:17.070Z | auto\n\nfix 0.6.0\n\n- Removed obsolete file: skill-card.md\n- Updated CHANGELOG.md to reflect recent changes\n- No changes to core logic or functionality\n\nv0.5.0 | 2026-09-05T16:15:53.641Z | auto\n\nfix 0.5.0\n\n- Updated documentation in SKILL.md and CHANGELOG.md for accuracy and clarity.\n- Removed obsolete file: skill-card.md.\n- No changes to main logic; this is a documentation cleanup and alignment release.\n\nv0.4.2 | 2026-08-30T11:13:19.268Z | auto\n\nfix v0.4.2\n\n- Updated documentation in CHANGELOG.md and SKILL.md for clarity and completeness.\n- skill-card.md file removed.\n- No changes to core logic or functionality.\n\nv0.4.1 | 2026-08-26T17:25:44.796Z | auto\n\n## fix skill v0.4.1\n\n- Emphasized that `/fix` must fully resume and complete the original interrupted deliverable after correcting behavior, not just patch rules and stop.\n- Updated core description and procedure to clarify the two-phase workflow: Fix (root cause & improvement) βž” Resume (complete original work).\n- Minor clarifications and editorial enhancements for step breakdown and task management.\n- Added `scripts/detect-agent-env.sh` script.\n- Removed `skill-card.md` file.\n\nv0.4.0 | 2026-08-21T05:41:00.750Z | auto\n\n## fix v0.4.0\n\n- Refined rule scope logic: `--local` now covers both `.claude/rules/` and `.agents/AGENTS.md`; clearer rules on project/workspace vs global file locations.\n- Explicitly forbids writing to global rules (including `~/.agents/rules/` and `~/.agents/GEMINI.md`) when local mode is set.\n- Clarified documentation on rule file precedence, with improved instructions for local/global separation and sync caveats.\n- Removed outdated `skill-card.md`; updated docs and procedures to match.\n- Documentation and procedural improvements; no user-facing command or interface changes.\n\nv0.3.12 | 2026-08-18T05:41:26.219Z | auto\n\n# fix Skill v0.3.12\n\n- Updated: Improved step2-improvement.md with enhanced detail or corrections.\n- Updated: CHANGELOG.md revised to reflect recent changes.\n- Removed: skill-card.md file deleted to reduce redundancy or obsolete documentation.\n\nv0.3.11 | 2026-08-09T14:11:12.785Z | auto\n\n**Summary:** Minor update adding a dependency and cleaning up docs.\n\n- Added explicit dependency on the `cleanup` skill in SKILL.md.\n- Removed redundant `skill-card.md` file.\n- Documentation updates and maintenance to CHANGELOG.md and SKILL.md; no changes to core behavior.\n\nv0.3.10 | 2026-08-06T09:21:35.968Z | auto\n\n**Version 0.3.10 Changelog**\n\n- Removed: `skill-card.md` file deleted.\n- Updated: `CHANGELOG.md` file modified.\n- No functional or procedural changes to SKILL.md detected.\n\nv0.3.9 | 2026-07-28T23:09:38.883Z | auto\n\nVersion 0.3.9\n\n- Enforced that a /fix invocation MUST register at least 5+ granular TodoWrite steps (not 4 generic tasks); collapsing into 4 steps is now a HARD STOP.\n- Clarified that on chained /fix requests, Resume tasks from incomplete prior fixes must be preserved and included beyond fix-2 (not overwritten).\n- Added strict instruction to present trade-off-axis questions (not just disposition choices) via AskUserQuestion after emitting a plan artifact, especially with --plan or any unresolved review axes.\n- Improved clarity on options for `--plan` and `--local`, and clarified routed behaviors and fallback mechanisms.\n- Updated topics and procedural documentation for consistency and to reflect new behavior on plan approval, question sequencing, and artifact handling.\n- Removed: obsolete skill-card.md.\n\nv0.3.8 | 2026-07-23T13:39:20.154Z | auto\n\nfix v0.3.8\n\n- Added ambiguity guard script: `resources/fix-and-ambiguity-guard.sh`\n- Updated core documentation: `CHANGELOG.md`, `SKILL.md`, and `step3-resume.md`\n- Removed obsolete file: `skill-card.md`\n- General improvements to behavioral guidance and step3 resume detail\n\nv0.3.7 | 2026-07-16T12:29:48.602Z | auto\n\nfix 0.3.7\n\n- Added `--local` option to scope Step 2 rule modifications to workspace- or project-local rules only, preventing accidental global rule updates.\n- Updated Step 2 procedure in SKILL.md to describe local rule location resolution and global fallback prevention.\n- Clarified environment detection requirements before rule or settings modification.\n- Minor documentation updates for configuration file guidance.\n- Removed obsolete `skill-card.md` file.\n\nv0.3.6 | 2026-07-07T19:12:11.762Z | auto\n\n## fix 0.3.6\n\n- Updated step2-improvement.md with new or revised guidance.\n- Updated CHANGELOG.md to reflect recent changes.\n- No core logic or procedural changes introduced in SKILL.md.\n\nv0.3.5 | 2026-07-04T07:20:42.031Z | auto\n\nfix 0.3.5\n\n- Updated CHANGELOG.md and step2-improvement.md with latest procedure and guidance.\n- Removed obsolete skill-card.md for improved clarity and maintenance.\n- No changes to core logic or procedureβ€”documentation-focused update.\n\nv0.3.4 | 2026-07-02T01:40:56.354Z | auto\n\nfix 0.3.4\n\n- Expanded and clarified content in step3-resume.md and step4-wrapup.md for improved guidance.\n- Enhanced and reorganized documentation in SKILL.md; now provides clearer procedures and stricter requirements.\n- CHANGELOG.md updated to reflect recent adjustments.\n- No changes to core logic or interfaces; all updates are documentation and guidance improvements.\n\nv0.3.3 | 2026-06-26T16:24:09.630Z | auto\n\nfix 0.3.3\n\n- Updated documentation in CHANGELOG.md and step2-improvement.md to clarify workflow and enforcement.\n- Removed the outdated skill-card.md file.\n- No functional changes to core logic or behavior.\n\nv0.3.2 | 2026-06-19T23:10:38.894Z | auto\n\nfix v0.3.2\n\n- Updated CHANGELOG.md and step2-improvement.md for more accurate or current guidance.\n- Removed obsolete skill-card.md file to reduce redundancy.\n- No behavioral logic changes to skill execution; documentation improvements only.\n- Ensures procedures and dependencies in fix tasks remain aligned with intended usage.\n\nv0.3.1 | 2026-06-13T10:09:02.207Z | auto\n\nVersion 0.3.1\n\n- Split detailed step guidance into separate topic files for easier maintenance and clarity (`behavior-discipline.md`, `step2-improvement.md`, `step3-resume.md`, `step4-wrapup.md`).\n- Added new topics and a Topics index table in `SKILL.md`, enabling topic-specific invocation and modular documentation.\n- Updated procedure to reference and require reading topic files at each step.\n- Improved instructions for safe TodoWrite usage, including explicit dependency and reference state declarations in tasks.\n- Removed obsolete `skill-card.md` file.\n\nv0.3.0 | 2026-06-03T12:12:52.907Z | auto\n\nVersion 0.3.0 of the \"fix\" skill\n\n- Added CHANGELOG.md and LICENSE files.\n- Removed legacy documentation file: skill-card.md.\n- Improved documentation in SKILL.md for handling TodoWrite task arrays (clarified pseudo-code, added explicit notes on array construction to prevent task loss).\n- No functional/logic changes to the core skill behavior; updates are documentation and licensing/metadata only.\n\nv0.1.5 | 2026-05-17T16:36:19.770Z | user\n\nEnglish documentation + chained /fix protocol + Step 1.5 action plan\n\nv0.1.4 | 2026-04-15T02:41:49.658Z | user\n\nTranslate remaining Korean to English, clarify TODO cleanup requirements\n\nv0.1.3 | 2026-04-13T13:25:42.969Z | user\n\nAdd 5-Why analysis and AskUserQuestion on uncertainty\n\nv0.1.2 | 2026-04-11T13:12:16.398Z | user\n\nAdd AskUserQuestion guidance when unsure what to execute; add metadata block (author, version)\n\nv0.1.1 | 2026-04-03T05:33:09.355Z | user\n\nTranslate SKILL.md to English\n\nv0.1.0 | 2026-04-01T05:00:54.612Z | user\n\nInitial release: analyze mistakes, improve rules/skills/hooks to prevent recurrence\n\nArchive index:\n\nArchive v0.7.1: 11 files, 57755 bytes\n\nFiles: behavior-discipline.md (6448b), CHANGELOG.md (14482b), LICENSE (1063b), resources/fix-and-ambiguity-guard.sh (4416b), scripts/detect-agent-env.sh (2030b), skill-card.md (1783b), SKILL.md (41708b), step2-improvement.md (31142b), step3-resume.md (27909b), step4-wrapup.md (11568b), _meta.json (122b)\n\nFile v0.7.1:SKILL.md\n\n---\nmetadata:\n author: es6kr\n version: \"0.1.6\"\nname: fix\ndepends-on:\n - cleanup\ndescription: |\n User behavior correction skill. Triggered by \"fix:\" prefix feedback (e.g., \"fix: why didn't you commit?\").\n Analyzes the mistake, improves the relevant prompt (skill/rule/agent/memory/hook) to prevent recurrence,\n then fixes the current issue. TodoWrite required for all steps.\n Use when \"fix:\", \"fix this\", \"correct\", \"why not\", \"why missing\", \"behavior fix\" is mentioned.\n---\n\n# Fix: Behavior Correction & Work-Resume Skill\n\nActivated when user gives feedback with \"fix:\" prefix. Finds the root cause of the mistake, improves the relevant prompt (skill/rule/agent/memory/CLAUDE.md/hook), and **seamlessly resumes and completes the interrupted original work (`Fix -> Resume` Complete Workflow)**.\n\n> πŸ’‘ **Core Identity of `/fix`**: `/fix` is NOT a tool that only patches rules and stops. The primary purpose of this skill is the **complete two-phase flow: `Fix (5-Why & Prompt Improvement) βž” Resume (Complete the original interrupted deliverable & hand over to next work)`**. Stopping after rule modification without fully executing and delivering the original work is a fundamental failure of this skill.\n\n\n## Trigger\n\n- Messages with `fix:` prefix\n- Behavior correction feedback: \"fix this\", \"correct\", \"why not\", \"why missing\"\n\n## Options\n\n- `--plan`: In Step 2, instead of modifying prompts directly, **emit only the modification plan** for user review before execution. Use for complex changes or changes spanning multiple files. **Forced Ask (HARD STOP)**: After saving the plan artifact .md and presenting the summary, you MUST invoke `AskUserQuestion` instead of stopping at plain text, forcing an explicit user decision.\n - **Trade-off-axis questions FIRST, disposition LAST (HARD STOP β€” applies to ANY /fix flow that authors or promotes a plan artifact, not only `--plan`)**: a generic disposition-only ask (`Apply plan now` / `Refine plan` / `Hold`) is FORBIDDEN when the plan contains Trade-offs rows or unresolved human-review questions (open interpretation notes, \"confirm on review\" markers). Convert **each** trade-off axis / open review question into its own question object in the `questions` array (one axis per question, max 4 per call β€” chunk sequential calls when more, never drop the tail), then ask the disposition (`Apply plan now` / `Refine plan` / `Hold`) as the **last** question or a follow-up call. Recurrence source: a promote-completion ask that offered only approve/refine/hold caused the user to re-request the trade-off review manually.\n- `--local`: Scope Step 2 rule modifications to the **workspace-local** or **project-local** rule directory only. Use when the rule applies to a specific workspace (e.g., `~/ghq/github.com//`) or a specific repo, not globally.\n - Resolution order (Step 2 picks the innermost matching location):\n 1. **Project-local** β€” `/.claude/rules/` or `/.agents/AGENTS.md` if cwd is inside a git repo\n 2. **Workspace-local** β€” nearest `.claude/rules/` or `/.agents/AGENTS.md` walking up from cwd\n 3. **Fallback** β€” if neither exists, ask the user whether to create one (do NOT silently fall through to global `~/.agents/rules/` or global `~/.agents/GEMINI.md`)\n - **Do not** write to `~/.agents/rules/` or `~/.agents/GEMINI.md` (and its symlinks like `~/.gemini/GEMINI.md`) when `--local` is set. Global rule files are synced across devices via chezmoi/Syncthing; `--local` opts into workspace/project-scoped protection only.\n - Rule-file location + strength still respect the `rule-management.md` location-plus-method dual-axis ask when the scope choice within the local set is ambiguous (project vs workspace).\n\n## Topic Dispatch\n\n**When this skill is invoked with a topic specifier (e.g., `/fix step3-resume` or `Skill(\"fix\", \"step3-resume\")`), load and follow only the matching topic file. Do not echo the Topics table or summarize other topics in the response.** The Topics table below is an index β€” for a normal `/fix` invocation, execute the Procedure below and Read each step's topic file when you reach that step.\n\n## Topics\n\nThe core procedure (Step 0 β†’ 4) lives below. Heavy step detail is split into topic files β€” **Read the matching topic before executing that step**.\n\n| Topic | Description | Guide |\n|-------|-------------|-------|\n| step2-improvement | Step 2 detail: 4-filter gate, escalation matrix, `--plan`, Checkpoint | [step2-improvement.md](./step2-improvement.md) |\n| step3-resume | Step 3 detail: intent inference, reject re-call, verification guard | [step3-resume.md](./step3-resume.md) |\n| step4-wrapup | Step 4 detail: report format, medium separation, status-based prune | [step4-wrapup.md](./step4-wrapup.md) |\n| behavior-discipline | Destructive-command gate, multi-repo tracking, chained-fix deps, angerβ†’TDD switch | [behavior-discipline.md](./behavior-discipline.md) |\n\n## Procedure\n\n### Step 0. TodoWrite (MANDATORY β€” first action, no exceptions)\n\n**Before any analysis or text output**, register TODO items.\n\n**⚠️ CRITICAL β€” Do not delete prior fix tasks on chained /fix (HARD STOP)**:\n\nWhen a new /fix arrives while a prior /fix's tasks are still pending/in_progress:\n- **Do not delete** prior fix tasks β€” incomplete work (especially Resume) is lost\n- **Insert 4 new fix tasks via TaskCreate**\n- Include the prior fix's incomplete work in the new fix's Resume step (fix-5+ β€” not `fix-2`, which is the canonical plugin-install sub-item; see the \"fix-2\" naming note near line 125)\n\n**⚠️ CRITICAL β€” Preserve existing tasks when TaskCreate is unavailable (HARD STOP)**:\n\nIn sessions where TaskCreate is disconnected/unavailable, only TodoWrite is usable. **TodoWrite takes an array and overwrites the entire todo list on every call** β€” registering only 4 fix-* items will **wipe all existing todos**.\n\n**Self-check immediately before calling**:\n1. How many existing tasks (N) are registered in TodoWrite? (Confirm from prior call result or context)\n2. Did you **include all N existing tasks in this call's array**?\n3. Did you **append** the 4 fix-0/1/2/3 items after the existing N?\n\n**Correct pattern** (pseudo-code; `...existing_8_tasks` is a placeholder for the actual array of existing tasks read from the prior TodoWrite/TaskList output β€” substitute the real entries verbatim):\n\n```text\n# If 8 existing tasks exist, call with a 12-item array adding fix-* 4\nTodoWrite([\n ...existing_8_tasks, # ← replace with the actual 8 existing task objects, not a literal spread\n { content: \"πŸ” fix: {summary} β€” root cause analysis\", status: \"in_progress\" },\n { content: \"πŸ”§ Root cause fix\", status: \"pending\" },\n { content: \"πŸ”„ Resume original work: {one-line summary of original work}\", status: \"pending\" },\n { content: \"πŸ“‹ Wrap-up: report + task pruning\", status: \"pending\" },\n])\n```\n\n**Forbidden pattern** (data loss):\n```text\n# Ignoring existing tasks and registering only 4 fix-* β†’ all existing tasks vanish\nTodoWrite([\n { content: \"πŸ” fix: ...\", status: \"in_progress\" },\n { content: \"πŸ”§ Root cause fix\", status: \"pending\" },\n { content: \"πŸ”„ Resume original work: ...\", status: \"pending\" },\n { content: \"πŸ“‹ Wrap-up: report + task pruning\", status: \"pending\" },\n]) # ❌ Existing task data is lost\n```\n\n**Default form (when no existing tasks β€” MINIMUM 5+ GRANULAR STEPS HARD STOP)**:\n\nEvery `/fix` task registration MUST contain at least 5+ (typically 6~8) granular steps. Collapsing the workflow or Resume phase into 4 or fewer generic items is strictly forbidden (`HARD STOP`).\n\n```text\nTodoWrite([\n { id: \"fix-0\", content: \"πŸ” fix: {user feedback summary} β€” 5-Why root cause analysis\", status: \"in_progress\" },\n { id: \"fix-1\", content: \"πŸ”§ Prompt improvement plan (Step 1.5 Action Plan table & AskUserQuestion approval)\", status: \"pending\" },\n { id: \"fix-2\", content: \"πŸ”Œ Plugin/Dependency installation (if required) & environment parity check\", status: \"pending\" },\n { id: \"fix-3\", content: \"πŸ› οΈ Skill/Tool invocation & official autoloader execution (view_file IsSkillFile)\", status: \"pending\" },\n { id: \"fix-4\", content: \"πŸ§ͺ Empirical Fix Verification (verify fix actually works in current execution)\", status: \"pending\" },\n { id: \"fix-5\", content: \"πŸ”„ Resume original work: {granular breakdown step 1}\", status: \"pending\" },\n { id: \"fix-6\", content: \"πŸ”„ Resume original work: {granular breakdown step 2}\", status: \"pending\" },\n { id: \"fix-7\", content: \"πŸ“‹ Wrap-up & AskUserQuestion next options\", status: \"pending\" },\n])\n```\n\n- **Antigravity (Gemini) Users**: Create or update the `task.md` artifact representing the TODO list above. This fulfills the TodoWrite requirement.\n- **`task.md` is Antigravity-only (HARD STOP)**: a Claude Code session must NEVER edit the workspace `.agents/task.md` β€” it is the Antigravity harness's task artifact, and writing another harness's session state into it mixes two sessions' tracking in one file (FA class `claude-code-session-checklist-in-agents-task-md`). Two distinct Claude Code media exist and must not be conflated: **durable fix-task tracking** = the `claude-task` CLI fallback below (never scratchpad); **ad-hoc session progress checklists** (non-fix, session-scoped) = a file under the session scratchpad directory.\n- **Claude Code with `TaskCreate`/`TodoWrite` unavailable (HARD STOP β€” mechanical gate, not advisory)**: `ToolSearch` returning no match is NEVER sufficient diagnosis on its own β€” it cannot distinguish \"temporarily disconnected\" from \"disabled in this context\". **This gate blocks Step 0 completion**: before falling back to the CLI medium below, you MUST actually execute a direct `TaskCreate` call (not merely `ToolSearch` it) at least once per session, and again at the start of any `/fix` call after a prior direct call returned a disconnect-class error (connectivity can change mid-session). A `ToolSearch`-only check does NOT satisfy this gate β€” the gate requires the call attempt itself, because only the call's error message distinguishes the two cases below.\n - Error mentions disconnect/MCP-unreachable β†’ treat as recoverable β€” retry at the start of each subsequent `/fix` call in this session\n - Error is **\"exists but is not enabled in this context\"** β†’ this is a context/settings gap, not connectivity. **Report this to the user in the same turn, in plain text, before or alongside the fix-continuation work** β€” do not silently normalize the workaround as if no explanation were owed. State it plainly: \"`TaskCreate` exists but is disabled in this session's context β€” this may be fixable in Claude Code settings.\" Silently working around it for an entire session without ever surfacing this is itself a Step 0 violation.\n - Only after this diagnosis, if no task tool is usable this turn, use the `claude-task` CLI (`todowrite` skill's `claude-task` topic β€” `claude-task --env agent add/list/update`) to track fix-0/1/2/3, updating status at every step transition. This CLI persists to `~/.agents/tasks/default/`, a fixed directory that survives session/scratchpad-path changes β€” **do NOT use the session scratchpad directory** for this tracking; the scratchpad path changes across sessions/compacts and silently drops its contents (case history: failed-attempts.md \"scratchpad ephemeral task loss\"). Narrating steps in prose only, with no durable record, does not satisfy the \"register tasks\" requirement β€” `claude-task` is an interim substitute, not a replacement goal, for `TaskCreate`.\n - **Self-check (before relying on the `claude-task` fallback in any `/fix` call this session)**: (1) Have I made an actual `TaskCreate` call attempt this session (not just `ToolSearch`)? β†’ If no, make one now. (2) Did that call's error say \"not enabled in this context\"? β†’ If yes, have I told the user this in plain text yet this session? β†’ If no, say so now, in this turn. (3) Am I about to write fix-tracking state to the scratchpad directory instead of `claude-task`? β†’ Forbidden β€” scratchpad is session-scoped and ephemeral, not a durable-tracking medium.\n\n- In Resume tasks (`fix-5+`), list **the initial request plus everything in progress including the immediately preceding action**.\n - **Multi-substep Resume Breakdown (MINIMUM 5+ STEPS HARD STOP)**: When resuming multi-stage or complex work, **break Resume down into explicit substeps (`fix-5`, `fix-6`, `fix-7`, etc.)** instead of flattening it into a single line. This ensures sequential execution proceeds through all remaining phases without dropping intermediate actions (such as plugin install, skill call, code edit, empirical verification, or post-plan decisions).\n - Example: `fix-2: Plugin install`, `fix-3: Skill invocation`, `fix-4: Empirical fix verification`, `fix-5: Code implementation`, `fix-6: Verification & Walkthrough`\n- **Multi-question `questions` Array Rule (HARD STOP)**: When invoking `AskUserQuestion` to address multiple decision axes or questions, **NEVER lump them into a single question object with compound text**. Build an array of discrete question objects in `questions: [{question: Q1, options: [...]}, {question: Q2, options: [...]}]` (one question per decision axis, up to 4 questions per call).\n- **[Measure 2] Dependency and Reference State Declaration (MANDATORY)**: When registering `fix-2`, you must explicitly declare the **preconditions (Depends on)** and the **base commit state (Reference commit)** required for the `Resume` task to run safely.\n - *Format Example*: `πŸ”„ Resume original work: {summary} (Depends on: {preconditions}, Reference commit: {commit_sha})`\n- **Naming note (HARD STOP β€” do not reuse `fix-2` for this)**: the Resume step as a whole (fix-5+, Step 3 below) = \"Complete the original work with the revised approach\" β€” the goal is **the deliverable the user originally requested**, not skill/rule changes themselves. `fix-2` is reserved exclusively for the canonical Plugin/Dependency-install sub-item (line 103 above) β€” never use it as shorthand for \"the Resume step\"\n- Step 0 is **the first tool call** after /fix activation. Text output before TodoWrite = violation.\n\n### 1. Root Cause Analysis (5-Why depth)\n\n**Environment Detection (MANDATORY)**: Before modifying any rules or settings file, detect the current platform via runtime environment variables:\n- **macOS**: Check `$__CFBundleIdentifier` β€” `com.google.antigravity` = Antigravity, `com.microsoft.VSCode` = VS Code, `com.todesktop.230313mzl4w4u92` = Cursor\n- **Windows**: Check `$env:ANTIGRAVITY_AGENT` β€” `1` = Antigravity. Also `$env:ANTIGRAVITY_EDITOR_APP_ROOT` for confirmation.\n\nRouting table by detected environment:\n- **Antigravity (Gemini)**:\n - Permissions config: Guide user to edit `~/.gemini/config/config.json`. Do not edit it directly.\n - Behavioral rules (Global): Edit `~/.gemini/GEMINI.md` (points to `~/.agents/GEMINI.md`, synced via chezmoi/Syncthing).\n - Behavioral rules (`--local`): Edit nearest `/.agents/AGENTS.md` or `/.agents/AGENTS.md`. NEVER touch `~/.agents/GEMINI.md` or `~/.agents/rules/` when `--local` is active.\n- **Claude Code** (neither Antigravity env var is set):\n - Permissions config: Edit `~/.claude/settings.json`.\n - Behavioral rules (Global): Edit `CLAUDE.md` or `~/.agents/rules/`.\n - Behavioral rules (`--local`): Edit `/.claude/rules/` or `/.claude/rules/`.\n\nDo NOT use file-existence checks to detect the environment β€” both `.gemini/` and `.claude/` coexist on the same machine.\n\n**No trivial exception (HARD STOP)**: Even when the symptom is fixable with a 1-line change, 5-Why analysis and the entire step-by-step procedure are mandatory. Bypassing or skipping any steps (Step 0 to Step 4) when `/fix` is triggered is strictly forbidden. Even for \"simple typos / encoding issues / minor file copies\", the procedure must be executed step-by-step.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Skip `/fix` step-by-step procedure when the correction seems simple or obvious | Always execute Step 0 (`TaskCreate`/`TodoWrite`, or `task.md` for Antigravity) first, followed sequentially by Step 1 (5-Why), Step 1.5, Step 2, Step 3, and Step 4 |\n| 2 | Directly modify files or execute commands on a `/fix` trigger before initializing the task checklist | Ensure the environment-appropriate checklist medium (`TaskCreate`/`TodoWrite` for Claude Code, `task.md` for Antigravity) is initialized as the very first tool call in the turn |\n| 3 | Treat `TaskCreate`/`TodoWrite` as the only Claude Code fallback in this summary table | When both are disabled this turn, use the `claude-task` CLI (see Step 0's \"Claude Code with `TaskCreate`/`TodoWrite` unavailable\" detail above) for durable multi-session tracking β€” never the session scratchpad directory, which is session-scoped and silently drops its contents across a session/compact boundary |\n\n**Zero-content abusive invocation exception (HARD STOP)**: the \"no trivial exception\" rule above assumes the `/fix` arguments contain *some* identifiable behavior-correction content, however terse. When the arguments are **pure abuse with zero identifiable target** (e.g. a single insult with no instruction, no described mistake, no reference to prior turns), the full Step 0-4 procedure does not apply β€” there is nothing to run 5-Why analysis against. In this case: do not fabricate a target by guessing, and do not run TodoWrite/5-Why against an empty premise. Instead, briefly name the pattern (repeated content-free abusive messages) and set a boundary β€” invoke `AskUserQuestion` or plain text asking what specifically should be corrected, if the pattern is a first occurrence in the conversation. If abusive messages continue to recur with no content across multiple turns despite this, that is a candidate for `EndConversation` per its own tool guidance (sustained abuse, explicit prior warning required) β€” this exception does not itself authorize ending the conversation. The moment any subsequent `/fix` invocation in the same conversation contains identifiable content (even mixed with continued abusive language), the full Step 0-4 procedure resumes as normal β€” this exception is scoped to content-free invocations only, not to the presence of any abusive language.\n\n**Recurrence pre-check (first step of Step 1) β€” MANDATORY 2-stage**:\n\n**Stage 0 β€” RAG semantic search (if RAG receiver available)**:\n- If the current environment has a registered RAG search tool (an MCP store with a find-style tool), call it with the fix pattern's core keywords **before** the grep step\n- Semantic search catches paraphrased recurrences that exact-match grep misses (one pattern surfaces under different wordings)\n- If RAG returns one or more archived/historical hits with similar semantic, classify as \"Nth recurrence\" even if the exact phrasing does not grep-match\n- Receiver tool name is vendor-agnostic β€” `mcp____*-find` style. Caller picks whichever RAG store is registered in the current environment\n\n**Stage 1 β€” exact-match grep (always run)**:\n1. `Grep -r \"${FA_DATA_DIR:-$HOME/.claude/skills/cleanup/data}\"` for prior records of the same pattern (the FA store is relocatable β€” see [`fa/SKILL.md`](../fa/SKILL.md) \"FA data store\"; a literal path here misses HOT and archive whenever `FA_DATA_DIR` is set) β€” **recursive search covers both HOT (`failed-attempts.md`) and archive (`archive/*.md`)**. Also grep `~/.agents/rules/*.md`.\n - `failed-attempts.md` grows unbounded (10K+ lines in an active install) and a single blocking grep pass over it can be slow or, occasionally, fail outright with no partial result. Prefer `node /scripts/stream-search-fa.js [--dir ]` β€” it streams matches line-by-line as they're found instead of waiting for one full-file pass, so a slow or interrupted run still surfaces whatever it already matched. Plain `Grep -r` remains an acceptable fallback when the script is unavailable.\n2. **Current-workspace tracker grep (HARD STOP)** β€” resolve the active workspace's checklist path via `bash /resources/workspace-config.sh --export` (reads the workspace-bindings config; exposes `WSCFG_CHECKLIST_PATH` etc.), then grep that resolved file for the pattern's core keywords too. A recurring infra symptom (host name / service name / error code) can already have its root cause and a decided fix recorded there even when neither the recurrence log nor RAG has it β€” a workspace tracker's active/incomplete items are never RAG-indexed (only fully-completed entries sync to the receiver), so this grep is the only path that catches them. Skip only when the resolver reports no checklist configured for this workspace.\n3. If found in **HOT or the workspace tracker** β†’ classify as \"Nth recurrence\" β†’ include in Why analysis \"why prior fixes were ineffective\" (for a workspace-tracker hit that already names a decided fix, treat executing that fix β€” not re-diagnosing from scratch β€” as the default next action)\n4. If found in **archive only** β†’ **invoke `Skill(\"fa\", \"fa-prune\")` Step 7 restoration procedure** (cut section from archive β†’ paste into HOT with recurrence label). Without restoration, the escalation rule (1st=rule / 2nd=hook review / 3rd=hook required) is silently invalidated.\n5. If found in **both** archive and HOT β†’ already in HOT (no restoration needed); just add recurrence note\n6. If the rule already exists but wasn't followed β†’ **do not stop at \"existing rule not followed\"; strengthen the rule** β€” rewrite rule text to be more specific/explicit, or design an enforcement mechanism (hook, PreToolUse guard). \"Existing rule wasn't followed\" is not a conclusion; the goal is **to analyze why it wasn't followed and make it followable**\n\n**Why RAG + grep both (not RAG alone)**:\n- RAG: semantic β€” catches paraphrased recurrences, misses exact-token rules\n- grep: exact β€” catches rule violations, misses semantic recurrences\n- Both required for full coverage. RAG-only = misses \"existing rule wasn't followed\" detections. grep-only = misses \"Nth recurrence with different phrasing\" detections\n\n**Confirm existing rule coverage (CRITICAL β€” do not duplicate rules in fix.md)**:\n\nThe following general principles apply before entering the fix procedure. If your environment already enforces them as always-on rules, do not duplicate them into fix's own body β€” that creates location errors and duplication:\n\n- **Forbid arbitrary action on unclear instructions** β€” when user instructions/statements admit multiple interpretations, AskUserQuestion is required (do not act on a guess)\n- **Cross-verify state from multiple sources** β€” do not conclude from a single statement/output; verify at least 2 sources\n- **Don't guess existing code's purpose/behavior β€” read it** β€” verify against primary sources (code, API, files)\n- **Glob/Grep before claiming absence/necessity** β€” claims of \"doesn't exist / is needed\" must follow code verification\n- **Skill language = SKILL.md frontmatter `description` language** β€” before any Step 2 Edit/Write to a skill file (SKILL.md, topic .md, resources), check that file's `description` language (`head -5 ` or `Grep \"^description:\"`) and write in that same language. Fix is the highest-frequency skill editor in this environment, so this check is easy to skip when the conversation itself is in a different language than the target skill β€” do not carry the conversation's language into the Edit\n\n**If Why analysis identifies the above rules as root cause, the rules themselves do not need to be modified** β€” go deeper with Why 4-5 to ask \"why was that rule ignored in the fix flow?\". If the answer is \"fix procedure forces a reactive flow\" or \"existing rules aren't applied automatically\", do not trap the rule inside the fix skill β€” record it as a recurrence in failed-attempts.md (next candidate for hook automation).\n\nDon't stop at the direct cause. Dig **5 levels deep** to bridge cause analysis directly into Resume execution:\n\n```\nWhy 1 (Symptom): What went wrong? (the immediate mistake)\nWhy 2 (Judgment): Why did I make that decision? (missing knowledge / flawed assumption)\nWhy 3 (Structural): What rule/prompt must be fixed to prevent recurrence? (target skill/rule/hook)\nWhy 4 (Interrupted Work): What was the original user request / deliverable that was interrupted by this failure?\nWhy 5 (Next Resume Action): What concrete actions must be executed NEXT to completely finish and deliver that original work?\n```\n\n- Why 1~3 identify **what to fix in prompts/rules/skills**.\n- Why 4~5 identify **what to do next to resume and finish the original deliverable**.\n- Search for the responsible **skill/rule/hook** files (Grep/Glob)\n\n**Why 4 scope (HARD STOP β€” scan ALL open threads, not just the most recent interruption)**: \"the original user request... interrupted by this failure\" reads as singular and invites answering with only the interruption immediately preceding this `/fix`/`/fa` call. That is a category error β€” invoking `/fix` or `/fa` is itself the mechanism for resuming interrupted work, so the act of calling either skill must never be treated as a topic change that excuses leaving an earlier thread unresolved. Before writing Why 4, re-scan the whole session (not just the last few turns) for other still-open threads: a bare text-question a Stop hook flagged but that was never re-asked via `AskUserQuestion`, an `AskUserQuestion` the user rejected whose reject cause was never revisited, a recommendation that ended in an implicit \"proceed now or later?\" with no follow-up, or any deliverable the user asked for that never got a completion signal. If more than one such thread exists, Why 4 must enumerate all of them (not just the most recent), and Why 5's Resume actions must cover each one β€” not only the thread that triggered this particular `/fix`/`/fa` call.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Write Why 4 as \"the task right before this /fix call was interrupted\" and stop there | Scan the full session transcript for every still-open thread, list all of them in Why 4 |\n| 2 | Treat \"the user moved to a different topic\" as an explanation for why an earlier thread got dropped | `/fix`/`/fa` calls are resume mechanisms, not topic changes β€” their invocation never excuses leaving prior threads unresolved |\n| 3 | Resume (Step 3) only the thread that prompted this call | Resume (or explicitly re-ask) every thread enumerated in Why 4, not only the newest one |\n\n**Completion gate β€” do NOT proceed to Step 1.5 until ALL of these are true:**\n1. Each issue has **Why 1, Why 2, Why 3, Why 4, Why 5** written out explicitly β€” stopping at Why 3 fails the gate. Why 1~3 define the root cause & prompt fix, and Why 4~5 define the exact original work and the immediate next resume actions.\n2. Why 3 identifies a **specific target** (skill, rule, hook, agent prompt, project config, etc.) to fix.\n3. Why 5 identifies the **concrete sequence of actions** to be executed in Step 3 Resume.\n4. No AskUserQuestion or implementation actions during Step 1 β€” analysis only.\n\n\n### 1.5. Action plan per Why (MANDATORY β€” required before entering Step 2)\n\n**This table MUST be physically emitted in your visible output before any Step 2 Edit/Write.** Knowing the targets mentally from the Why analysis is NOT a substitute β€” the table is the forcing function that surfaces \"one Why β†’ multiple fix spots\". Skipping the emission silently leads to partial corrections (you fix the one spot you remember and miss the others).\n\n**Iterate over all Whys and explicitly enumerate the action for each.** All entries in this list must be executed in Step 2 before Step 3 can proceed.\n\n```text\n| Why | Target file : spot | Action |\n|-----|--------------------|--------|\n| Why 1 | (current issue β€” symptom) | Root cause understanding |\n| Why 2 | : judgment section | Add judgment rule |\n| Why 3 | : procedure/gate | Add structural gate & prompt fix |\n| Why 4 | (interrupted original work) | Identify original deliverable scope |\n| Why 5 | (target deliverable/tool) | Step 3 Resume: execute concrete next actions to finish original work |\n```\n\n**Multi-spot enumeration & Resume linkage rule (HARD STOP)**: A single Why often maps to multiple spots. Enumerate one row per spot. **Why 4~5 MUST produce explicit action rows detailing the concrete Step 3 Resume actions** (e.g. running scripts, completing report tables, issuing final Ask/Next). Omitting Resume action rows from the Action Plan table is strictly forbidden.\n\n**Action types**:\n- Edit/Write β†’ execute in Step 2\n- failed-attempts.md recording β†’ execute in Step 2 (mandatory on recurrence)\n- hook design/creation β†’ execute in Step 2 (when escalation applies)\n- Step 3 Resume β†’ execute in Step 3\n\n**Gate into Step 2 (HARD STOP β€” symmetric with the Completion gate into Step 1.5)**: do NOT perform any Step 2 Edit/Write until the table above is emitted in your visible output. The Completion gate already blocks entry *into* 1.5; this gate blocks exit *from* 1.5 into Step 2. Without it, a Step 1 β†’ Step 2 fast-path skips the table.\n\n**Step 2 Checkpoint verifies that every row in this table is completed.**\n\n### 2. Prompt Improvement (Prevent Recurrence) β€” never skip\n\nIf Step 1 produced even one Why, Step 2 is **mandatory**. Default medium = `feedback` memory (1st-2nd recurrence); rule-file Edit only when the **4-filter gate** passes (3rd+ recurrence); hook implementation at 4th+ recurrence with a deterministic pattern. Minimize always-on rule context.\n\n**Language gate (HARD STOP β€” mechanical, run before every skill-file Edit/Write in this step, not just once per fix call)**: this rule has already recurred more than once (search failed-attempts.md for the \"skill language mismatch\" pattern) precisely because it lived only as prose in the \"Confirm existing rule coverage\" bullet list in Step 1 β€” easy to read and still skip under conversation-language momentum. Before each individual Edit/Write to a skill file (`SKILL.md`, topic `.md`, `resources/*`) in this step: (1) run `head -5 ` or `Grep \"^description:\"` on the skill's `SKILL.md` to get its language, (2) write the new content in that language β€” if the skill is English-described and the content you're about to add contains locale-specific illustration, abstract it (describe the concept, don't insert literal non-English vocabulary) rather than translate-then-insert. This check runs **per file**, not once β€” a fix touching 3 skill files needs 3 checks, since they can differ in language. `~/.claude/skills/hook-kit/resources/block-skill-language-mismatch.sh` (PreToolUse:Edit/Write) is a backstop, not a substitute for this check β€” do not rely on the hook catching it after the fact.\n\n**Skill-First Improvement Discipline (HARD STOP)**: When the root cause originates from a skill procedure, topic output gap, or template defect, modifying the skill file itself (`skills//SKILL.md` or `topics/*.md`) is MANDATORY. Do NOT default to adding rules exclusively into global `GEMINI.md` or `CLAUDE.md`. Global rule files are reserved for universal behavioral constraints (3rd+ recurrence); skill procedure defects must be resolved directly within the target skill.\n\n**Rule/Skill Fix Execution Rule (HARD STOP)**: When a `/fix` task updates a skill/rule file that specifies a mandatory tool or skill call (such as `receiving-code-review`), simply editing the file text is incomplete β€” executing the mandated skill protocol on the active target codebase or artifact is MANDATORY before declaring the task completed.\n\n**Prompt Improvement Plan AskUserQuestion Gate (HARD STOP)**: Before applying file edits to any skill file (`skills/**/*.md`) or rule file (`rules/**/*.md`), **you MUST emit the Step 1.5 Action-plan table and call `AskUserQuestion` presenting the proposed prompt modifications for user confirmation**. Modifying prompt/skill/rule files without first presenting the modification plan via `AskUserQuestion` is strictly forbidden.\n\n**Read [step2-improvement.md](./step2-improvement.md) before executing** β€” it holds the 4-filter gate, medium-priority table, escalation matrix, no-stage-skipping Don't/Do, `--plan` mode, and the Step 2 Checkpoint (verify every Why-level target from the Step 1.5 table was actually modified). Do not advance to Step 3 until the Checkpoint passes.\n\n### 2.5 Plugin/Dependency Installation Step (MANDATORY HARD STOP β€” confirmation-gated)\n\nIf the updated or referenced skill/rule specifies a plugin or dependency (e.g. `superpowers` plugin `obra/superpowers`, `cc-plugin`, or external tools) that is not already installed, **first check whether it is already present** (e.g. `claude plugin list` / equivalent) β€” if already installed, this step is a no-op, proceed. If not installed: installing a plugin/dependency executes code from an external source, so it needs explicit user approval before running β€” **call `AskUserQuestion` presenting the exact install command** (e.g. `claude plugin add `) and only execute it once the user approves. Skipping plugin installation entirely (running neither the presence check nor, once approved, the install) and proceeding straight to doc edits or resume is still strictly forbidden (`HARD STOP`) β€” the gate added here is the confirmation step, not a license to skip installation.\n\n### 2.6 Skill/Tool Invocation Step (MANDATORY HARD STOP)\n\nIf the updated or referenced skill/rule mandates a skill or tool call (e.g. `receiving-code-review`, `code-review`, `AskUserQuestion`), **you MUST execute the tool call / autoloader invocation (`view_file` on SKILL.md with `IsSkillFile: true` or native tool execution)** in this step. Updating doc text without physically triggering the tool/skill invocation is strictly forbidden (`HARD STOP`).\n\n### 2.7 Empirical Fix Verification Step (MANDATORY HARD STOP)\n\nBefore moving to Step 3 Resume, **you MUST run concrete, empirical verification** demonstrating that the fix implemented in Step 2 actually works in the active session and codebase (e.g., verifying task checklist step creation, running tests, or verifying command exit codes). Relying on text edits alone without empirical verification is strictly forbidden (`HARD STOP`).\n\n### 2.8 Active Task Completion & Ask Priority Gate (HARD STOP)\n\nCompleting active tasks in the session's checklist medium (`TaskList`/`TodoWrite` for Claude Code, `task.md` for Antigravity) is the #1 top priority over invoking the `next` skill or proposing next-step options.\n- If an active task has open questions, trade-offs, or requires user confirmation/decision, presenting `AskUserQuestion` for that active task is MANDATORY as the very first action of the turn.\n- Invoking `next` skill or offering next-action suggestions while tasks are pending/in_progress or open asks remain is strictly forbidden (`HARD STOP`).\n\n### 3. Resume Original Work\n\n**The most important step.** Complete the user's original request β€” not just the fix. Infer user intent and pin the verification medium verbatim; re-call any rejected AskUserQuestion once its reject cause is resolved; resume existing in_progress tasks; reproduce verification through the exact user-reported medium (no detour).\n\n**When the resumed step is itself a skill/tool call** (e.g., an un-invoked `next` / consolidate / ask), it becomes its **own terminal task** and the actual call MUST run **this turn** before wrap-up β€” reporting \"it should now be called\" and stopping is the exact Antigravity drift the guard exists for. See step3-resume.md \"Skill/tool-invocation resume is a first-class task\".\n\n**Read [step3-resume.md](./step3-resume.md) before executing** β€” it holds intent inference, missing-question identification, dismissal-signal handling, reject-cause classification + secondary-issue default, the verification-scope-reduction guard, the Step 3 mandatory self-questions (PR Test Plan sync, architectural-finding record), and the skill/tool-invocation resume rule (same-turn call, an unchecked box in the session's checklist medium blocks wrap-up).\n\n### 4. Wrap-up (Report + Task Pruning)\n\nReport the fix (πŸ” root cause / πŸ”§ improvement / πŸ”„ current fix / πŸ“‹ wrap-up), separate outstanding work by medium (actionable β†’ TaskList, BLOCKED β†’ fix_plan.md hold section), then status-prune **all** completed tasks created this session (fix-* + original work), preserving pending/in_progress.\n\n**Read [step4-wrapup.md](./step4-wrapup.md) before executing** β€” it holds the chained-Resume integration gate, the report format + emoji mapping, the medium-separation principle, the status-based prune matrix, and the per-step self-checks.\n\n## Anti-patterns\n\n- Calling the full /fix procedure just to log a 1st/2nd-occurrence mistake β€” use `/fa` (the\n `fa` skill) for a record-only entry that reports the escalation stage without Step 0-4\n- Repeating \"already fixed\" without actually fixing the root cause\n- Patching only the current issue without improving prompts (skill/rule/agent/memory/CLAUDE.md/hook)\n- Text response without TodoWrite after /fix activation\n- Recording in failed-attempts.md when the root cause is a skill defect (skill fix is 1st priority)\n- **Stopping at Why 1** β€” fixing the symptom without asking Why 2-3 (structural cause)\n- **Not cleaning up TODO/Task after completion** β€” must delete all fix TODOs when done\n- **\"User is right, so skip\"** β€” even when the user's point is correct, Steps 0~4 must all execute. fix's value is not resolving the current issue but preventing recurrence. \"You're right, executing right away\" abandons Why analysis + rule modifications\n- **\"Fixing right now\" / \"I know the cause, skip\"** β€” Step 1 Why analysis cannot be skipped, whether recurrence or trivial. Recurrence = evidence that prior fix's Why was insufficient, so go **deeper**. \"Fix right now\" is not a procedure that exists in the fix skill\n- **Half-baked / rushed fix (HARD STOP)** β€” Skipping steps, rushing to text response, or patching surface symptoms without rigorous 5-Why, prompt improvement, and real verification. Every /fix call must be executed with identical rigor and completeness.\n- **Resume scope narrowing via auto-Reject classification** β€” When Resume produces an AskUserQuestion for option design, **all findings (Accept + Reject + Defer)** must appear as user-decidable options. Auto-Reject classification (`superpowers:receiving-code-review` \"Push back when wrong\" procedure) followed by excluding the Reject finding from options strips the user's override authority. The user typically phrases this as \"fix them all together β€” why only X separately?\". See consolidate/next.md \"Reject finding option mandate\" for the required option pattern (Accept-applied / Apply-ALL-override / Defer-all)\n- **Option outcome must be pre-verified for path-based or cross-cutting tooling** β€” When AskUserQuestion options change a tool's behavior whose outcome depends on **path-based** or **commit-history** analysis (release-please, semantic-release, changesets, dependabot config, CI matrix rules, etc.), the option author must **dry-run / simulate / enumerate the outcome** before presenting options to the user. The user's authority is \"decide between simulated outcomes,\" not \"pick the option label and discover the real outcome only after merge.\" If options A and B both produce the same real-world outcome (e.g., still bumps every package because a cross-cutting `feat(...)` commit touches every package's path), state that fact in the option descriptions or merge the options. Failing this verification means the user invests effort in choosing an option that does not change the eventual result, then has to fix it after seeing the unchanged outcome. Specifically for release-please: enumerate `git log ..HEAD -- skills//` for every package before committing to a `last-release-sha` choice β€” if any cross-cutting `feat(...)` commit (e.g., monorepo-wide annotation, config bump touching every package) sits in that window, the chosen base will not block bumps.\n- **Pre-verify extends to architecture recommendations and tool-behavior explanations** β€” the \"verify against primary sources before asserting\" principle (Step 1's cross-verify / read-don't-guess / Glob-Grep-before-claiming) is not limited to bug diagnosis. Do not present an architecture recommendation or an explanation of how a tool behaves before checking the primary source (docs, config, the tool's actual output). Presenting a recommendation and then repeatedly retracting it as verification catches up is the exact pattern this bans β€” verify first, recommend once.\n- **Modifying files without environment detection**: Editing settings or rules files without detecting the active execution environment (e.g. editing Claude Code settings while under Antigravity, or editing shared `~/.agents/rules` workspace rules for out-of-scope/unrelated domains).\n- **Missing Test Implementation & Verification (HARD STOP)**: Modifying rules or tools without writing or running executable test cases (unit tests, hook test scripts, or assertion suites) to empirically verify that the fix works and prevents recurrence. Text edits alone without test execution do not satisfy `/fix` completion.\n- **Guessing Ambiguous Intent Prohibited (HARD STOP)**: When a `/fix` trigger or user feedback is short, ambiguous, or underspecified (e.g. \"missing\", \"not that\", \"why missing\"), **guessing the target task or taking arbitrary execution action is STRICTLY FORBIDDEN**. You MUST invoke `AskUserQuestion` presenting explicit candidate options to clarify the exact target requirement before taking action.\n\nFile v0.7.1:_meta.json\n\n{\n \"ownerId\": \"kn74k8yfvftx6f062qa8fzyd8h8373jd\",\n \"slug\": \"fix\",\n \"version\": \"0.7.1\",\n \"publishedAt\": 1791273343634\n}\n\nFile v0.7.1:behavior-discipline.md\n\n# Behavior Discipline β€” destructive commands / multi-repo tracking / chained fix / angerβ†’TDD switch\n\nThis topic bundles the behavior-discipline rules that fire during the fix flow.\n\n## Destructive-command restraint (HARD STOP)\n\n**Never run filesystem/index-destroying commands (`git reset --hard`, `git checkout -- .`, `rm -rf`, etc.) for the purpose of reverting or resetting work without prior coordination and user approval.** When a reset is unavoidable (e.g., undoing a temporary commit), step through a non-destructive alternative (`git reset --soft` / `git reset HEAD~1` followed by per-file `git restore`) and perform it safely.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Run `git reset --hard HEAD~1` to destructively drop a temporary local commit | Use `git reset --soft HEAD~1` or `git reset HEAD~1` to release the commit while preserving changes, then apply per-file `git restore` if needed |\n| 2 | Unilaterally run `git checkout -- .` or `git restore .` to wipe all working-directory edits at once | Keep open the possibility that changes must be preserved; restore carefully per file, or roll back safely only after user confirmation |\n\n## Multi-repository original-work tracking and context discrimination (HARD STOP)\n\n**When you receive an error report or `/fix` feedback while switching back and forth across multiple projects (repositories), do not get trapped in the narrow view of the currently active directory β€” replay the whole session history.** Identify which target repository was the \"Original Work\" (the recent build error, push failure, or edit target) and **cross-verify via the full local repository state** (`git status`, `git log`) before switching to the correct target and handling the work.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Get a commit-convention error in repo A but, absorbed in repo B (recently edited), try to fix the wrong commit | Read the feedback, switch the working directory immediately to repo A where the bad commit actually exists, and amend the correct commit |\n| 2 | When the subject of the user's feedback is omitted during multi-project work, impulsively assume the current folder is the target and edit it | Quickly tour each workspace running `git status` or `git log -n 5` to determine which project holds the error target |\n\n## Chained-fix dependency declaration and completed-task pruning (HARD STOP)\n\n**On `/fix`, the registered `fix-2 (Resume)` task must declare the preconditions under which the work can run safely β€” to prevent configuration damage from stale execution** β€” and during the session `cleanup` step, prune **only completed (`[x]`) tasks**; do not unilaterally delete in-progress or held (stale) incomplete tasks.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Register only the bare `Resume` command on the `fix-2` task without preconditions (Depends on) and base commit SHA (Reference commit) | Record preconditions and snapshot, e.g. `- [ ] fix-33: πŸ”„ Resume original work: ... (Depends on: , Reference commit: )` |\n| 2 | During session `cleanup`, freely delete stale incomplete `fix-*` tasks recorded in `task.md` without tracking history | Prune only completed (`[x]`) `fix-*` tasks; keep held or in-progress incomplete tasks intact |\n\n## Immediate TDD auto-switch on user-anger / deception signals (HARD STOP)\n\n**When two signals co-occur β€” a strong user-anger signal (profanity / hostile language) plus a direct verification-failure claim (e.g. \"it's not installed\", \"it's not applied\", \"the fallback doesn't work either\", \"neither X nor Y works\", \"it still shows the old one\") β€” stop the ad-hoc Edit/rebuild/install attempts immediately** β†’ extract the logic under verification into a pure function β†’ write Red unit tests (3+ scenarios) β†’ confirm fail β†’ Green implement β†’ confirm pass β†’ switch to verifying the new build via a code grep of the installed artifact. Three or more repeated ad-hoc fixes accumulate the same mistake, so TDD is mandatory.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Keep repeating ad-hoc Edit + rebuild + install even after an anger signal + verification-failure claim | Switch to TDD immediately: extract the logic to a pure function β†’ Red tests (normal + user-reported scenario + edge case, at least 3) β†’ confirm fail β†’ Green implement β†’ confirm pass β†’ installed-artifact grep |\n| 2 | Conclude \"success\" from the install command's output line alone | Confirm a substring grep match of the new logic inside the installed dir artifact (`~/.vscode/extensions/-/dist/`, `~/.cursor/extensions/...`). Zero matches = install failed = retry. matches > 0 = verification passed |\n| 3 | Think \"the user is angry, so quickly try another new fix\" | An anger signal = a procedure-defect signal. One more ad-hoc attempt = the same mistake repeated. TDD is faster in the end (unit tests catch regressions immediately) |\n| 4 | Reuse the same path prefix in a command after `cd` (e.g. `cd packages/X && code --install-extension packages/X/file.vsix`) | After `cd`, use the filename only (`cd packages/X && code --install-extension file.vsix`) or an absolute path. Just before composing the command, check `pwd` + duplicated path prefix |\n\n### Procedure\n\n1. Detect co-occurrence of an anger/profanity signal + at least one verification-failure-claim keyword\n2. Check whether the just-attempted fix was an ad-hoc Edit + the count (3+ = mandatory TDD)\n3. Extract the logic under verification into a pure function (existing inline logic β†’ a separate helper file)\n4. Write unit tests: normal case + reproduce the user-reported scenario + edge case (e.g. null/undefined input, empty collection)\n5. Run tests β†’ confirm Red (report the failure result explicitly)\n6. Fix the logic β†’ confirm Green (report all scenarios passing explicitly)\n7. Import the helper into the caller (extension.ts, etc.) and apply it\n8. build + install β†’ confirm a substring grep match of the artifact code at the installed-artifact path\n9. Report verification to the user in the form \"Red N failing β†’ Green N passing β†’ installed grep N matches\"\n\n### Exceptions\n\n- The user explicitly instructs \"no TDD, fix directly\" or \"do it fast, ad-hoc\"\n- Logic for which pure-function extraction is impossible (e.g. code with only a UI side effect, direct vscode-API dependency)\n- The anger signal stems from a cause other than verification failure (e.g. timeout, policy refusal)\n\nFile v0.7.1:CHANGELOG.md\n\n# Changelog\n\n## [0.7.1](https://github.com/es6kr/skills/compare/fix-v0.7.0...fix-v0.7.1) (2026-10-04)\n\n\n### Bug Fixes\n\n* **fix:** suppress additionalContext injection in headless/Ralph runs ([ca84cf5](https://github.com/es6kr/skills/commit/ca84cf5124901654c5618e28ee3116e3c008f92d))\n\n## [0.7.0](https://github.com/es6kr/skills/compare/fix-v0.6.2...fix-v0.7.0) (2026-09-30)\n\n\n### Features\n\n* **cleanup, fa:** enhance session cleanup pipeline, automated FA rotation, and streaming search ([9b3f366](https://github.com/es6kr/skills/commit/9b3f36609c3ebb1f227bcef549cffb3a8e85d0a5))\n\n## [0.6.2](https://github.com/es6kr/skills/compare/fix-v0.6.1...fix-v0.6.2) (2026-09-18)\n\n\n### Bug Fixes\n\n* **cleanup:** make the session-end report table self-sufficient ([#487](https://github.com/es6kr/skills/issues/487)) ([c4a0255](https://github.com/es6kr/skills/commit/c4a02557fb8de3b32cf337c549f62535dabf824b))\n\n## [0.6.1](https://github.com/es6kr/skills/compare/fix-v0.6.0...fix-v0.6.1) (2026-09-08)\n\n\n### Bug Fixes\n\n* **fix:** mention the claude-task fallback + no-scratchpad rule in the summary table ([0ab146a](https://github.com/es6kr/skills/commit/0ab146a3f745a82b0564e806c2131c81f46fec64))\n* **tdd:** scope the Red-only commit ban to shared branches ([fc2e6ec](https://github.com/es6kr/skills/commit/fc2e6ecdd1906c41d47955226e247aeb03a6f367))\n\n## [0.6.0](https://github.com/es6kr/skills/compare/fix-v0.5.0...fix-v0.6.0) (2026-09-06)\n\n\n### Features\n\n* **cc-plugin:** implement post-commit dev-reflect and cache drift guard ([3f78c05](https://github.com/es6kr/skills/commit/3f78c054e7c00e7c33730d3378c5aff6575566e4))\n\n## [0.5.0](https://github.com/es6kr/skills/compare/fix-v0.4.2...fix-v0.5.0) (2026-09-05)\n\n\n### Features\n\n* **fa:** move FA lifecycle ownership (retrospect, fa-prune, scripts) from cleanup to fa ([fd7f18e](https://github.com/es6kr/skills/commit/fd7f18ef9e85b8e3170b41ed6a52bce524d81bc7))\n* promote next-feat (fa lifecycle ownership) ([90c90bb](https://github.com/es6kr/skills/commit/90c90bb4796087ff6eaa5491b3c4524f7ed829a7))\n\n\n### Bug Fixes\n\n* **cleanup:** hand retrospect and fa-prune ownership to the fa skill ([5821410](https://github.com/es6kr/skills/commit/58214106c334fbce36559a1495d5131513152524))\n* **fix:** honour FA_DATA_DIR in the Stage 1 recurrence pre-check ([df2eb5b](https://github.com/es6kr/skills/commit/df2eb5b41d7a4133a2b5700a31e4f074174947dd))\n\n## [0.4.2](https://github.com/es6kr/skills/compare/fix-v0.4.1...fix-v0.4.2) (2026-08-29)\n\n\n### Bug Fixes\n\n* **fix:** add current-workspace tracker grep to recurrence pre-check ([1b5ef18](https://github.com/es6kr/skills/commit/1b5ef18c0c52fafbb856de2bd534733f0664002c))\n* promote next-fix batch (task plugin split, claudify matcher, pr recheck, omz chezmoi fix) ([3e90fd5](https://github.com/es6kr/skills/commit/3e90fd56ade0522d6773eb03f38760a317dd5180))\n\n## [0.4.1](https://github.com/es6kr/skills/compare/fix-v0.4.0...fix-v0.4.1) (2026-08-26)\n\n\n### Bug Fixes\n\n* accumulate 16 patch-level bug fixes and guard enhancements across skills ([d214e5d](https://github.com/es6kr/skills/commit/d214e5dcc7fac1bc07baf3b6cec62999aea732f0))\n* apply PR [#363](https://github.com/es6kr/skills/issues/363) Copilot Minor review findings ([731745c](https://github.com/es6kr/skills/commit/731745c6d67c329c8c6dde666107672282a3894a))\n* **core:** align workflow steps, next suggestion patterns, and browser topics ([c68d489](https://github.com/es6kr/skills/commit/c68d489d01a79862b8933b4a0542168cf676cd3a))\n* promote next-fix batch (consolidate fabrication guard, session rewind, config-driven PR base) ([7ca0ccb](https://github.com/es6kr/skills/commit/7ca0ccbf13cefafedc33a16a7361756c95f8b8f6))\n* resolve PR [#363](https://github.com/es6kr/skills/issues/363) audit Pending findings (plane_bulk_update profile, hook checker schema, regex, dedup) ([19ffc83](https://github.com/es6kr/skills/commit/19ffc83f296ad5568b82a85b104fcf419580c102))\n\n## [0.4.0](https://github.com/es6kr/skills/compare/fix-v0.3.12...fix-v0.4.0) (2026-08-20)\n\n\n### Features\n\n* **fa:** add lightweight FA-record entry point ([8860a0c](https://github.com/es6kr/skills/commit/8860a0c98de74b909d04ee0d756d77234ab6a496))\n* promote next-feat batch (hook registry schema, self-reference path anchoring) ([0c33ffa](https://github.com/es6kr/skills/commit/0c33ffac99a9237f4530566470dabeaea128c209))\n* promote next-feat staging (lifecycle guards, triage automation, and workflow safety procedures) ([77d58ac](https://github.com/es6kr/skills/commit/77d58ac3a771a4897043c9eea8b149ea1e8ba2ff))\n\n\n### Bug Fixes\n\n* **fix:** correct escalation-matrix stage numbering + point to /fa ([fde51ea](https://github.com/es6kr/skills/commit/fde51eaf488d83a5e05aad31d31c713e87b57c48))\n* **hook-kit:** repair hook paths broken by the within-marketplace relocation ([#340](https://github.com/es6kr/skills/issues/340)) ([0d9b701](https://github.com/es6kr/skills/commit/0d9b70181015e4822c7cf5cd2fe122d5af708d26))\n* promote next-fix batch (hook path repair, topic-dispatch scoping, conflict diagnosis) ([eb7ecb6](https://github.com/es6kr/skills/commit/eb7ecb61dda9701d78f12dc810781dc7cb687caa))\n\n## [0.3.12](https://github.com/es6kr/skills/compare/fix-v0.3.11...fix-v0.3.12) (2026-08-17)\n\n\n### Bug Fixes\n\n* **hook-kit:** stop claudify-skip hook from false-positiving on claudify's own description ([3b83567](https://github.com/es6kr/skills/commit/3b835677726181d51bef66c89736e63303a04696))\n* promote next-fix staging (30 fixes across 14 skills) ([ee467c0](https://github.com/es6kr/skills/commit/ee467c045d779d7b80d30f160763ec3534a9742b))\n* **wip:** cross-ref PR-URL and TaskCreate subject repo-qualifier rules ([#186](https://github.com/es6kr/skills/issues/186)) ([4982364](https://github.com/es6kr/skills/commit/49823641a7b08123ebd0325273892bee41bc3280))\n\n## [0.3.11](https://github.com/es6kr/skills/compare/fix-v0.3.10...fix-v0.3.11) (2026-08-09)\n\n\n### Bug Fixes\n\n* declare undeclared skill-to-skill dependencies (7 skills) ([#271](https://github.com/es6kr/skills/issues/271)) ([36a9f9d](https://github.com/es6kr/skills/commit/36a9f9d7c1fac9bb1c4c96b325a067ab92ad0da7))\n* promote accumulated next-fix fixes to main ([95656e9](https://github.com/es6kr/skills/commit/95656e9b551ee0bb77904a0a571d49c53bc01cc9))\n\n## [0.3.10](https://github.com/es6kr/skills/compare/fix-v0.3.9...fix-v0.3.10) (2026-08-05)\n\n\n### Bug Fixes\n\n* **wip:** cross-ref PR-URL and TaskCreate subject repo-qualifier rules ([#186](https://github.com/es6kr/skills/issues/186)) ([951c1e6](https://github.com/es6kr/skills/commit/951c1e6871e78e226757c6a7ae5ae53efeb7bfb0))\n\n## [0.3.9](https://github.com/es6kr/skills/compare/fix-v0.3.8...fix-v0.3.9) (2026-07-28)\n\n\n### Bug Fixes\n\n* **fix:** add mechanical per-file language gate before Step 2 skill edits ([c457a42](https://github.com/es6kr/skills/commit/c457a428969cff01de0df2e72c06e37387f987a9))\n* **next-fix:** promote staged fixes across hook-kit, next, cleanup, fix-plan ([34f1c67](https://github.com/es6kr/skills/commit/34f1c67beee3a8279e0e80de4ab3a87ba2223d5c))\n* **next,fix,wip:** reduce meta-task over-registration + enforce skill-invocation resume ([beec453](https://github.com/es6kr/skills/commit/beec453da85d70c79ec9403c83259e7a4a28d303))\n* **next,fix:** close the chained-turn next-call gap (12th recurrence) ([dd7c582](https://github.com/es6kr/skills/commit/dd7c58286a355a2451cb9e0a6f08ef1865dbe018))\n* resolve PR [#197](https://github.com/es6kr/skills/issues/197) review findings (CodeRabbit + Copilot + Internal Review) ([b54236a](https://github.com/es6kr/skills/commit/b54236a4fa4b3fef23645dfc3b184916980b7f65))\n* staging bundle β€” meta-task registration, next-call-gap, bash-guard consolidation, hook-kit FP fixes ([dc1b790](https://github.com/es6kr/skills/commit/dc1b790688808df7649ef390a22caa5f66a8aa40))\n\n## [0.3.8](https://github.com/es6kr/skills/compare/fix-v0.3.7...fix-v0.3.8) (2026-07-23)\n\n\n### Bug Fixes\n\n* **fix:** externalize Korean detection patterns in ambiguity-guard hook ([18dc89f](https://github.com/es6kr/skills/commit/18dc89fe309d035197db4aefb4bb6be920395858))\n* **fix:** step3-resume + SKILL body refinements ([944597d](https://github.com/es6kr/skills/commit/944597df28eab767052a26ced7c4d5ea6ee71a73))\n* hook relocation + Korean-pattern externalization (cc-plugin, fix, wip) ([f4af5b5](https://github.com/es6kr/skills/commit/f4af5b564b2d43387a5d004f875e56b30a36ce13))\n* **next-fix:** accumulate bug fixes for docxport, wip, fix-plan, and hook-kit ([6eec083](https://github.com/es6kr/skills/commit/6eec083b7fbc429bdabcfcc89d7778b185dd7497))\n* skills body bundle β€” consolidate/fix/hook-kit refinements + English-clean guard hooks (Ralph-loop bypass) ([2e26f41](https://github.com/es6kr/skills/commit/2e26f412a5b963984898e13caaca186c3617ca08))\n\n## [0.3.7](https://github.com/es6kr/skills/compare/fix-v0.3.6...fix-v0.3.7) (2026-07-16)\n\n\n### Bug Fixes\n\n* **commit-tidy,fix:** content-over-operation subjects + --local rule scoping ([61ba092](https://github.com/es6kr/skills/commit/61ba0929587bfd74b1f0a081ff9b316846c24969))\n* **consolidate,fix-plan:** promote next-fix staging (review hardening + periodic archive) ([24726e9](https://github.com/es6kr/skills/commit/24726e99a5b2972f706d8749ea3a45cbc358984b))\n* **fix:** add --local option scoping Step 2 rule edits to workspace/project rules ([0975195](https://github.com/es6kr/skills/commit/09751956b7bfac9bcf145568d9c760f6dd393260))\n* **fix:** make --plan STOP explicit β€” sub-ask answer is not apply-approval ([0b4d392](https://github.com/es6kr/skills/commit/0b4d3924fb8785735971fdfb267827ddf40973a7))\n* **fix:** require environment detection before rule modifications ([8ab91ea](https://github.com/es6kr/skills/commit/8ab91ea2ca9f5463f3c9d766c97a4d074b6d5cad))\n\n## [0.3.6](https://github.com/es6kr/skills/compare/fix-v0.3.5...fix-v0.3.6) (2026-07-07)\n\n\n### Bug Fixes\n\n* **fix,web-browser:** publish-scope edit gate + managed-surface backend detection ([2e28fc4](https://github.com/es6kr/skills/commit/2e28fc4d39953ee6a88f64bd8c8d20907ba01e39))\n* **fix:** qualify Wiki-LLM medium paths with the workspace wiki prefix ([a00b2f8](https://github.com/es6kr/skills/commit/a00b2f89636d2ec4779f7995712ffac22c1ed5ae))\n* **skills:** review-feedback bundle β€” consolidate trigger wording + fix wiki paths ([784854e](https://github.com/es6kr/skills/commit/784854e3e07696ca8d16274215004488861862d1))\n\n## [0.3.5](https://github.com/es6kr/skills/compare/fix-v0.3.4...fix-v0.3.5) (2026-07-03)\n\n\n### Bug Fixes\n\n* **skills:** patch bundle β€” consolidate/next/fix/skill-kit/github-flow ([3cb90cb](https://github.com/es6kr/skills/commit/3cb90cb7601f619b63518860bebfb693d58a7633))\n\n## [0.3.4](https://github.com/es6kr/skills/compare/fix-v0.3.3...fix-v0.3.4) (2026-06-30)\n\n\n### Bug Fixes\n\n* **skills:** add procedural guards + standardize description scalar ([#66](https://github.com/es6kr/skills/issues/66)) ([fcc921f](https://github.com/es6kr/skills/commit/fcc921fba3928aad7421ecff888d5dcee5ae5655))\n\n## [0.3.3](https://github.com/es6kr/skills/compare/fix-v0.3.2...fix-v0.3.3) (2026-06-25)\n\n\n### Bug Fixes\n\n* **fix:** split Step 2 medium by content type β€” case history to failed-attempts.md ([c1b4720](https://github.com/es6kr/skills/commit/c1b4720349874311611c1a867a5ce4386df56891))\n* **fix:** split Step 2 medium by content type β€” case history to failed-attempts.md ([#62](https://github.com/es6kr/skills/issues/62)) ([747b3f9](https://github.com/es6kr/skills/commit/747b3f957ca0fefdbc5044eb08f66b8aafc1e26a))\n\n## [0.3.2](https://github.com/es6kr/skills/compare/fix-v0.3.1...fix-v0.3.2) (2026-06-19)\n\n\n### Bug Fixes\n\n* bundle skill patches across 7 scopes ([f18f47c](https://github.com/es6kr/skills/commit/f18f47c2d05f13b8e3f3ad42675a2dabbb31c824))\n* bundle skill patches across github-flow, skill-kit, fix ([0ef74c1](https://github.com/es6kr/skills/commit/0ef74c14aabfbdc2f802c34b3a1b431217e95208))\n* **fix,skill-kit:** add rule-file Edit gate + undeclared vendor coupling lint ([009348b](https://github.com/es6kr/skills/commit/009348b42a41fe23e94c42c2960d0e789dcc1cbc))\n* **fix:** require command / API / syntax primary-source verification before Edit ([738c388](https://github.com/es6kr/skills/commit/738c38802b129af233d14d35ee5233685da65d59))\n\n## [0.3.1](https://github.com/es6kr/skills/compare/fix-v0.3.0...fix-v0.3.1) (2026-06-13)\n\n\n### Refactor\n\n* **fix,next:** decompose oversized SKILL.md into topic files ([#51](https://github.com/es6kr/skills/issues/51)) ([525eb17](https://github.com/es6kr/skills/commit/525eb170c1c3d371c76a4b1ef8033d624cea6002))\n\n## [0.3.0](https://github.com/es6kr/skills/compare/fix-v0.2.0...fix-v0.3.0) (2026-06-03)\n\n\n### Features\n\n* add metadata block (author, version) to all skills ([a36d9a5](https://github.com/es6kr/skills/commit/a36d9a5f029b595847220c3cc867370c7ff30a21))\n* **ci:** add lint jobs and untrack LICENSE ([#7](https://github.com/es6kr/skills/issues/7) Phase 1) ([03a8587](https://github.com/es6kr/skills/commit/03a85872c575c6ffdf72f5ca2bdb353fdc947a73))\n* **claude-session,fix:** version bump with improvements ([f4dc817](https://github.com/es6kr/skills/commit/f4dc8171c051474f1d454c4211ca26b1b16e91bf))\n* publish 7 new skills, update 4 existing skills ([dce016d](https://github.com/es6kr/skills/commit/dce016da291f4c9da03746f8be668fa5db04e578))\n* update 4 skills β€” session move, mcp diagnostics, git-repo worktree, fix improvements ([316c85f](https://github.com/es6kr/skills/commit/316c85f186ef94bbb5acae86d26dd6ac7fb027e9))\n\n\n### Bug Fixes\n\n* address CodeRabbit review findings on PR [#4](https://github.com/es6kr/skills/issues/4) ([bbaefdc](https://github.com/es6kr/skills/commit/bbaefdc8a88f26b0b072e115d0696e732ac52e0c))\n* **skills:** address PR [#9](https://github.com/es6kr/skills/issues/9) deferred review feedback ([9268a83](https://github.com/es6kr/skills/commit/9268a83ec98a32a8bf731398503c46e60328b1a3))\n* **skills:** translate fix/next to English + data-architecture locale patterns ([#9](https://github.com/es6kr/skills/issues/9)) ([d426d2b](https://github.com/es6kr/skills/commit/d426d2b7dfec9f82a3106d1df055763324220bba))\n\n## [0.2.0](https://github.com/es6kr/skills/compare/fix-v0.1.5...fix-v0.2.0) (2026-05-24)\n\n\n### Features\n\n* **ci:** add lint jobs and untrack LICENSE ([#7](https://github.com/es6kr/skills/issues/7) Phase 1) ([03a8587](https://github.com/es6kr/skills/commit/03a85872c575c6ffdf72f5ca2bdb353fdc947a73))\n\n\n### Bug Fixes\n\n* **skills:** address PR [#9](https://github.com/es6kr/skills/issues/9) deferred review feedback ([9268a83](https://github.com/es6kr/skills/commit/9268a83ec98a32a8bf731398503c46e60328b1a3))\n\nFile v0.7.1:skill-card.md\n\n## Description:\n\nHelps an agent investigate behavior-correction feedback, improve its guidance to prevent recurrence, and resume the interrupted task.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[drumrobot](https://clawhub.ai/user/drumrobot)\n\n### License/Terms of Use:\n\nMIT\n\n## Use Case:\n\nDevelopers and agent users invoke this skill after behavior-correction feedback to investigate a mistake, improve the relevant guidance, and complete the interrupted work.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may inspect broad agent history containing sensitive information.\n\nMitigation: Review the records it needs to access and limit exposure of unrelated or sensitive material.\n\nRisk: It may make lasting changes to rules, memory, skills, hooks, or agent settings.\n\nMitigation: Prefer explicit /fix or fix: invocation and --local changes; review each confirmation and proposed persistent change before allowing global updates, hook changes, or plugin installs.\n\n## Reference(s):\n\n- [Fix on ClawHub](https://clawhub.ai/drumrobot/skills/fix)\n\n## Skill Output:\n\n**Output Type(s):** [Guidance, Markdown, Code, Shell commands, Configuration]\n\n**Output Format:** [Markdown with change summaries, proposed or applied edits, and verification results]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May revise agent guidance and resume the original task.]\n\n## Skill Version(s):\n\n0.7.1 (source: ClawHub release and CHANGELOG)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nFile v0.7.1:step2-improvement.md\n\n# Step 2: Prompt Improvement (Prevent Recurrence) β€” never skip\n\n**Step 2 execution gate (HARD STOP)**:\nIf Step 1 produced even one Why, Step 2 is **mandatory**. The deliverable depends on recurrence count and the 4-filter gate below:\n\n- **1st-2nd recurrence (default)**: record the lesson, **medium split by content type (HARD STOP β€” FA single-location rule)**:\n - **Case history** (violation-case quote, date, Nth-recurrence count, \"how to apply\" tied to a specific incident) β†’ **`~/.claude/skills/cleanup/data/failed-attempts.md` (HOT)** via `/cleanup retrospect`. Violation cases live ONLY in failed-attempts.md β€” **never in `memory/feedback_*.md`**. Writing a violation-case + date entry to a `feedback_*.md` file violates the FA single-location rule (`rules/failed-attempts.md`).\n - **Pure user preference** (how-to-work guidance with NO violation-case quote, NO date, NO Nth-count) β†’ a `feedback` memory entry is acceptable. The moment a date / violation-quote / recurrence-count appears, it is case history β†’ route to failed-attempts.md instead.\n - Neither requires a rule-file Edit. failed-attempts.md (HOT) costs 0 always-on tokens and is searchable via the `/cleanup retrospect` recurrence pre-check.\n- **3rd+ recurrence**: rule-file Edit is allowed **only if the 4-filter gate passes** (see below). If any filter fails β†’ stay in memory + route to skill/hook/CLAUDE.md instead.\n- **4th+ recurrence with deterministic pattern**: hook implementation (script + settings.json registration + parse verification). Rule body minimizes to a pointer to the hook.\n- **AskUserQuestion mandatory before rule-file Edit (HARD STOP β€” every time)**: adding a new Don't/Do table OR a new self-check procedure section to a rule file requires explicit user ask first. Passing the 4-filter gate does NOT exempt the ask. The user must decide on the location (`~/.agents/rules/` vs `/.claude/rules/` vs inside a skill), the strength (HARD STOP vs note), the number of Don't/Do rows, and the length of the self-check procedure. Editing without ask = imposing always-on context cost without user consent. 1st-stage default = `feedback` memory OR a short skill cross-ref + failed-attempts entry (on-demand mediums). When rule strengthening is needed at 2nd+ stage, prefer hook β†’ lazy-loaded skill invocation first to avoid the per-session always-on cost. See also: `rule-kit/add.md` same obligation.\n\n**4-filter gate for rule-file Edit (ALL must pass β€” entered at 3rd+ recurrence)**:\n\n| # | Filter | Meaning |\n|---|--------|---------|\n| 1 | **Destructive/irreversible/security impact** | Secret leak, destructive git, prod/infra damage, permission escalation. \"Inconvenience\" or \"ugly\" fails |\n| 2 | **3+ verified recurrences** | 1st-2nd = feedback memory only. Recurrence cluster must share the same pattern |\n| 3 | **Deterministic pattern** | Objectively judgeable via grep/regex/structure. \"Depends on context\" patterns can't be enforced β€” rule will be bypassed every time |\n| 4 | **Always-on cost < violation cost** | Rule takes session tokens. Violation cost (time/money/data) per incident Γ— remaining sessions must exceed rule load cost |\n\nFailing any filter β†’ route to other medium per the table below:\n\n| Pattern | Routing target |\n|---------|----------------|\n| Domain knowledge / procedure | skill (on-demand) |\n| 1st-2nd-time case note | `feedback` memory |\n| Project-bounded policy | workspace CLAUDE.md / `.claude/rules/` |\n| \"Recommended\" / \"would be nice\" | drop (rules enforce, not suggest) |\n| Deterministic + automatable | hook (rule is fallback only) |\n| **Wrong factual claim inside a curated wiki (Wiki-LLM) that Claude cites** | **Wiki-LLM medium** β€” edit `/wiki/pages/**/*.md` + `/wiki/log.md` `page-update` + commit. Bidirectional: fix Step 1 recurrence pre-check should also Grep the wiki for pattern re-emergence before authoring the correction |\n\nZero Edit/Write **on the rule file** is allowed when memory + skill/hook is the chosen medium. Step 2 is complete when the chosen medium received its deliverable.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Write Why as inline text only (no medium produced) | Produce the Why's deliverable in the chosen medium per the Priority table (memory feedback is the 1st default for 1st-2nd recurrence) |\n| 2 | Assume \"current issue is resolved, so Step 2 is unnecessary\" | Resolving current issue = Step 3, recurrence prevention = Step 2. Both are mandatory (medium may be memory, not rule) |\n| 3 | Shorten Step 2 in later fixes within a chain | Every /fix call is the same quality. No shortening by call count |\n| 4 | Edit a skill/rule file after partial Grep (e.g., only \"Step 7\", \"Summary\" keywords) | **Read the entire file** before any Edit. Skill files have section dependencies (templates, MANDATORY markers in other sections) β€” partial Grep can miss the existing canonical answer and lead to inventing redundant/conflicting rules |\n| 5 | Invent a new title/template/keyword when the user reports a missing element | First Grep the target skill for existing templates/MANDATORY markers (e.g., `Grep \"template\\|MANDATORY\"`). The user's report often refers to an existing template that wasn't followed, not a missing one |\n| 6 | Build complex matching tables (skill lists, file presence checks) for rule criteria | **Prefer the simplest 1st-class signal first**. Before authoring a matching table, ask \"is there a single field/line that decides this?\" (e.g., SKILL.md frontmatter `description` language decides skill language β€” no publish-target table needed) |\n| 7 | Author vendor-specific code (URL, skill name, MCP tool name, instance-bound command) into a generic skill body | Before authoring integration in a generic skill, **grep vendor skill docs for existing dispatch design**: `grep -rE \"\" ~/.claude/skills//`. If found, follow that pattern. Generic skill declares abstract dispatch (`--=:`); vendor skill implements receiver. See the rule on forbidding vendor-specific references in generic skills |\n| 8 | Add case-history meta OR ANY date stamp into a skill or rule body β€” case-history examples: \"violation case\", \"verified YYYY-MM-DD\", \"Nth recurrence\". Date stamp examples: `(HARD STOP -- added YYYY-MM-DD)`, `(HARD STOP -- newly added YYYY-MM-DD)`, `(recurrence-driven YYYY-MM-DD)`, \"observed YYYY-MM-DD\", \"added in YYYY-MM-DD fix\". Any literal `\\d{4}-\\d{2}-\\d{2}` substring in new_string counts | Skill/rule body keeps Don't/Do + self-check + procedure only -- **no date stamps anywhere**, including section headers (`### X (HARD STOP -- added DATE)`), parenthetical annotations, code comments (`// observed DATE`), \"added/newly added\" footers, \"since DATE\" inline notes. Case history lives **only** in `~/.claude/skills/cleanup/data/failed-attempts.md` (HOT). If a case reference is essential, use a date-free pointer: `(see failed-attempts.md \"\")`. **Self-check before every skill/rule Edit (MANDATORY, regex-strict)**: run `grep -E '[0-9]{4}-[0-9]{2}-[0-9]{2}' <<< \"$new_string\"` mentally -- 1+ match -> STRIP every match before calling Edit, then move case-history content (if any) into failed-attempts.md HOT as a separate write. Enforcement hook: `~/.claude/hooks/block-date-in-skill-rule.sh` (PreToolUse:Edit/Write on `skills/**/*.md` and `rules/**/*.md`) -- rejects calls whose new_string contains the date regex. Hook is the safety net; the self-check is the first line |\n| 9 | Edit a published/public skill (clawhub-registered, PUBLIC repo) with user-specific instance values (per-account scope sets, account names, org-internal policy) | Before every skill Edit, check publish scope: published skill bodies keep the GENERIC principle only; instance values route to the local rules medium (`~/.agents/rules/` or workspace rules). See skill-usage.md publish-scope obligation |\n\n\"Prompt\" = any persistent text that influences Claude's behavior β€” **including project-domain knowledge stores (Wiki-LLM, RAG index, curated notes) that Claude cites during Query**. When a domain-knowledge store exists, a factual error inside it recirculates on every Query β†’ treat wiki content correction as a Step 2 target medium, not just a Step 3 artifact edit.\n\nPriority (check in order β€” **stop at the first match**):\n\n| Priority | Target | Condition | Example |\n|----------|--------|-----------|---------|\n| **1st (default)** | **Memory** (`feedback` type) | All 1st-2nd-recurrence records, or context/reference info | new or updated `feedback_.md` |\n| 2nd | **Skill** (`~/.claude/skills/`, `.claude/skills/`) | Skill procedure defect (missing/wrong step) | Fix procedure step missing |\n| 3rd | **Rule** (`~/.agents/rules/`, `.claude/rules/`) | 3rd+ recurrence + 4-filter gate ALL pass | Add to existing rule section |\n| 4th | **Sub-agent / CLAUDE.md** (`.claude/agents/*.md`, project root) | Policy bound to a specific context (agent/project) | Add to agent description / project CLAUDE.md |\n| 5th | **Hook** (`settings.json` hooks) | 4th+ recurrence + deterministic pattern (grep/regex-judgeable) | Add PreToolUse/PostToolUse hook |\n| **Parallel (any stage)** | **Wiki-LLM / project domain knowledge store** (`/wiki/pages/**`, RAG index, curated docs) | Wrong / oversimplified / outdated **domain claim** cited by wiki pages that Claude uses during Query. Not behavior β€” factual correctness of stored knowledge | Edit `/wiki/pages/**/*.md` (correction) + amend `/wiki/raw/*.md` frontmatter (source note) + add `/wiki/log.md` `page-update` entry + commit. If a Lint procedure exists in `/wiki/CLAUDE.md`, also propose a Lint rule strengthening |\n\n**Why Rule is not 1st**: a rule consumes always-on token cost continuously. Adding a rule for every mistake inflates the context until you can no longer follow the rules themselves β€” a paradox. memory (feedback) costs 0 tokens + is reachable via search β€” the natural medium for 1st-2nd-recurrence learning. Rules are reserved for permanent protection patterns that passed the 4-filter gate.\n\n### `--local` scope routing (HARD STOP when flag set)\n\nWhen `/fix --local` is invoked, the 3rd-priority \"Rule\" row above **must not** target `~/.agents/rules/` (global). Instead resolve the innermost matching workspace/project rule directory:\n\n1. **Project-local**: `/.claude/rules/` β€” cwd is inside a git repo (`git rev-parse --show-toplevel` succeeds)\n2. **Workspace-local**: walk up from cwd to the nearest `.claude/rules/` (typically `/.claude/rules/`). Workspace = a non-git parent containing multiple git projects\n3. **Neither present**: AskUserQuestion β€” \"Create `.claude/rules/` at project or workspace?\" β€” do NOT silently fall through to global `~/.agents/rules/`\n\nThe choice between project vs workspace when **both** exist follows the `rule-management.md` location-plus-method dual-axis ask.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Write to `~/.agents/rules/` despite `--local` because \"the pattern feels universal\" | `--local` = user's explicit opt-in for scoped protection. Universal claims that need global scope require dropping the flag |\n| 2 | Skip the ask when neither project nor workspace `.claude/rules/` exists | Ask before creating. Silent creation buries the location decision |\n| 3 | Add a hook to `~/.claude/hooks/` (global) as the enforcement side of a `--local` rule | Hook location follows the rule scope. Workspace/project-scoped rules pair with project-local hooks or in-repo scripts (`.githooks/`, `pre-commit`, etc.) |\n\n**Self-check (before Step 2 Edit under `--local`)**:\n1. Is `--local` set in the /fix invocation?\n2. Did you run `git rev-parse --show-toplevel` (project) and walk up for `.claude/rules/` (workspace)?\n3. Is the target file path under one of those two, and NOT under `~/.agents/rules/`?\n4. If the fix pairs a rule with an enforcement mechanism (hook, pre-commit script), does the enforcement side also live inside the scoped repo/workspace?\n\n**Use Do & Don't table format (MANDATORY for 2+ recurrences)**:\nWhen adding or strengthening rules, use the **Do & Don't table** instead of prose. Placing forbidden patterns (Don't) next to correct alternatives (Do) raises scan speed and compliance. For rules that have recurred 2+ times, switching to a table is required.\n\n```markdown\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | {violation pattern} | {correct pattern} |\n```\n\nWhen fixing:\n- **Skill is 1st priority** β€” if the problem is a skill's incomplete procedure, fix the skill. Don't skip to failed-attempts.md\n- **If Why 3's conclusion is \"missing procedure/rule\"**: first look for an existing skill that owns that procedure. If a skill owns it, fix the skill β†’ then the rule file\n - Example: \"no move rule exists\" β†’ adding a move rule to the archive skill is the 1st priority; the rule-management rule is 2nd\n- **If the fix skill's own procedural defect is the cause**: fix/SKILL.md is also a target β€” do not grant itself an exception\n- Rule location must be confirmed via **AskUserQuestion**\n- failed-attempts.md recording is **only for cases not covered by higher-priority targets** β€” no duplicate recording if root cause is already reflected in a skill or prompt\n- **Profanity masking when recording to failed-attempts.md**: exclude or mask (`****`/`XX`) any user profanity/slurs in quoted text; preserve the anger context with a neutral term (\"anger signal\") instead of the raw word. Same rule as `cleanup/retrospect.md` Step 4-2 masking\n\n**Escalation on recurrence** (4-stage progressive β€” minimize always-on context):\n\nMinimize rule usage. **Default medium = memory (feedback)**. Edit a rule body only at the 3rd recurrence + after passing the 4-filter. Strengthening a rule on every fix causes always-on context inflation.\n\n- **1st time**: **write a 1-3 line feedback memory** β€” new or update existing `~/.claude/projects//memory/feedback_.md`. No rule-file Edit. Record the case body separately in failed-attempts.md HOT.\n- **2nd time**: **augment the feedback memory** β€” enrich the same memory entry with the case, trigger conditions, and How to apply. Add 2nd-time meta to failed-attempts.md HOT. Still no rule-file Edit.\n- **3rd time**: **enter the 4-filter gate** β€” confirm all 4 filters pass:\n - pass β†’ append 1-2 lines or a single Don't/Do row to an existing rule section (minimal). Grant the HARD STOP marker only for security/destructive/irreversible impact\n - any filter fails β†’ re-route the medium (strengthen the skill procedure / CLAUDE.md / consider a hook design). No rule addition\n- **4th time**: **if the pattern is deterministic, a hook is mandatory** (HARD STOP β€” implement it in this fix). script + chmod +x + install into `~/.claude/hooks/` + register in `settings.json` + `python3/jq` parse verification. Minimize the rule body to a hook pointer. For a non-deterministic pattern, redesign the skill procedure (no rule addition).\n- **Recurrence after hook**: hook failed to block β†’ strengthen the hook pattern + record in `failed-hooks.md` (not failed-attempts.md)\n\n| Stage | Default medium | Rule-file action | Context impact | failed-attempts.md handling |\n|-------|---------------|------------------|----------------|------------------------------|\n| 1st | 1-3 line `feedback` memory | **forbidden** | 0 (memory is not always-on) | Register case body |\n| 2nd | augment `feedback` memory | **forbidden** | 0 | Keep case body + 2nd-time meta |\n| 3rd | 1-2 lines or a single row, only if the 4-filter passes | **conditionally allowed** | minimal or 0 | Keep case body + 3rd-time meta |\n| 4th | hook implementation (deterministic patterns only) | hook pointer only | the hook enforces; minimize the rule body | HOT β†’ archive |\n\n**Forbidden patterns**:\n- \"At the 1st time, author a full Don't/Do table + HARD STOP + Scenarios\" β€” context inflation\n- \"At the 3rd time, add a rule without the 4-filter check\" β€” the 4-filter is the gate\n- \"At the 4th time, write only the hook spec and defer implementation\" β€” hook spec + implementation are the same fix's Step 2 deliverable\n\n## Don't / Do β€” no stage skipping\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | 1st time β†’ author full Don't/Do table + Scenarios + HARD STOP as a new section (context inflation) | 1st time = 1-2 line prose or single row **inside an existing related section**. No new section. Defer the full table + section to the 2nd time |\n| 2 | 2nd time β†’ still only add 1-2 line prose to the same existing section (same as 1st time) | 2nd time = promote into a **standalone new section** + expand to Don't/Do table + self-check + Scenarios + HARD STOP |\n| 3 | 4th time (hook registration) β†’ write only spec and defer implementation | 4th time = actually author the script + install + register in settings.json + parse-verify (`python3 -c \"import json\"`). Mandatory |\n| 4 | Ignore recurrence count β†’ jump straight to hook design/implementation | Honor the stage sequence. 1st-3rd time = rule strengthening attempts; only at 4th time do you reach for a hook |\n| 5 | 2nd time β†’ just add another row to the 1st-time's appended line without restructuring | 2nd time = restructure: cut the 1st-time line from the existing section + paste as the kernel of the new standalone section, then expand |\n\n## Stage decision procedure\n\n1. In Step 1 recurrence pre-check (Stage 0 RAG + Stage 1 grep), identify the Nth recurrence count\n2. Apply the stage matching N from the matrix above\n3. 1st-3rd time = author rule file content (Don't/Do / Scenarios / hook design); 4th time = implement the hook\n\n## Rule-file Edit gate (HARD STOP β€” AskUserQuestion mandatory)\n\n**Before Edit/Write on any file under `~/.agents/rules/**`, `~/.claude/rules/**`, `/.claude/rules/**`, the fix flow MUST call AskUserQuestion to confirm: (a) which file to add to, (b) whether to add at all (memory/skill might be the better medium).** This applies even when fix Step 2 has decided rule strengthening is the chosen stage.\n\n**Why**: `rule-management.md` (always_on) requires AskUserQuestion for any rule add/modify. fix's Step 2 routing decision (memory vs rule vs hook) selects the **medium category** but does not override the per-file `where to add` decision. Skipping the ask creates \"/fix triggers rule rewrites without owner consent\" β€” even sound rule additions accumulate without alignment.\n\n**Skill files (`skills/**/*.md`) are NOT rule files** β€” direct Edit allowed (e.g., `step2-improvement.md` itself). The rule scope is strictly `rules/`, `.claude/rules/` directories.\n\n### Don't / Do\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | \"/fix Step 2 chose rule β†’ directly Edit `branch-policy.md` (or other rule file)\" | AskUserQuestion first: \"Add to {existing file X} / {existing file Y} / {new file} / drop\" β†’ only after answer, Edit |\n| 2 | Chain multiple rule additions in one fix run without ask | Each rule-file Edit is a separate ask. Even 2nd addition in the same fix needs its own ask |\n| 3 | Treat rule-kit skill as optional convenience | `skill-usage.md` HARD STOP: rule file Edit goes through `rule-kit` skill. Call `Skill(\"rule-kit\", \"add\")` (or `route`) **before** Edit |\n| 4 | \"Routing question was already implied by /fix scope\" rationalization | /fix scope = \"fix this behavior\". Rule file location + content = separate decisions requiring explicit user input |\n| 5 | Skip ask on minor rule additions (\"only 1 line\") | Line count is irrelevant. The rule's location and presence are user decisions |\n\n### Self-check (every time before Edit/Write on rule file)\n\n1. Is the target path `~/.agents/rules/*.md`, `~/.claude/rules/*.md`, or `/.claude/rules/*.md`?\n2. If yes, did you call AskUserQuestion for (a) location and (b) presence?\n3. Did you invoke `rule-kit` skill per `skill-usage.md` requirement?\n4. Only after both β†’ Edit. Otherwise STOP and ask first.\n\n## Command / API / syntax primary-source verification (HARD STOP)\n\n**When adding a CLI command / API call / config option / file path to a rule or skill body, verify each token against primary source (`--help`, `man`, official docs, source code) BEFORE Edit/Write.** Citing a flag/option/path from memory or analogy with sibling commands silently embeds wrong syntax β€” the rule body becomes a recurrence trap.\n\n### Don't / Do\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Cite `gh auth refresh -u ` by analogy with `gh auth switch -u` / `gh auth status -u` | Run `gh auth refresh --help` first; confirm each flag exists. Sibling-command flag presence β‰  this command's flag presence |\n| 2 | Paste a `curl -X POST ...` example from training data without verifying the endpoint path / header shape against the provider's current API docs | Fetch the provider's API doc (or call the endpoint with `--head`) before pasting. APIs version-drift |\n| 3 | \"It worked in another project, so the syntax is fine\" | Verify in **the destination project's CLI/API version**. flag/path drifts across versions and forks |\n| 4 | Add a file path (`/etc/...`, `~/.config/...`) without confirming it exists on the target OS / version | `ls` / `command -v` / `find` to confirm. macOS/Linux/Windows paths differ |\n| 5 | Quote a complex multi-line command (heredoc, pipeline) without dry-running once | Dry-run once (with `--dry-run` or `echo`) before placing it in a rule body. Syntax errors hidden in heredoc/quoting are silent |\n\n### Self-check (every time before adding a command/API/syntax token to a rule/skill body)\n\n1. List each CLI flag / option / API path / file path being added.\n2. For each item, did I run `--help` / fetch docs / call the endpoint to verify it exists in the target version?\n3. Where the rule cites a \"sibling command\" pattern (e.g., `gh auth switch -u` while documenting `gh auth refresh`), did I verify each command independently?\n4. Did I dry-run multi-line commands or complex quoting?\n5. If verification was skipped, the rule body is unverified β€” re-verify before Edit, or remove the token.\n\n### Pointer\n\n`(see failed-attempts.md \"command syntax primary-source missing\")` for case history.\n\n### Pointer\n\nSee `~/.agents/rules/rule-management.md` (rule scope) + `~/.agents/rules/skill-usage.md` \"Rule file Edit triggers rule-kit\" + `(see failed-attempts.md \"rule edit without ask in fix\")` for details.\n4. failed-attempts.md HOT entry only updates the Nth-time meta β€” do not re-author the case body redundantly\n\n**Hook deferral forbidden (HARD STOP)**:\n\nWriting only a hook **specification** (\"hook X to be implemented on Nth recurrence\") without the actual script + installation is a procedure violation at the 3rd recurrence. The spec must be **implemented in the same fix** (script file + chmod +x + settings.json registration). \"Implement on next recurrence\" defers indefinitely and the same mistake recurs.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | \"Hook spec to be implemented on Nth recurrence\" deferral text in failed-attempts.md | 3rd recurrence = write hook script in this fix's Step 2 + install + register + verify with `jq` parsing settings.json |\n| 2 | \"Spec is done, implementation is the next fix's job\" thinking at 3rd recurrence | Spec + implementation = same Step 2 deliverable. Splitting them = procedure violation |\n| 3 | Skip the Checkpoint \"Verify escalation artifacts\" item | Step 2 Checkpoint #6 explicitly verifies \"hook script file + settings.json registration\" β€” missing = Step 2 incomplete |\n\n(Case history: see failed-attempts.md \"hook deferral\".)\n\n**`--plan` mode**:\n- Emit only the list of target files + a preview of changes per file\n- Do not perform Edit/Write (but **plan artifact .md saving is performed**)\n- **Stop here after Step 2** β€” do not proceed to Step 3 or 4\n- After reporting the plan, wait for user response. On \"apply\" approval, perform Edit/Write and proceed to Step 3\n- **\"apply\" approval = a SEPARATE, EXPLICIT user instruction to implement (e.g., \"apply\", \"go\", \"implement it\") issued AFTER the plan is reported.** An `AskUserQuestion` you issue during the plan phase (location, design axis, trade-off) refines the PLAN β€” its answer is **NOT** \"apply\" approval. After incorporating a sub-ask answer, re-report the updated plan and **STOP again**. Do not slide from \"location decided\" into Edit/Write/commit.\n- **Do not issue an execution-triggering ask during `--plan`.** The plan phase ends only when the user freely responds with an apply/implement instruction β€” never because an `AskUserQuestion` was answered.\n\n**Self-check (HARD STOP β€” before ANY Edit/Write/commit while `--plan` was set):**\n1. Did the user issue an EXPLICIT apply/implement instruction (\"apply\" / \"go\" / \"implement it\") *after* the plan was reported? β†’ If no, **STOP** β€” you are still in the plan phase\n2. Am I about to treat a plan-refinement sub-ask answer (location, design axis, trade-off) as approval? β†’ **Forbidden.** That answer refines the plan; re-report + STOP\n3. Did I save the plan artifact .md (path + 3-5 line summary only in chat)? β†’ Required in `--plan` mode before any wait\n\n**Plan artifact .md saving (MANDATORY in `--plan` mode)** β€” applies the artifact-path rules:\n\n| Environment detection | Save path | Filename |\n|---------------------|-----------|----------|\n| `{workspace}/.ralph/docs/generated/` exists | `.ralph/docs/generated/plan-fix-{slug}.md` | slug = key keyword (e.g., `consolidate-next-action`) |\n| `{workspace}/.omc/plans/` exists (no Ralph) | `.omc/plans/plan-fix-{slug}.md` | same |\n| Neither exists | Confirm path via AskUserQuestion | β€” |\n\n**Chat output format** (after saving artifact):\n```text\nPlan saved: \n\nKey summary:\n- N target files\n- Key changes ...\n\nSee the file above for details. Reply \"apply\" or with feedback.\n```\n\nDo not re-dump the entire plan body into chat β€” chat shows only path + 3-5 line summary.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Output --plan results only in chat and stop | Save .md to `.ralph/docs/generated/` or `.omc/plans/` and report the path |\n| 2 | Save the artifact but also dump the full plan body in chat | Chat = path + 3-5 line summary only |\n| 3 | Decide \"it's just a draft, no need to save\" | --plan = artifact. Always save |\n| 4 | Treat a mid-flow location / design / trade-off `AskUserQuestion` answer as \"apply\" approval and proceed to Edit/Write/commit | Sub-ask answer refines the plan β†’ re-report + STOP. Execution needs a SEPARATE explicit apply/implement instruction |\n| 5 | Enter `--plan` and skip reading this topic, so the STOP + artifact rules never load | fix SKILL.md Step 2 mandates reading this topic before acting. The `--plan` STOP is also surfaced in SKILL.md's flag description for when the topic is not read |\n\n**Checkpoint (MANDATORY before proceeding to Step 3; in `--plan` mode, only after approval):**\n**Verify that the targets identified at every Why level (1~5) were actually modified before completing Step 2:**\n0. **Was the Step 1.5 Action-plan table physically emitted in this fix's visible output?** If not, the planning step was skipped β€” emit it now (at \"Target file : spot\" granularity) before any further verification. Then confirm each Why row enumerates **all** spots, including multiple spots inside one file. A Why whose target file has N edit spots but only 1 table row = under-enumerated β†’ re-list before proceeding. (Skipping 1.5 emission is the direct cause of \"fixed the output template but missed the procedure/table/self-check\" partial corrections.)\n1. **Iterate over Why 1~5** and enumerate the target file paths each level identified (skills, rules, agents, etc.)\n2. For each file, confirm that Edit/Write was performed in this Step 2\n3. If any target was not modified, **do not advance to Step 3 β€” finish the modifications first**\n4. **Do not pass on \"existing rule not followed\" alone without modifications** β€” if a rule existed but wasn't followed, strengthen its text to be more specific/explicit, or add examples / forbidden patterns. \"Just naming the rule path\" and moving on permits the same mistake to recur\n5. **Do not check only Why 3 while omitting Why 1-2 targets** β€” if Why 2 says \"X causes misunderstanding\", X must be modified\n6. **Verify escalation artifacts**: if this fix is the Nth recurrence, confirm the artifact for\n that count was actually produced in Step 2, per the primary \"4-stage progressive\" matrix\n above (this item does not use a separate numbering): **3rd time** = rule-file edit if the\n 4-filter gate passes (mark the FA entry `status=hook-pending` when filter #3's deterministic\n check looks likely to need automation soon), **4th time** = hook script file + settings.json\n registration + parse-based verification. Missing artifact = Step 2 incomplete.\n - **HARD STOP β€” \"script file authored alone = done\" is FALSE**: hook script + chmod +x + copy to `~/.claude/hooks/` + **`settings.json` PostToolUse/PreToolUse matcher registration + post-registration parse verification (`jq` or `python3 -c \"import json\"`) confirming actual registration** is the full Step 2 deliverable.\n - Mandatory verification command: `python3 -c \"import json; d=json.load(open('~/.claude/settings.json')); ...\"` to confirm the registered hook command is present in the matcher array. Skipping this = Step 2 incomplete.\n - **HARD STOP β€” authoring the script alone is not enough**: a hook is only \"done\" once it is registered AND the registration is parse-verified. Omitting settings.json registration silently disables the hook. (Case history: see failed-attempts.md \"RAG store mandate\".)\n - **HARD STOP β€” registration-verified is not the same as detection-verified**: a hook whose job is to grep the transcript for a pattern (a Skill call, a marker, a keyword) MUST be executed against **real transcript data** before the escalation is declared complete β€” `jq`/`python3 -c \"import json\"` only proves the settings.json entry parses, not that the hook's own logic actually fires or fires correctly. Run the hook directly with a realistic Stop-event payload (`{\"transcript_path\": \"\"}`) piped to it and confirm both: (a) it does NOT block when the target condition is absent, and (b) it DOES block when the target condition is genuinely present. A free-text regex (bare keyword match, no JSON-structure anchor) is especially prone to false-positiving on the target skill's own description text recurring in \"available skills\" system-reminder blocks β€” test explicitly against a transcript excerpt containing that description text. (Case history: see failed-attempts.md \"cleanup missing mandatory Skill calls\" β€” a hook built to catch this was registered and parse-valid, but its regex matched the target skill's own listed description forever, silently disabling the hook indefinitely.)\n7. **Verify IaC constraints**: if the recovery or original work (Resume) touches infrastructure (Ansible, Terraform, docker compose) or server configuration, prove β€” before execution, by 1:1 comparison β€” that the design fully honors your infrastructure rules (e.g. no manual SSH operations on managed hosts, no direct operations on infra-tool-managed services).\n\nFile v0.7.1:step3-resume.md\n\n# Step 3: Resume Original Work\n\n**This is the most important step.** The user's original request must be completed β€” not just the fix itself.\n\n**3-0. Infer user intent (MANDATORY β€” execute before any mechanical task listing)**:\nFrom the user's /fix message (skill args) and session context, infer **\"what outcome does the user want\"**:\n1. **Re-read /fix args**: identify which words the user emphasized and what they said \"must be done\"\n2. **Cross-reference session context**: what is the current state of that work? Code modified but not verified? Not deployed? Not committed?\n3. **Pin down the concrete meaning of \"resolve / complete / proceed\"**: the same word means different things in different contexts. \"Resolve\" = code fix? Through verification? Through deployment? β€” infer from session state\n4. **State the inferred result as one sentence**: \"What the user wants: {concrete action}\". This sentence is the basis for all subsequent task listing\n5. **Specify verification medium (HARD STOP β€” prevent scope reduction)**: copy the medium the user saw (URL, API endpoint, screen path, command output) verbatim. In fix Step 3 verification, **reproduce via that medium directly**. No detoured verification.\n\n| User message | Verification medium (use verbatim in Resume) |\n|--------------|----------------------------------------------|\n| \"/api/system-log?limit=30: HttpError\" | `curl /api/system-log?limit=30` (with cookie) β€” verify response status/body |\n| \"500 on the login screen\" | Playwright on sign-in screen β†’ submit β†’ verify response |\n| \"Error when clicking X button on page Y\" | Playwright on page Y β†’ click X button β†’ verify result |\n| \"File upload failure\" | Reproduce with the same file + same form data via multipart POST |\n\nExample: `/fix start with Critical` + session shows code modified but not verified β†’ \"What the user wants: Playwright verification that the modified code actually works\" + verification medium: the screen path the user reported (e.g., `/dashboard/sso-callback`)\n\n**5.5. Identify \"missing question to user\" (HARD STOP)**:\n\nIf the user's fix args contain expressions like \"you didn't ask / the ask comes first / you skipped it / you should have asked\", the fix's purpose is **to identify the missing question and ask the user directly in Step 3**. Do not autonomously decide the answer.\n\n| User expression | Required action in fix Step 3 |\n|-----------------|-------------------------------|\n| \"you didn't ask X\" | Add an ask for X to the user in Step 3 |\n| \"Y is the ask that comes first\" | Make the first action of Step 3 the Y ask |\n| \"you should have read the prompt, found what was missing, and put it in resume\" | Re-read fix.md / the related skill and specify the missing step (usually an ask) in the Resume step |\n| \"distinguish in-progress vs waiting\" / \"you didn't ask about what's waiting\" | Two separate asks for \"in progress\" + \"waiting on\" (do not merge into one option) |\n\n**Active Task Ask Priority (HARD STOP)**:\nIf an active task has open questions, design choices, trade-offs, or requires user confirmation/decision, presenting `AskUserQuestion` for that active task MUST be the very first action of Step 3. Completing the active work taking into account user decisions is the primary goal; invoking `next` skill or proposing unrelated next steps is forbidden until all active tasks are complete.\n\n**Self-check (every time the fix args contain \"didn't ask / missing ask\" keywords)**:\n1. What specific question did the user want asked? β€” Identify from fix args\n2. Is the asked subject \"in progress\" or \"waiting on\" or both? β€” Split into separate asks if both\n3. Use free-text (Other) instead of guess options β€” assumption options force misalignment with user's real state\n4. Make the ask the **first action** of Step 3, not the last\n\n6. **Recognize user dismissal signals (HARD STOP β€” do not re-raise secondary facts)**: items the user has explicitly dismissed must **not be re-raised** in fix Step 1 verification / Step 3 reporting. Focus on the core work only.\n\n**Dismissal trigger keywords**:\n\n| User expression | Interpretation |\n|-----------------|----------------|\n| \"Just force push over there\" | That remote/branch state is out of verification scope |\n| \"Forget about that\" / \"That's done\" | Item handled or irrelevant β€” do not raise |\n| \"Don't worry about it\" / \"Skip\" | That fact is irrelevant to the core work |\n| \"Already did it\" / \"Handled\" | User handled it directly β€” no re-verification/re-reporting |\n| \"Why do you keep bringing up X\" / \"Again with X\" | Annoyance at secondary mention of X in the prior response β€” return to core immediately |\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Re-report dismissed items under the pretext of \"fact verification\" | Verification is limited to the core work medium. Even if dismissed items appear in git fetch/grep, exclude them from report text |\n| 2 | Statements that \"prove the user's guess wrong\" | Do not fabricate something the user never said and refute it. Quote only what the user said |\n| 3 | After dismissal, re-mention the same fact \"for accuracy\" once more | One dismissal = permanent silence. Same in all follow-up responses |\n| 4 | Continue mentioning X despite annoyance signals (\"damn\", \"why X again\", \"wtf\") | Annoyance signal = ↑ ask priority + immediate return to core. Zero mention of dismissed items from the next response |\n\n**Self-check (every time before writing a response)**:\n1. Did the user dismiss any item in the prior N messages?\n2. If so, does that item appear in this response's text?\n3. If it appears, is it directly tied to the core work? β€” remove if not essential to the core work\n\n**3-0.5. Re-call rejected AskUserQuestion (HARD STOP)**:\n\nIf the turn immediately before fix had **AskUserQuestion rejected + /fix triggered** as the flow, then after fix Resume removes the reject cause, **re-calling ask with improved options** is part of Step 3's deliverable. Do not autonomously decide \"end without re-call\".\n\n**3-0.6. Bypassed Ask Recovery Gate (HARD STOP)**:\n\nIf `/fix` was triggered because an `AskUserQuestion` decision gate (e.g. `/skill-kit route` placement, plan trade-offs, human review questions, prompt improvement plan approval) was omitted or bypassed in the preceding turn/request, **the Resume step MUST execute that exact missing `AskUserQuestion` as its first deliverable action**. Reporting rule/skill updates without calling the bypassed `AskUserQuestion` is a strict Step 3 violation.\n\n## Reject cause classification\n\n| Reject reason | Can fix resolve it? | Resume handling |\n|---------------|---------------------|-----------------|\n| ask **secondary issue** (visual noise, stale context, inaccurate option description) | βœ… Yes | Remove cause in fix Step 2/3 β†’ **re-call ask with improved options** |\n| ask **intent rejection** (user denies the very intent to proceed) | ❌ No | No re-call. End with fix completion report |\n| ask **option mismatch** (the options themselves are wrong) | βœ… Yes | Restructure options β†’ re-call ask |\n| ask **timing mismatch** (preconditions unmet) | βœ… Yes | Satisfy preconditions β†’ re-call ask |\n\n## Don't / Do table\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | AskUserQuestion rejected β†’ fix done β†’ autonomously decide \"end without re-call\" | If fix resolved the reject cause, **re-call with improved options**. Reject β‰  permanent end |\n| 2 | Default-interpret the reject reason as \"user rejects the very intent\" | Determine the reject reason from the user's immediate message (/fix args, annoyance signals). Distinguish intent rejection vs secondary issue |\n| 3 | \"We already asked once; let the user decide on their own\" | A secondary issue that fix resolved leaves the user able to decide via ask. ask = decision trigger |\n| 4 | Re-call by copy-pasting the rejected options verbatim | Reflect the reject cause in description (e.g., note \"Summary cleaned up\" β†’ attestation the user can verify) |\n| 5 | Avoid ask out of \"re-call = nagging\" thinking | Reporting reject-cause resolution + re-calling ask is not nagging. It restores user decision authority |\n\n## Self-check (every time before entering fix Step 3)\n\n1. Was there an **AskUserQuestion call in the turn right before this fix trigger**? β†’ If no, skip this procedure\n2. Was that AskUserQuestion **rejected**? (`The user doesn't want to proceed with this tool use`) β†’ If no, skip\n3. Determine reject reason from immediate user /fix args + annoyance signals β†’ classify as intent rejection vs secondary issue\n4. If it was a secondary issue and fix resolved it β†’ include an **ask re-call** in fix Step 3 (part of the deliverable)\n5. In the re-call's option descriptions, **state the fact fix resolved** as attestation (e.g., \"Summary cleanup complete (only 1 active)\")\n\n## Reject reason default = secondary issue (HARD STOP)\n\nWhen the reject reason is ambiguous, **default to \"secondary issue\" (re-call required)**. \"Intent rejection\" must be evidenced by user message β€” without evidence, treat as secondary.\n\n| Evidence | Classification |\n|----------|----------------|\n| User followed reject with `/fix args` pointing at option/info problem (e.g., \"the options are insufficient\", \"primary source not gathered\", \"you assumed\", \"why didn't you use it\") | **Secondary issue** β€” fix-resolve cause β†’ re-call ask |\n| User explicitly said \"cancel\", \"stop\", \"I won't\" before or after reject | Intent rejection β€” no re-call |\n| User provided primary-source data themselves (e.g., ran `/doctor` and shared output) after reject | **Secondary issue** β€” they wanted primary source first; ask now valid β†’ re-call mandatory |\n| No further user message after reject (silence) | Ambiguous β†’ **default secondary** (re-call with safe options) |\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Default reject reason to \"intent rejection\" β†’ text-only options report β†’ no re-call | Default to secondary issue β†’ re-call with improved options after fix |\n| 2 | User shared primary source after reject β†’ assume \"the user wants to decide for themselves\" β†’ text report only | Primary source share = \"ask now ready\" signal β†’ re-call ask mandatory |\n| 3 | Hesitate to re-call out of \"will the user reject again?\" worry β†’ text options only | Re-call cost β‰ˆ 0. Avoidance is the bigger cost (user anger) |\n\n## Case history\n\nWhen an immediately-preceding ask was rejected and `/fix` cleaned up the reject cause, the completion report must **not** autonomously decide \"end without re-call\" β€” re-call the improved ask. (See failed-attempts.md \"reject re-call\".)\n\n**3-1. Resume existing in_progress tasks (HARD STOP)**:\nIf TaskList had in_progress/pending entries before entering fix, fix Step 3 must **continue executing those tasks** before fix can end. \"Already in TaskList, so no need to separate\" is not resume β€” **actual execution** is resume.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | End fix saying \"existing tasks are in TaskList, so no separation needed\" | Continue executing existing in_progress tasks in fix Step 3 |\n| 2 | Resume only the Resume step's own subject scope and ignore existing tasks | The Resume step's tasks + existing in_progress tasks are **all** resume targets |\n| 3 | Shorten resume with \"login success = verification complete\" | Login is a prerequisite. Run each verification item (countdown, permissions, etc.) individually |\n| 4 | After completing 1 Resume item β†’ switch to AskUserQuestion \"what's next?\" | **Complete all Resume items sequentially**. Completing 1 is not a switch point β€” start the next item immediately |\n| 5 | Sub-task completed β†’ \"this task is done, let's take a breath\" | After sub-task completes, immediately move to the next item of the Resume task. AskUserQuestion only **after all Resume items complete** |\n\n1. Re-read the Resume step's task subject(s) (`fix-5+` in the canonical scheme, not `fix-2` β€” see SKILL.md's naming note) β€” it contains the full list from the initial request to the immediately preceding action\n2. **Classify done/not-done**: confirm the current state of each task (done, in progress, not yet started)\n3. **Multi-substep Resume Breakdown (MINIMUM 5+ STEPS HARD STOP)**: Never collapse the Resume phase into 1 generic single line. Always register explicit sub-items for: (a) plugin/dependency installation (`fix-2`), (b) skill invocation (`fix-3`), (c) empirical fix verification (`fix-4`), (d) code modification / deliverable execution (`fix-5`), (e) verification & walkthrough (`fix-6`). Flattening these into 4 or fewer items is strictly forbidden (`HARD STOP`).\n4. **Identify missing tasks**: list the correct procedure step by step, compare with what actually ran, and find **skipped intermediate steps**. Example: in \"create issue β†’ branch β†’ implement β†’ PR\", if issue creation was skipped, that is the missing task\n3.5. **Retroactive correction of the trigger object (HARD STOP)**: If the `/fix` was triggered because an action on a specific object in the past missed a required step (e.g., \"you missed RAG import when archiving file X earlier\"), **you must retroactively perform the missing step on that exact past object (file X) in Step 3**. Applying the new rule only to tests or future objects is a violation. The object that triggered the fix must be fully corrected.\n4. Register the not-done + missing tasks and execute sequentially\n5. Produce each task's **original deliverable** (e.g., classification table, plan document, deployment result, checklist update)\n6. Verify after completing all tasks\n\n**Step 3 constraints**:\n- **Destructive commands require AskUserQuestion even during fix** β€” `git checkout -- .`, `git reset --hard`, `rm -rf`, etc. must not be executed without approval even under the pretext of \"restoring original work\"\n- **Do not reinterpret user instructions** β€” if fix feedback is ambiguous, confirm via AskUserQuestion. Do not flip interpretations like reading \"don't lose the changes\" as \"delete the changes\"\n\n**Non-destructive verification is autonomous; only the destructive action is ask-gated (HARD STOP)**:\n\nThe destructive-command-requires-ask rule above is **not** a license to defer the *non-destructive verification* that precedes the destructive action. Resume's deliverable includes **autonomously running every read-only verification that informs the gated decision, so the ask is presented WITH the results already in hand** β€” not \"should I even verify?\".\n\nDraw the boundary explicitly:\n\n| Stage | Examples | In resume |\n|-------|----------|-----------|\n| **Non-destructive verification** (no state/infra mutation) | `terraform plan` / Semaphore `dry_run` (after env-parity check), `ansible --check --diff`, `kubectl diff`, `--dry-run=client`, read-only API GET, `git fetch`, build/test in a scratch dir | **Run autonomously.** Part of the Resume deliverable. Surface the diff/plan result |\n| **Destructive / irreversible action** (mutates state, infra, remote) | `terraform apply` / Semaphore real apply, `ansible-playbook` (no --check), `kubectl apply`, `git push`, merge, deploy, `rm`/`reset --hard` | **Ask-gated.** Present the ask carrying the verification result from the stage above |\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Defer the dry-run/plan together with the deploy because \"deploy = user decision\" | Run the dry-run/plan autonomously first β†’ then ask only about the actual apply/deploy, with the plan result attached |\n| 2 | Over-apply \"destructive needs ask\" to its preceding read-only step | Ask gates only the mutation. The read-only verification that feeds the decision is autonomous |\n| 3 | Present a deploy ask with no plan result (\"shall I deploy?\") | Present \"plan shows N add / M change / K destroy β€” proceed with apply?\" β€” the user decides from evidence, not blind |\n| 4 | Skip a known-risky dry-run entirely instead of running it the safe way | If the dry-run itself has a project-specific risk (e.g. Semaphore `dry_run:true` can apply β€” see project rules), satisfy the safe path first (verify env var parity / use local `terraform plan`), then run it. \"Risky β†’ skip\" β‰  \"make it safe β†’ run\" |\n\n**Anti-patterns**:\n- \"Script creation complete. Run it later\" β€” fix's goal is **completing the original work**, not improving tooling. Tooling is the means.\n- **Only reporting \"X is now possible\" and stopping** β€” register the not-done task via TaskCreate and **execute it immediately**. A status report is a precondition for execution, not the result.\n- **Do not stop at file generation (e.g., pr_body.md creation) without executing the actual application update command (e.g., gh pr edit --body-file).** Status report or file generation is not the final deliverable. The final state must be physically applied and verified via the target medium.\n- **Do not assume \"original work already ended, so Resume is unnecessary\"** β€” original work = the **deliverable** the user wanted, not \"the act of invoking a skill/command\". Even if an upper workflow (N steps) was invoked, if one intermediate step was missed, that step's deliverable does not yet exist = original work incomplete. After fix, the missed step must **be run now**.\n- **Do not assume \"session ended, so re-running is impossible\"** β€” most skills are stateless. Only the missed step needs to be run standalone. There's no need to redo the entire upper workflow.\n\n**Forbid verification scope reduction (HARD STOP β€” 2nd recurrence prevention)**:\n\nDo not use a different medium than what the user reported as a detour. Reproduce via the \"verification medium\" specified in fix Step 3-0.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | User reports \"/api/X error\" β†’ substitute verification with login success / other APIs working | Directly call the user-seen `/api/X` via curl/Playwright β†’ verify response status/body |\n| 2 | User reports \"permission error on screen Y\" β†’ after DB ALTER, only confirm admin login | Enter the user-seen screen via admin session β†’ reproduce the same interaction β†’ confirm whether the permission error recurs |\n| 3 | One step (login) passes β†’ assume subsequent steps (permission check / page entry / API call) are OK | Run each subsequent step **individually** for every step in the user-reported medium |\n| 4 | Assume \"logs are clean β†’ normal\" | Logs clean + **the user-medium reproduction response** both required |\n\n**Self-check (every time before reporting verification complete)**:\n1. Did you copy the user's fix-args medium (URL/API/screen) accurately?\n2. Did you call/reproduce directly via that medium?\n3. **Did you write and execute an automated test case / script verifying the fix?** (Text edits alone are invalid without running empirical test commands)\n4. Did you compare the response with the user-reported error to confirm \"normal\" vs same/similar?\n5. Did you avoid detoured verification (different URL, different screen, logs only)?\n\n(Case history: a verification reported \"complete\" after checking only login + dashboard load, while the user-reported API itself still reproduced the error β€” see failed-attempts.md \"verification scope reduction\".)\n\n**Forbid declaring the primary ask \"unrecoverable\"/done and pivoting to a secondary deliverable before exhausting known recovery avenues (HARD STOP)**:\n\nWhen the user's concrete ask is \"get X back\" / \"make Y work again\" (data recovery, restoring a broken state, undoing a loss) and a first pass of checks comes up empty, do not declare it \"irrecoverable\" and move the conversation to a secondary deliverable (a tooling improvement so it won't happen again, a commit, a PR, a doc) as if that discharges the ask. A secondary deliverable is real work, but it is not a substitute progress report for an open primary ask β€” and moving straight into further tool actions (commit/push/PR) right after a partial-effort \"unrecoverable\" conclusion reads to the user as abandoning their actual problem for busywork.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Run 1-2 checks (e.g. grep one directory, diff one backup), find nothing, declare \"genuinely unrecoverable\", then pivot to fixing the tool/process | Enumerate every recovery avenue you already know exists (RAG/semantic index, other synced machines/sync-conflict copies, other backup mechanisms) and actually run each one before concluding \"unrecoverable\" |\n| 2 | Write the recovery-avenue list into a rule/skill as \"only check this if the user asks for more\" | If you know a channel might hold the answer, try it now, in the same turn β€” don't gate it behind a future explicit ask. Deferring your own known checks to \"if user asks\" reproduces the same partial-effort pattern the user is angry about |\n| 3 | Treat \"I improved the tool so this discloses better next time\" as resolving this turn's ask | Ship the tooling fix if warranted, but state plainly, separately, and first: \"the recovery avenues I checked (list them) all came up empty for THIS session β€” here's what's still possible / here's what's truly gone\" |\n| 4 | After a user gets angry that \"the problem isn't solved,\" respond by explaining the git/PR actions you just took | Respond by doing more recovery work (or, if genuinely exhausted, restating precisely what was tried and why nothing more can be tried) β€” not by re-justifying the secondary deliverable |\n\n**Self-check (every time before declaring something unrecoverable / done)**:\n1. What is the user's literal, concrete ask? (not the reframed/tooling version of it)\n2. List every recovery avenue you are aware could exist for this class of problem (RAG/semantic search, other machines, other backup mechanisms, alternate reconstruction paths) β€” did you actually run all of them, or only the first 1-2 that came to mind?\n3. Are you about to pivot to a secondary deliverable (tooling fix, commit, PR, doc) while the primary ask's channel list is only partially checked? β†’ Finish the channel list first\n4. Does your next message lead with the primary ask's status, or does it lead with the secondary deliverable? β†’ Primary ask status must come first, plainly\n\n(Case history: after confirming a session's compact-boundary parentUuid was already unrecoverable via 2 local checks, this deliverable pivoted straight to a tooling-disclosure fix, commit, push, and draft PR without ever checking the RAG/Qdrant index for the same session's pre-break content β€” the user's actual ask was still open. See failed-attempts.md \"premature unrecoverable declaration + pivot to secondary deliverable\".)\n\n**Step 3 mandatory self-questions (MANDATORY before marking the Resume step complete)**:\n1. Did Why analysis identify a \"skipped intermediate step\"? β†’ If yes, that step is the Resume step's **immediate execution target**\n2. Can that step **run standalone now (stateless)?** β†’ If yes, run it unconditionally. \"Original work is done, skip\" is a violation\n3. If the missed step is a skill/tool invocation β†’ it becomes its **own terminal `fix-N` task**; emit the actual tool call **this turn** (not a report that it will run) and mark done only after its result returns. See \"Skill/tool-invocation resume is a first-class task\" below. (Antigravity: represent as an unchecked `task.md` entry that blocks wrap-up β€” see wip/antigravity.md \"Skill-invocation resume\".)\n4. **PR work sync check (HARD STOP)**: If this fix's original work is an active PR (`gh pr list --state open` includes the work's branch), did new feature/fix implementations get reflected in the PR body's Test Plan? β€” `gh pr view --json body` β†’ confirm a `- [ ]` line matching the implemented behavior exists. Missing line = skipped step β†’ add via `gh pr edit --body` before completing the Resume step. Applies even when no test was written: a manually verified behavior still needs a Test Plan line so reviewers know what was checked\n5. **Architectural finding record check (HARD STOP)**: During fix work, was a non-obvious architectural fact discovered (e.g., \"X record has no Y field\", \"API Z silently fails on type W\", \"framework auto-strips Q under condition R\")? If yes, decide its recording medium **before completing the Resume step**:\n - Project-specific structural fact β†’ `CLAUDE.md` (project root) or `/.claude/rules/.md`\n - Reusable across projects β†’ `~/.claude/skills//data/` or `~/.agents/rules/.md`\n - Session-local context only β†’ no record needed\n - \"Code change alone = fix complete\" thinking is a violation. The discovery is **load-bearing knowledge** for the next person (or future session) touching this surface β€” silent loss = the same wall hit again\n6. **Non-destructive verification precedence check (HARD STOP)**: Does completing the original work involve a destructive/ask-gated action (apply, deploy, merge, push)? β†’ If yes, did you **autonomously run the preceding non-destructive verification (dry-run / plan / `--check` / `--dry-run` / read-only diff)** and attach its result to the ask? Presenting the ask without the verification result β€” or deferring the dry-run together with the destructive action β€” is a violation (see \"Non-destructive verification is autonomous\" boundary above)\n\n## Skill/tool-invocation resume is a first-class task β€” same-turn execution (HARD STOP β€” Antigravity drift prevention)\n\nWhen the missed step this fix resumes **is itself a skill or tool invocation** (e.g., \"the `next` skill was not called\", \"consolidate was skipped\", \"the ask was not issued\"), prose instructions to \"execute it in Step 3\" are not enough β€” some runtimes (notably Antigravity/Gemini) narrate the intent and stop instead of emitting the actual tool call, even across repeated retries. Enforce mechanically:\n\n1. **Give the skill/tool call its own granular task** (`fix-N`), never folded into a broader \"resume original work\" line. Its subject names the exact call: `πŸ› οΈ Resume: invoke β€” `.\n2. **It is the terminal action of the fix.** The fix cannot reach Step 4 wrap-up while this task is open. A completion report emitted while this task is unchecked is a Step 3 violation.\n3. **Complete = the tool call actually ran**, not \"reported that it will run\". Marking the task done without the invocation's tool-result present in the transcript is forbidden β€” this is the \"reporting a verb β‰  executing it\" failure applied to the resumed skill call.\n4. **Same turn, not next turn.** Emit the tool call in the same turn the fix reaches this task β€” do not defer to \"the next turn will handle it\". There is no next turn guaranteed to fire.\n\n### Antigravity (Gemini) β€” task.md enforcement\n\nAntigravity tracks via the `task.md` artifact and emulates skills, so a prose \"invoke skill X\" does not reliably trigger a tool call. Represent the resumed skill/tool call as an explicit **unchecked** `task.md` entry and treat that unchecked box as a hard block on wrap-up:\n\n- The entry stays `[ ]` until the skill/tool call has actually executed and returned. Do not pre-check it.\n- Do not write the completion report or clear the task list while the skill-invocation entry is `[ ]`.\n- If the runtime drifts to a report without the call, the correct recovery is to **emit the call now** β€” not to re-explain that it should be called. See wip/antigravity.md \"Skill-invocation resume\" for the task.md notation.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Report \"the next skill should now be invoked\" and end the turn | Emit the actual `Skill(...)`/tool call as the turn's action, then handle its result |\n| 2 | Fold the skill call into a \"Resume original work: {everything}\" one-liner | Give the skill call its own `fix-N` task with the exact call named |\n| 3 | Mark the skill-invocation task done because the plan says to call it | Done only after the call ran and returned β€” verify the tool-result exists |\n| 4 | (Antigravity) pre-check the `task.md` box then narrate the call | Leave `[ ]` until executed; the unchecked box blocks wrap-up |\n\nFile v0.7.1:step4-wrapup.md\n\n# Step 4: Wrap-up (Report + Task Pruning)\n\n**⚠️ Chained /fix Resume integrated execution gate (HARD STOP)**:\n\nIf /fix has been invoked 2+ times in this session, **before** marking fix-* tasks deleted in Step 4, collect **all πŸ”„ Resume tasks** in TaskList and verify outstanding work.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | completedβ†’deleted only the current fix's fix-2 | Collect **every** task in TaskList containing the `πŸ”„ Resume` keyword |\n| 2 | Ignore and delete a prior fix's Resume that is in_progress | **Split prior Resume's outstanding work into separate tasks** before deleting |\n| 3 | Mark each fix complete independently | **Integrate and clean up** outstanding work from all Resumes before bulk-deleting |\n\n**Procedure**:\n1. Call `TaskList` β†’ collect every task containing `πŸ”„ Resume` or `Resume`\n2. Extract outstanding work from each Resume task's description\n3. **Register outstanding work as new tasks** (without the fix-* prefix)\n5. **Suggest Next Actions (Only When ALL Tasks Completed β€” HARD STOP)**: Completing active tasks is top priority. Present active task decision/confirmation (`AskUserQuestion`) FIRST if open questions exist. Invoke `next` / `AskUserQuestion` for next actions ONLY when ALL registered tasks in `task.md` or `TaskList` are 100% completed (`[x]`). If uncompleted tasks (`pending` or `in_progress`) remain or active task asks exist, DO NOT invoke `next` or present next action options β€” directly proceed to complete the task or ask the active decision item in the same turn.\n6. **Call `Skill(\"next\")` after the wrap-up report when the batch is complete (HARD STOP β€” the mirror of step 5)**: step 5 forbids a premature `next`; this step forbids the omitted one. When every registered task IS completed and the turn is ending on the wrap-up report, the same turn MUST include a `Skill(\"next\")` call (its own gates then decide whether an ask follows). A **mid-turn AskUserQuestion on another axis** (push confirmation, trade-off answer, option selection) does NOT substitute for this call. Do not rely on the Stop-hook safety net: on a continuation chain (a turn resumed from an earlier Stop-hook block), the harness suppresses every later stop's hooks (`stop_hook_active` loop prevention), so long chained /fix turns are precisely where only the explicit call fires (next-invocation family recurrence evidence).\n **Context-gate precheck (HARD STOP β€” run immediately BEFORE the `Skill(\"next\")` call)**: re-measure live context usage via the injection script first. A below-threshold reading from earlier in the turn/chain is **stale-LOW** and proves nothing β€” a full /fix flow can grow usage tens of points past the old number. If the live reading is at/above the session model's threshold (or the script emits a `CLEANUP-GATE` directive), lead the turn-final ask with a **Recommended cleanup/retrospective option citing the live percentage** β€” next-action candidate discovery becomes secondary and may be skipped (recommend cleanup instead of composing next-action candidates).\n\n\n```text\nFix complete:\n- πŸ” Root cause: {what was missing}\n- πŸ”§ Improvement: {which file was modified and how}\n- πŸ”„ Current fix: {result of fixing the current issue} (Note: any referenced PRs/Issues must use clickable links `[PR #N](URL)`)\n- πŸ“‹ Wrap-up: {fix-* tasks deleted, outstanding work separated}\n```\n\n**Section emoji prefix matches fix-* task emojis (HARD STOP)**: The report's section prefix must use the same emojis as the fix-0/1/2/3 task emojis registered in Step 0. This keeps section identity consistent between the registered task and its report deliverable. Do not omit the emoji or substitute different ones.\n\n| Task (Step 0) | Report section |\n|---------------|---------------|\n| πŸ” fix-0 (root cause analysis) | πŸ” Root cause |\n| πŸ”§ fix-1 (root cause fix) | πŸ”§ Improvement |\n| πŸ”„ fix-2 (Resume original work) | πŸ”„ Current fix |\n| πŸ“‹ fix-3 (Wrap-up: report + task pruning) | πŸ“‹ Wrap-up |\n\n**Outstanding-work separation guard (HARD STOP β€” required before deleting fix-* tasks)**:\n\nIf fix-2 (Resume Original Work) contains outstanding work, **separate by medium per status** before deleting fix-* tasks:\n\n## Medium separation principle (HARD STOP)\n\n| Status | Example | Medium (TaskList vs checklist) |\n|--------|---------|--------------------------------|\n| Hold (user decision) | \"Track B is next session\", \"Playwright on hold\" | **TaskList**: when actionable |\n| Partial completion | Track A done, Track B not run | **TaskList**: separate task for Track B |\n| Awaiting follow-up verification | Awaiting CI pass, awaiting merge review | **TaskList**: can trigger verification |\n| **Awaiting external response (BLOCKED)** | Awaiting owner reply, external API lock, awaiting permission grant | **Register in fix_plan.md hold section (no task)** |\n| **Cannot proceed autonomously** | Items that cannot move one step without user decision/external action | **fix_plan.md hold section** |\n\n**Why is BLOCKED forbidden as a task?**\n- TaskList = \"tracking actionable work\" medium. Only register items that can be auto-triggered\n- BLOCKED = no external trigger means no progress β†’ tracking it as a task adds no value beyond \"still BLOCKED\" reports each session\n- fix_plan.md hold section = \"carry over to next session + trigger when external response arrives\" information preservation\n- Registering an item in both media only adds sync burden\n\n## Don't / Do table\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Register external-wait items in both a separate task and fix_plan | Register only in fix_plan.md hold section. No task creation |\n| 2 | Create a task with subject \"[BLOCKED] awaiting reply on xxx\" | Use fix_plan.md `## Hold` section in the form `- [ ] [BLOCKED] xxx (... awaiting reply, trigger: ...)` |\n| 3 | \"Register as task so the user doesn't forget\" thinking | fix_plan.md is reloaded at each session start, so it won't be forgotten. The checklist is sufficient |\n| 4 | Keep both checklist and task entries to \"strengthen safety\" | Duplicate media = mismatch risk. Unify to a single medium |\n\n## Self-check procedure (before deleting fix-3)\n\n1. Re-read fix-2 subject + body β†’ extract the full list of original work\n2. Classify each item's status:\n - (a) Done β€” task completed\n - (b) Actionable hold / partial completion / verification needed β€” register as a separate task in **TaskList**\n - (c) **BLOCKED (external response/permission)** β€” register in **fix_plan.md hold section (no task)**\n3. fix-* tasks may only be deleted after (b) and (c) are reflected in their media\n4. If a wrong BLOCKED task is found β†’ immediately delete + transfer to fix_plan.md\n\n**Violation patterns**:\n- fix-2 \"resume original work\" scope had Track A + B; completed only Track A and marked fix-2 completed β†’ deleted\n- Misclassifying a user-held item as \"done\"\n- Losing outstanding-work information for the sake of TODO list cleanliness\n\n**Correct flow** (example):\n- Before marking fix-2 complete: register Track B (the unfinished verification) as a separate task β†’ fix-2 completed β†’ fix-* deleted\n\n**After reporting + outstanding-work separation verified, delete all `fix-*` TODO items created in Step 0** β€” fix TODOs are temporary session-level tracking only; outstanding work is preserved in separate tasks while only `fix-*` are cleaned up.\n\n## fa-record ⟺ rule/skill-edit symmetry gate (HARD STOP)\n\nA fix produces TWO independent deliverables that must **both** exist (or neither, when nothing was strengthened): (a) the prevention-medium edit (rule / skill / hook / memory), and (b) the failed-attempts.md HOT case-body record (per the Step 2 escalation matrix β€” recorded at every stage). Completing only one side is a recurring asymmetry, in both directions.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Strengthen a rule/skill body and skip the fa HOT case record | If any rule/skill/hook was edited this fix, verify the case body is in failed-attempts.md HOT. Record it before pruning |\n| 2 | Record the case in fa HOT but leave the owning skill/rule procedure defect unfixed | Both directions: case in fa + structural fix in the owning skill/rule |\n| 3 | Treat \"rule edited\" (or \"ad-hoc rule edit without /fix\") as the whole fix | Rule edit = prevention; fa record = case history. Separate deliverables, both mandatory. A behavior correction done **outside** /fix still owes both β€” re-enter the fix flow |\n\n**Self-check (before deleting fix-3)**: Did this fix (or this session's preceding ad-hoc correction) edit any rule/skill/hook? β†’ If yes, `grep` failed-attempts.md HOT for this case's keyword. Absent = record the case body now, before pruning.\n\n> See `step2-improvement.md` \"Case history medium\" + `fix/SKILL.md` for the full `failed-attempts.md` HOT path. Consumers who installed only `fix/` (without the owning skill that hosts `failed-attempts.md` HOT) must wire the path via their environment.\n\n**[Measure 3] Status-based pruning of completed tasks (MANDATORY β€” HARD STOP)**:\n\nThe cleanup-step prune target is **status-based, not prefix-based**. Cleaning up only `fix-*` and leaving the original-work tasks behind is a violation.\n\n## Prune target matrix\n\n| Task kind | Status | Cleanup target? |\n|-----------|--------|-----------------|\n| **fix-\\*** | completed | βœ… mark deleted |\n| **fix-\\*** | in_progress / pending | ❌ keep (work incomplete) |\n| **original-work tasks** (created this session) | completed | βœ… mark deleted |\n| **original-work tasks** (created this session) | in_progress / pending | ❌ keep (outstanding work) |\n| **remaining actionable task** (not awaiting external response) | pending | ❌ keep |\n| **BLOCKED task** (awaiting external response) | pending | ❌ keep + consider transferring to the fix_plan.md hold section |\n| **stale tasks from a prior session** | any status | delete only on explicit user instruction (no autonomous deletion) |\n\n## Don't / Do table\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Mark only `fix-*` tasks deleted and keep the completed original-work tasks | Mark **all completed tasks created this session** deleted (both `fix-*` and original work) |\n| 2 | Assume \"only the `fix-*` prefix is the cleanup target\" | The prefix is just an identifier. The criteria are **status (completed) + creation time (this session)** |\n| 3 | Keep completed original-work tasks \"just in case, for history tracking\" | TaskList is for tracking active work. Completed history is preserved in git log / fix_plan.md / report text. Keeping it in TaskList is stale noise |\n| 4 | Bulk-delete down to remaining pending tasks too | pending = outstanding work. Keeping it is correct. Distinguish status clearly |\n| 5 | Clean up stale tasks from a prior session along with these | Only this session's tasks are cleanup targets. Prior-session tasks need a separate decision (user instruction) |\n\n## Self-check (every time before marking fix-3 deleted)\n\n1. **Call `TaskList`** to read the full task state\n2. Identify the tasks created this session (both `fix-*` and original work)\n3. Classify by status:\n - completed β†’ cleanup target\n - in_progress / pending β†’ keep\n4. Mark all completed (`fix-*` + original work) tasks deleted\n5. State the keep reason for remaining pending tasks in the report\n\n## Case history\n\nA session completed all of its original-work tasks plus the fix-* tasks, but only fix-* were pruned β€” the completed original-work tasks lingered as stale noise. This is what the status-based (not prefix-based) rule prevents. (See failed-attempts.md \"status-based prune\".)\n\nFile v0.7.1:LICENSE\n\nMIT License\n\nCopyright (c) 2026 es6.kr\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n\nArchive v0.7.0: 11 files, 57353 bytes\n\nFiles: behavior-discipline.md (6448b), CHANGELOG.md (14211b), LICENSE (1063b), resources/fix-and-ambiguity-guard.sh (3874b), scripts/detect-agent-env.sh (2030b), skill-card.md (1766b), SKILL.md (41708b), step2-improvement.md (31142b), step3-resume.md (27909b), step4-wrapup.md (11568b), _meta.json (122b)\n\nFile v0.7.0:SKILL.md\n\n---\nmetadata:\n author: es6kr\n version: \"0.1.6\"\nname: fix\ndepends-on:\n - cleanup\ndescription: |\n User behavior correction skill. Triggered by \"fix:\" prefix feedback (e.g., \"fix: why didn't you commit?\").\n Analyzes the mistake, improves the relevant prompt (skill/rule/agent/memory/hook) to prevent recurrence,\n then fixes the current issue. TodoWrite required for all steps.\n Use when \"fix:\", \"fix this\", \"correct\", \"why not\", \"why missing\", \"behavior fix\" is mentioned.\n---\n\n# Fix: Behavior Correction & Work-Resume Skill\n\nActivated when user gives feedback with \"fix:\" prefix. Finds the root cause of the mistake, improves the relevant prompt (skill/rule/agent/memory/CLAUDE.md/hook), and **seamlessly resumes and completes the interrupted original work (`Fix -> Resume` Complete Workflow)**.\n\n> πŸ’‘ **Core Identity of `/fix`**: `/fix` is NOT a tool that only patches rules and stops. The primary purpose of this skill is the **complete two-phase flow: `Fix (5-Why & Prompt Improvement) βž” Resume (Complete the original interrupted deliverable & hand over to next work)`**. Stopping after rule modification without fully executing and delivering the original work is a fundamental failure of this skill.\n\n\n## Trigger\n\n- Messages with `fix:` prefix\n- Behavior correction feedback: \"fix this\", \"correct\", \"why not\", \"why missing\"\n\n## Options\n\n- `--plan`: In Step 2, instead of modifying prompts directly, **emit only the modification plan** for user review before execution. Use for complex changes or changes spanning multiple files. **Forced Ask (HARD STOP)**: After saving the plan artifact .md and presenting the summary, you MUST invoke `AskUserQuestion` instead of stopping at plain text, forcing an explicit user decision.\n - **Trade-off-axis questions FIRST, disposition LAST (HARD STOP β€” applies to ANY /fix flow that authors or promotes a plan artifact, not only `--plan`)**: a generic disposition-only ask (`Apply plan now` / `Refine plan` / `Hold`) is FORBIDDEN when the plan contains Trade-offs rows or unresolved human-review questions (open interpretation notes, \"confirm on review\" markers). Convert **each** trade-off axis / open review question into its own question object in the `questions` array (one axis per question, max 4 per call β€” chunk sequential calls when more, never drop the tail), then ask the disposition (`Apply plan now` / `Refine plan` / `Hold`) as the **last** question or a follow-up call. Recurrence source: a promote-completion ask that offered only approve/refine/hold caused the user to re-request the trade-off review manually.\n- `--local`: Scope Step 2 rule modifications to the **workspace-local** or **project-local** rule directory only. Use when the rule applies to a specific workspace (e.g., `~/ghq/github.com//`) or a specific repo, not globally.\n - Resolution order (Step 2 picks the innermost matching location):\n 1. **Project-local** β€” `/.claude/rules/` or `/.agents/AGENTS.md` if cwd is inside a git repo\n 2. **Workspace-local** β€” nearest `.claude/rules/` or `/.agents/AGENTS.md` walking up from cwd\n 3. **Fallback** β€” if neither exists, ask the user whether to create one (do NOT silently fall through to global `~/.agents/rules/` or global `~/.agents/GEMINI.md`)\n - **Do not** write to `~/.agents/rules/` or `~/.agents/GEMINI.md` (and its symlinks like `~/.gemini/GEMINI.md`) when `--local` is set. Global rule files are synced across devices via chezmoi/Syncthing; `--local` opts into workspace/project-scoped protection only.\n - Rule-file location + strength still respect the `rule-management.md` location-plus-method dual-axis ask when the scope choice within the local set is ambiguous (project vs workspace).\n\n## Topic Dispatch\n\n**When this skill is invoked with a topic specifier (e.g., `/fix step3-resume` or `Skill(\"fix\", \"step3-resume\")`), load and follow only the matching topic file. Do not echo the Topics table or summarize other topics in the response.** The Topics table below is an index β€” for a normal `/fix` invocation, execute the Procedure below and Read each step's topic file when you reach that step.\n\n## Topics\n\nThe core procedure (Step 0 β†’ 4) lives below. Heavy step detail is split into topic files β€” **Read the matching topic before executing that step**.\n\n| Topic | Description | Guide |\n|-------|-------------|-------|\n| step2-improvement | Step 2 detail: 4-filter gate, escalation matrix, `--plan`, Checkpoint | [step2-improvement.md](./step2-improvement.md) |\n| step3-resume | Step 3 detail: intent inference, reject re-call, verification guard | [step3-resume.md](./step3-resume.md) |\n| step4-wrapup | Step 4 detail: repo\n\nArchive v0.6.2: 11 files, 56746 bytes\n\nFiles: behavior-discipline.md (6448b), CHANGELOG.md (13915b), LICENSE (1063b), resources/fix-and-ambiguity-guard.sh (3874b), scripts/detect-agent-env.sh (2030b), skill-card.md (2521b), SKILL.md (39412b), step2-improvement.md (31142b), step3-resume.md (27909b), step4-wrapup.md (11568b), _meta.json (122b)\n\nArchive v0.6.1: 11 files, 56430 bytes\n\nFiles: behavior-discipline.md (6448b), CHANGELOG.md (13597b), LICENSE (1063b), resources/fix-and-ambiguity-guard.sh (3874b), scripts/detect-agent-env.sh (2030b), skill-card.md (1962b), SKILL.md (39412b), step2-improvement.md (31142b), step3-resume.md (27909b), step4-wrapup.md (11568b), _meta.json (122b)\n\nArchive v0.6.0: 11 files, 55889 bytes\n\nFiles: behavior-discipline.md (6448b), CHANGELOG.md (13158b), LICENSE (1063b), resources/fix-and-ambiguity-guard.sh (3874b), scripts/detect-agent-env.sh (2030b), skill-card.md (1873b), SKILL.md (38181b), step2-improvement.md (31142b), step3-resume.md (27909b), step4-wrapup.md (11568b), _meta.json (122b)\n\nArchive v0.5.0: 11 files, 56002 bytes\n\nFiles: behavior-discipline.md (6448b), CHANGELOG.md (12886b), LICENSE (1063b), resources/fix-and-ambiguity-guard.sh (3874b), scripts/detect-agent-env.sh (2030b), skill-card.md (2446b), SKILL.md (38181b), step2-improvement.md (31142b), step3-resume.md (27909b), step4-wrapup.md (11568b), _meta.json (122b)\n\nArchive v0.4.2: 11 files, 55463 bytes\n\nFiles: behavior-discipline.md (6448b), CHANGELOG.md (12121b), LICENSE (1063b), resources/fix-and-ambiguity-guard.sh (3874b), scripts/detect-agent-env.sh (2030b), skill-card.md (1954b), SKILL.md (38005b), step2-improvement.md (31142b), step3-resume.md (27909b), step4-wrapup.md (11568b), _meta.json (122b)\n\nArchive v0.4.1: 11 files, 55168 bytes\n\nFiles: behavior-discipline.md (6448b), CHANGELOG.md (11666b), LICENSE (1063b), resources/fix-and-ambiguity-guard.sh (3874b), scripts/detect-agent-env.sh (2030b), skill-card.md (2489b), SKILL.md (37068b), step2-improvement.md (31142b), step3-resume.md (27909b), step4-wrapup.md (11568b), _meta.json (122b)\n\nArchive v0.4.0: 10 files, 52763 bytes\n\nFiles: behavior-discipline.md (6448b), CHANGELOG.md (10602b), LICENSE (1063b), resources/fix-and-ambiguity-guard.sh (3874b), skill-card.md (2612b), SKILL.md (34937b), step2-improvement.md (31142b), step3-resume.md (27909b), step4-wrapup.md (10894b), _meta.json (122b)\n\nArchive v0.3.12: 10 files, 51791 bytes\n\nFiles: behavior-discipline.md (6448b), CHANGELOG.md (9407b), LICENSE (1063b), resources/fix-and-ambiguity-guard.sh (3730b), skill-card.md (2341b), SKILL.md (34279b), step2-improvement.md (30882b), step3-resume.md (27909b), step4-wrapup.md (10894b), _meta.json (123b)","readmeExcerpt":"Skill: fix Owner: drumrobot Summary: User behavior correction skill. Triggered by \"fix:\" prefix feedback (e.g., \"fix: why didn't you commit?\"). Analyzes the mistake, improves the relevant prompt (skill/rule/agent/memory/hook) to prevent recurrence, then fixes the current issue. TodoWrite required for all steps. Use when \"fix:\", \"fix this\", \"correct\", \"why not\", \"why missing\", \"behavior fix\" is mentioned. Tags: latest","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"# If 8 existing tasks exist, call with a 12-item array adding fix-* 4\nTodoWrite([\n ...existing_8_tasks, # ← replace with the actual 8 existing task objects, not a literal spread\n { content: \"πŸ” fix: {summary} β€” root cause analysis\", status: \"in_progress\" },\n { content: \"πŸ”§ Root cause fix\", status: \"pending\" },\n { content: \"πŸ”„ Resume original work: {one-line summary of original work}\", status: \"pending\" },\n { content: \"πŸ“‹ Wrap-up: report + task pruning\", status: \"pending\" },\n])"},{"language":"text","snippet":"# Ignoring existing tasks and registering only 4 fix-* β†’ all existing tasks vanish\nTodoWrite([\n { content: \"πŸ” fix: ...\", status: \"in_progress\" },\n { content: \"πŸ”§ Root cause fix\", status: \"pending\" },\n { content: \"πŸ”„ Resume original work: ...\", status: \"pending\" },\n { content: \"πŸ“‹ Wrap-up: report + task pruning\", status: \"pending\" },\n]) # ❌ Existing task data is lost"},{"language":"text","snippet":"TodoWrite([\n { id: \"fix-0\", content: \"πŸ” fix: {user feedback summary} β€” 5-Why root cause analysis\", status: \"in_progress\" },\n { id: \"fix-1\", content: \"πŸ”§ Prompt improvement plan (Step 1.5 Action Plan table & AskUserQuestion approval)\", status: \"pending\" },\n { id: \"fix-2\", content: \"πŸ”Œ Plugin/Dependency installation (if required) & environment parity check\", status: \"pending\" },\n { id: \"fix-3\", content: \"πŸ› οΈ Skill/Tool invocation & official autoloader execution (view_file IsSkillFile)\", status: \"pending\" },\n { id: \"fix-4\", content: \"πŸ§ͺ Empirical Fix Verification (verify fix actually works in current execution)\", status: \"pending\" },\n { id: \"fix-5\", content: \"πŸ”„ Resume original work: {granular breakdown step 1}\", status: \"pending\" },\n { id: \"fix-6\", content: \"πŸ”„ Resume original work: {granular breakdown step 2}\", status: \"pending\" },\n { id: \"fix-7\", content: \"πŸ“‹ Wrap-up & AskUserQuestion next options\", status: \"pending\" },\n])"},{"language":"text","snippet":"Why 1 (Symptom): What went wrong? (the immediate mistake)\nWhy 2 (Judgment): Why did I make that decision? (missing knowledge / flawed assumption)\nWhy 3 (Structural): What rule/prompt must be fixed to prevent recurrence? (target skill/rule/hook)\nWhy 4 (Interrupted Work): What was the original user request / deliverable that was interrupted by this failure?\nWhy 5 (Next Resume Action): What concrete actions must be executed NEXT to completely finish and deliver that original work?"},{"language":"text","snippet":"| Why | Target file : spot | Action |\n|-----|--------------------|--------|\n| Why 1 | (current issue β€” symptom) | Root cause understanding |\n| Why 2 | : judgment section | Add judgment rule |\n| Why 3 | : procedure/gate | Add structural gate & prompt fix |\n| Why 4 | (interrupted original work) | Identify original deliverable scope |\n| Why 5 | (target deliverable/tool) | Step 3 Resume: execute concrete next actions to finish original work |"},{"language":"markdown","snippet":"| # | Don't | Do |\n|---|-------|-----|\n| 1 | {violation pattern} | {correct pattern} |"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nmetadata:\n author: es6kr\n version: \"0.1.6\"\nname: fix\ndepends-on:\n - cleanup\ndescription: |\n User behavior correction skill. Triggered by \"fix:\" prefix feedback (e.g., \"fix: why didn't you commit?\").\n Analyzes the mistake, improves the relevant prompt (skill/rule/agent/memory/hook) to prevent recurrence,\n then fixes the current issue. TodoWrite required for all steps.\n Use when \"fix:\", \"fix this\", \"correct\", \"why not\", \"why missing\", \"behavior fix\" is mentioned.\n---\n\n# Fix: Behavior Correction & Work-Resume Skill\n\nActivated when user gives feedback with \"fix:\" prefix. Finds the root cause of the mistake, improves the relevant prompt (skill/rule/agent/memory/CLAUDE.md/hook), and **seamlessly resumes and completes the interrupted original work (`Fix -> Resume` Complete Workflow)**.\n\n> πŸ’‘ **Core Identity of `/fix`**: `/fix` is NOT a tool that only patches rules and stops. The primary purpose of this skill is the **complete two-phase flow: `Fix (5-Why & Prompt Improvement) βž” Resume (Complete the original interrupted deliverable & hand over to next work)`**. Stopping after rule modification without fully executing and delivering the original work is a fundamental failure of this skill.\n\n\n## Trigger\n\n- Messages with `fix:` prefix\n- Behavior correction feedback: \"fix this\", \"correct\", \"why not\", \"why missing\"\n\n## Options\n\n- `--plan`: In Step 2, instead of modifying prompts directly, **emit only the modification plan** for user review before execution. Use for complex changes or changes spanning multiple files. **Forced Ask (HARD STOP)**: After saving the plan artifact .md and presenting the summary, you MUST invoke `AskUserQuestion` instead of stopping at plain text, forcing an explicit user decision.\n - **Trade-off-axis questions FIRST, disposition LAST (HARD STOP β€” applies to ANY /fix flow that authors or promotes a plan artifact, not only `--plan`)**: a generic disposition-only ask (`Apply plan now` / `Refine plan` / `Hold`) is FORBIDDEN when the plan contains Trade-offs rows or unresolved human-review questions (open interpretation notes, \"confirm on review\" markers). Convert **each** trade-off axis / open review question into its own question object in the `questions` array (one axis per question, max 4 per call β€” chunk sequential calls when more, never drop the tail), then ask the disposition (`Apply plan now` / `Refine plan` / `Hold`) as the **last** question or a follow-up call. Recurrence source: a promote-completion ask that offered only approve/refine/hold caused the user to re-request the trade-off review manually.\n- `--local`: Scope Step 2 rule modifications to the **workspace-local** or **project-local** rule directory only. Use when the rule applies to a specific workspace (e.g., `~/ghq/github.com//`) or a specific repo, not globally.\n - Resolution order (Step 2 picks the innermost matching location):\n 1. **Project-local** β€” `/.claude/rules/` or `/.agents/AGENTS.md` if cwd is inside a git repo\n 2. **Work"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn74k8yfvftx6f062qa8fzyd8h8373jd\",\n \"slug\": \"fix\",\n \"version\": \"0.7.1\",\n \"publishedAt\": 1791273343634\n}"},{"path":"behavior-discipline.md","content":"# Behavior Discipline β€” destructive commands / multi-repo tracking / chained fix / angerβ†’TDD switch\n\nThis topic bundles the behavior-discipline rules that fire during the fix flow.\n\n## Destructive-command restraint (HARD STOP)\n\n**Never run filesystem/index-destroying commands (`git reset --hard`, `git checkout -- .`, `rm -rf`, etc.) for the purpose of reverting or resetting work without prior coordination and user approval.** When a reset is unavoidable (e.g., undoing a temporary commit), step through a non-destructive alternative (`git reset --soft` / `git reset HEAD~1` followed by per-file `git restore`) and perform it safely.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Run `git reset --hard HEAD~1` to destructively drop a temporary local commit | Use `git reset --soft HEAD~1` or `git reset HEAD~1` to release the commit while preserving changes, then apply per-file `git restore` if needed |\n| 2 | Unilaterally run `git checkout -- .` or `git restore .` to wipe all working-directory edits at once | Keep open the possibility that changes must be preserved; restore carefully per file, or roll back safely only after user confirmation |\n\n## Multi-repository original-work tracking and context discrimination (HARD STOP)\n\n**When you receive an error report or `/fix` feedback while switching back and forth across multiple projects (repositories), do not get trapped in the narrow view of the currently active directory β€” replay the whole session history.** Identify which target repository was the \"Original Work\" (the recent build error, push failure, or edit target) and **cross-verify via the full local repository state** (`git status`, `git log`) before switching to the correct target and handling the work.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Get a commit-convention error in repo A but, absorbed in repo B (recently edited), try to fix the wrong commit | Read the feedback, switch the working directory immediately to repo A where the bad commit actually exists, and amend the correct commit |\n| 2 | When the subject of the user's feedback is omitted during multi-project work, impulsively assume the current folder is the target and edit it | Quickly tour each workspace running `git status` or `git log -n 5` to determine which project holds the error target |\n\n## Chained-fix dependency declaration and completed-task pruning (HARD STOP)\n\n**On `/fix`, the registered `fix-2 (Resume)` task must declare the preconditions under which the work can run safely β€” to prevent configuration damage from stale execution** β€” and during the session `cleanup` step, prune **only completed (`[x]`) tasks**; do not unilaterally delete in-progress or held (stale) incomplete tasks.\n\n| # | Don't | Do |\n|---|-------|-----|\n| 1 | Register only the bare `Resume` command on the `fix-2` task without preconditions (Depends on) and base commit SHA (Reference commit) | Record preconditions and snapshot, e.g. `- [ ] fix-33: πŸ”„ Resume original work: ... (Depends on: