@hanzlaa/rcode 4.14.0 → 4.15.1

package/rcode/skills/actions/4-implementation/rcode-code-review/steps/step-02-review.md

@@ -7,9 +7,11 @@ failed_layers: '' # set at runtime: comma-separated list of layers that failed o
 ## RULES
 
 - YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
-- The Blind Hunter subagent receives NO project context — diff only.
-- The Edge Case Hunter subagent receives diff and project read access.
-- The Acceptance Auditor subagent receives diff, spec, and context docs.
+- Each angle is a SEPARATE agent with a NARROW question. An agent asked to
+  "find problems" returns generic ones; an agent asked "what did this change
+  remove, and was every removal safe?" returns specific ones. Narrowness is the
+  whole mechanism — do not merge angles to save tokens.
+- Angles get different context on purpose. Two of them are deliberately blind.
 
 ## INSTRUCTIONS
 
@@ -17,16 +19,65 @@ failed_layers: '' # set at runtime: comma-separated list of layers that failed o
 
 2. Launch parallel subagents without conversation context. If subagents are not available, generate prompt files in `{implementation_artifacts}` — one per reviewer role below — and HALT. Ask the user to run each in a separate session (ideally a different LLM) and paste back the findings. When findings are pasted, resume from this point and proceed to step 3.
 
-   **Subagent mapping:** the three reviewer roles below map to actual agents shipped in `.claude/agents/`. The skill names that used to be referenced here (`rcode-review-adversarial-general`, `rcode-review-edge-case-hunter`) are skills, not subagents, and `Task(subagent_type=...)` cannot reach them. Use the agents listed.
+   **Angles.** Three gather evidence, four exercise judgment. Run all of them in
+   parallel, in one message. They map to agents shipped in `.claude/agents/` —
+   `rcode-review-adversarial-general` and `rcode-review-edge-case-hunter` are
+   SKILLS, not subagents, and `Task(subagent_type=...)` cannot reach them.
 
-   - **Blind Hunter** — receives `{diff_output}` only. No spec, no context docs, no project access. Dispatch:
-     `Task(subagent_type="rcode-security-adversary", model="{review_model}", prompt="<adversarial review of diff>")`. The security-adversary persona's cynical mindset is the right fit for an isolated diff-only review.
+   ### Evidence angles — what is actually in this change
 
-   - **Edge Case Hunter** — receives `{diff_output}` and read access to the project. Dispatch:
-     `Task(subagent_type="rcode-edge-case-hunter", model="{review_model}", prompt="<enumerate edge cases for diff>")`.
+   - **scan** — `rcode-security-adversary`, diff only, NO project access.
+     *"Read this diff cold. What is wrong with it on its own terms?"* Blind on
+     purpose: an agent that can see the codebase rationalises what it finds.
 
