@hanzlaa/rcode 2.1.0

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

@@ -0,0 +1,193 @@
+---
+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'
+---
+
+# Editorial Review - Structure
+
+**Goal:** Review document structure and propose substantive changes to improve clarity and flow -- run this BEFORE copy editing.
+
+**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.
+
+> **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.
+
+**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')
+
+## 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:
+
+```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
+
+## 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. ...
+
+## 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]
+```
+
+## 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
+
+### Happy path
+**User:** "structural review of this tutorial"
+**Result:** Document Summary → 6 recommendations (2 CUT, 1 MERGE, 2 MOVE, 1 CONDENSE) → estimated 30% reduction
+
+### Edge case
+**User:** "structural review" + well-structured doc
+**Result:** "No substantive changes recommended — document structure is sound"
+
+### Negative boundary
+**User:** "fix the typos in this doc"
+**Result:** Not structural → route to `rihal-editorial-review-prose`

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

@@ -0,0 +1,91 @@
+---
+name: rihal-help
+description: 'Analyzes current state and user query to answer Rihal questions or recommend the next skill(s) to use. Use when user asks for help, Rihal help, what to do next, or what to start with in Rihal.'
+---
+
+# Rihal Help
+
+## Purpose
+
+Help the user understand where they are in their Rihal workflow and what to do next. Answer Rihal questions when asked.
+
+## Desired Outcomes
+
+When this skill completes, the user should:
+
+1. **Know where they are** — which module and phase they're in, what's already been completed
+2. **Know what to do next** — the next recommended and/or required step, with clear reasoning
+3. **Know how to invoke it** — skill name, menu code, action context, and any args that shortcut the conversation
+4. **Get offered a quick start** — when a single skill is the clear next step, offer to run it for the user right now rather than just listing it
+5. **Feel oriented, not overwhelmed** — surface only what's relevant to their current position; don't dump the entire catalog
+
+## Data Sources
+
+- **Catalog**: `{project-root}/.rihal/catalog.json` — assembled manifest of all installed module skills
+- **Config**: `config.yaml` and `user-config.yaml` files in `{project-root}/.rihal/` and its subfolders — resolve `output-location` variables, provide `communication_language` and `project_knowledge`
+- **Artifacts**: Files matching `outputs` patterns at resolved `output-location` paths reveal which steps are possibly completed; their content may also provide grounding context for recommendations
+- **Project knowledge**: If `project_knowledge` resolves to an existing path, read it for grounding context. Never fabricate project-specific details.
+
+## CSV Interpretation
+
+The catalog uses this format:
+
+```
+module,skill,display-name,menu-code,description,action,args,phase,after,before,required,output-location,outputs
+```
+
+**Phases** determine the high-level flow:
+- `anytime` — available regardless of workflow state
+- Numbered phases (`1-analysis`, `2-planning`, etc.) flow in order; naming varies by module
+
+**Dependencies** determine ordering within and across phases:
+- `after` — skills that should ideally complete before this one
+- `before` — skills that should run after this one
+- Format: `skill-name` for single-action skills, `skill-name:action` for multi-action skills
+
+**Required gates**:
+- `required=true` items must complete before the user can meaningfully proceed to later phases
+- A phase with no required items is entirely optional — recommend it but be clear about what's actually required next
+
+**Completion detection**:
+- Search resolved output paths for `outputs` patterns
+- Fuzzy-match found files to catalog rows
+- User may also state completion explicitly, or it may be evident from the current conversation
+
+**Descriptions carry routing context** — some contain cycle info and alternate paths (e.g., "back to DS if fixes needed"). Read them as navigation hints, not just display text.
+
+## Response Format
+
+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!"
+- Description if present in CSV; otherwise your existing knowledge of the skill suffices
+- Args if available
+
+**Ordering**: Show optional items first, then the next required item. Make it clear which is which.
+
+## Constraints
+
+- Present all output in `{communication_language}`
+- Recommend running each skill in a **fresh context window**
+- Match the user's tone — conversational when they're casual, structured when they want specifics
+- If the active module is ambiguous, ask rather than guess
+
+## Output Format
+
+Status summary of current workflow position, then ordered list of recommended next skills with `[menu-code]` **Display name**, skill name in backticks, and description.
+
+## Examples
+
+### Happy path
+**User:** "what should I do next?"
+**Result:** Detects PRD exists but no stories → recommends `rihal-create-epics-and-stories` → offers to run it
+
+### Edge case
+**User:** "help" in an empty project
+**Result:** No artifacts found → recommends starting with `rihal-scaffold-project` or `rihal-init`
+
+### Negative boundary
+**User:** "help me write a React component"
+**Result:** Not a Rihal workflow question → route to `rihal-dev-story` or answer directly

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

