@hanzlaa/rcode 2.8.0 → 3.1.0

package/rihal/skills/core/rihal-editorial-review-prose/SKILL.md

@@ -118,3 +118,8 @@ Three-column markdown table:
 ### Negative boundary
 **User:** "restructure this document"
 **Result:** Not prose review → route to `rihal-editorial-review-structure`
+
+## Memory Bank Hooks
+
+- **Reads:** the document under review; `style_guide` if provided
+- **Writes:** nothing — produces a recommendations report only

package/rihal/skills/core/rihal-editorial-review-structure/SKILL.md

@@ -1,211 +1,73 @@
 ---
 name: rihal-editorial-review-structure
-description: 'Structural editor that proposes cuts, reorganization, and simplification while preserving comprehension. Use when user requests structural review or editorial review of structure'
+description: Structural editor that proposes cuts, reorganization, and consolidation while preserving comprehension. Use when the user requests structural review, "review the structure of this doc", or "tighten this document". Run before copy editing. For prose-level fixes (typos, grammar, word choice) use rihal-editorial-review-prose instead.
 triggers:
   - "editorial review structure"
+  - "structural review"
+  - "tighten this doc"
+  - "review document structure"
+  - "cut this doc down"
+user-invocable: true
 ---
 
-# Editorial Review - Structure
+## Overview
 
-**Goal:** Review document structure and propose substantive changes to improve clarity and flow -- run this BEFORE copy editing.
+Structural editor focused on high-value density. Reviews a document's organisation and proposes substantive changes — cut, merge, move, condense — without altering content. Brevity equals clarity; every section must justify its existence. Outputs prioritised recommendations the user accepts or rejects. **Content is sacrosanct** — never challenge ideas, only optimise how they are organised. Detailed principles, structure models, and the recommendation schema live in [`references.md`](references.md).
 
-**Your Role:** You are a structural editor focused on HIGH-VALUE DENSITY. Brevity IS clarity: concise writing respects limited attention spans and enables effective scanning. Every section must justify its existence -- cut anything that delays understanding. True redundancy is failure. Follow ALL steps in the STEPS section IN EXACT ORDER. DO NOT skip steps or change the sequence. HALT immediately when halt-conditions are met. Each action within a step is a REQUIRED action to complete that step.
+## Inputs
 
-> **STYLE GUIDE OVERRIDE:** If a style_guide input is provided, it overrides ALL generic principles in this task (including human-reader-principles, llm-reader-principles, reader_type-specific priorities, structure-models selection, and the Microsoft Writing Style Guide baseline). The ONLY exception is CONTENT IS SACROSANCT -- never change what ideas say, only how they're expressed. When style guide conflicts with this task, style guide wins.
+- `content` (required) — the document
+- `style_guide` (optional) — overrides all generic principles in this skill except "content is sacrosanct"
+- `purpose` (optional) — e.g. "quickstart tutorial", "API reference"
+- `target_audience` (optional) — e.g. "new users", "decision makers"
+- `reader_type` (optional, default `humans`) — `humans` preserves comprehension aids; `llm` optimises for precision and density
+- `length_target` (optional) — e.g. "30% shorter", "no limit"
 
-**Inputs:**
-- **content** (required) -- Document to review (markdown, plain text, or structured content)
-- **style_guide** (optional) -- Project-specific style guide. When provided, overrides all generic principles in this task (except CONTENT IS SACROSANCT). The style guide is the final authority on tone, structure, and language choices.
-- **purpose** (optional) -- Document's intended purpose (e.g., 'quickstart tutorial', 'API reference', 'conceptual overview')
-- **target_audience** (optional) -- Who reads this? (e.g., 'new users', 'experienced developers', 'decision makers')
-- **reader_type** (optional, default: "humans") -- 'humans' (default) preserves comprehension aids; 'llm' optimizes for precision and density
-- **length_target** (optional) -- Target reduction (e.g., '30% shorter', 'half the length', 'no limit')
+## Process
 
