From 0d36d3a06654eaccc8cc6539aefa8bc44fc0ed8e Mon Sep 17 00:00:00 2001 From: Ryota Ikezawa Date: Mon, 14 Sep 2026 17:54:46 +0900 Subject: [PATCH 1/6] chore(context): remove orphaned zero-cost-scaling rule from deployed targets The rule was converted to a skill of the same name, but the source deletion only made chezmoi forget the entry; ~/.claude/rules/zero-cost-scaling.md stayed deployed and billed 1,749 always-on chars per turn. The skill body is byte-identical, so nothing is lost. Same gap .chezmoiremove already closes for the superseded writing skills. Co-Authored-By: Claude Fable 5.1 --- home/.chezmoiremove | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/home/.chezmoiremove b/home/.chezmoiremove index 77f7415..919338e 100644 --- a/home/.chezmoiremove +++ b/home/.chezmoiremove @@ -8,3 +8,7 @@ .claude/skills/article-writing .claude/skills/technical-writing .claude/skills/japanese-ai-writing-proofreader +# +# Moved to home/dot_claude/skills/zero-cost-scaling (identical body); the rule +# copy kept billing 1.7K chars on every turn on machines that applied before. +.claude/rules/zero-cost-scaling.md From f0a031cff9353423f2b17007717fbe3174561af3 Mon Sep 17 00:00:00 2001 From: Ryota Ikezawa Date: Mon, 14 Sep 2026 17:57:04 +0900 Subject: [PATCH 2/6] chore(context): cut workflow.md from 7.2K to 3.6K chars Every removed line had a home elsewhere in the always-on set or in a deterministically loaded rule: - "Demand Elegance" and "Systematic Bug Fixing" restate the Simplicity ladder and "bug fix = root cause" in development-principles.md; the failing-test-first line lives in the paths:-scoped tdd.md, which fires at the moment code is edited - "Task Management" restated harness defaults (task tracking, plan approval); the one line with no other home (capture corrections in memory) moved to Planning - The model-tier table duplicated the agent frontmatter and the agent list the harness already injects; what the table added that nothing else carries (haiku override, advisor limits, sonnet[1m] billing, the CLAUDE_CODE_SUBAGENT_MODEL precondition) survives as bullets - Worktree-location rationale compressed to one clause; the constraint and the 114K-token measurement stay verbatim Co-Authored-By: Claude Fable 5.1 --- home/dot_claude/rules/workflow.md | 91 ++++++------------------------- 1 file changed, 18 insertions(+), 73 deletions(-) diff --git a/home/dot_claude/rules/workflow.md b/home/dot_claude/rules/workflow.md index 623c402..7df196c 100644 --- a/home/dot_claude/rules/workflow.md +++ b/home/dot_claude/rules/workflow.md @@ -2,85 +2,30 @@ ## Planning -- For non-trivial tasks (3+ steps or architectural decisions): **brainstorm → design → plan** in that order - - Brainstorm: explore user intent, ask one question at a time, propose 2-3 approaches with tradeoffs - - Design: get incremental approval on each section before proceeding - - Plan: break into checkable items only after design is agreed upon -- If something goes sideways, STOP and re-plan immediately -- Use plan mode for verification steps, not just building -- Write detailed specs upfront to reduce ambiguity - -## Subagent Strategy - -Delegation is decided here and nowhere else. When the harness default says not to spawn agents unasked, that default wins — what follows describes _how_ to delegate once delegation is warranted, not a standing instruction to delegate. - -### Whether to delegate at all - -Spawning costs a fixed ~10K tokens before any work happens: every subagent re-reads this rule set plus the repo's CLAUDE.md and git status, and re-reads the target files the caller already has. Measured 2026-07-25: three agents that accomplished nothing burned 114K tokens. Weigh that fixed cost against what staying inline would add to the caller's own history. - -- Delegate when the work dwarfs the spawn cost, when it needs isolation from the caller's context, or when whoever generates it must not be the one who evaluates it -- Stay inline for small, high-frequency tasks — the fixed cost is paid per call, so inline usually wins on total tokens -- On a 1M-context session, context hygiene alone does not justify a spawn -- Codex (`codex-subagent`) is for when an independent model's read is the point — cross-model review, a second opinion on a diagnosis — or when the user asks for it by name. It is not the default owner of ordinary coding work - -### Model Tiers - -| Role | Model | How | -| :------------------------------------------ | :----------------------------------------- | :------------------------------------------------------------------------------------- | -| Planning, design, architecture, evaluation | Main session (opus; fable for the hardest) | stay in main process | -| Mid-task escalation at decision points | advisor (fable) | `/advisor fable` — the advisor reads the live transcript and returns guidance | -| Implementation from an approved plan | sonnet | `implementer` agent (`~/.claude/agents/`) | -| Mechanical single-file edits, grunt work | haiku | `implementer` with `model: haiku` override | -| First-pass diff screening (spec compliance) | sonnet | `spec-reviewer` agent (read-only); main session adjudicates its findings | -| Adversarial claim verification | sonnet | `skeptic` agent (read-only); refutes audit findings / hypotheses before acting on them | -| Exploration / research fan-out | Explore agent | read-only; return conclusions, not file dumps | - -- The dispatcher never implements what it will evaluate; the implementer never evaluates its own diff -- On subscription plans (incl. Max), `sonnet[1m]` bills usage credits — for >200K-context tasks, split the task or escalate to `opus` (1M included) instead -- Precondition: `CLAUDE_CODE_SUBAGENT_MODEL` must stay unset (it overrides every per-agent model choice) -- The advisor escalates up (approach choice, recurring errors, pre-completion checks) while subagent tiers delegate down — they compose; an opus main with a fable advisor is a valid pair -- The advisor runs without tools and only reads the transcript: useful for plans and risk checks, but it does NOT satisfy generator-evaluator separation (the evaluator must test behavior) -- Constraints: a fable main session accepts only `fable` as advisor; through a business LLM gateway the advisor tool is not guaranteed to work - -### Subagent-Driven Development (default for implementation) +- Non-trivial tasks (3+ steps or an architectural decision): **brainstorm → design → plan**, in that order. Brainstorm asks one question at a time and offers 2-3 approaches with tradeoffs; design gets each section approved before the next; plan breaks the agreed design into checkable items +- If something goes sideways, stop and re-plan before continuing +- After any correction from the user, capture the pattern in persistent memory so it survives the session -- Once a plan exists, dispatch the `implementer` agent with `isolation: "worktree"` — its system prompt carries workspace discipline, hard limits, and the reporting protocol, so the brief only needs the task spec itself -- Main session stays as the evaluator (see `harness-engineering.md` generator-evaluator separation); it reviews diffs directly instead of spawning review subagents -- Brief subagents with task-relevant context inline — they have no conversation history -- After a worktree agent completes, verify placement: `git worktree list` + `git branch -v` must show the main tree untouched and the feature branch at the agent's commits; repoint with `git branch -f` if not -- **Push and PR creation require explicit user confirmation** — including post-phase follow-ups (docs, cleanup, completion records). Prefer branch-protection enforcement over discipline. +## Delegation -### Worktree Location +Delegation is decided here and nowhere else. The harness default of not spawning agents unasked wins; this section says how to delegate once it is warranted. -- When creating worktrees manually (sequential subagent dispatch in a shared worktree), always use **`/.claude/worktrees/`** -- NOT `~/.claude/worktrees/` (user-global) and NOT sibling-of-repo paths (`../foo-branch`) -- Add `.claude/worktrees/` to the project's `.gitignore` if not already excluded -- Rationale: keeps worktrees scoped to the project, avoids cross-project name collisions, and makes cleanup obvious (delete with the project, not orphaned in a global cache) -- The Agent tool's `isolation: "worktree"` parameter handles its own worktree placement automatically — this rule applies to manually-created worktrees only +- Spawning costs a fixed ~10K tokens before any work happens: the subagent re-reads the rules, CLAUDE.md, git status, and the target files the caller already has. Measured 2026-07-25: three agents that accomplished nothing burned 114K tokens. Delegate when the work dwarfs that cost, needs isolation from the caller's context, or when the generator must not be the evaluator. Stay inline for small, high-frequency tasks; on a 1M-context session, context hygiene alone does not justify a spawn +- Codex (`codex-subagent`) is for when an independent model's read is the point — cross-model review, a second opinion on a diagnosis — or when the user asks for it by name. It is not the default owner of coding work +- Roles: the main session plans, designs, and evaluates. `implementer` (sonnet; override `model: haiku` for mechanical single-file edits) implements from an approved plan. `spec-reviewer` screens diffs and `skeptic` refutes claims, both read-only; the main session adjudicates their findings. Explore agents return conclusions, not file dumps +- `/advisor fable` escalates decision points up (approach choice, recurring errors, pre-completion checks). It has no tools and reads only the transcript, so it never satisfies generator-evaluator separation +- `sonnet[1m]` bills usage credits on subscription plans: for >200K-context tasks, split the task or use `opus`. `CLAUDE_CODE_SUBAGENT_MODEL` must stay unset or it overrides every per-agent model choice +- Stay in the main process for brainstorming, spec clarification, architecture decisions, exploratory debugging, and trivial edits (single file, <10 lines, obvious intent) -### Stay in main process for +### Subagent-driven implementation -- Brainstorming, spec clarification, architecture decisions -- Exploratory work (debugging, bug reproduction, interactive TDD) -- Trivial edits: single file, <10 lines, obvious intent +- Dispatch `implementer` with `isolation: "worktree"` and the task spec inline. It has no conversation history; its system prompt already carries workspace discipline and the reporting protocol +- The dispatcher never implements what it will evaluate; the implementer never evaluates its own diff. The main session reviews the diff itself instead of spawning review subagents +- After a worktree agent finishes, `git worktree list` and `git branch -v` must show the main tree untouched and the feature branch at the agent's commits; repoint with `git branch -f` if not +- **Push and PR creation require explicit user confirmation**, including post-phase follow-ups (docs, cleanup, completion records) +- Manually created worktrees go in `/.claude/worktrees/` (add it to `.gitignore`), never `~/.claude/worktrees/` or a sibling of the repo: project-scoped, no cross-project name collisions, cleanup obvious. The Agent tool's `isolation: "worktree"` places its own ## Verification -- Never mark a task complete without proving it works: the verification command runs **in the same message** as the completion claim, with full output and exit code shown -- Diff behavior between main and your changes when relevant -- If you didn't run it, you don't know - -## Demand Elegance (Balanced) - -- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution" -- Elegance means simpler, not bigger — no refactors, abstractions, or features beyond what the task requires - -## Systematic Bug Fixing - +- Never claim completion without proof: the verification command runs **in the same message** as the claim, with full output and exit code. Diff behavior against main when relevant - Investigate before patching: reproduce the bug, then diff a working case against the broken one -- Capture the bug in a failing test before fixing it (fix-loop limits: see `harness-engineering.md` Oscillation Guard) - -## Task Management - -- Track multi-step work with the harness Task tools or plan-document checkboxes; check in before starting implementation -- After any correction from the user, capture the pattern in persistent memory so it survives the session From 0c1416800b9e44cb7cd7e0e9c7fa2d52abaa0a41 Mon Sep 17 00:00:00 2001 From: Ryota Ikezawa Date: Mon, 14 Sep 2026 17:57:05 +0900 Subject: [PATCH 3/6] chore(context): drop the harness-vs-guardrail preamble from always-on The taxonomy explaining why sections are tagged [Harness] or [Guardrail] is guidance for maintaining the rule set, not for acting on it. It now lives in harness-meta.md, which is paths:-scoped to .claude/** and CLAUDE.md, replacing the cross-reference that pointed back at the preamble. Every constraint in harness-engineering.md stays; wording is compressed. 3.1K to 2.0K chars. Co-Authored-By: Claude Fable 5.1 --- home/dot_claude/rules/harness-engineering.md | 59 +++++--------------- home/dot_claude/rules/harness-meta.md | 2 +- 2 files changed, 16 insertions(+), 45 deletions(-) diff --git a/home/dot_claude/rules/harness-engineering.md b/home/dot_claude/rules/harness-engineering.md index 5aa092c..d3abd8b 100644 --- a/home/dot_claude/rules/harness-engineering.md +++ b/home/dot_claude/rules/harness-engineering.md @@ -1,56 +1,27 @@ # Harness Engineering -## Harness vs Guardrail +## Generator-Evaluator Separation -Sections in this file fall into two categories: - -- **[Harness]** Pre-design — shapes how the agent runs _before_ it acts -- **[Guardrail]** Post-verification — detects deviation _after_ the agent acts - -Harness is a design decision; guardrail is a mechanical check. Separating "is this pre-design or post-verification?" prevents rule bloat. - -Push checks toward guardrails whenever a deterministic tool can do the job: **the stronger the mechanical verification, the more autonomy the agent can be safely given**. - -## [Guardrail] Generator-Evaluator Separation - -- Never self-assess quality of your own output as the final verdict -- When reviewing code you wrote, launch a separate agent that did not participate in generation -- When the main session only planned and subagents generated, the main session is a valid evaluator — no extra review subagent needed -- The evaluator should test behavior, not read implementation to form its judgment +- Never let self-assessment of your own output be the final verdict. Code you wrote is reviewed by a separate agent that did not generate it; when the main session only planned and subagents generated, the main session is a valid evaluator +- The evaluator tests behavior; it does not read the implementation to form its judgment - Subagent reports are hypotheses, not facts: verify load-bearing claims against primary sources (run the commands, read the files) before acting on them -## [Harness] Sprint Contracts - -- Before implementation: agree on concrete "done" criteria with the user -- Done criteria must be verifiable (testable assertions, observable behavior, measurable outcomes) -- If criteria cannot be verified automatically, state which require manual verification -- For multi-turn implementation tasks, encode the contract via `/goal ` so the harness tracks completion across turns (shows live elapsed/turns/tokens overlay) - -## [Guardrail] Review Discipline - -### Giving reviews +## Sprint Contracts -- Review only changed code. Do not flag pre-existing issues unless they interact with changes -- Classify findings: CRITICAL (blocks ship) / IMPORTANT (should fix) / LOW (nice-to-have) -- Drop LOW findings. Present only CRITICAL and IMPORTANT -- For each fix: state whether it addresses the root cause or is a workaround +- Before implementing, agree on concrete "done" criteria with the user: testable assertions, observable behavior, measurable outcomes. Say which require manual verification +- For multi-turn implementation, encode the contract via `/goal ` so the harness tracks completion across turns -### Receiving reviews +## Review Discipline -- Do not blindly implement feedback — first verify the suggestion is technically correct -- If a reviewer's suggestion would break something, say so with evidence -- If feedback is vague or unclear, ask for clarification instead of guessing intent -- No performative agreement ("great suggestion!") — just evaluate and act +- Giving: review only changed code, flagging pre-existing issues only when they interact with the change. Classify CRITICAL (blocks ship) / IMPORTANT (should fix) / LOW and present only CRITICAL and IMPORTANT. For each fix, say whether it addresses the root cause or is a workaround +- Receiving: verify a suggestion is technically correct before implementing it; if it would break something, say so with evidence; ask when feedback is vague. No performative agreement -## [Guardrail] Oscillation Guard +## Oscillation Guard -- If a fix reverts a previous fix (A -> B -> A pattern), stop and escalate to the user -- When stuck in a fix loop (3+ attempts at the same issue), re-plan instead of retrying -- Maximum 5 review-fix iterations before presenting current state to user +- A fix that reverts a previous fix (A -> B -> A): stop and escalate to the user +- 3+ attempts at the same issue: re-plan instead of retrying. Maximum 5 review-fix iterations before presenting the current state to the user -## [Harness] Decision Records +## Decision Records -- Record non-trivial technical decisions as ADRs (Architecture Decision Records) -- Check for existing ADR directory (`docs/adr/`, `docs/decisions/`, `adr/`, etc.) and follow that convention. If none exists, recommend `docs/adr/` -- Before making architectural choices, read existing ADRs for prior decisions and constraints -- Write ADRs in English; file naming `NNNN-short-description.md`; sections: Status / Context / Decision / Consequences +- Record non-trivial technical decisions as ADRs. Follow the repo's existing ADR directory convention (`docs/adr/`, `docs/decisions/`, `adr/`, …); if none exists, recommend `docs/adr/`. Read existing ADRs before making architectural choices +- English; file naming `NNNN-short-description.md`; sections: Status / Context / Decision / Consequences diff --git a/home/dot_claude/rules/harness-meta.md b/home/dot_claude/rules/harness-meta.md index 1d1c7f9..cf23041 100644 --- a/home/dot_claude/rules/harness-meta.md +++ b/home/dot_claude/rules/harness-meta.md @@ -32,7 +32,7 @@ Where to place a new constraint, by violation history and reversibility: - Skip levels when the action is irreversible — go straight to L3+ instead of trusting prose - Prefer machine-checkable enforcement (L3/L4) over instructions (L1/L2) whenever a deterministic check is possible -- See `harness-engineering.md` for why this matches "the stronger the mechanical verification, the more autonomy" +- Harness (pre-design that shapes how the agent runs) vs guardrail (post-hoc mechanical check): push checks toward guardrails whenever a deterministic tool can do the job. The stronger the mechanical verification, the more autonomy the agent can safely be given ## Harness Simplification From 7395ab194097c4890d2ea1b4f554eddf4be2bb13 Mon Sep 17 00:00:00 2001 From: Ryota Ikezawa Date: Mon, 14 Sep 2026 17:57:05 +0900 Subject: [PATCH 4/6] chore(context): compress db-safety.md to the judgment the hook cannot make The hook enforces the literal patterns; the prose only needs the cases it cannot see (recovering from transient errors, dynamic construction, false positives on diagnostics, how to run one deliberately). Same five constraints, 1.6K to 1.2K chars. Co-Authored-By: Claude Fable 5.1 --- home/dot_claude/rules/db-safety.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/home/dot_claude/rules/db-safety.md b/home/dot_claude/rules/db-safety.md index bb37512..d789114 100644 --- a/home/dot_claude/rules/db-safety.md +++ b/home/dot_claude/rules/db-safety.md @@ -1,9 +1,9 @@ # Database Safety -A PreToolUse Bash hook (`block-destructive-db.sh`) denies known destructive database commands (`db:reset`, `prisma migrate reset`, `TRUNCATE`, `DROP DATABASE`, …) regardless of test-environment markers. Generic markers such as `NODE_ENV=test` do not prove which datasource a framework or raw client will target. The rules below cover the judgment the hook cannot make. +A PreToolUse Bash hook (`block-destructive-db.sh`) denies known destructive database commands (`db:reset`, `prisma migrate reset`, `TRUNCATE`, `DROP DATABASE`, …) regardless of test-environment markers: `NODE_ENV=test` does not prove which datasource a framework or raw client will target. The judgment the hook cannot make: -- Never wipe a database to recover from a transient error (concurrent-test schema noise, flaky migrations, stale fixtures). These are environment problems; a reset destroys dev data that lives in no seed or snapshot. -- On schema/DDL errors: stop the destructive plan, capture the exact error and command, report with that evidence, and wait for instruction. Whether a reset is acceptable is the user's call — they know what dev data they have. -- Never construct a destructive database command dynamically with parameter, brace, glob, or runtime data expansion. The hook recognizes known literal patterns and simple quote/backslash concatenation; it is an advisory guard, not a shell AST/dataflow evaluator. -- The guard may conservatively match a database runner and destructive task text across shell control operators. If a diagnostic only needs to print or search those strings, issue it as a separate Bash call. -- A test marker does not bypass the hook. To run a destructive command deliberately, run it in your own shell (the hook only blocks tool-invoked commands), or add a narrowly scoped per-project allow rule in `.claude/settings.json` for the specific command. +- Never wipe a database to recover from a transient error (concurrent-test schema noise, flaky migrations, stale fixtures). A reset destroys dev data that lives in no seed or snapshot +- On schema/DDL errors: stop, capture the exact error and command, report with that evidence, and wait for instruction. Whether a reset is acceptable is the user's call +- Never build a destructive database command from parameter, brace, glob, or runtime expansion. The hook matches known literal patterns only; it is an advisory guard, not a shell evaluator +- The hook may match a database runner plus destructive text across shell control operators. A diagnostic that only prints or searches those strings goes in a separate Bash call +- To run a destructive command deliberately, the user runs it in their own shell (the hook only sees tool-invoked commands), or adds a narrowly scoped allow rule for that command in the project's `.claude/settings.json` From bee0fcfec0471aa35d9baaf463bc12382e95f4f8 Mon Sep 17 00:00:00 2001 From: Ryota Ikezawa Date: Mon, 14 Sep 2026 17:57:05 +0900 Subject: [PATCH 5/6] chore(context): compress markdown-formatting.md rationale, keep every rule The line-break section carried two paragraphs of CommonMark and CJK rendering rationale per rule; each is now one clause on the bullet it justifies. The "When to diagram" table stays intact because the writing-bench rubric references it by name. 2.9K to 2.0K chars. Co-Authored-By: Claude Fable 5.1 --- home/dot_claude/rules/markdown-formatting.md | 26 ++++++-------------- 1 file changed, 8 insertions(+), 18 deletions(-) diff --git a/home/dot_claude/rules/markdown-formatting.md b/home/dot_claude/rules/markdown-formatting.md index d179240..a705b48 100644 --- a/home/dot_claude/rules/markdown-formatting.md +++ b/home/dot_claude/rules/markdown-formatting.md @@ -1,22 +1,19 @@ # Markdown Formatting -Language-independent formatting rules for Markdown output (responses, PR bodies, docs). +Language-independent rules for Markdown output (responses, PR bodies, docs). -- Don't hardcode numbers at the start of headings or list items. If order matters, let Markdown's ordered-list syntax (`1.` `2.`) render the numbering; don't type the numerals into the body text yourself. +- Don't type numerals into headings or list items. If order matters, use ordered-list syntax (`1.` `2.`) and let Markdown render the numbering ## Line breaks in prose -Prose has **no column limit** and is **not hard-wrapped** by default. Write one paragraph per line and let the editor/renderer soft-wrap. A hard wrap gains nothing in rendered Markdown (CommonMark collapses a soft break to a space) and is a footgun on hard-break surfaces (below). - -- **Never wrap hard-break surfaces**: GitHub issue / PR / comment bodies render every single newline as a `
`, so a wrapped paragraph shows as jagged forced breaks. Write them as long unwrapped lines with a blank line between paragraphs. (Tables and code blocks are not prose — leave them.) -- **Follow the repo's prose convention when it declares one**: Prettier `proseWrap`, or an existing consistently-wrapped corpus (e.g. these rule files). Match it. -- [Semantic Line Breaks](https://sembr.org/) (one sentence per line) is **opt-in** — worth it only where the repo wants sentence-granularity prose diffs, never the global default. When wrapping, break only at sentence boundaries (。．.！？!?), never mid-clause. Japanese: a mid-sentence wrap can render as a bogus half-width space (CJK segment-break removal is unevenly implemented), so the sentence boundary is the only safe break. - -**Code line length** is not governed here — it follows each language's own formatter / linter (`.editorconfig`, `.stylua.toml`, Prettier, `shfmt`, etc.), never a Markdown-wide column rule. +- Prose has **no column limit** and is **not hard-wrapped**: one paragraph per line, soft-wrapped by the renderer. CommonMark collapses a soft break to a space, so wrapping gains nothing +- **Never wrap GitHub issue / PR / comment bodies**: every newline renders as `
`. Tables and code blocks are not prose +- Follow the repo's declared prose convention (Prettier `proseWrap`, a consistently wrapped corpus) when there is one. [Semantic Line Breaks](https://sembr.org/) are opt-in per repo, never the default; when wrapping, break only at sentence boundaries (。．.！？!?), since a mid-sentence wrap in Japanese can render a bogus half-width space +- Code line length follows each language's own formatter, never a Markdown rule ## Diagrams: mermaid in artifacts, ASCII in chat -Use mermaid in **written artifacts only** — PR bodies, ADRs, README, technical docs, .md files — where GitHub, Obsidian, VS Code preview, etc. render it as a real diagram. In chat/terminal responses it is the reverse: mermaid does not render there, so use ASCII art, prose, or short bullet lists instead. +Use mermaid only in written artifacts (PR bodies, ADRs, README, `.md` files) where GitHub, Obsidian, or VS Code render it. Chat/terminal responses do not render it: use ASCII art, prose, or short bullets there. ### When to diagram @@ -29,11 +26,4 @@ A diagram is due when prose would make the reader sketch it themselves: | Structural before/after comparison | two graphs side by side | | Procedure of ≥5 steps containing branches | `flowchart` | -### Authoring rules - -- ≤ ~10 nodes per diagram; split larger into multiple -- Concrete node labels (`UserService`, not `ServiceA`) -- Show before/after side-by-side for structural refactors -- Prefer `LR` for pipelines, `TD` for hierarchies - -For embedding in GitHub PR bodies safely (backslash-escape pitfall), see `gh-pr-body.md`. +≤ ~10 nodes per diagram (split larger ones); concrete node labels (`UserService`, not `ServiceA`); `LR` for pipelines, `TD` for hierarchies. For embedding in GitHub PR bodies safely, see `gh-pr-body.md`. From aad5bd9611b1ab1ab49a829b9bca9c54cf400a75 Mon Sep 17 00:00:00 2001 From: Ryota Ikezawa Date: Mon, 14 Sep 2026 18:02:00 +0900 Subject: [PATCH 6/6] chore(context): restore hook accuracy and the Authoring rules heading Skeptic review of the diet found two regressions: db-safety.md understated the hook (it normalizes quote/backslash concatenation before matching, per its own header comment), and gh-pr-body.md plus writing/references/technical.md still point at a "Authoring rules" heading in markdown-formatting.md that the compression had folded away. Both restored at a cost of 60 chars. Co-Authored-By: Claude Fable 5.1 --- home/dot_claude/rules/db-safety.md | 2 +- home/dot_claude/rules/markdown-formatting.md | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/home/dot_claude/rules/db-safety.md b/home/dot_claude/rules/db-safety.md index d789114..65e2c61 100644 --- a/home/dot_claude/rules/db-safety.md +++ b/home/dot_claude/rules/db-safety.md @@ -4,6 +4,6 @@ A PreToolUse Bash hook (`block-destructive-db.sh`) denies known destructive data - Never wipe a database to recover from a transient error (concurrent-test schema noise, flaky migrations, stale fixtures). A reset destroys dev data that lives in no seed or snapshot - On schema/DDL errors: stop, capture the exact error and command, report with that evidence, and wait for instruction. Whether a reset is acceptable is the user's call -- Never build a destructive database command from parameter, brace, glob, or runtime expansion. The hook matches known literal patterns only; it is an advisory guard, not a shell evaluator +- Never build a destructive database command from parameter, brace, glob, or runtime expansion. The hook matches known literal patterns on a quote/backslash-normalized copy; it is an advisory guard, not a shell evaluator - The hook may match a database runner plus destructive text across shell control operators. A diagnostic that only prints or searches those strings goes in a separate Bash call - To run a destructive command deliberately, the user runs it in their own shell (the hook only sees tool-invoked commands), or adds a narrowly scoped allow rule for that command in the project's `.claude/settings.json` diff --git a/home/dot_claude/rules/markdown-formatting.md b/home/dot_claude/rules/markdown-formatting.md index a705b48..c047011 100644 --- a/home/dot_claude/rules/markdown-formatting.md +++ b/home/dot_claude/rules/markdown-formatting.md @@ -26,4 +26,6 @@ A diagram is due when prose would make the reader sketch it themselves: | Structural before/after comparison | two graphs side by side | | Procedure of ≥5 steps containing branches | `flowchart` | +### Authoring rules + ≤ ~10 nodes per diagram (split larger ones); concrete node labels (`UserService`, not `ServiceA`); `LR` for pipelines, `TD` for hierarchies. For embedding in GitHub PR bodies safely, see `gh-pr-body.md`.