@hanzlaa/rcode 2.1.0

package/rihal/workflows/discuss.md

@@ -0,0 +1,227 @@
+# Workflow: rihal:discuss
+
+<purpose>
+Orchestrate a single-agent quick sync session. This is the lightweight alternative to council — one agent, one round, conversational tone, no mandatory artifact. Feels like texting one colleague, not calling a board meeting.
+</purpose>
+
+<output_format>
+Lightweight — no full banner. Open with one-line header:
+```
+◆ Spawning {agent-id}...
+```
+Agent response opens with header: `🧭 **Sadiq (صادق) — Director of Strategy:**`.
+No closure banner (discuss is lightweight). End with optional Next Up if the user should escalate: `Want to convene full council? /rihal:council <question>`.
+</output_format>
+
+<required_reading>
+@.rihal/references/output-format.md
+</required_reading>
+
+<process>
+## Step 0 — Usage check
+
+If `$ARGUMENTS` is empty or contains only `--help` or `-h`:
+- Print the usage block below
+- STOP — do not proceed to Step 1, do not read any reference files
+
+**Usage:**
+```
+/rihal:discuss [agent-name] <question>
+```
+
+**Examples:**
+```
+/rihal:discuss sadiq should I pivot this idea?
+/rihal:discuss waleed what stack should I use for a multi-tenant SaaS?
+/rihal:discuss what's the kill criterion for this project?
+/rihal:discuss fatima is this release ready to ship?
+```
+
+Only after the user provides arguments, proceed to Step 0.5.
+
+## Step 0.5 — Detect strategic decisions (redirect to council)
+
+Run two checks in parallel — classifier AND panel scorer top-1. Either signal triggers the redirect.
+
+```bash
+TYPE=$(node .rihal/bin/rihal-tools.cjs classify-question "$ARGUMENTS" 2>/dev/null | grep -o '"type": *"[^"]*"' | cut -d'"' -f4)
+TOP_AGENT=$(node .rihal/bin/rihal-tools.cjs select-panel "$ARGUMENTS" --top 1 2>/dev/null | grep -o '"panel": *\["[^"]*"' | cut -d'"' -f4)
+```
+
+**Redirect to council if EITHER condition holds:**
+
+1. `question_type` is `market`, `discovery`, or `greenfield`
+2. Top-scoring agent is `mariam` or `hussain-pm` (these signal market/scope intent — better answered by a council)
+
+The classifier can mistype overloaded words like "launch", but the panel scorer uses richer keyword tables (Mariam owns dubai/uae/affiliate/launch/business). Combining both signals catches more cases.
+
+If either condition holds:
+
+```
+⚠ Strategic / market decisions benefit from multiple perspectives.
+
+/rihal:discuss is single-agent. For "should we" questions across domains, use:
+
+/rihal:council $ARGUMENTS
+```
+
+Only proceed past this step if both checks pass — question is tactical or single-domain (codebase, team, release, design) AND top agent is sadiq/waleed/fatima.
+
+After Step 0.5 confirmation, proceed to load references by Reading:
+- `.rihal/references/council-protocol.md` (agent conventions and response format)
+
+<available_agent_types>
+Use these exact `subagent_type` values when calling the Agent tool:
+
+- `rihal-sadiq` — 🧭 Sadiq (Strategy)
+- `rihal-waleed` — 🏗️ Waleed (CTO)
+- `rihal-fatima` — 🛡️ Fatima (QA)
+- `rihal-mariam` — 📣 Mariam (Marketing)
+- `rihal-hussain-pm` — 📋 Hussain-PM (Product)
+</available_agent_types>
+
+## Step 1 — Initialize
+
+Call the helper binary to parse arguments and resolve the agent:
+
+```bash
+INIT_JSON=$(node .rihal/bin/rihal-tools.cjs init discuss "$ARGUMENTS")
+```
+
+Parse the JSON for:
+
+- `agent_id` — resolved agent id (may be `null` if first token wasn't a known agent)
+- `question` — the cleaned question text (with agent name stripped if it was the first token)
+- `config` — `{ user_name, project_name, language, mode }` from `.rihal/config.yaml`
+- `paths` — `{ state, planning_root, sessions_dir, ... }`
+- `question_type` — classification result
+- `installed_agents` — list of installed agent ids
+
+## Step 2 — Resolve agent
+
+**If `agent_id` is not null:** use it directly. The init command already identified the first token as a known agent.
+
+**If `agent_id` is null:** auto-route to the best agent by calling:
+
+```bash
+node .rihal/bin/rihal-tools.cjs select-panel "$QUESTION" --top 1
+```
+
+Use the first (and only) agent in the returned `panel` array.
+
+Print: `💬 Discussing with {agent display name}...`
+
+Display name mapping:
+- `sadiq` → `🧭 Sadiq (Strategy)`
+- `waleed` → `🏗️ Waleed (CTO)`
+- `fatima` → `🛡️ Fatima (QA)`
+- `mariam` → `📣 Mariam (Marketing)`
+- `hussain-pm` → `📋 Hussain-PM (Product)`
+
+## Step 3 — Optional codebase scan
+
+**Only run this if `question_type` is `codebase`, `team`, or `release`.**
+
+```bash
+test -f .rihal/config.yaml && cat .rihal/config.yaml
+test -f README.md && head -30 README.md
+git log --oneline -5 2>/dev/null
+```
+
+Produce a 3-5 line "Context" summary from the output.
+
+**Skip this step entirely** for `market`, `discovery`, `greenfield`, and `design` question types — they don't need codebase context for a quick discuss.
+
+## Step 4 — Spawn single agent
+
+Spawn the resolved agent via the Agent tool with this prompt:
+
+```
+You are being spawned for a quick Rihal discuss session.
+
+## The user's question
+{question}
+
+## Context
+{the summary from Step 2, or "No codebase context needed for this question type." if skipped}
+
+## Session metadata
+- Project: {config.project_name}
+- User: {config.user_name}
+- Communication language: {config.language}
+
+## Instructions
+This is a quick discuss session — one round, conversational tone. Be direct and concise.
+Scale your response to the substance — a simple question gets a short answer.
+Start your reply with your icon + name header.
+```
+
+Use `subagent_type` = `rihal-{agent_id}` (e.g., `rihal-sadiq`).
+
+## Step 5 — Print response verbatim
+
+Print the agent's response exactly as returned. No orchestrator note, no round labeling, no summarization. This is a conversation, not a formal session.
+
+## Success Criteria
+
+- [ ] Single agent selected and spawned (Sadiq, Waleed, Fatima, Mariam, or Hussain-PM)
+- [ ] Agent response printed verbatim to user
+- [ ] If guided mode and user saves: artifact written to `.planning/council-sessions/discuss-{date}-{slug}.md`
+- [ ] Session recorded in `state.json` via rihal-tools.cjs
+
+## Step 6 — Offer to save (guided mode only)
+
+**If `config.mode === 'guided'`:** ask the user via AskUserQuestion:
+
+```
+Save this discussion? [y/N]
+```
+
+**If yes:** write a minimal artifact to `{paths.sessions_dir}/discuss-{YYYY-MM-DD}-{slug}.md`:
+
+```markdown
+# Discuss — {short question summary}
+
+**Date:** {ISO date}
+**Agent:** {agent display name}
+**Project:** {config.project_name}
+
+## Question
+{original question}
+
+## Response
+{verbatim agent response}
+```
+
+Create `{paths.sessions_dir}` with `mkdir -p` if needed. The `{slug}` is a lowercase-hyphenated slug of the first 6 words of the question.
+
+Print: `💾 Discussion saved: .planning/council-sessions/discuss-{date}-{slug}.md`
+
+Append footer:
+```
+─── ~10K tokens · {duration}s · 1 agent ───
+```
+
+(Use estimation from `.rihal/references/response-style.md#session-cost-footer`)
+
+**If no, or `config.mode === 'yolo'`:** skip saving entirely.
+
+## Step 7 — Update state
+
+```bash
+node .rihal/bin/rihal-tools.cjs state record-session
+```
+
+This records the discuss session in `.rihal/state.json` as `last_session`.
+
+## On Error
+
+- **Empty arguments:** print usage block and stop (Step 0).
+- **Question redirects to council:** print redirect message (Step 0.5).
+- **state.json missing or corrupted:** continue without error — session artifact is mandatory, state tracking is optional.
+- **`rihal-tools.cjs` not found:** tell the user to run `rihal-code install-v2`.
+- **No installed agents:** print "No agents installed. Run `rihal-code install-v2`."
+- **Agent id not in installed list:** print available agents and ask the user to pick one.
+- **Agent returns empty response:** print "Agent responded empty. Check question clarity and retry."
+
+</process>

package/rihal/workflows/do.md

@@ -0,0 +1,175 @@
+<purpose>
+Analyze freeform text from the user and route to the most appropriate Rihal command. This is a dispatcher — it never does the work itself. Match user intent to the best command, confirm the routing, and hand off.
+</purpose>
+
+<required_reading>
+@.rihal/references/output-format.md
+Read all files referenced by the invoking prompt's execution_context before starting.
+</required_reading>
+
+<process>
+
+<step name="parse_args">
+Extract `$ARGUMENTS` and detect `--auto` flag (suppresses confirmation, dispatches immediately):
+
+```bash
+AUTO_MODE=false
+QUESTION="$ARGUMENTS"
+if [[ "$ARGUMENTS" == *"--auto"* ]]; then
+  AUTO_MODE=true
+  QUESTION=$(echo "$ARGUMENTS" | sed 's/--auto[[:space:]]*//' | xargs)
+fi
+```
+</step>
+
+<step name="validate">
+**Check for input.**
+
+If `$QUESTION` is empty, present the main menu via AskUserQuestion:
+
+```
+What would you like to do?
+
+1. Quick chat with one expert (/rihal:discuss)
+2. Convene the council (/rihal:council)
+3. Discuss an unlocked phase (/rihal:discuss-phase)
+4. Plan a phase (/rihal:plan)
+5. Execute a phase (/rihal:execute)
+6. Sprint planning (/rihal:sprint-planning)
+7. Execute a sprint (/rihal:execute-sprint)
+8. Check sprint status (/rihal:sprint-status)
+9. Break milestone into epics & stories (/rihal:create-epics-and-stories)
+10. Implement a story (/rihal:dev-story)
+11. Check progress (/rihal:progress)
+12. Auto-advance to next step (/rihal:next)
+13. Debug an issue (/rihal:debug)
+14. Resume paused work (/rihal:resume-work)
+15. Add a note (/rihal:note)
+16. Something else — describe it
+```
+
+If user picks 1-15, invoke that command. If 16, capture text and continue.
+</step>
+
+<step name="check_project">
+**Check if project exists.**
+
+```bash
+INIT=$(node ".rihal/bin/rihal-tools.cjs" state load 2>/dev/null)
+```
+
+Track whether `.planning/` exists — some routes require it, others don't.
+</step>
+
+<step name="route">
+**Match intent to command.**
+
+Evaluate `$QUESTION` against these routing rules. Apply the **first matching** rule:
+
+| If the text describes... | Route to | Why |
+|--------------------------|----------|-----|
+| Starting a new project, "set up", "initialize" | `/rihal:new-project` | Needs full project initialization |
+| Mapping or analyzing an existing codebase | `/rihal:map-codebase` | Codebase discovery |
+| A bug, error, crash, failure, or something broken | `/rihal:debug` | Needs systematic investigation |
+| Exploring, researching, comparing, or "how does X work" | `/rihal:research-phase` | Domain research before planning |
+| Scope unclear, conflicting UIs/options, "which one", "better UX", "still have confusion", "how should X look", brainstorming vision | `/rihal:discuss-phase` | Decisions not yet locked — gather before planning |
+| A complex task: refactoring, migration, multi-file architecture, system redesign | `/rihal:add-phase` | Needs a full phase with plan/build cycle |
+| Planning a specific phase, "plan phase N" | `/rihal:plan` | Direct phase-level planning |
+| "Sprint planning", "plan the sprint", "next sprint", "what's in this sprint" | `/rihal:sprint-planning` | Sprint-level scope/capacity planning |
+| Executing a sprint, "run the sprint", "start sprint", "work on sprint" | `/rihal:execute-sprint` | Sprint execution with wave batching |
+| Sprint status, "how is the sprint going", "sprint board", "sprint progress" | `/rihal:sprint-status` | Current sprint state |
+| "Create milestones", "plan milestones", "create roadmap", "what milestones do I need", "break project into milestones" | `/rihal:create-milestone` | Roadmap-level planning — designs M1..Mn from the PRD. Do NOT route to `create-epics-and-stories`; that skill decomposes a single milestone into epics |
+| Break milestone into epics/stories, "create stories", "user stories", "epics" | `/rihal:create-epics-and-stories` | Milestone → epic → story decomposition (assumes roadmap already exists) |
+| Create a single story, "add story", "write a story for X" | `/rihal:create-story` | Single story addition |
+| Implement a story, "work on story", "dev story", "build story" | `/rihal:dev-story` | Story-level implementation |
+| Find gaps in milestone plans, "gaps in plans", "missing plan", "unplanned phases" | `/rihal:plan-milestone-gaps` | Identify and fill planning gaps |
+| Executing a phase, "build phase N", "run phase N", "implement phase" | `/rihal:execute` | Direct phase execution request |
+| Running all remaining phases automatically | `/rihal:autonomous` | Full autonomous execution |
+| A review or quality concern about existing work | `/rihal:verify-work` | Needs verification |
+| "Council", "discuss strategy", "should we" | `/rihal:council` | Multi-agent strategic discussion |
+| List plans across phases, "all plans", "show plans" | `/rihal:list-plans` | Cross-phase plan table |
+| Checking progress, status, "where am I", "board" | `/rihal:progress` | Status check |
+| Resuming work, "pick up where I left off" | `/rihal:resume-work` | Session restoration |
+| A note, idea, or "remember to..." | `/rihal:note` | Capture for later |
+| Adding tests, "write tests", "test coverage" | `/rihal:add-tests` | Test generation |
+| Completing a milestone, shipping, releasing | `/rihal:complete-milestone` | Milestone lifecycle |
+| A specific, actionable, small task (add feature, fix typo, update config) | `/rihal:quick` | Self-contained, single executor |
+| Market/discovery/greenfield question (from classify) | `/rihal:council` | Needs multi-perspective discovery |
+
+If no rule matches, fall back to the classifier:
+
+```bash
+CLASSIFY=$(node ".rihal/bin/rihal-tools.cjs" classify-question "$QUESTION")
+```
+
+Parse `type` from JSON — map codebase/team/release → `/rihal:discuss`; market/discovery/greenfield → `/rihal:council`. Default: `/rihal:discuss`.
+
+**Requires `.planning/` directory:** All routes except `/rihal:new-project`, `/rihal:map-codebase`, `/rihal:help`, `/rihal:discuss`, `/rihal:council`. If the project doesn't exist and the route requires it, suggest `/rihal:new-project` first.
+
+**Ambiguity handling:** If the text could reasonably match multiple routes, ask the user via AskUserQuestion with the top 2-3 options. Prefer `discuss-phase` over `plan`/`add-phase` when scope-uncertainty signals are present ("confusion", "not sure", "which one", "better way", "how should", ≥2 conflicting UIs/options mentioned).
+
+Example:
+
+```
+"Refactor the auth system" could be:
+1. /rihal:add-phase — Full planning cycle (recommended for multi-file refactors)
+2. /rihal:discuss-phase — Gather decisions first (recommended if scope is fuzzy)
+3. /rihal:quick — Quick execution (if scope is small and clear)
+
+Which approach fits better?
+```
+</step>
+
+<step name="display">
+**Show the routing decision.**
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+ RIHAL ► ROUTING
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Input: {first 80 chars of $QUESTION}
+Scope: {one-line scope summary}
+Routing to: {chosen command}
+Reason: {one-line why}
+```
+</step>
+
+<step name="dispatch">
+**Invoke the chosen command.**
+
+If `AUTO_MODE` is true OR routing is unambiguous, invoke immediately:
+
+```
+/rihal:{command} {arguments}
+```
+
+Otherwise show suggestion and ask via AskUserQuestion:
+
+```
+Based on your request, I'd use: /rihal:{command} {arguments}
+
+1. Yes, run it
+2. Pick a different route
+3. Cancel
+```
+
+If the chosen command expects a phase number and one wasn't provided in the text, extract it from context or ask via AskUserQuestion.
+
+After invoking the command, stop. The dispatched command handles everything from here.
+</step>
+
+</process>
+
+<success_criteria>
+- [ ] Input validated (not empty)
+- [ ] Intent matched to exactly one Rihal command
+- [ ] Ambiguity resolved via user question (if needed)
+- [ ] Scope-uncertainty signals steer to `/rihal:discuss-phase` over planning routes
+- [ ] Project existence checked for routes that require it
+- [ ] Routing decision displayed before dispatch
+- [ ] Command invoked with appropriate arguments
+- [ ] No work done directly — dispatcher only
+</success_criteria>
+</content>
+</invoke>

package/rihal/workflows/docs-update.md

@@ -0,0 +1,261 @@
+# Workflow: rihal:docs-update
+
+<purpose>
+Generate, update, and verify project documentation — both canonical doc types and existing hand-written docs. The orchestrator detects the project's doc structure, assembles a work manifest tracking every item, dispatches parallel doc-writer and doc-verifier agents across waves, reviews existing docs for accuracy, identifies documentation gaps, and fixes inaccuracies via a bounded fix loop. All state is persisted in a work manifest so no work item is lost between steps. Output: Complete, structure-aware documentation verified against the live codebase.
+</purpose>
+
+<available_agent_types>
+Valid Rihal subagent types (use exact names — do not fall back to 'general-purpose'):
+- rihal-tech-writer — Writes and updates project documentation files
+- rihal-docs-auditor — Verifies factual claims in docs against the live codebase
+</available_agent_types>
+
+## Step 0 — Usage check
+
+If `$ARGUMENTS` is empty or contains only `--help` or `-h`:
+- Print the usage block below
+- STOP — do not proceed
+
+**Usage:**
+```
+/rihal:docs-update [phase]
+```
+
+**Examples:**
+```
+/rihal:docs-update
+/rihal:docs-update 02
+```
+
+<process>
+
+## Step 1: Initialize context
+
+Initialize docs-update context by scanning the project:
+
+```bash
+# Create docs directory if needed
+test -d docs || mkdir -p docs
+
+# Read agent manifest to get model for doc writers
+AGENT_MANIFEST=".rihal/_config/agent-manifest.csv"
+if [[ -f "$AGENT_MANIFEST" ]]; then
+  DOC_WRITER_MODEL=$(grep -i "rihal-tech-writer" "$AGENT_MANIFEST" | cut -d',' -f3)
+else
+  DOC_WRITER_MODEL="claude-opus"  # fallback
+fi
+```
+
+Extract from project analysis:
+- `doc_writer_model` — model string from agent manifest (never hardcode a model name)
+- `commit_docs` — whether to commit generated files when done (read from `.planning/config.json` if exists)
+- `existing_docs` — find all existing Markdown files with `find docs -name "*.md" 2>/dev/null`
+- `project_type` — detect from: `package.json`, `src/pages/api` or `pages/api`, `bin/` or `cli/`, `LICENSE`, `vercel.json` or `netlify.toml`, `lerna.json` or `pnpm-workspace.yaml`, `test/` or `__tests__/`
+- `doc_tooling` — detect from: `docusaurus.config.js`, `vitepress.config.js`, `mkdocs.yml`, `storybook.js`
+- `project_root` — `$(pwd)`
+
+## Step 2: Classify project
+
+Map the `project_type` boolean signals from the init JSON to a primary type label and collect conditional doc signals.
+
+**Primary type classification (first match wins):**
+
+| Condition | primary_type |
+|-----------|-------------|
+| `is_monorepo` is true | `"monorepo"` |
+| `has_cli_bin` is true AND `has_api_routes` is false | `"cli-tool"` |
+| `has_api_routes` is true AND `is_open_source` is false | `"saas"` |
+| `is_open_source` is true AND `has_api_routes` is false | `"open-source-library"` |
+| (none of the above) | `"generic"` |
+
+**Conditional doc signals (check independently after primary classification):**
+
+After determining primary_type, check each signal independently. A CLI tool that is also open source with API routes still gets all three conditional docs.
+
+| Signal | Conditional Doc |
+|--------|----------------|
+| `has_api_routes` is true | Queue API.md |
+| `is_open_source` is true | Queue CONTRIBUTING.md |
+| `has_deploy_config` is true | Queue DEPLOYMENT.md |
+
+Present the classification result:
+```
+Project type: {primary_type}
+Conditional docs queued: {list or "none"}
+```
+
+## Step 3: Build doc queue
+
+Assemble the complete doc queue from always-on docs plus conditional docs from Step 2.
+
+**Always-on docs (queued for every project):**
+1. README
+2. ARCHITECTURE
+3. GETTING-STARTED
+4. DEVELOPMENT
+5. TESTING
+6. CONFIGURATION
+
+**Conditional docs (add only if signal matched):**
+- API (if `has_api_routes`)
+- CONTRIBUTING (if `is_open_source`)
+- DEPLOYMENT (if `has_deploy_config`)
+
+**IMPORTANT: CHANGELOG.md is NEVER queued.** The doc queue is built exclusively from the 9 known doc types listed above.
+
+**Doc queue limit:** Maximum 9 docs. Always-on (6) + up to 3 conditional = at most 9.
+
+**CONTRIBUTING.md confirmation (new file only):**
+
+If CONTRIBUTING.md is in the conditional queue AND does NOT exist in `existing_docs`:
+
+1. If `--force` is present in `$ARGUMENTS`: skip confirmation, include CONTRIBUTING.md.
+2. Otherwise, use AskUserQuestion:
+
+```
+AskUserQuestion([{
+  question: "This project appears to be open source. CONTRIBUTING.md does not exist yet. Create it?",
+  header: "Contributing",
+  multiSelect: false,
+  options: [
+    { label: "Yes, create it", description: "Generate CONTRIBUTING.md with project guidelines" },
+    { label: "No, skip it", description: "This project does not need a CONTRIBUTING.md" }
+  ]
+}])
+```
+
+If user selects "No": remove CONTRIBUTING.md from the queue.
+
+## Step 4: Present queue and confirm
+
+Present the assembled doc queue to the user with confirmation:
+
+```
+AskUserQuestion([{
+  question: "Doc queue assembled ({N} docs). Proceed with generation?",
+  header: "Doc queue",
+  multiSelect: false,
+  options: [
+    { label: "Proceed", description: "Generate all {N} docs in the queue" },
+    { label: "Abort", description: "Cancel doc generation" }
+  ]
+}])
+```
+
+If user selects "Abort": exit the workflow.
+
+## Step 5: Spawn doc writers in waves
+
+Create output directories:
+```bash
+mkdir -p docs
+```
+
+For each doc in the queue, spawn a `rihal-tech-writer` agent in parallel waves (up to 3 agents in parallel per wave):
+
+```
+Task(
+  subagent_type="rihal-tech-writer",
+  prompt="
+Generate documentation for {doc_type}.
+Output path: {resolved_path}
+Project type: {primary_type}
+Mode: {create|update}
+
+${EXISTING_CONTENT:+Existing content:\n${EXISTING_CONTENT}}
+
+Write the doc to: {resolved_path}
+Do NOT commit — the orchestrator will handle that.
+  "
+)
+```
+
+## Step 6: Verify generated docs
+
+After all doc writers complete, spawn `rihal-docs-auditor` agents to cross-check all generated content against the live codebase.
+
+For each generated doc:
+```
+Task(
+  subagent_type="rihal-docs-auditor",
+  prompt="
+Verify this documentation file against the live codebase:
+Path: {resolved_path}
+
+Check for:
+- Outdated/incorrect information
+- References to non-existent files/modules
+- Version mismatches
+- API changes not reflected in docs
+
+Report any inaccuracies found. Do NOT fix — just report.
+  "
+)
+```
+
+## Step 7: Persist work manifest and close
+
+Write all work items to `.planning/tmp/docs-work-manifest.json`:
+
+```bash
+mkdir -p .planning/tmp
+# Write manifest with all generated docs, verification results, and any fixes needed
+```
+
+If `commit_docs` is enabled:
+```bash
+# Stage generated docs and commit
+git add docs/*.md
+git commit -m "docs: regenerate and verify project documentation"
+```
+
+```
+## Docs Update Complete
+
+**Project type:** {primary_type}
+**Docs generated:** {count}
+**Docs verified:** {count}
+**Issues found:** {count or "none"}
+
+Generated docs:
+{list with line counts}
+
+${ISSUES:+
+Issues to fix:
+{list}
+
+Run /rihal:docs-update --fix to auto-correct found issues.
+}
+
+Next: Review docs in your editor or run verification again with /rihal:docs-update
+```
+
+</process>
+
+<success_criteria>
+- [ ] Project type correctly classified
+- [ ] Doc queue assembled with always-on + conditional docs
+- [ ] CONTRIBUTING.md confirmation shown when appropriate
+- [ ] User confirmed queue before generation
+- [ ] Doc writers spawned in parallel waves
+- [ ] All docs generated and written to correct paths
+- [ ] Doc verifiers run and report inaccuracies
+- [ ] Work manifest persisted
+- [ ] Docs committed if enabled
+- [ ] Results presented with next steps
+</success_criteria>
+
+## Success Criteria
+
+- [ ] Task completed as requested
+- [ ] Output saved or reported
+- [ ] State updated if necessary
+- [ ] No errors encountered
+
+## On Error
+
+If arguments are invalid, missing files, or subagent fails:
+- Validate inputs match expected format
+- Check that required files exist
+- Retry with clearer arguments or report the specific error to the user
+