-## Overview
+1. **Validate input.** HALT if content is fewer than 3 words or `reader_type` is invalid. Note current word and section counts.
+2. **Understand purpose.** Use provided `purpose` and `target_audience` or infer them. Pick the structure model that fits (Tutorial / Reference / Explanation / Prompt / Pyramid — see references).
+3. **Structural analysis.** If `style_guide` provided, consult it first. Map every section's word count. Test against the model's rules (e.g. "does the recommendation come first?" for Pyramid). Identify cuts, merges, moves, splits, true redundancies, scope violations, buried critical information.
+4. **Flow analysis.** Does the sequence match how readers use the doc? Look for premature detail, missing scaffolding, FAQs that should be inline, appendices that should be cut, summaries that repeat the body verbatim.
+5. **Generate recommendations.** Categorise each: `CUT`, `MERGE`, `MOVE`, `CONDENSE`, `QUESTION`, `PRESERVE`. One-sentence rationale, estimated word impact. Flag cuts that may hurt comprehension when `reader_type=humans`.
+6. **Output.** Document summary + prioritised recommendations + total estimated reduction. If nothing to fix: "No substantive changes recommended — document structure is sound." (valid completion, not an error.)
 
-Editorial review structure skill for Rihal Code.
-
-## Principles
-
-- Comprehension through calibration: Optimize for the minimum words needed to maintain understanding
-- Front-load value: Critical information comes first; nice-to-know comes last (or goes)
-- One source of truth: If information appears identically twice, consolidate
-- Scope discipline: Content that belongs in a different document should be cut or linked
-- Propose, don't execute: Output recommendations -- user decides what to accept
-- **CONTENT IS SACROSANCT: Never challenge ideas -- only optimize how they're organized.**
-
-## Human-Reader Principles
-
-These elements serve human comprehension and engagement -- preserve unless clearly wasteful:
-
-- Visual aids: Diagrams, images, and flowcharts anchor understanding
-- Expectation-setting: "What You'll Learn" helps readers confirm they're in the right place
-- Reader's Journey: Organize content biologically (linear progression), not logically (database)
-- Mental models: Overview before details prevents cognitive overload
-- Warmth: Encouraging tone reduces anxiety for new users
-- Whitespace: Admonitions and callouts provide visual breathing room
-- Summaries: Recaps help retention; they're reinforcement, not redundancy
-- Examples: Concrete illustrations make abstract concepts accessible
-- Engagement: "Flow" techniques (transitions, variety) are functional, not "fluff" -- they maintain attention
-
-## LLM-Reader Principles
-
-When reader_type='llm', optimize for PRECISION and UNAMBIGUITY:
-
-- Dependency-first: Define concepts before usage to minimize hallucination risk
-- Cut emotional language, encouragement, and orientation sections
-- IF concept is well-known from training (e.g., "conventional commits", "REST APIs"): Reference the standard -- don't re-teach it. ELSE: Be explicit -- don't assume the LLM will infer correctly.
-- Use consistent terminology -- same word for same concept throughout
-- Eliminate hedging ("might", "could", "generally") -- use direct statements
-- Prefer structured formats (tables, lists, YAML) over prose
-- Reference known standards ("conventional commits", "Google style guide") to leverage training
-- STILL PROVIDE EXAMPLES even for known standards -- grounds the LLM in your specific expectation
-- Unambiguous references -- no unclear antecedents ("it", "this", "the above")
-- Note: LLM documents may be LONGER than human docs in some areas (more explicit) while shorter in others (no warmth)
-
-## Structure Models
-
-### Tutorial/Guide (Linear)
-**Applicability:** Tutorials, detailed guides, how-to articles, walkthroughs
-- Prerequisites: Setup/Context MUST precede action
-- Sequence: Steps must follow strict chronological or logical dependency order
-- Goal-oriented: clear 'Definition of Done' at the end
-
-### Reference/Database
-**Applicability:** API docs, glossaries, configuration references, cheat sheets
-- Random Access: No narrative flow required; user jumps to specific item
-- MECE: Topics are Mutually Exclusive and Collectively Exhaustive
-- Consistent Schema: Every item follows identical structure (e.g., Signature to Params to Returns)
-
-### Explanation (Conceptual)
-**Applicability:** Deep dives, architecture overviews, conceptual guides, whitepapers, project context
-- Abstract to Concrete: Definition to Context to Implementation/Example
-- Scaffolding: Complex ideas built on established foundations
-
-### Prompt/Task Definition (Functional)
-**Applicability:** Rihal tasks, prompts, system instructions, XML definitions
-- Meta-first: Inputs, usage constraints, and context defined before instructions
-- Separation of Concerns: Instructions (logic) separate from Data (content)
-- Step-by-step: Execution flow must be explicit and ordered
-
-### Strategic/Context (Pyramid)
-**Applicability:** PRDs, research reports, proposals, decision records
-- Top-down: Conclusion/Status/Recommendation starts the document
-- Grouping: Supporting context grouped logically below the headline
-- Ordering: Most critical information first
-- MECE: Arguments/Groups are Mutually Exclusive and Collectively Exhaustive
-- Evidence: Data supports arguments, never leads
-
-## STEPS
-
-### Step 1: Validate Input
-
-- Check if content is empty or contains fewer than 3 words
-- If empty or fewer than 3 words, HALT with error: "Content too short for substantive review (minimum 3 words required)"
-- Validate reader_type is "humans" or "llm" (or not provided, defaulting to "humans")
-- If reader_type is invalid, HALT with error: "Invalid reader_type. Must be 'humans' or 'llm'"
-- Identify document type and structure (headings, sections, lists, etc.)
-- Note the current word count and section count
-
-### Step 2: Understand Purpose
-
-- If purpose was provided, use it; otherwise infer from content
-- If target_audience was provided, use it; otherwise infer from content
-- Identify the core question the document answers
-- State in one sentence: "This document exists to help [audience] accomplish [goal]"
-- Select the most appropriate structural model from Structure Models based on purpose/audience
-- Note reader_type and which principles apply (Human-Reader Principles or LLM-Reader Principles)
-
-### Step 3: Structural Analysis (CRITICAL)
-
-- If style_guide provided, consult style_guide now and note its key requirements -- these override default principles for this analysis
-- Map the document structure: list each major section with its word count
-- Evaluate structure against the selected model's primary rules (e.g., 'Does recommendation come first?' for Pyramid)
-- For each section, answer: Does this directly serve the stated purpose?
-- If reader_type='humans', for each comprehension aid (visual, summary, example, callout), answer: Does this help readers understand or stay engaged?
-- Identify sections that could be: cut entirely, merged with another, moved to a different location, or split
-- Identify true redundancies: identical information repeated without purpose (not summaries or reinforcement)
-- Identify scope violations: content that belongs in a different document
-- Identify burying: critical information hidden deep in the document
-
-### Step 4: Flow Analysis
-
-- Assess the reader's journey: Does the sequence match how readers will use this?
-- Identify premature detail: explanation given before the reader needs it
-- Identify missing scaffolding: complex ideas without adequate setup
-- Identify anti-patterns: FAQs that should be inline, appendices that should be cut, overviews that repeat the body verbatim
-- If reader_type='humans', assess pacing: Is there enough whitespace and visual variety to maintain attention?
-
-### Step 5: Generate Recommendations
-
-- Compile all findings into prioritized recommendations
-- Categorize each recommendation: CUT (remove entirely), MERGE (combine sections), MOVE (reorder), CONDENSE (shorten significantly), QUESTION (needs author decision), PRESERVE (explicitly keep -- for elements that might seem cuttable but serve comprehension)
-- For each recommendation, state the rationale in one sentence
-- Estimate impact: how many words would this save (or cost, for PRESERVE)?
-- If length_target was provided, assess whether recommendations meet it
-- If reader_type='humans' and recommendations would cut comprehension aids, flag with warning: "This cut may impact reader comprehension/engagement"
-
-### Step 6: Output Results
-
-- Output document summary (purpose, audience, reader_type, current length)
-- Output the recommendation list in priority order
-- Output estimated total reduction if all recommendations accepted
-- If no recommendations, output: "No substantive changes recommended -- document structure is sound"
-
-Use the following output format:
+## Output Format
 
 ```markdown
 ## Document Summary
-- **Purpose:** [inferred or provided purpose]
-- **Audience:** [inferred or provided audience]
-- **Reader type:** [selected reader type]
-- **Structure model:** [selected structure model]
-- **Current length:** [X] words across [Y] sections
+- Purpose: ...
+- Audience: ...
+- Reader type: humans | llm
+- Structure model: tutorial | reference | explanation | prompt | pyramid
+- Current length: X words across Y sections
 
 ## Recommendations
-
-### 1. [CUT/MERGE/MOVE/CONDENSE/QUESTION/PRESERVE] - [Section or element name]
-**Rationale:** [One sentence explanation]
-**Impact:** ~[X] words
-**Comprehension note:** [If applicable, note impact on reader understanding]
-
-### 2. ...
+### 1. [CUT|MERGE|MOVE|CONDENSE|QUESTION|PRESERVE] — Section name
+Rationale: ...
+Impact: ~X words
+Comprehension note: (if applicable)
 
 ## Summary
-- **Total recommendations:** [N]
-- **Estimated reduction:** [X] words ([Y]% of original)
-- **Meets length target:** [Yes/No/No target specified]
-- **Comprehension trade-offs:** [Note any cuts that sacrifice reader engagement for brevity]
+- Total recommendations: N
+- Estimated reduction: X words (Y%)
+- Meets length target: Yes | No | no target specified
+- Comprehension trade-offs: ...
 ```
 
