kotonoha 0.1.6-dev.0 → 0.3.0

package/skills/consulting-analyst/assets/templates/analysis-brief.md

@@ -0,0 +1,58 @@
+# Analysis brief: <analysis title>
+
+<State what decision this analysis supports and what the decision-maker will
+be able to decide after reading it.>
+
+- Analysis owner: <person or team>
+- Decision-maker: <role or forum>
+- Decision deadline: <YYYY-MM-DD>
+- Destination: Analysis / Blueprint / White Paper / Proposal / Presentation
+- Status: Draft / In Analysis / Ready for Handoff / Blocked
+
+## Decision question
+
+<Write one question naming the actor, choice or problem, scope, and time
+horizon.>
+
+## Intended outcome
+
+<State the decision or action this analysis must enable and how success will
+be measured.>
+
+## Scope and exclusions
+
+### In scope
+
+- <Scope item>
+
+### Out of scope
+
+- <Excluded item and where it will be handled>
+
+## Constraints
+
+| Constraint ID | Constraint | Source | Consequence |
+|---|---|---|---|
+| CON-001 | <Constraint> | <Source> | <Impact on analysis or options> |
+
+## Available evidence
+
+| Source ID | Source | Statement type | Date | Owner | Known limitation |
+|---|---|---|---|---|---|
+| SRC-001 | <File, data set, interview, or URL> | Fact source / Estimate source / Context | <Date> | <Owner> | <Limitation> |
+
+## Decision-critical unknowns
+
+| Unknown ID | Question | Why it matters | Collection method | Owner | Deadline |
+|---|---|---|---|---|---|
+| UNK-001 | <Unknown> | <Decision impact> | <Method> | <Owner> | <Date> |
+
+## Framework selection
+
+| Framework | Decision need | Expected output | Reason selected |
+|---|---|---|---|
+| <Framework> | <Need> | <Artifact field> | <Reason> |
+
+## Frozen requirements
+
+- <Facts, definitions, criteria, deadlines, or constraints that may not change>

package/skills/consulting-analyst/assets/templates/decision-analysis.md

@@ -0,0 +1,62 @@
+# Decision analysis
+
+Use the Current–Target–Gap section, the option-comparison section, or both
+only when they are required by the decision.
+
+## Current–Target–Gap
+
+| Dimension | Current state and evidence | Target state and measure | Gap ID | Intervention ID | Required intervention | Dependency | Owner |
+|---|---|---|---|---|---|---|---|
+| <Capability, process, data, technology, governance, people, or operations> | <State and EVD IDs> | <State and target> | GAP-001 | INT-001 | <Intervention> | <Dependency> | <Owner> |
+
+### Transition risks
+
+| Risk ID | Gap or intervention IDs | Risk | Trigger | Mitigation | Decision owner |
+|---|---|---|---|---|---|
+| RSK-001 | GAP-001 / INT-001 | <Risk> | <Trigger> | <Mitigation> | <Owner> |
+
+## Option criteria
+
+Define criteria and weights before scoring options.
+
+| Criterion ID | Criterion | Definition | Direction | Weight | Scoring anchors | Mandatory threshold |
+|---|---|---|---|---:|---|---|
+| CRT-001 | <Criterion> | <Definition> | Higher / Lower is better | <Percent> | 1=<anchor>, 3=<anchor>, 5=<anchor> | <Threshold or none> |
+
+The weights must sum to 100%. Record and resolve any exception before scoring.
+
+## Option score details
+
+Use one row per option and criterion so every score has its own evidence.
+
+| Option | Criterion ID | Score | Weight | Weighted score | Evidence | Rationale and caveat |
+|---|---|---:|---:|---:|---|---|
+| <Option> | CRT-001 | <1–5> | <Percent> | <Score × weight> | <EVD IDs> | <Why this anchor applies> |
+
+## Option summary
+
+| Option | Weighted total | Mandatory threshold result | Disqualified | Rank | Material caveat |
+|---|---:|---|---|---:|---|
+| <Option> | <Total> | Pass / Fail | Yes / No | <Rank> | <Caveat> |
+
+## Sensitivity analysis
+
+At minimum, test:
+
+1. Equal weights across all criteria
+2. A one-anchor increase and decrease for the top-weighted criterion scores
+3. A plausible weight shift away from the highest-weighted criterion
+4. Every case where a change causes a rank flip or threshold failure
+
+| Scenario | Exact perturbation | Recalculated ranking | Rank or threshold change | Decision impact |
+|---|---|---|---|
+| Base case | None | <Ranking> | None | <Impact> |
+| Equal weights | <Weights> | <Ranking> | <Change> | <Whether recommendation changes> |
+| Score stress | <Option, criterion, ±1 anchor> | <Ranking> | <Change> | <Impact> |
+| Weight stress | <Criterion and weight change> | <Ranking> | <Change> | <Impact> |
+
+## Decision interpretation
+
+- Recommended option or intervention set: <Answer>
+- Why the arithmetic supports but does not determine the judgment: <Reason>
+- Conditions that would change the ranking: <Conditions>

