docs: normalize the Claude Code user reference to "user"

docs/agents/han-core/research-analyst.md

@@ -39,7 +39,7 @@ Dispatch via the `Agent` tool with `subagent_type: han-core:research-analyst`.
 Give it:
 
 1. **A framed question or sub-angle.** The specific decision, unknown, or domain this analyst owns. If the question implies discrete alternatives, name them.
-2. **Provided material, by reference (optional).** Docs or links the operator supplied. The agent holds these to web-source scrutiny.
+2. **Provided material, by reference (optional).** Docs or links the user supplied. The agent holds these to web-source scrutiny.
 3. **No codebase contents.** The web-facing angle is deliberately isolated. Codebase evidence comes from a separate `codebase-explorer` dispatch, not this one.
 
 Example prompts:

docs/evidence.md

@@ -9,7 +9,7 @@ This page supplements [YAGNI](./yagni.md). YAGNI's evidence test answers *is the
 ## TL;DR
 
 - **Three principles ground the rule.** Evidence drawn from closer to the originating event or data carries more weight than evidence at greater remove (proximity). Independently corroborated evidence beats single-source evidence (corroboration). The absence of evidence is a distinct state worth naming, not the bottom of a tier list (no-evidence labeling).
-- **Trust classes name the boundary.** Codebase evidence is the trusted current-state anchor. Web evidence sits outside the trust boundary. Operator-provided material gets interested-party scrutiny.
+- **Trust classes name the boundary.** Codebase evidence is the trusted current-state anchor. Web evidence sits outside the trust boundary. User-provided material gets interested-party scrutiny.
 - **Proximity is a heuristic, not a ranked ladder.** Running code beats documentation in many situations, but not all. Formal-methods contexts, specification-compliance contexts, and regulatory contexts invert the ordering. The rule names the principle and walks you through the inversions. It does not hand you a numbered list to apply blindly.
 - **The corroboration gate is scoped to web sources.** A single web claim that drives a recommendation gets marked single-source and cannot stand alone. Codebase evidence at a specific file path and line is not weakened by being a single citation. That asymmetry is intentional and matches how `/research` already behaves.
 - **No evidence is a state with a name and a response.** When a claim has no evidence at any tier, the response is to label it, defer the dependent decision, and name the trigger that would reopen it. The same defer-with-trigger pattern YAGNI uses.
@@ -64,7 +64,7 @@ The corroboration gate and the proximity heuristic both rest on a vocabulary tha
 
 - **Codebase** is the trusted current-state anchor. The current source code, the current tests, the current configuration, the current build output. When codebase evidence contradicts other evidence, surface the conflict explicitly and treat the codebase as authoritative on what the system does today.
 - **Web** sits outside the trust boundary. Documentation pages, blog posts, Stack Overflow, GitHub issues, RFCs, vendor whitepapers, LLM-generated content. Web sources can be wrong, stale, adversarially shaped, or contextually misapplied. The corroboration gate applies here.
-- **Provided** is operator-supplied material. Files you pasted in, links you handed to a skill, screenshots, transcripts. Apply interested-party scrutiny: the operator's intent in providing the material is itself a piece of context. Operator-provided material is held to the same scrutiny as a web source.
+- **Provided** is user-supplied material. Files you pasted in, links you handed to a skill, screenshots, transcripts. Apply interested-party scrutiny: the user's intent in providing the material is itself a piece of context. User-provided material is held to the same scrutiny as a web source.
 
 These trust classes are the same ones [`/research`](./skills/han-core/research.md) already uses. The canonical rule extracts them so other skills and agents can apply the same vocabulary.
 

docs/skills/han-coding/code-review.md