-## HALT CONDITIONS
-
-- HALT with error if content is empty or fewer than 3 words
-- HALT with error if reader_type is not "humans" or "llm"
-- If no structural issues found, output "No substantive changes recommended" (this is valid completion, not an error)
+## Examples
 
-## Workflow
+**Happy path** — `structural review of this tutorial` → 6 recommendations (2 CUT, 1 MERGE, 2 MOVE, 1 CONDENSE) → ~30% reduction estimated.
 
-1. Read the user request and extract key parameters.
-2. Execute the skill logic as described in the Overview.
-3. Return output in the format specified below.
+**Edge case — already tight** — Output: "No substantive changes recommended — document structure is sound."
 
-## Output Format
+**Negative — wrong skill** — `fix the typos in this doc` is prose, not structure. Route to `rihal-editorial-review-prose`.
 
-- Structured Markdown response
-- Headers for each section
-- Concise, actionable content
-
-## Examples
+## Memory Bank Hooks
 
-### Happy path
-**User:** "structural review of this tutorial"
-**Result:** Document Summary → 6 recommendations (2 CUT, 1 MERGE, 2 MOVE, 1 CONDENSE) → estimated 30% reduction
+- **Reads:** the document passed in; `style_guide` if referenced
+- **Writes:** nothing — produces a recommendations report only
 