package/skills/consulting-analyst/assets/templates/hypothesis-evidence-ledger.md

@@ -0,0 +1,48 @@
+# Hypothesis and evidence ledger
+
+<State which decision question these hypotheses test and how the ledger will
+prevent unsupported conclusions.>
+
+## Hypotheses
+
+| Hypothesis ID | Issue ID | Falsifiable proposition | Rationale, not proof | Confidence | Decision if true | Decision if false |
+|---|---|---|---|---|---|---|
+| HYP-001 | Q1.1 | <Proposition> | <Why plausible> | High / Medium / Low | <Consequence> | <Consequence> |
+
+## Evidence
+
+Use one evidence row per hypothesis pairing, or explicitly list multiple HYP
+IDs when direction and limitations apply equally to all of them. If they
+differ, use separate rows with the same EVD ID; repeated evidence is not
+independent corroboration.
+
+Preserve interpretations as `Interpretation` rows linked to their underlying
+EVD IDs. Interpretations do not count as supporting evidence.
+
+| Evidence ID | Hypothesis IDs | Direction | Statement type | Source ID and date | Finding or interpretation and underlying EVD IDs | Quality | Limitation |
+|---|---|---|---|---|---|---|---|
+| EVD-001 | HYP-001, <other applicable HYP IDs> | Supports / Weakens / Neutral | Fact / Estimate / Interpretation | SRC-001, <date> | <Finding, or interpretation with underlying EVD IDs> | High / Medium / Low | <Limitation> |
+
+## Assumption register
+
+Assumptions may guide analysis but do not count as supporting evidence.
+
+| Assumption ID | Related issue or hypothesis | Assumption | Impact if false | Validation method | Owner | Deadline |
+|---|---|---|---|---|---|---|
+| ASM-001 | Q1.1 / HYP-001 | <Unverified condition> | <Impact> | <Method> | <Owner> | <Date> |
+
+## Hypothesis decisions
+
+A `Supported` hypothesis must cite at least one `Fact` or `Estimate` EVD row
+whose direction is `Supports` for that hypothesis. Assumptions and
+interpretations alone cannot establish `Supported` status.
+
+| Hypothesis ID | Status | Reason | Remaining uncertainty | Next evidence action | Owner | Deadline |
+|---|---|---|---|---|---|---|
+| HYP-001 | Supported / Weakened / Rejected / Open | <Reason with EVD IDs; Supported requires at least one Fact or Estimate> | <Uncertainty> | <Action> | <Owner> | <Date> |
+
+## Contradictions and alternative explanations
+
+| ID | Related hypothesis | Counterevidence or alternative | Materiality | Resolution |
+|---|---|---|---|---|
+| ALT-001 | HYP-001 | <Alternative> | High / Medium / Low | <How handled> |