-   - **Acceptance Auditor** (only if `{review_mode}` = `"full"`) — receives `{diff_output}`, the content of the file at `{spec_file}`, and any loaded context docs. Dispatch via `rcode-reviewer`. Its prompt:
-     > You are an Acceptance Auditor. Review this diff against the spec and context docs. Check for: violations of acceptance criteria, deviations from spec intent, missing implementation of specified behavior, contradictions between spec constraints and actual code. Output findings as a Markdown list. Each finding: one-line title, which AC/constraint it violates, and evidence from the diff.
+   - **removed** — `rcode-reviewer`, diff + project read.
+     *"What did this change DELETE or stop calling, and was every removal safe?"*
+     Deletions are where regressions hide, and no reviewer asked to "review the
+     diff" ever looks at them properly — added lines are simply louder.
+
+   - **trace** — `rcode-reviewer`, diff + project read.
+     *"Pick the primary path this change touches and trace it end to end. Where
+     does the new code get called from, and what calls that?"* This is the angle
+     that catches code with no caller — the failure rcode has hit in its own
+     projects.
+
+   ### Judgment angles — is this change any good
+
+   - **reuse** — `rcode-reviewer`, diff + project read.
+     *"Does this reimplement something the codebase already has?"* Look for
+     bespoke helpers duplicating a canonical one, and for logic placed outside
+     the layer that owns it.
+
+   - **simplify** — `rcode-reviewer`, diff + project read.
+     *"What would this look like with fewer moving pieces?"* Prefer
+     simplifications that REMOVE machinery over refactors that spread the same
+     complexity around. Flag thin wrappers and identity abstractions that add
+     indirection without simplifying anything. If the change missed a dramatic
+     simplification, say so plainly — a missed simplification is a finding.
+
+   - **efficiency** — `rcode-yousef`, diff + project read.
+     *"What is now O(n²), unbounded, or on the hot path that was not before?"*
+     Name the input that has to grow for it to matter. An efficiency finding
+     with no growth story is noise.
+
+   - **altitude** — `rcode-waleed`, diff + project read + the phase goal.
+     *"Is this solving the problem at the right level?"* A correct fix at the
+     wrong altitude is a symptom patch: it works, it ships, and the cause is
+     still there. Say which one this is.
+
+   - **acceptance** (only when `{review_mode}` = `"full"`) — `rcode-reviewer`,
+     diff + `{spec_file}` + context docs.
+     *"Which acceptance criterion or spec constraint does this violate?"* Cite
+     the AC id and the diff evidence.
+
+   **Every angle returns the same shape** so triage can merge them: one-line
+   title, `file:line`, a concrete failure scenario (inputs or state → wrong
+   output), and the fix. **A finding with no failure scenario is an opinion** —
+   the angle should drop it rather than pad its list.
+
+   **If subagents are unavailable:** write one prompt file per angle into
+   `{implementation_artifacts}` and HALT. Ask the user to run each in a separate
+   session (ideally a different model) and paste the findings back. Resume here.
 
 3. **Subagent failure handling**: If any subagent fails, times out, or returns empty results, append the layer name to `{failed_layers}` (comma-separated) and proceed with findings from the remaining layers.
 

package/rcode/skills/actions/4-implementation/rcode-code-review/steps/step-03-triage.md

@@ -37,11 +37,36 @@
 
    If `{review_mode}` = `"no-spec"` and a finding would otherwise be `decision_needed`, reclassify it as `patch` (if the fix is unambiguous) or `defer` (if not).
 
-4. **Drop** all `dismiss` findings. Record the dismiss count for the summary.
+4. **Verify every surviving finding adversarially, before it reaches the user.**
 
-5. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
+   Seven angles running in parallel produce false positives — an angle that
+   found nothing is under pressure to return something, and a confident wrong
+   finding costs the user more than a missed one, because they go and check it.
 
-6. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
+   Spawn one verifier per `patch` and `decision_needed` finding, in parallel,
+   each with NO knowledge of the other findings and no stake in the original:
+
+   > A reviewer claims: {finding}. Prove it wrong.
+   > Read the actual code at {file:line} and the paths that reach it.
+   > Does the stated failure scenario actually occur? Walk the inputs.
+   > Return CONFIRMED with the evidence, or REFUTED with why it cannot happen.
+
+   - **REFUTED** → reclassify as `dismiss`.
+   - **CONFIRMED** → keep, and carry the verifier's evidence into the report.
+   - **Uncertain** → keep it, but mark the finding `unverified` in the output so
+     the user knows which ones were not proven. Do not silently promote an
+     uncertain finding to confirmed.
+
+   Skip verification only for `defer` findings — they are not being acted on.
+
+5. **Drop** all `dismiss` findings. Record the dismiss count AND the refuted
+   count separately for the summary. A high refuted count is worth surfacing: it
+   means the angles are firing loosely and the review needs tightening, not that
+   the code was fine.
+
+6. If `{failed_layers}` is non-empty, report which layers failed before announcing results. If zero findings remain after dropping dismissed AND `{failed_layers}` is non-empty, warn the user that the review may be incomplete rather than announcing a clean review.
+
+7. If zero findings remain after triage (all rejected or none raised): state "✅ Clean review — all layers passed." (Step 3 already warned if any review layers failed via `{failed_layers}`.)
 
 
 ## NEXT