-### Edge case
-**User:** "structural review" + well-structured doc
-**Result:** "No substantive changes recommended — document structure is sound"
+## Detailed reference
 
-### Negative boundary
-**User:** "fix the typos in this doc"
-**Result:** Not structural → route to `rihal-editorial-review-prose`
+See [`references.md`](references.md) for: the full principle list, human-reader vs LLM-reader principles, the five structure models with applicability rules, and HALT conditions.

package/rihal/skills/core/rihal-editorial-review-structure/references.md

@@ -0,0 +1,110 @@
+# Editorial Review (Structure) — Detailed Reference
+
+Detailed principles and models for [`SKILL.md`](SKILL.md).
+
+---
+
+## Core principles
+
+- **Comprehension through calibration** — minimum words needed to maintain understanding.
+- **Front-load value** — critical information first; nice-to-know last (or cut).
+- **One source of truth** — if information appears identically twice, consolidate.
+- **Scope discipline** — content that belongs in a different document should be cut or linked.
+- **Propose, don't execute** — output recommendations; the user decides what to accept.
+- **Content is sacrosanct** — never challenge ideas, only optimise how they're organised.
+
+---
+
+## Human-reader principles (preserve unless clearly wasteful)
+
+When `reader_type=humans`:
+
+- **Visual aids** — diagrams, images, flowcharts anchor understanding.
+- **Expectation-setting** — "What you'll learn" helps readers confirm fit.
+- **Reader's journey** — organise biologically (linear progression), not logically (database).
+- **Mental models** — overview before details prevents cognitive overload.
+- **Warmth** — encouraging tone reduces anxiety for new users.
+- **Whitespace** — admonitions and callouts provide visual breathing room.
+- **Summaries** — recaps reinforce; they're not redundancy.
+- **Examples** — concrete illustrations make abstract concepts accessible.
+- **Engagement** — transitions and variety maintain attention; they're functional, not "fluff".
+
+---
+
+## LLM-reader principles (when `reader_type=llm`)
+
+Optimise for precision and unambiguity:
+
+- **Dependency-first** — define concepts before usage to minimise hallucination risk.
+- **Cut emotional language**, encouragement, orientation sections.
+- **Reference known standards** ("conventional commits", "Google style guide") — leverage training. But still provide examples to ground specific expectations.
+- **Consistent terminology** — same word for same concept throughout.
+- **Eliminate hedging** — no "might", "could", "generally". Direct statements.
+- **Prefer structured formats** — tables, lists, YAML — over prose.
+- **Unambiguous references** — no unclear antecedents like "it", "this", "the above".
+
+LLM-targeted documents may be longer than human ones in some areas (more explicit) and shorter in others (no warmth).
+
+---
+
+## Structure models
+
+Pick the one matching the document's purpose.
+
+### Tutorial / Guide (Linear)
+**For:** tutorials, how-to articles, walkthroughs.
+- Prerequisites: setup must precede action.
+- Sequence: strict chronological or logical dependency order.
+- Goal-oriented: clear "Definition of Done" at the end.
+
+### Reference / Database
+**For:** API docs, glossaries, configuration references, cheat sheets.
+- Random access — no narrative flow required; users jump to specific items.
+- MECE — topics are Mutually Exclusive and Collectively Exhaustive.
+- Consistent schema — every item follows identical structure (Signature → Params → Returns).
+
+### Explanation (Conceptual)
+**For:** deep dives, architecture overviews, conceptual guides, project context.
+- Abstract → concrete: definition → context → implementation/example.
+- Scaffolding: complex ideas built on established foundations.
+
+### Prompt / Task Definition (Functional)
+**For:** Rihal tasks, prompts, system instructions, XML definitions.
+- Meta-first: inputs, usage constraints, context defined before instructions.
+- Separation of concerns: instructions (logic) separate from data (content).
+- Step-by-step: execution flow explicit and ordered.
+
+### Strategic / Context (Pyramid)
+**For:** PRDs, research reports, proposals, decision records.
+- Top-down: conclusion / status / recommendation starts the document.
+- Grouping: supporting context grouped logically below the headline.
+- Ordering: most critical information first.
+- MECE: arguments are Mutually Exclusive and Collectively Exhaustive.
+- Evidence: data supports arguments, never leads.
+
+---
+
+## Recommendation categories
+
+| Category | Use when |
+|---|---|
+| `CUT` | Section adds no value to the stated purpose; remove entirely |
+| `MERGE` | Two sections cover overlapping ground; combine |
+| `MOVE` | Critical information is buried, or details precede their setup |
+| `CONDENSE` | Section is needed but verbose — shorten significantly |
+| `QUESTION` | Decision the author needs to make (not the editor's call) |
+| `PRESERVE` | Element looks cuttable but actually serves comprehension — explicitly keep |
+
+---
+
+## HALT conditions
+
+- HALT with error if content is empty or fewer than 3 words.
+- HALT with error if `reader_type` is not `humans` or `llm`.
+- If no structural issues found: output "No substantive changes recommended — document structure is sound." (Valid completion, not an error.)
+
+---
+
+## Style guide override
+
+If a `style_guide` is provided, it overrides all generic principles in this skill — including human-reader principles, LLM-reader principles, structure-model selection, and the Microsoft Writing Style Guide baseline. The single exception is **content is sacrosanct**: never change what ideas say, only how they're expressed.

package/rihal/skills/core/rihal-help/SKILL.md

@@ -65,7 +65,7 @@ module,skill,display-name,menu-code,description,action,args,phase,after,before,r
 For each recommended item, present:
 - `[menu-code]` **Display name** — e.g., "[CP] Create PRD"
 - Skill name in backticks — e.g., `rihal-create-prd`
-- For multi-action skills: action invocation context — e.g., "tech-writer lets create a mermaid diagram!"
+- For multi-action skills: action invocation context — e.g., "noor lets create a mermaid diagram!"
 - Description if present in CSV; otherwise your existing knowledge of the skill suffices
 - Args if available
 
@@ -101,3 +101,8 @@ Status summary of current workflow position, then ordered list of recommended ne
 ### Negative boundary
 **User:** "help me write a React component"
 **Result:** Not a Rihal workflow question → route to `rihal-dev-story` or answer directly
+
+## Memory Bank Hooks
+
+- **Reads:** nothing — `help` is pure reference output
+- **Writes:** nothing — read-only

package/rihal/skills/core/rihal-incident-record/SKILL.md

@@ -0,0 +1,161 @@
+---
+name: rihal-incident-record
+description: Generate a change record + post-mortem in one flow. Use after resolving any production incident, deploying any non-trivial change, or making any decision that future-you will need to retrace. Implements the verified Rihal change-record format from `template/docs/change_records/`. Pairs with rihal-debug — once the bug is rooted-out, this skill writes the record.
+triggers:
+  - "incident record"
+  - "post mortem"
+  - "change record"
+  - "document this incident"
+  - "write a postmortem"
+  - "record this change"
+  - "rca write up"
+  - "incident summary"
+user-invocable: true
+---
+
+## Overview
+
+Every production change deserves a record; every incident deserves a post-mortem. This skill produces both in the documented Rihal format, so the team builds an institutional memory rather than repeating the same Slack-message-as-archaeology pattern. Output goes to the Memory Bank automatically — `.rihal/memory/change-records/` for changes, `.rihal/memory/incidents/post-mortems/` for incidents.
+
+## Two formats
+
+### Change record (`change-records/YYYYMMDD-NNN.md`)
+
+Mirrors the Rihal template at `template/docs/change_records/20250514-001.md`. Use for any deploy, schema change, infra change, or anything you'd want to find again in 6 months.
+
+```markdown
+### Change ID
+`YYYYMMDD-NNN`
+
+### Date of Change
+YYYY-MM-DD
+
+### Requester
+<name + role>
+
+### Change Owner
+<name + team>
+
+### Change Category
+Backend (BE) | Frontend (FE) | Infra | Data | Security
+
+### Change Type
+Hotfix | Standard release | Schema migration | Config change
+
+### Change Description
+<one paragraph — what changed, why, what users see>
+
+### Related Tickets / References
+- GitHub PR: #N
+- Issue: #M
+- Related change records: <links>
+
+### Risk Assessment
+Low | Medium | High | Emergency
+- <specific risks identified>
+
+### Deployment Method
+<Helm | Compose | manual | gradual rollout %>
+
+### Approval
+Approved by: <name>
+Approval date: YYYY-MM-DD
+
+### Rollback Plan
+<exact steps to revert; test the rollback in staging first if possible>
+
+### Verification & Outcome
+Successful | Partial | Rolled back
+- <verification steps and outcomes>
+
+### Post-Change Notes
+<anything useful for future-you>
+```
+
+### Post-mortem (`incidents/post-mortems/YYYYMMDD-<slug>.md`)
+
+For resolved incidents. Format below.
+
+```markdown
+# Incident — <one-line headline>
+
+**Date:** YYYY-MM-DD
+**Duration:** <X minutes>
+**Severity:** SEV1 (customer-facing data loss) | SEV2 (degraded service) | SEV3 (internal)
+**Detection:** <how we noticed — Sentry alert, customer report, internal monitoring>
+**Resolution:** <one sentence>
+
+## Timeline
+
+- HH:MM — <event>
+- HH:MM — <event>
+- HH:MM — <resolution>
+
+## Root cause
+
+<one paragraph, mechanism not symptom>
+
+## Contributing factors
+
+- <factor 1>
+- <factor 2>
+
+## What worked
+
+- <what helped us recover quickly>
+
+## What didn't
+
+- <what slowed us down — be honest, not defensive>
+
+## Action items
+
+- [ ] <preventive measure> — owner — by when
+- [ ] <detective measure> — owner — by when
+- [ ] <documentation update> — owner — by when
+
+## Memory Bank update
+
+- known-issues.md: <removed | updated>
+- decisions.md: <appended new decision if relevant>
+```
+
+## Workflow
+
+1. **Detect type:** is this a planned change (change record) or a resolved incident (post-mortem)? Both can apply if a change caused an incident.
+2. **Gather facts.** From Sentry, PRs, deploy logs, Slack threads. Quote verbatim where useful.
+3. **Generate the document** using the appropriate template.
+4. **Save to the Memory Bank** at the right path. ID format `YYYYMMDD-NNN` (sequence per day).
+5. **Update related Memory Bank files:**
+   - Remove the issue from `known-issues.md` if a real fix shipped.
+   - Append a decision to `decisions.md` if the post-mortem produced one.
+6. **Schedule a follow-up review** if action items remain — 1 week typical.
+
+## Output Format
+
+The skill writes the file directly. Output to the user is a confirmation:
+
+```
+✓ Change record saved to .rihal/memory/change-records/20260426-001.md
+   Type: <type>
+   Severity / Risk: <level>
+   
+Memory Bank updates:
+  → known-issues.md: removed entry "<title>"
+  → decisions.md: appended decision "<title>"
+
+Action items: <count> open, <count> due this week
+```
+
+## Examples
+
+**Happy path — change record** — Deployed Postgres 16 upgrade. Auto-generates change-records/20260426-001.md with risk: medium, rollback: Helm rollback to previous chart version, verification: ground-truth queries pass. Approved by Hanzla, deployed gradually with 24h soak.
+
+**Happy path — post-mortem** — Login broke for Arabic usernames for 3h. Root cause: client_encoding mismatch on a new Postgres replica. Timeline + actions + Memory Bank update (remove the bug from known-issues, add a CI check that asserts client_encoding = utf8). One follow-up: add ground-truth tests for non-ASCII auth.
+
+**Negative — "we resolved it on Slack, no need for a doc"** — Refuse. Slack threads decay; Memory Bank persists. The 10 minutes spent writing the post-mortem saves an hour the next time the same class of bug appears.
+
+## Memory Bank Hooks
+
+- **Reads:** `.rihal/memory/incidents/known-issues.md` (so we know what to clean up)
+- **Writes:** `.rihal/memory/change-records/YYYYMMDD-NNN.md` (changes); `.rihal/memory/incidents/post-mortems/YYYYMMDD-<slug>.md` (incidents); plus updates to `known-issues.md` and `decisions.md` as side-effects

package/rihal/skills/core/rihal-index-docs/SKILL.md

@@ -96,3 +96,8 @@ Index docs skill for Rihal Code.
 **User:** "document this project"
 **Result:** Not indexing → route to `rihal-document-project`
 - Skip hidden files (starting with .) unless specified
+
+## Memory Bank Hooks
+
+- **Reads:** every doc in the indexing scope
+- **Writes:** the index file at the configured output path; does NOT modify `.rihal/memory/` (use `rcode-memory-distill` for memory bank index regeneration)

package/rihal/skills/core/rihal-init/SKILL.md

@@ -125,3 +125,8 @@ JSON config vars returned to the calling skill. When init path runs, interactive
 ### Negative boundary
 **User:** "initialize my project"
 **Result:** rihal-init is internal — user should use `rihal-scaffold-project` or `/rihal:install` instead
+
+## Memory Bank Hooks
+
+- **Reads:** `package.json`, existing `.rihal/state.json` to detect prior runs
+- **Writes:** `.rihal/config.yaml`, `.rihal/state.json`, `.rihal/context/active.md`, `.rihal/context/project-brief.md`, `.rihal/RIHLA.md`. Bootstraps the project so all subsequent rcode skills have a stable root.