package/skills/consulting-analyst/assets/templates/issue-tree.md

@@ -0,0 +1,35 @@
+# Issue tree: <root decision question>
+
+<State how this tree decomposes the root question and which decision it is
+intended to support.>
+
+## Decomposition logic
+
+- Logic used at level 1: <Causes / Options / Capabilities / Lifecycle / Economics>
+- Reason: <Why this logic is collectively sufficient for the root>
+- Known overlap or omission: <Residual limitation>
+
+## Tree
+
+```text
+Q0 <Root decision question>
+├── Q1 <Branch>
+│   ├── Q1.1 <Priority leaf>
+│   └── Q1.2 <Supporting leaf>
+└── Q2 <Branch>
+    ├── Q2.1 <Priority leaf>
+    └── Q2.2 <Out-of-scope leaf>
+```
+
+## Leaf register
+
+| Issue ID | Parent | Question | Status | Priority | Evidence needed | Decision consequence |
+|---|---|---|---|---|---|---|
+| Q1.1 | Q1 | <Answerable question> | Open / Answered / Unknown / Out of scope | High / Medium / Low | <Evidence> | <Why the answer matters> |
+
+## MECE review
+
+- Material overlap: <Overlap and resolution>
+- Missing branch risk: <Possible omission>
+- Scope boundary: <Why excluded branches do not block the decision>
+- Review owner: <Person or role>

package/skills/consulting-analyst/assets/templates/synthesis-handoff.md

@@ -0,0 +1,68 @@
+# Synthesis and handoff: <analysis title>
+
+<State the decision this handoff enables and what the receiving writing or
+presentation skill must communicate.>
+
+- Decision-maker: <Role or forum>
+- Decision question: <Question>
+- Decision deadline: <YYYY-MM-DD>
+- Current answer: <Recommendation, conclusion, or explicit unknown>
+- Confidence: High / Medium / Low
+- Destination: <Skill and target doctype or presentation purpose>
+- Analysis status: Completed / Incomplete
+- Omitted artifacts and reason: <Artifact: reason, or none>
+
+## Answer first
+
+<State the current best answer and the action it implies.>
+
+## Supporting findings
+
+| Finding ID | Issue IDs | Hypothesis IDs | Finding | Evidence | Related Gap, Intervention, or Criterion IDs | Confidence | So what |
+|---|---|---|---|---|---|---|---|
+| FND-001 | <Q IDs> | <HYP IDs> | <Finding> | <EVD IDs> | <GAP / INT / CRT IDs, or N/A with reason> | High / Medium / Low | <Decision implication> |
+
+## Recommended actions
+
+| Action ID | Supporting Finding IDs | Related Issue and Hypothesis IDs | Gap, Intervention, or Criterion IDs | Action | Owner | Timing | Success measure | Validation checkpoint |
+|---|---|---|---|---|---|---|---|---|
+| ACT-001 | <FND IDs> | <Q / HYP IDs> | <GAP / INT / CRT IDs, or N/A with reason> | <Action> | <Owner> | <Date or phase> | <Measure> | <Checkpoint> |
+
+Preserve the Q / HYP → FND / EVD → GAP / INT / CRT → ACT chain where
+applicable. Use only IDs defined in the analysis; mark inapplicable links
+`N/A` with a reason rather than inventing gaps, interventions, or criteria.
+
+## Options or transformation path
+
+- Selected option or target state: <Option, capability, or intervention>
+- Criteria, Gap, or Intervention IDs: <CRT / GAP / INT IDs, as applicable>
+- Rejected alternatives and reasons: <Options and reasons>
+- Sensitivity or sequencing conditions: <Conditions>
+
+## Assumptions, counterevidence, and uncertainty
+
+| ID | Type | Statement | Decision impact | Validation or response |
+|---|---|---|---|---|
+| UNC-001 | Assumption / Estimate / Counterevidence / Unknown | <Statement> | <Impact> | <Action> |
+
+## Evidence gaps
+
+| Gap ID | Missing evidence | Decision blocked or conditional | Owner | Deadline |
+|---|---|---|---|---|
+| EGP-001 | <Evidence> | <Impact> | <Owner> | <Date> |
+
+## Communication handoff
+
+- Target audience and prior knowledge: <Audience>
+- Target doctype or scenario: <Doctype or presentation purpose>
+- Required conclusion or call to action: <Outcome>
+- Evidence that must appear: <FND and EVD IDs>
+- Material caveats that must appear: <UNC IDs>
+- Frozen criteria, weights, scores, confidence, and wording: <Items>
+- Sections or slides that are optional: <Items>
+- Questions to return to consulting-analyst: <Return conditions>
+
+If `Analysis status` is `Incomplete`, the receiving skill must either return
+the decision-critical gaps to `consulting-analyst` or preserve the incomplete
+status, evidence gaps, confidence, and conditional wording visibly in the
+output.