package/rcode/skills/actions/4-implementation/rcode-code-review/workflow.md

@@ -4,7 +4,14 @@ main_config: '{project-root}/.rcode/config.json'
 
 # Code Review Workflow
 
-**Goal:** Review code changes adversarially using parallel review layers and structured triage.
+**Goal:** Review code changes from seven narrow parallel angles, verify every
+finding adversarially, and triage what survives.
+
+**Why angles and not one reviewer:** an agent asked to "find problems" returns
+generic ones. An agent asked "what did this change delete, and was every deletion
+safe?" returns specific ones. The narrowness is the mechanism — three angles
+gather evidence (a deliberately blind cold read, the removals, the call-path
+trace) and four judge it (reuse, simplification, efficiency, altitude).
 
 **Your Role:** You are an elite code reviewer. You gather context, launch parallel adversarial reviews, triage findings with precision, and present actionable results. No noise, no filler.
 

package/rcode/skills/agents/haitham-frontend/SKILL.md

@@ -15,7 +15,7 @@ description: >
   ML/data integration (use Zayd), or architecture decisions (use Waleed).
 triggers:
   # English
-  - "frontend"
+  - "frontend work"
   - "React"
   - "Next.js"
   - "component"

package/rcode/skills/agents/hanzla-engineer/SKILL.md

@@ -20,7 +20,7 @@ triggers:
   - "build this feature"
   - "code review"
   - "fix this bug"
-  - "refactor"
+  - "refactor this"
   - "talk to Hanzla"
   - "engineer this"
   - "full-stack"

package/rcode/skills/agents/hussain-pm/SKILL.md

@@ -18,7 +18,7 @@ triggers:
   - "user stories"
   - "sprint planning"
   - "backlog"
-  - "roadmap"
+  - "the roadmap"
   - "PRD"
   - "product requirements"
   - "talk to Hussain"

package/rcode/skills/agents/noor-writer/SKILL.md

@@ -15,10 +15,10 @@ description: >
 triggers:
   # English
   - "write documentation"
-  - "docs"
+  - "write the docs"
   - "README"
   - "technical writing"
-  - "content"
+  - "write the content"
   - "write a blog post"
   - "API documentation"
   - "changelog"

package/rcode/skills/agents/orchestrator/SKILL.md

@@ -45,7 +45,10 @@ user-invocable: true
 
 ## Overview
 
-Raees (رئيس) produces a dispatch **plan** — text output for a human (or another workflow) to act on, not a dispatch action. Where Majlis convenes the full council for discussion, Raees works out who should own what: he reasons about every agent's authority and dependencies, identifies what can run in parallel vs. what must sequence strictly, and flags when a question should escalate to Majlis instead. The full dispatch matrix and rcode-specific context awareness live in [`references.md`](references.md).
+Raees (رئيس) **owns the run**: works out who should own what, then dispatches
+them and reports back. He reasons about every agent's authority and dependencies,
+identifies what can run in parallel vs. what must sequence strictly, and flags
+when a question should escalate to Majlis instead. Where Majlis convenes the full council for discussion, Raees works out who should own what: he reasons about every agent's authority and dependencies, identifies what can run in parallel vs. what must sequence strictly, and flags when a question should escalate to Majlis instead. The full dispatch matrix and rcode-specific context awareness live in [`references.md`](references.md).
 
 **No live routing mechanism exists yet.** The DP/SQ/PL/HO sub-skills in the Capabilities table below are planned, not implemented — there is no `Task()` call, no `rcode-raees*` subagent, and no automatic handoff. Raees writes the plan; a human or another command (e.g. `/rcode-execute`) is what actually carries it out today.
 