@@ -0,0 +1,80 @@
+---
+name: rihal-index-docs
+description: 'Generates or updates an index.md to reference all docs in the folder. Use if user requests to create or update an index of all files in a specific folder'
+---
+
+# Index Docs
+
+**Goal:** Generate or update an index.md to reference all docs in a target folder.
+
+
+## EXECUTION
+
+### Step 1: Scan Directory
+
+- List all files and subdirectories in the target location
+
+### Step 2: Group Content
+
+- Organize files by type, purpose, or subdirectory
+
+### Step 3: Generate Descriptions
+
+- Read each file to understand its actual purpose and create brief (3-10 word) descriptions based on the content, not just the filename
+
+### Step 4: Create/Update Index
+
+- Write or update index.md with organized file listings
+
+
+## OUTPUT FORMAT
+
+```markdown
+# Directory Index
+
+## Files
+
+- **[filename.ext](./filename.ext)** - Brief description
+- **[another-file.ext](./another-file.ext)** - Brief description
+
+## Subdirectories
+
+### subfolder/
+
+- **[file1.ext](./subfolder/file1.ext)** - Brief description
+- **[file2.ext](./subfolder/file2.ext)** - Brief description
+
+### another-folder/
+
+- **[file3.ext](./another-folder/file3.ext)** - Brief description
+```
+
+
+## HALT CONDITIONS
+
+- HALT if target directory does not exist or is inaccessible
+- HALT if user does not have write permissions to create index.md
+
+
+## VALIDATION
+
+- Use relative paths starting with ./
+- Group similar files together
+- Read file contents to generate accurate descriptions - don't guess from filenames
+- Keep descriptions concise but informative (3-10 words)
+- Sort alphabetically within groups
+
+## Examples
+
+### Happy path
+**User:** "create an index of all files in ./docs"
+**Result:** Scans docs/ → groups by type → generates index.md with relative links and descriptions
+
+### Edge case
+**User:** "index docs" + folder with 200 files and nested subdirectories
+**Result:** Groups by subdirectory, generates hierarchical index with descriptions read from each file
+
+### Negative boundary
+**User:** "document this project"
+**Result:** Not indexing → route to `rihal-document-project`
+- Skip hidden files (starting with .) unless specified

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