package/skills/consulting-analyst/references/evidence-and-hypotheses.md

@@ -0,0 +1,80 @@
+# Evidence and hypothesis discipline
+
+The analysis must preserve the difference between what is known, estimated,
+assumed, interpreted, and recommended.
+
+## Statement types
+
+| Type | Meaning | Required handling |
+|---|---|---|
+| Fact | Directly supported by a traceable source | Record source, date, scope, and limitations |
+| Estimate | Quantified approximation | Record method, range, sensitivity, and owner |
+| Assumption | Unverified condition used to proceed | Record validation plan and impact if false |
+| Interpretation | Meaning inferred from facts or estimates | Show the reasoning and alternatives |
+| Recommendation | Proposed action | Trace to findings, constraints, and decision criteria |
+
+## Hypothesis record
+
+A useful hypothesis includes:
+
+- A specific proposition
+- The issue-tree leaf it answers
+- Why it is plausible
+- Supporting evidence expected
+- Disconfirming evidence expected
+- A confidence level
+- A decision consequence if true or false
+
+Do not write confidence as a percentage unless it comes from a defined model
+or elicitation method. Use `High`, `Medium`, or `Low` with a short rationale.
+
+## Evidence quality
+
+Assess evidence by:
+
+- Directness: does it measure the claimed phenomenon?
+- Reliability: can the source and method be trusted?
+- Recency: is it current enough for the decision?
+- Representativeness: does it cover the relevant population and context?
+- Independence: does it corroborate rather than repeat another source?
+- Materiality: could it change the conclusion or action?
+
+Record contradictory evidence beside supporting evidence. Do not relegate it
+to an appendix that the synthesis ignores.
+
+Use one evidence row per hypothesis pairing, or explicitly list multiple HYP
+IDs if the direction and limitations are the same for each hypothesis. Where
+they differ, reuse the EVD ID in separate pairing rows; this does not create
+independent corroboration.
+
+Preserve interpretations as `Interpretation` rows with links to underlying
+EVD IDs and alternative explanations. Interpretations do not count as
+supporting evidence. A `Supported` hypothesis requires at least one `Fact` or
+`Estimate` EVD row marked `Supports` for that hypothesis; assumptions and
+interpretations alone are insufficient.
+
+## Causal claims
+
+Before stating that one factor caused another, check:
+
+- Temporal order
+- Plausible mechanism
+- Alternative explanations
+- Selection and measurement bias
+- Whether an intervention changed the outcome
+
+When these conditions are not met, use association or contribution language
+instead of causation.
+
+## Evidence gaps
+
+For every decision-critical gap, record:
+
+- Missing evidence
+- Why it matters
+- Best available collection method
+- Owner
+- Deadline
+- Decision that must wait or proceed conditionally
+
+An explicit unknown is better than a fabricated conclusion.

package/skills/consulting-analyst/references/framework-selection.md