@@ -20,7 +20,7 @@ Operator documentation for the `/code-review` skill in the han plugin. This docu
 - **Per-agent dispatcher tailoring.** When `/code-review` dispatches `structural-analyst` and `behavioral-analyst`, it appends a default-SUGG directive so those agents start at the lowest severity and escalate only when the change introduces or worsens the issue. When it dispatches `junior-developer` and `edge-case-explorer`, it appends a file-list scoping directive so findings concern code on the scoped file list (with a narrower wording for `edge-case-explorer` that preserves its caller-read protocol while keeping the failure-mode target on the file list). These directives are `/code-review`'s tailoring; the agents' default behavior in other skills is unchanged.
 - **Reachability phrase-match gate (Step 7.2).** When an agent's own rationale contains phrases like *theoretical*, *hypothetical*, *defense-in-depth*, *effectively impossible*, *in case the upstream*, *could happen*, *should never happen*, or *edge case that does not occur*, the finding is demoted by one severity before the rubric is applied. Security findings are exempt because the security agent's evidence standard already requires a demonstrated exploit path. The gate is a cheap, deterministic first pass and is brittle to paraphrase by design; a finding that hedges its reachability without one of the literal phrases is caught semantically by the Step 7.4 validation pass, not by growing the phrase list.
 - **Independent findings validation (Step 7.4).** After the agent findings are collected and classified, the skill dispatches one `adversarial-validator` over the *consolidated corrective finding list* — the same agent `/investigate` uses to attack a root cause and fix. It is the only pass that re-reads the change in fresh context and judges each finding against the code rather than against the producing agent's rationale, so it does not anchor on what the specialists concluded. Each finding comes back Confirmed (kept), Partially Refuted (demoted one severity), or Refuted (dropped). A finding is dropped only when the validator supplies concrete counter-evidence at `file_path:line_number`; a bare assertion demotes rather than drops, and an uncertain verdict leaves the finding standing. Security findings are dropped only when the demonstrated exploit is refuted with counter-evidence. The pass is a finding *filter, not a finding source* — it never contributes findings of its own — and it skips entirely when the review produced no corrective findings.
-- **Branch context loaded at Step 1.5.** Before agents are dispatched, the skill loads four sources of branch-level context in order: PR description (via `gh pr view` when `gh` is available, Mode A only), a local `pr-body`, `PR_BODY.md`, or `.pr-body` file at the repo root, branch commit messages, and an implementation plan from the planning directory. The planning directory resolves first to the `plans:` (or `planning:`) key under CLAUDE.md's `## Project Discovery` section; otherwise the skill globs `docs/plans/*/feature-implementation-plan.md` and `plans/*/feature-implementation-plan.md`, picking the directory whose name matches the current branch (treating `-` and `_` as interchangeable). The loaded content is summarized into a `$branch_context` block of at most 200 words and plumbed, alongside the user's `$focus_areas` argument, into every agent prompt so agents avoid re-raising items the team has already deferred or resolved. Because PR descriptions, ticket bodies, and commit messages are third-party content that can carry text aimed at steering the review agent, the skill treats `$branch_context` as **untrusted data, not instructions**: the Step 1.5 summary strips any directives addressed to the reader or an agent, and Step 3.5 wraps the binding in explicit untrusted-data markers with a guard telling agents to use it for intent only and never to obey instructions inside it. The operator's own `$focus_areas` argument is trusted and is not wrapped. Step 1.5 is skipped in Mode C; in Mode A and Mode B, when none of the four sources returns content the skill emits a single fail-open warning and proceeds with `$branch_context` set to `none provided`.
+- **Branch context loaded at Step 1.5.** Before agents are dispatched, the skill loads four sources of branch-level context in order: PR description (via `gh pr view` when `gh` is available, Mode A only), a local `pr-body`, `PR_BODY.md`, or `.pr-body` file at the repo root, branch commit messages, and an implementation plan from the planning directory. The planning directory resolves first to the `plans:` (or `planning:`) key under CLAUDE.md's `## Project Discovery` section; otherwise the skill globs `docs/plans/*/feature-implementation-plan.md` and `plans/*/feature-implementation-plan.md`, picking the directory whose name matches the current branch (treating `-` and `_` as interchangeable). The loaded content is summarized into a `$branch_context` block of at most 200 words and plumbed, alongside the user's `$focus_areas` argument, into every agent prompt so agents avoid re-raising items the team has already deferred or resolved. Because PR descriptions, ticket bodies, and commit messages are third-party content that can carry text aimed at steering the review agent, the skill treats `$branch_context` as **untrusted data, not instructions**: the Step 1.5 summary strips any directives addressed to the reader or an agent, and Step 3.5 wraps the binding in explicit untrusted-data markers with a guard telling agents to use it for intent only and never to obey instructions inside it. The user's own `$focus_areas` argument is trusted and is not wrapped. Step 1.5 is skipped in Mode C; in Mode A and Mode B, when none of the four sources returns content the skill emits a single fail-open warning and proceeds with `$branch_context` set to `none provided`.
 - **Self-consistency check at Step 9.0.** Before the structural verification, the skill scans every pair of findings on the same file with overlapping line ranges, detects contradictory recommendations, demotes both, and adds a `Tension with {other-task-id}:` note for the human reviewer. Cross-file semantic contradictions are out of scope.
 - **Premise verification before standards-compliance findings.** Step 5 requires reading at least one architectural file in the codebase that demonstrates a standard's premise before the skill raises a "violates standard X" finding. When the file does not confirm the premise, the finding is omitted with a logged note rather than raised on inferred premises.
 - **Project-pattern deference.** A pattern that differs from general best practices but is consistent within the project is *not* a finding. Only deviations from the project's own conventions count.