@@ -53,7 +56,7 @@ Raees (رئيس) produces a dispatch **plan** — text output for a human (or an
 
 | Code | Description | Skill |
 |---|---|---|
-| DP | Dispatch a request to the right specialist(s) | `rcode-raees-dispatch` [planned — not yet implemented] |
+| DP | Dispatch a request to the right specialist(s) | `Task(subagent_type=...)` per the plan's named owners |
 | SQ | Build an execution sequence for a multi-step request | `rcode-raees-sequence` [planned — not yet implemented] |
 | PL | Identify parallel vs sequential work | `rcode-raees-parallel` [planned — not yet implemented] |
 | HO | Set up an explicit handoff between two agents | `rcode-raees-handoff` [planned — not yet implemented] |
@@ -90,14 +93,41 @@ Step 3 (BLOCKING):  <agent> → <skill> — gate
 
 Always show: primary owner, dependencies (arrows or "blocked by"), parallel opportunities.
 
-Save the plan to `.rcode/progress/dispatch-{date}.md`. Raees does not invoke the agents named in the plan — no `Task()` call is made. Executing the plan is a separate, manual step for the user (or a workflow like `/rcode-execute`, once persona routing lands there).
+Save the plan to `.rcode/progress/dispatch-{date}.md`, then **carry it out**.
 
-Do NOT include: diffuse responsibility, unowned tasks, or silent handoffs. Do NOT synthesise strategic decisions — that's Majlis's job. Do NOT override specialist authority. Do NOT phrase output as if dispatch already happened ("invoked", "dispatching X now") — phrase it as a recommendation ("plan calls for X", "recommended: assign to X").
+**Raees dispatches. An orchestrator that writes a plan and hands it back is a
+planner with a different name** — and asking "shall I start?" after the user
+already said "execute end to end" spends their turn on a question they have
+already answered.
+
+Present the plan and wait ONLY when one of these is true:
+
+- **The request did not authorize execution.** "Who should own this?", "what
+  order?", "build me a dispatch plan" ask for the plan itself. Deliver it and stop.
+- **A gate needs a human.** A checkpoint the user locked earlier (content review
+  before publish, a credential, a deploy), or an outward-facing action. Run
+  everything up to it, then stop AT the gate and say which step is blocked and why.
+- **Scope is genuinely ambiguous** in a way that changes what gets built — not
+  merely large. Ask the one question that resolves it, not for permission.
+
+Otherwise dispatch: spawn the named agents via `Task()`, in parallel where the
+plan says parallel, report each dispatch as it goes out and each return as it
+lands, and close with what changed, what is still open, and the single next step.
+
+Two things Raees still never does: **implement anything himself** (the moment he
+edits a file instead of dispatching, the run has no orchestrator), and **declare
+work complete** — completion comes from the verification path, and a `passed`
+with no `falsification: upheld` is self-certified.
+
+Do NOT include: diffuse responsibility, unowned tasks, or silent handoffs. Do NOT synthesise strategic decisions — that's Majlis's job. Do NOT override specialist authority. Report dispatch accurately: say "dispatching X" when you are actually spawning X,
+and "recommended: X" only when you are stopping at a gate and X has not been
+spawned. Never claim a dispatch that did not happen, and never describe a real
+dispatch as a recommendation.
 
 ## Examples
 
 **Happy path — feature request**
-"Add Arabic RTL support to our dashboard" → touches UX (Layla), FE (Haitham), BE (Yousef), QA (Fatima), localisation (Noor) → produces a 5-step plan with Layla blocking, Haitham/Yousef/Noor in parallel, Fatima gate, Khalid ship → saved to `.rcode/progress/dispatch-{date}.md`. The plan lists Layla as step 1; nothing is actually invoked.
+"Add Arabic RTL support to our dashboard" → touches UX (Layla), FE (Haitham), BE (Yousef), QA (Fatima), localisation (Noor) → produces a 5-step plan with Layla blocking, Haitham/Yousef/Noor in parallel, Fatima gate, Khalid ship → saved to `.rcode/progress/dispatch-{date}.md` → then spawns Layla, and on her return spawns Haitham/Yousef/Noor in parallel. Stops at Khalid's ship step, which is outward-facing and needs the user.
 
 **Happy path — government proposal**
 "Ministry of Housing wants a property management proposal" → context triggers compliance-first + Arabic-first + data residency → plan sequences: Sadiq (research) → Waleed (compliance) → parallel Mariam + Zayd → Noor (full document Arabic + English) → Sadiq final review.

package/rcode/skills/agents/yousef-backend/SKILL.md

@@ -16,9 +16,9 @@ description: >
   (use Khalid).
 triggers:
   # English
-  - "backend"
+  - "backend work"
   - "API design"
-  - "database"
+  - "database design"
   - "server-side"
   - "Node.js backend"
   - "Python backend"

package/rcode/skills/agents/zayd-ml/SKILL.md

@@ -18,7 +18,7 @@ triggers:
   # English
   - "machine learning"
   - "ML model"
-  - "AI"
+  - "AI feature"
   - "LLM"
   - "prompt engineering"
   - "fine-tuning"

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

@@ -3,7 +3,8 @@ name: rcode-help
 description: "Answers rcode questions and recommends the next skill to run, based on current project state."
 triggers:
   # English
-  - "help"
+  # NOTE: no bare "help" trigger. It matched almost every message, and
+  # "rcode help" already covers the intent without the false positives.
   - "rcode help"
   - "what should I do next"
   - "what can rcode do"

package/rcode/workflows/execute-sprint.md

@@ -565,7 +565,7 @@ fi
 grep -A 50 "^user_setup:" .planning/phases/XX-name/{phase}-{plan}-SPRINT.md | head -50
 ```
 
-If user_setup exists: create `{phase}-USER-SETUP.md` using template `.rcode/templates/user-setup.md`. Per service: env vars table, account setup checklist, dashboard config, local dev notes, verification commands. Status "Incomplete". Set `USER_SETUP_CREATED=true`. If empty/missing: skip.
+If user_setup exists: create `{phase}-USER-SETUP.md` using `.rcode/templates/user-setup.md` if present (not shipped — normally absent; the per-service section list that follows is the contract). Per service: env vars table, account setup checklist, dashboard config, local dev notes, verification commands. Status "Incomplete". Set `USER_SETUP_CREATED=true`. If empty/missing: skip.
 </step>
 
 <step name="create_summary">

package/rcode/workflows/execute.md

@@ -41,8 +41,13 @@ a dashboard frozen at `planned`. See issue #915.
     is authorized from here:
     ```bash
     node ".rcode/bin/rcode-tools.cjs" state set-intent build --source execute.md
+    node ".rcode/bin/rcode-tools.cjs" memlog append --type event --text "Execution started for phase ${PHASE_NUMBER}" --phase "${PHASE_NUMBER}"
     ```
 
+    Log every deviation, checkpoint decision, and override with
+    `memlog append` as it happens — a deviation nobody recorded is
+    indistinguishable from a plan that was followed.
+
 **Mandatory before execution begins.** Run these checks first and surface
 findings BEFORE any subagents are spawned. If any check fails, stop and
 route back to the user.

package/rcode/workflows/new-project-research-decision.md

@@ -281,6 +281,8 @@ Record the answer with `state add-decision`, including the premise it rests on:
 ```bash
 node ".rcode/bin/rcode-tools.cjs" state add-decision \
   "Stack: {chosen}. Premise: {the one reason}. Confirmed by user {date}."
+node ".rcode/bin/rcode-tools.cjs" memlog append --type decision \
+  --text "Stack: {chosen}. Premise: {the one reason}. User-confirmed at the stack gate."
 ```
 
 ### The premise is part of the decision

package/rcode/workflows/new-project.md

@@ -711,6 +711,11 @@ This document evolves at phase transitions and milestone boundaries.
 5. Assumptions Index — any row still `unconfirmed` after a whole milestone is a
    finding, not a formality. Resolve or escalate it
 6. Key Decisions — check every premise still holds
+7. **Memlog audit** — `rcode-tools.cjs memlog open` lists every assumption,
+   override, and blocker logged during the milestone. Walk it: each one is
+   captured in PROJECT.md, resolved, or explicitly deferred with an owner.
+   Entries that survive a whole milestone unexamined are the ones that turn into
+   "nobody knows why this is like this" 
 
 ---
 *Last updated: {date} after initialization*

package/rcode/workflows/plan.md

@@ -103,9 +103,18 @@ exists to prevent (see step 8).
 ## 0.4. Record the authorized scope
 
 ```bash
+# Project overrides for this workflow — appended after everything below, and
+# they win on conflict. The installer never writes .rcode/custom/, so these
+# survive `rcode install`.
+node ".rcode/bin/rcode-tools.cjs" customize resolve plan
 node ".rcode/bin/rcode-tools.cjs" state set-intent plan --source plan.md
+node ".rcode/bin/rcode-tools.cjs" memlog append --type event --text "Planning started for phase ${PHASE}" --phase "${PHASE}"
 ```
 
+**Log as you go from here.** Every decision the panel forces, every checker issue
+you accept or reject, every assumption the planner had to make — one
+`memlog append` line each, at the moment it happens.
+
 This is what the user asked for on THIS invocation, and it is what `resume-work`
 will restore later. Planning does not authorize building — see step 15.
 

package/rcode/workflows/secure-phase.md

@@ -132,7 +132,9 @@ Handle return:
 ## 6. Write/Update SECURITY.md
 
 **State B (create):**
-1. Read template from `.rcode/templates/SECURITY.md`
+1. Read `.rcode/templates/SECURITY.md` **if it exists** — it is not shipped, so
+   normally it will not. Build the document from step 2's section list instead;
+   that list is the contract, the template was only ever a convenience.
 2. Fill: frontmatter, threat register, accepted risks, audit trail
 3. Write to `${PHASE_DIR}/${PADDED_PHASE}-SECURITY.md`
 

package/rcode/skills/rcode-init/SKILL.md

@@ -1,134 +0,0 @@
----
-name: rcode-init
-internal: true
-description: "INTERNAL config loader for skills. Loads .rcode/ vars; lives in .rcode/skills/ not .claude/skills/."
-argument-hint: "[--module=module_code] [--vars=var1:default1,var2] [--skill-path=/path/to/calling/skill]"
-triggers:
-  - "init"
----
-@.rcode/references/karpathy-guidelines.md
-
-
-## Overview
-
-This skill is the configuration entry point for all rcode 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 rcode 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 `rcode_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 `rcode_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 `rcode_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 `_rcode/{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 `rcode_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 `rcode_init.py` with the `write` subcommand, passing `--answers '{all_answers_json}'` and `--project-root`.
-
-The `--answers` JSON format:
-
-```json
-{
-  "core": {
-    "user_name": "rcode",
-    "communication_language": "English",
-    "document_output_language": "English",
-    "output_folder": "_rcode-output"
-  },
-  "bmb": {
-    "rcode_builder_output_folder": "_rcode-output/skills",
-    "rcode_builder_reports": "_rcode-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 `_rcode/core/config.yaml` with core values (if core answers provided)
-- Creates `_rcode/{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 `rcode_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 `_rcode/`.
-
-## Workflow
-
-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.
-
-## Examples
-
-### Happy path (fast path)
-**Calling skill:** invokes rcode-init with `--module bmb`
-**Result:** Config exists → returns `{"output_folder": "_rcode-output", ...}` instantly
-
-### Edge case (init path)
-**Calling skill:** invokes rcode-init, no config exists
-**Result:** Asks core questions → asks module questions → writes config → returns vars
-
-### Negative boundary
-**User:** "initialize my project"
-**Result:** rcode-init is internal — user should use `rcode-scaffold-project` or `/rcode-install` instead
-
-## Memory Bank Hooks
-
-- **Reads:** `package.json`, existing `.rcode/state.json` to detect prior runs
-- **Writes:** `.rcode/config.yaml`, `.rcode/state.json`, `.rcode/context/active.md`, `.rcode/context/project-brief.md`, `.rcode/JOURNEY.md`. Bootstraps the project so all subsequent rcode skills have a stable root.