@@ -0,0 +1,84 @@
+# Framework selection
+
+Choose frameworks from the decision need, not from familiarity or prestige.
+The smallest sufficient set is usually one analytical framework and one
+communication framework.
+
+## Selection sequence
+
+1. Name the actor and decision.
+2. Identify the uncertainty blocking that decision.
+3. Choose the framework that exposes or reduces that uncertainty.
+4. Define the artifact or decision field the framework must populate.
+5. Remove the framework if its output will not change the decision.
+
+## Primary frameworks
+
+### Issue Tree
+
+Use when the root question is too broad to answer directly. Select one
+decomposition logic per level. Good branches are answerable and decision
+relevant.
+
+Avoid mixing causes, solutions, departments, and project phases as siblings.
+That structure creates overlap without revealing what is missing.
+
+### Hypothesis–Evidence–Falsification
+
+Use when an explanation, forecast, or proposed solution must be tested.
+Define what would make the hypothesis less likely before collecting only
+supporting evidence.
+
+Avoid hypotheses that cannot fail, such as "improving quality may help".
+
+### Causal tree and 5 Whys
+
+Use for a specific observed outcome when the causal mechanism matters. Each
+link requires evidence; asking "why" repeatedly does not establish causality.
+
+Avoid forcing one root cause when several interacting causes fit the evidence.
+
+### Current–Target–Gap
+
+Use for Blueprint, transformation, capability, operating-model, or roadmap
+work. Describe current and target states with comparable dimensions before
+identifying gaps and interventions.
+
+Avoid target states made only of product names or aspirational adjectives.
+
+### Weighted decision matrix
+
+Use when several viable alternatives must be compared across competing
+criteria. Define scoring anchors and disqualifiers before assigning scores.
+
+Avoid false precision. Run sensitivity analysis when small weight changes can
+reverse the ranking.
+
+### Pyramid Principle
+
+Use to communicate a supported conclusion. Start with the answer, group
+mutually distinct reasons, then show evidence.
+
+Avoid using the pyramid to hide uncertainty or omit contradictory evidence.
+
+### SCQA
+
+Use when the audience needs a short path from shared context to a decision
+question. Keep the complication factual and proportional.
+
+Avoid manufacturing urgency or conflict that the evidence does not support.
+
+## Supporting lenses
+
+Use these only when their outputs feed a hypothesis, criterion, gap, or
+action:
+
+- PESTLE for external conditions
+- Five Forces for industry economics
+- 3C for customer, competitor, and company fit
+- SWOT for summarizing evidenced internal and external conditions
+- Capability Map for future-state abilities and ownership
+- Impact/Effort Matrix for sequencing already defined interventions
+
+Never stack several lenses to make an analysis look comprehensive. Coverage
+comes from the issue tree and evidence, not the number of framework names.

package/skills/consulting-analyst/references/handoff-contract.md