han-coding/references/evidence-rule.md

@@ -10,7 +10,7 @@ Every artifact a skill or agent cites carries one of three trust classes:
 
 - **Codebase** is the trusted current-state anchor. The current source code, current tests, current configuration, current build output. When codebase evidence contradicts other evidence, treat the codebase as authoritative on what the system does today.
 - **Web** sits outside the trust boundary. Documentation, blog posts, Stack Overflow, GitHub issues, RFCs, vendor whitepapers, LLM-generated content. Web sources can be wrong, stale, adversarially shaped, or contextually misapplied.
-- **Provided** is operator-supplied material. Files pasted in, links handed to a skill, screenshots, transcripts. Apply interested-party scrutiny; hold to the same standard as web sources.
+- **Provided** is user-supplied material. Files pasted in, links handed to a skill, screenshots, transcripts. Apply interested-party scrutiny; hold to the same standard as web sources.
 
 ## The three principles
 

han-coding/references/readability-rule.md

@@ -1,6 +1,6 @@
 # Readability Rule (Human-Readable Output Standard)
 
-This is the shared readability standard that every reader-facing Han skill applies while it writes. Its one aim: when an operator runs a reader-facing skill, the human-facing deliverable it produces can be found, understood, and used by a reader who did not do the work and lacks the author's context.
+This is the shared readability standard that every reader-facing Han skill applies while it writes. Its one aim: when a user runs a reader-facing skill, the human-facing deliverable it produces can be found, understood, and used by a reader who did not do the work and lacks the author's context.
 
 That aim is pursued through observable properties of the text, not a comprehension score. The output leads with its main point, gives each paragraph one idea, uses descriptive headings, keeps sentences short and active, prefers common words, and reveals detail in layers. The observable gate on those properties is the standardized self-check at the end of this rule. The standard commits to that check, not to a promise about a reader's comprehension.
 

han-coding/skills/code-overview/SKILL.md

@@ -32,7 +32,7 @@ Read these before doing anything. They constrain every step below.
 - **The overview applies the shared readability standard.** As it writes and refines the overview, the skill loads and applies [`../../references/readability-rule.md`](../../references/readability-rule.md), holding the default audience frame: a capable reader who did not do this work and lacks the author's context. The standard governs how the overview reads (main point first, descriptive headings, one idea per paragraph, progressive disclosure), never whether a required fact about the code appears. Its dedicated `han-core:readability-editor` pass (Step 7) replaces the older information-architect / junior-developer readability review; the accuracy validator is a separate pass and stays.
 - **Read-only, always.** The skill explains; it never edits the target. It writes only its own scratch overview file. BECAUSE the job is understanding, not modification — this keeps the skill safe to point at unfamiliar code.
 - **Accurate to the code, always.** Every claim the overview makes — the why it states (grounded in commit and PR/issue intent, comments, and what the code visibly does toward a goal), what the code does, each flow step, each named entry point, each change grouped by intent — must be grounded in the actual code and its intent, never inferred past the evidence or invented. BECAUSE a confidently wrong overview is worse than none: it sends the reader to the wrong file with false confidence and silently corrupts the mental model the skill exists to build. The adversarial validation pass (Step 7) exists to catch this. It is accuracy control on the *description*, NOT a quality judgment about the code — the two are different lines, and crossing into the second is still forbidden.