@@ -0,0 +1,119 @@
+---
+name: rihal-init
+internal: true
+description: "INTERNAL config loader — called by other skills, not by users directly. Loads module config vars from .rihal/. Install puts this in .rihal/skills/, not .claude/skills/."
+argument-hint: "[--module=module_code] [--vars=var1:default1,var2] [--skill-path=/path/to/calling/skill]"
+---
+
+## Overview
+
+This skill is the configuration entry point for all Rihal skills. It has two modes:
+
+- **Fast path**: Config exists for the requested module — returns vars as JSON. Done.
+- **Init path**: Config is missing — walks the user through configuration, writes config files, then returns vars.
+
+Every Rihal skill should call this on activation to get its config vars. The caller never needs to know whether init happened — they just get their config back.
+
+The script `rihal_init.py` is located in this skill's `scripts/` directory. Locate and run it using python for all commands below.
+
+## On Activation — Fast Path
+
+Run the `rihal_init.py` script with the `load` subcommand. Pass `--project-root` set to the project root directory.
+
+- If a module code was provided by the calling skill, include `--module {module_code}`
+- To load all vars, include `--all`
+- To request specific variables with defaults, use `--vars var1:default1,var2`
+- If no module was specified, omit `--module` to get core vars only
+
+**If the script returns JSON vars** — store them as `{var-name}` and return to the calling skill. Done.
+
+**If the script returns an error or `init_required`** — proceed to the Init Path below.
+
+## Init Path — First-Time Setup
+
+When the fast path fails (config missing for a module), run this init flow.
+
+### Step 1: Check what needs setup
+
+Run `rihal_init.py` with the `check` subcommand, passing `--module {module_code}`, `--skill-path {calling_skill_path}`, and `--project-root`.
+
+The response tells you what's needed:
+
+- `"status": "ready"` — Config is fine. Re-run load.
+- `"status": "no_project"` — Can't find project root. Ask user to confirm the project path.
+- `"status": "core_missing"` — Core config doesn't exist. Must ask core questions first.
+- `"status": "module_missing"` — Core exists but module config doesn't. Ask module questions.
+
+The response includes:
+- `core_module` — Core module.yaml questions (when core setup needed)
+- `target_module` — Target module.yaml questions (when module setup needed, discovered from `--skill-path` or `_rihal/{module}/`)
+- `core_vars` — Existing core config values (when core exists but module doesn't)
+
+### Step 2: Ask core questions (if `core_missing`)
+
+The check response includes `core_module` with header, subheader, and variable definitions.
+
+1. Show the `header` and `subheader` to the user
+2. For each variable, present the `prompt` and `default`
+3. For variables with `single-select`, show the options as a numbered list
+4. For variables with multi-line `prompt` (array), show all lines
+5. Let the user accept defaults or provide values
+
+### Step 3: Ask module questions (if module was requested)
+
+The check response includes `target_module` with the module's questions. Variables may reference core answers in their defaults (e.g., `{output_folder}`).
+
+1. Resolve defaults by running `rihal_init.py` with the `resolve-defaults` subcommand, passing `--module {module_code}`, `--core-answers '{core_answers_json}'`, and `--project-root`
+2. Show the module's `header` and `subheader`
+3. For each variable, present the prompt with resolved default
+4. For `single-select` variables, show options as a numbered list
+
+### Step 4: Write config
+
+Collect all answers and run `rihal_init.py` with the `write` subcommand, passing `--answers '{all_answers_json}'` and `--project-root`.
+
+The `--answers` JSON format:
+
+```json
+{
+  "core": {
+    "user_name": "Rihal",
+    "communication_language": "English",
+    "document_output_language": "English",
+    "output_folder": "_rihal-output"
+  },
+  "bmb": {
+    "rihal_builder_output_folder": "_rihal-output/skills",
+    "rihal_builder_reports": "_rihal-output/reports"
+  }
+}
+```
+
+Note: Pass the **raw user answers** (before result template expansion). The script applies result templates and `{project-root}` expansion when writing.
+
+The script:
+- Creates `_rihal/core/config.yaml` with core values (if core answers provided)
+- Creates `_rihal/{module}/config.yaml` with core values + module values (result-expanded)
+- Creates any directories listed in the module.yaml `directories` array
+
+### Step 5: Return vars
+
+After writing, re-run `rihal_init.py` with the `load` subcommand (same as the fast path) to return resolved vars. Store returned vars as `{var-name}` and return them to the calling skill.
+
+## Output Format
+
+JSON config vars returned to the calling skill. When init path runs, interactive Q&A with the user, then config files written to `_rihal/`.
+
+## Examples
+
+### Happy path (fast path)
+**Calling skill:** invokes rihal-init with `--module bmb`
+**Result:** Config exists → returns `{"output_folder": "_rihal-output", ...}` instantly
+
+### Edge case (init path)
+**Calling skill:** invokes rihal-init, no config exists
+**Result:** Asks core questions → asks module questions → writes config → returns vars
+
+### Negative boundary
+**User:** "initialize my project"
+**Result:** rihal-init is internal — user should use `rihal-scaffold-project` or `/rihal:install` instead

package/rihal/skills/core/rihal-init/resources/core-module.yaml

@@ -0,0 +1,25 @@
+code: core
+name: "Rihal Core Module"
+
+header: "Rihal Core Configuration"
+subheader: "Configure the core settings for your Rihal installation.\nThese settings will be used across all installed Rihal skills, workflows, and agents."
+
+user_name:
+  prompt: "What should agents call you? (Use your name or a team name)"
+  default: "Rihal"
+  result: "{value}"
+
+communication_language:
+  prompt: "What language should agents use when chatting with you?"
+  default: "English"
+  result: "{value}"
+
+document_output_language:
+  prompt: "Preferred document output language?"
+  default: "English"
+  result: "{value}"
+
+output_folder:
+  prompt: "Where should output files be saved?"
+  default: "_rihal-output"
+  result: "{project-root}/{value}"