@@ -0,0 +1,90 @@
+# Analysis handoff contract
+
+The handoff transfers reasoning and evidence without transferring ownership
+of final prose or presentation design.
+
+## Required fields
+
+`synthesis-handoff.md` must include:
+
+- Decision-maker and decision question
+- Intended outcome and deadline
+- Recommended answer and confidence
+- Supporting issue, hypothesis, finding, source, and evidence IDs
+- Assumptions and estimates
+- Counterevidence and alternative interpretations
+- Options, criteria, weights, and sensitivity when applicable
+- Current, target, gap, intervention, and action IDs when applicable
+- Risks, unresolved questions, and evidence-gathering actions
+- Required destination and target doctype or presentation purpose
+- Frozen items the receiving skill must preserve
+
+## ID semantics and traceability
+
+- `Q` identifies an issue; `HYP` a hypothesis; `FND` a synthesized finding.
+- `SRC` identifies a source record; `EVD` an analysis evidence record linked
+  to its source. Never rename a source record to `EVD` or overwrite analysis
+  evidence with a source citation.
+- `GAP` identifies a current-to-target gap; `INT` an intervention defined in
+  Current–Target–Gap; `CRT` an option criterion; `ACT` a recommended action.
+- Findings preserve their Q / HYP and EVD links and reference relevant
+  GAP / INT / CRT IDs. Actions link to supporting FND IDs, related Q / HYP
+  IDs, and applicable GAP / INT / CRT IDs. Transition risks reference the
+  affected GAP / INT IDs.
+- Preserve this chain in destination documents. Blueprint traceability keeps
+  relevant Q / HYP / FND / EVD and GAP / INT / CRT alongside its driver,
+  principle, capability, workstream, and KPI IDs. White Paper claims link
+  relevant HYP / FND / EVD IDs, while source records remain SRC IDs.
+- Use only defined, relevant IDs. Mark inapplicable links `N/A` with a reason;
+  do not require consulting IDs when no consulting handoff exists.
+
+If `Analysis status` is `Incomplete`, the receiving skill must either return
+the decision-critical gaps for further analysis or visibly preserve the
+incomplete status, evidence gaps, confidence, and conditional nature of every
+affected conclusion. It must not convert an incomplete handoff into an
+unqualified recommendation.
+
+## Handoff to tech-writer
+
+`tech-writer` owns document structure, doctype completeness, Markdown, and
+reader-facing prose. It may:
+
+- Reorder analysis to fit the doctype
+- Rename headings
+- Condense repeated evidence
+- Add doctype-required metadata and controls
+
+It must not:
+
+- Change evidence IDs or source meaning
+- Present assumptions as facts
+- Remove counterevidence that affects the conclusion
+- Change criteria, weights, scores, confidence, or recommendation without
+  returning the change to analysis
+
+## Handoff to presentation-planner
+
+`presentation-planner` owns audience reasoning, scenario, slide order, and
+visual handoff. It may:
+
+- Select the shortest evidence set that supports the audience decision
+- Split findings across slides
+- Adapt the order for the audience's prior knowledge
+
+It must preserve:
+
+- The decision question and requested action
+- Evidence status and confidence
+- Material caveats and counterevidence
+- Option-comparison logic
+- Conditions that would change the recommendation
+
+## Return conditions
+
+Return the handoff to `consulting-analyst` when:
+
+- A new conclusion is required
+- New evidence changes confidence or ranking
+- The audience asks a different decision question
+- Criteria or target-state dimensions change
+- Communication edits expose a contradiction in the analysis

package/skills/japanese-prose/NOTICE.md