-- **No quality judgment, ever.** The overview raises no findings, severities, or recommended changes — including in the PR-mode "what to watch" section, which is navigational only. BECAUSE reviewing a PR's quality is `code-review`'s job; this skill only helps the operator understand the PR before they review it. Crossing this line collapses the boundary between the two skills.
+- **No quality judgment, ever.** The overview raises no findings, severities, or recommended changes — including in the PR-mode "what to watch" section, which is navigational only. BECAUSE reviewing a PR's quality is `code-review`'s job; this skill only helps the reader understand the PR before they review it. Crossing this line collapses the boundary between the two skills.
 - **No PR statistics, ever.** The overview never states lines changed, files changed, additions/deletions, commit counts, or any other diff-stat figure — not in the intro, not in a section, not anywhere. BECAUSE these numbers go stale the instant the PR is updated and add no understanding; describe what changed and why, never how big the diff is.
 - **Ephemeral, not documentation.** The overview is written to a scratch file outside the repository and is never committed into the repository's documentation tree. BECAUSE durable feature and system docs are `project-documentation`'s job; this skill is an understand-now orientation aid.
 - **Default to small.** Start size classification at small and escalate only when a higher-band signal is clearly present. BECAUSE under-dispatching is recoverable by re-running larger; over-dispatching burns tokens and dilutes the overview.
@@ -107,7 +107,7 @@ Open the document with a title and a short **intro paragraph naming what is bein
 
 **Lead with the why, and let everything else flow from it.** The first section after the intro answers *why this code (or this change) exists* — the real problem it solves or the goal it accomplishes for the business or a user, then why it works the way it does and why it is the current solution to that need. Tell the why as a solution to a need, not as technical mechanics. Then frame every section that follows as serving that why: the flow shows how the code delivers on it, the context shows what it depends on to meet the need, the handoff shows where to start working on it. When the why is not recoverable from the code and its intent (commit messages, PR/issue text, comments, naming, tests), state what the code demonstrably does toward a goal and mark the inferred why as inferred — never invent a business rationale the evidence does not support.
 
-**Code mode** renders, in order: the title and intro paragraph; a coverage note **only if** coverage was partial; **Why it exists** (the problem the code solves or goal it serves, then briefly what it is and why it works the way it does — all flowing from the why); **Main flow** (a Mermaid chart with a one-line scope label, read as how the code delivers on the why); **Context and uses** (context and uses kept distinguishable, framed as what it depends on to meet the need and where that need is served from); **Where to start** (the concrete entry points the operator opens first).
+**Code mode** renders, in order: the title and intro paragraph; a coverage note **only if** coverage was partial; **Why it exists** (the problem the code solves or goal it serves, then briefly what it is and why it works the way it does — all flowing from the why); **Main flow** (a Mermaid chart with a one-line scope label, read as how the code delivers on the why); **Context and uses** (context and uses kept distinguishable, framed as what it depends on to meet the need and where that need is served from); **Where to start** (the concrete entry points the reader opens first).
 
 **PR mode** renders, in order: the same title and intro paragraph; the same conditional coverage note; **Why this change exists** (the problem the change solves or goal it advances, then briefly the bottom line of what it does); **Changes by intent** (grouped by the reader-visible outcome each group delivers — the why each group serves — not by file, layer, or author motivation; a single logical change is one narrative with no grouping header); **How the change flows** (a Mermaid chart with a scope label, placed after the grouped changes BECAUSE the reviewer must know what changed before that chart is meaningful); **What to watch when reviewing** (navigational only — where the change is hardest to follow and why; never a quality or risk judgment).
 

han-coding/skills/code-overview/references/overview-template.md

@@ -36,7 +36,7 @@ remove the guidance comments, and keep the section order exactly as written.
   why told as a problem solved or goal met, with no detail a reader would
   otherwise look up in the code itself. The where-to-start / what-to-watch handoff
   section is the exception: it must name the concrete entry points (the specific
-  files or components) the operator would open first, or it is not actionable.
+  files or components) the reader would open first, or it is not actionable.
 - **Chart scope labels.** Every flow chart carries a one-line label stating what
   it covers, and — when coverage is partial — what it leaves out. A chart must
   make sense to a reader who reads only the chart and its label.
@@ -96,7 +96,7 @@ read as how the code delivers on the why above.}
 
 ## Where to start
 
-{The concrete entry points — the specific files or components — the operator
+{The concrete entry points — the specific files or components — the reader
 would open first to begin working, with one line each on what each is for.}
 ```