@@ -0,0 +1,17 @@
+# GiNZA dependency notice
+
+This skill is an original kotonoha implementation and does not include source
+code from `coji/natural-japanese`.
+
+Morphological and syntactic analysis uses
+[GiNZA](https://github.com/megagonlabs/ginza), its `ja_ginza` model, and
+spaCy. These dependencies are resolved by `uv` when a diagnostic script is
+run. GiNZA and its Japanese Universal Dependencies models are distributed
+under the MIT License. spaCy is distributed under the MIT License.
+SudachiPy and SudachiDict are distributed under the Apache License 2.0.
+GiNZA documents the licenses of its remaining dependencies and training
+datasets.
+
+The implementation targets GiNZA 5.2.x and uses token surface forms, lemmas,
+universal part-of-speech tags, dependency relationships, sentence boundaries,
+and named-entity labels.

package/skills/japanese-prose/SKILL.md

@@ -0,0 +1,111 @@
+---
+name: japanese-prose
+description: >-
+  Improves Japanese prose in technical and business documents using
+  kotonoha's original GiNZA-based diagnostics. Use when writing, rewriting,
+  reviewing, or scoring Japanese prose; when the user asks for more natural,
+  readable, concise, or less AI-like Japanese; or when tech-writer delegates
+  its sentence-level quality pass. Owns wording, sentence rhythm, reading
+  load, terminology review, and formulaic-expression detection. Does not own
+  technical-document structure or presentation storylines.
+license: MIT
+argument-hint: "[write|review|score] [quick|full] <target file or request>"
+---
+
+# japanese-prose
+
+Improves Japanese wording without changing approved facts, obligations,
+identifiers, evidence, code, or document structure. This is an original
+kotonoha implementation. It uses
+[GiNZA](https://github.com/megagonlabs/ginza) for tokenization, part-of-speech
+tagging, dependency parsing, lemmatization, and named-entity recognition.
+
+## Responsibility boundary
+
+- `tech-writer` owns doctype selection, section structure, completeness,
+  traceability, and Markdown organization.
+- `presentation-planner` owns audience strategy, scenarios, slide order, and
+  design specifications.
+- `japanese-prose` owns sentence-level Japanese: clarity, rhythm, reading
+  load, terminology, repeated patterns, and contextual rewriting.
+
+Never move, add, or remove sections unless the calling skill explicitly
+authorizes it. Never alter requirement IDs, risk IDs, control IDs, numbers,
+units, dates, proper nouns, citations, URLs, commands, tables, schemas,
+acceptance criteria, approval states, or normative force.
+
+## Modes
+
+- `write`: write or rewrite Japanese prose. Use `quick` unless the document
+  is external-facing, high-risk, or longer than roughly 10,000 Japanese
+  characters.
+- `review`: report problems and proposed corrections without editing.
+- `score`: run diagnostics and report the 0–100 score without rewriting.
+- `quick`: run prose lint once, review findings in context, edit, and rerun
+  until no new actionable findings appear.
+- `full`: run prose lint, reading-load lint, outline extraction, and
+  terminology extraction; then review the whole document against
+  `references/review-workflow.md`.
+
+## Workflow
+
+1. Read the target, audience, intended outcome, and calling skill's frozen
+   invariants.
+2. Read `references/writing-guidelines.md` before generating or rewriting
+   prose.
+3. Run the GiNZA prose diagnostic:
+
+   ```bash
+   uv run scripts/lint.py <target-file> --genre tech --json > <workdir>/prose-baseline.json
+   ```
+
+4. For `full` mode, also run:
+
+   ```bash
+   uv run scripts/lint.py <target-file> --genre tech --reading-load --json
+   uv run scripts/outline.py <target-file>
+   uv run scripts/terms.py <target-file> --json
+   ```
+
+5. Classify each finding as `fix` or `keep`. A detector identifies a review
+   target; it does not authorize blind replacement.
+6. Apply only fixes that improve the intended reader's understanding while
+   preserving the frozen invariants.
+7. Rerun the prose diagnostic with
+   `--baseline <workdir>/prose-baseline.json` to classify new, persisting,
+   and resolved findings. Replace the baseline only after recording the
+   decisions for the current round.
+8. Stop when every finding has a decision, no new actionable finding appears,
+   and the document passes the checks in `references/review-workflow.md`.
+
+Allow at most three edit-and-diagnose rounds per invocation. If actionable
+findings or invariant violations remain, report that the optimization did not
+converge and list the unresolved items.
+
+## Markdown emphasis
+
+When strong emphasis touches surrounding prose, put half-width spaces outside
+the delimiters: `これは **重要** です`, not `これは**重要**です`. Spaces are
+unnecessary at line boundaries or next to punctuation, and must not be placed
+inside `**`. Use ASCII spaces (`U+0020`), never full-width spaces (`U+3000`),
+tabs, or non-breaking spaces, immediately before and after emphasis embedded
+in prose. Write `これは **「重要」** と説明する`, not
+`これは　**「重要」**　と説明する`.
+
+## Diagnostic interpretation
+
+The score is a triage aid, not a quality certificate. Read
+`references/scoring.md` before presenting it. GiNZA provides linguistic
+observations; the agent remains responsible for deciding whether a change is
+correct in context.
+
+## Completion report
+
+Report:
+
+- mode and diagnostics executed
+- initial and final scores
+- findings fixed and findings deliberately kept
+- any skipped diagnostic and its reason
+- invariant verification result
+- `completed` or `did not converge`