@jstn-sdk/rcs 0.1.0 → 0.1.6

package/skills/blueprint/SKILL.md

@@ -1,22 +1,240 @@
 ---
 name: blueprint
-description: Canonical creator blueprinting surface for Roblox Creator Skills
+description: Canonical Roblox Studio consensus-planning workflow for creator architecture, scope, and implementation guidance
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Blueprint
 
-Use `$blueprint` to generate structured design and planning artifacts for the experience.
+Blueprint is the canonical creator planning workflow in RCS.
 
-For Roblox work, `$blueprint` must refine the pre-action artifact into an architecture-first plan:
-- verify the relevant Roblox concepts and services
-- normalize canonical terminology from creator-docs
-- finalize the modular file tree
-- explain ownership boundaries before implementation
+Use `$blueprint` to turn a creator brief into an execution-ready Roblox Studio plan with the right vocabulary, service boundaries, data flow, and verification path.
+Treat creator-docs as canonical when gameplay, UX, monetization, psychology, or Roblox-specific structure already exists in this repo.
 
-Never blueprint Roblox code from memory alone. Use the internal RCS knowledge layer first and treat creator-docs as canonical.
+Blueprint is the canonical creator-facing equivalent of consensus planning. It drives iterative planning with Planner, Architect, and Critic agents until the plan is explicit, testable, and ready for either `$forge` or `$team`.
 
-Follow with:
+## Usage
+
+```text
+$blueprint "task description"
+$blueprint --interactive "task description"
+```
+
+## Flags
+
+- `--interactive`: Enables user prompts at key decision points using the structured question UI.
+- `--deliberate`: Forces deliberate mode for high-risk work, including pre-mortem scenarios and expanded test planning.
+
+## Purpose
+
+Blueprint exists to stop planning drift before implementation:
+- convert vague feature ideas into Roblox-native architecture
+- name the real engine concepts and services involved
+- define server/client ownership before a single script changes
+- keep the repo from defaulting to generic enterprise abstractions that do not fit a Roblox experience
+
+## What Blueprint Must Produce
+
+- the concrete creator outcome
+- the gameplay/system scope
+- the exact Roblox services and object model touchpoints
+- server/client/shared ownership boundaries
+- module/script placement guidance
+- data shape guidance using Luau/Roblox terms
+- verification steps tied to the changed gameplay or tool flow
+
+## Roblox-Native Planning Rules
+
+- Prefer engine truth over generic software jargon.
+- Talk in terms of:
+  - Instances
+  - services
+  - remotes
+  - attributes
+  - tags
+  - replicated state
+  - server authority
+  - player lifecycle
+  - UI trees
+  - ModuleScripts
+  - typed Luau
+- If a plan introduces patterns that feel imported from enterprise backend work, justify them explicitly.
+- If a system can be expressed more directly through normal Roblox structures, choose that simpler path.
+
+## GPT-5.5 Guidance Alignment
+
+Use the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step planning, local overrides for the active workflow branch, evidence-backed planning and validation expectations, explicit stop rules, right-sized implementation/PRD shape, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.
+
+## Consensus Workflow
+
+Blueprint invokes the consensus-planning lane:
+
+```text
+$plan --consensus <arguments>
+$plan --consensus --interactive <arguments>
+```
+
+The consensus workflow:
+1. **Planner** creates an adaptive plan and a compact **BLUEPRINT-DR** summary before review. Do not default to exactly five steps; right-size the plan to the real scope:
+   - Principles (3-5)
+   - Decision Drivers (top 3)
+   - Viable Options (>=2) with bounded pros/cons
+   - If only one viable option remains, explicit invalidation rationale for alternatives
+   - Deliberate mode only: pre-mortem (3 scenarios) + expanded test plan (unit/integration/e2e/observability)
+2. **User feedback** `(--interactive only)`: Present the draft plan plus the Principles / Drivers / Options summary before review.
+3. **Architect** reviews for architectural soundness and must provide the strongest steelman antithesis, at least one real tradeoff tension, and, when possible, synthesis.
+4. **Critic** evaluates against quality criteria. Run only after Architect completes.
+5. **Re-review loop** (max 5 iterations): Any non-`APPROVE` Critic verdict must run the full closed loop of revise -> Architect -> Critic until approval or iteration cap.
+6. On Critic approval `(--interactive only)`: Present the final plan with approval options:
+   - Approve and execute via canonical `$forge`
+   - Approve and implement via `$team`
+   - Request changes
+   - Reject
+7. Final plan output **MUST** include:
+   - ADR (Decision, Drivers, Alternatives considered, Why chosen, Consequences, Follow-ups)
+   - available-agent-types roster
+   - follow-up staffing guidance for both `$forge` and `$team`
+   - suggested reasoning levels by lane
+   - explicit `rcs team` / `$team` launch hints
+   - a concrete team verification path
+8. On approval: **MUST** hand off to `$forge` or `$team`. Do not implement directly from the planning agent.
+
+> Important: Steps 3 and 4 MUST run sequentially. Await completion before step 4. Do NOT run Architect and Critic in parallel.
+
+## Pre-context Intake
+
+Before consensus planning or execution handoff, ensure a grounded context snapshot exists:
+
+1. Derive a task slug from the request.
+2. Reuse the latest relevant snapshot in `.rcs/context/{slug}-*.md` when available.
+3. If none exists, create `.rcs/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:
+   - task statement
+   - desired outcome
+   - known facts/evidence
+   - constraints
+   - unknowns/open questions
+   - likely codebase touchpoints
+4. If ambiguity remains high, gather brownfield facts first. When session guidance enables `USE_RCS_EXPLORE_CMD`, prefer `rcs explore` for simple read-only repository lookups with narrow, concrete prompts; otherwise use the richer normal explore path. Then run `$deep-interview --quick <task>` before continuing.
+5. If the plan depends on official docs, version-aware framework guidance, best practices, or external dependency behavior, auto-delegate `researcher` before finalizing the planning handoff.
+
+Do not hand off to execution modes until this intake is complete. If urgency forces progress, explicitly document the risk tradeoffs.
+
+## Pre-Execution Gate
+
+### Why the Gate Exists
+
+Execution modes (`$forge`, `autopilot`, `team`, `ultrawork`) are too expensive to launch against a vague request. Blueprint intercepts underspecified execution asks and redirects them into explicit planning first, so code execution starts from a bounded plan instead of a guess.
+
+This ensures:
+- explicit scope
+- test specification
+- planner/architect/critic consensus
+- no wasted execution cycles
+
+### Good vs Bad Prompts
+
+**Passes the gate**:
+- `forge fix the null check in src/hooks/bridge.ts:326`
+- `autopilot implement issue #42`
+- `team add validation to function processKeywordDetector`
+- `forge do:\n1. Add input validation\n2. Write tests\n3. Update README`
+
+**Gated and redirected to blueprint**:
+- `forge fix this`
+- `autopilot build the app`
+- `team improve performance`
+- `forge add player trading`
+- `ultrawork make it better`
+
+**Bypass the gate**:
+- `force: forge refactor the combat RemoteEvent handlers`
+- `! autopilot optimize everything`
+
+### When the Gate Does Not Trigger
+
+The gate auto-passes when it detects any concrete signal such as:
+- file path
+- issue or PR number
+- function/class/symbol name
+- explicit test runner target
+- numbered steps
+- acceptance criteria
+- error reference
+- provided code block
+- escape prefix
+
+### End-to-End Flow Example
+
+1. User types `forge add ranked matchmaking`.
+2. Gate detects an execution keyword plus an underspecified prompt.
+3. Gate redirects to **blueprint** with a message explaining the redirect.
+4. Blueprint consensus runs:
+   - Planner creates the initial plan
+   - Architect reviews the design
+   - Critic validates quality and testability
+5. On approval, the user chooses either:
+   - `$forge` for sequential execution with verification
+   - `$team` for parallel coordinated agents
+6. Execution begins with a clear, bounded plan.
+
+## Planning Checklist
+
+1. Identify the player-facing behavior and the creator outcome.
+2. Identify the Roblox runtime surfaces involved.
+3. Define who owns each mutation:
+   - server
+   - client
+   - shared module
+4. Define the canonical data shape using Luau-friendly structures.
+5. Define remote/event contracts only where they are truly needed.
+6. Define failure cases:
+   - stale replication
+   - duplicate grant
+   - invalid payload
+   - out-of-order UI updates
+   - partial save/load
+7. Define proof:
+   - which test
+   - which runtime path
+   - which state transition proves success
+
+## Anti-Slop Rules
+
+- Do not emit architecture that reads like an enterprise CRUD app unless the repo actually contains that system shape.
+- Do not use “DTO”, “controller”, “repository”, “microservice”, “middleware chain”, or similar language by default for Roblox gameplay code.
+- Do not hand off to implementation until naming, ownership, and verification are concrete.
+- Do not implement directly from blueprint. Approval hands off to `$forge` or `$team`.
+
+## Follow-On Design Lanes
+
+After the core blueprint, expand creator design depth when useful:
 - `$blueprint:psych`
 - `$blueprint:loop`
 - `$blueprint:retention`
 - `$blueprint:social`
+
+## Scenario Examples
+
+**Good:** The user says `continue` after the workflow already has a clear next step. Continue the current planning branch instead of restarting discovery or re-asking the same question.
+
+**Good:** The user changes only the downstream delivery shape, such as `make a PR after approval`. Preserve earlier non-conflicting planning constraints and update only the current handoff branch.
+
+**Bad:** The user says `continue`, and the workflow restarts broad discovery or drifts into implementation before the plan and verification path are grounded.
+
+## Example
+
+```text
+$blueprint "Plan a cross-server party queue for a Roblox combat experience.
+Need:
+- TeleportService handoff boundaries
+- party ownership and invite data shape
+- client/server split for queue UI
+- anti-duplication rules for queue join/leave
+- verification path for queue sync and teleport readiness"
+```
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/blueprint-loop/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: blueprint-loop
 description: Creator workflow for `$blueprint:loop`
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Blueprint Loop
@@ -17,3 +21,6 @@ Return a filled **Dopamine Loop Map** using `templates/psychology/dopamine-loop-
 - daily loop
 - weekly loop
 - comeback loop
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/blueprint-psych/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: blueprint-psych
 description: Creator workflow for `$blueprint:psych`
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Blueprint Psych
@@ -19,3 +23,6 @@ Return:
 - fairness risks.
 
 Use `docs/reference/player-psychology-framework.md` as the framework source.
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/blueprint-retention/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: blueprint-retention
 description: Creator workflow for `$blueprint:retention`
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Blueprint Retention
@@ -13,3 +17,6 @@ Return:
 - a filled **Retention Design Sheet** from `templates/psychology/retention-design-sheet.md`
 - a compact **Weekly LiveOps Plan**
 - comeback hooks and burnout guardrails
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/blueprint-social/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: blueprint-social
 description: Creator workflow for `$blueprint:social`
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Blueprint Social
@@ -13,3 +17,6 @@ Return a **Social Retention Spec** using `templates/psychology/social-mechanic-s
 - parties / guilds / trading / co-op / invites / presence systems as appropriate
 - why solo-only design would underperform
 - anti-spam guardrails
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/brief/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: brief
 description: Canonical creator briefing surface for Roblox Creator Skills
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Brief
@@ -25,3 +29,6 @@ Use the protocol in:
 Follow with:
 - `$brief:audience`
 - `$brief:motivation`
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/brief-audience/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: brief-audience
 description: Creator workflow for `$brief:audience`
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Brief Audience
@@ -17,3 +21,6 @@ Return a filled **Player Motivation Profile** using `templates/psychology/player
 - Name the primary fantasy before talking about features.
 - Call out likely session length and why the player comes back.
 - End with 3 audience risks or mismatches.
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/brief-motivation/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: brief-motivation
 description: Creator workflow for `$brief:motivation`
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Brief Motivation
@@ -20,3 +24,6 @@ Return a **Motivation Matrix** with:
 - Explain the dominant driver in one sentence.
 - Separate “good urgency” from manipulative pressure.
 - Prefer community when social play is naturally supported.
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/build-fix/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: build-fix
 description: Fix build and TypeScript errors with minimal changes
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Build Fix Skill
@@ -132,9 +136,9 @@ Combine with other skills for comprehensive fixing:
 ```
 Spawns multiple build-fixer agents in parallel for different files.
 
-**With Ralph:**
+**With Forge:**
 ```
-/ralph fix the build
+/forge fix the build
 ```
 Keeps trying until build passes, even if it takes multiple iterations.
 
@@ -143,3 +147,6 @@ Keeps trying until build passes, even if it takes multiple iterations.
 /team "debug build failures and fix type errors"
 ```
 Uses: explore → build-fixer → verifier workflow.
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/cancel/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: cancel
-description: Cancel any active RCS mode (autopilot, ralph, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)
+description: Cancel any active RCS mode (autopilot, forge, ultrawork, ecomode, ultraqa, swarm, ultrapilot, pipeline, team)
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Cancel Skill
@@ -17,9 +21,9 @@ a last resort.
 
 Automatically detects which mode is active and cancels it:
 - **Autopilot**: Stops workflow, preserves progress for resume
-- **Ralph**: Stops persistence loop, clears linked ultrawork if applicable
+- **Forge**: Stops persistence loop, clears linked ultrawork if applicable
 - **Ultrawork**: Stops parallel execution (standalone or linked)
-- **Ecomode**: Stops token-efficient parallel execution (standalone or linked to ralph)
+- **Ecomode**: Stops token-efficient parallel execution (standalone or linked to forge)
 - **UltraQA**: Stops QA cycling workflow
 - **Swarm**: Stops coordinated agent swarm, releases claimed tasks
 - **Ultrapilot**: Stops parallel autopilot workers
@@ -42,22 +46,22 @@ Or say: "cancelomc", "stopomc"
 - Swarm is a shared SQLite/marker mode (`.rcs/state/swarm.db` / `.rcs/state/swarm-active.marker`) and is not session-scoped.
 - The default cleanup flow calls `state_clear` with the session id to remove only the matching session files; modes stay bound to their originating session.
 
-## Normative Ralph cancellation post-conditions (MUST)
+## Normative Forge cancellation post-conditions (MUST)
 
-For Ralph-targeted cancellation (standalone or linked), completion is defined by post-conditions:
+For Forge-targeted cancellation (standalone or linked), completion is defined by post-conditions:
 
-1. Target Ralph state is terminalized, not silently removed:
+1. Target Forge state is terminalized, not silently removed:
    - `active=false`
    - `current_phase='cancelled'`
    - `completed_at` is set (ISO timestamp)
-2. If Ralph is linked to Ultrawork or Ecomode in the same scope, that linked mode is also terminalized/non-active.
+2. If Forge is linked to Ultrawork or Ecomode in the same scope, that linked mode is also terminalized/non-active.
 4. Cancellation MUST remain scope-safe: no mutation of unrelated sessions.
 
-See: `docs/contracts/ralph-cancel-contract.md`.
+See: `docs/contracts/forge-cancel-contract.md`.
 
 Active modes are still cancelled in dependency order:
-1. Autopilot (includes linked ralph/ultraqa/ecomode cleanup)
-2. Ralph (cleans its linked ultrawork or ecomode)
+1. Autopilot (includes linked forge/ultraqa/ecomode cleanup)
+2. Forge (cleans its linked ultrawork or ecomode)
 3. Ultrawork (standalone)
 4. Ecomode (standalone)
 5. UltraQA (standalone)
@@ -67,11 +71,11 @@ Active modes are still cancelled in dependency order:
 9. Team (tmux-based)
 10. Plan Consensus (standalone)
 
-## Normative Ralph post-conditions (MUST)
+## Normative Forge post-conditions (MUST)
 
-When cancellation targets Ralph state in a scope, completion requires all of the following:
+When cancellation targets Forge state in a scope, completion requires all of the following:
 
-1. Ralph state is terminal in that same scope: `active=false`, `current_phase='cancelled'` (or linked terminal phase), and `completed_at` is set.
+1. Forge state is terminal in that same scope: `active=false`, `current_phase='cancelled'` (or linked terminal phase), and `completed_at` is set.
 2. Linked Ultrawork/Ecomode in the same scope is also terminal/non-active.
 4. Unrelated sessions are untouched.
 
@@ -97,9 +101,9 @@ Every `state_clear` command honors the `session_id` argument, so even force mode
 
 Legacy compatibility list (removed only under `--force`/`--all`):
 - `.rcs/state/autopilot-state.json`
-- `.rcs/state/ralph-state.json`
-- `.rcs/state/ralph-plan-state.json`
-- `.rcs/state/ralph-verification.json`
+- `.rcs/state/forge-state.json`
+- `.rcs/state/forge-plan-state.json`
+- `.rcs/state/forge-verification.json`
 - `.rcs/state/ultrawork-state.json`
 - `.rcs/state/ecomode-state.json`
 - `.rcs/state/ultraqa-state.json`
@@ -112,7 +116,7 @@ Legacy compatibility list (removed only under `--force`/`--all`):
 - `.rcs/state/ultrapilot-ownership.json`
 - `.rcs/state/pipeline-state.json`
 - `.rcs/state/plan-consensus.json`
-- `.rcs/state/ralplan-state.json`
+- `.rcs/state/blueprint-state.json`
 - `.rcs/state/boulder.json`
 - `.rcs/state/hud-state.json`
 - `.rcs/state/subagent-tracking.json`
@@ -140,9 +144,9 @@ fi
 
 The skill now relies on the session-aware state contract rather than hard-coded file paths:
 1. Call `state_list_active` to enumerate `.rcs/state/sessions/{sessionId}/…` and discover every active session.
-2. For each session id, call `state_get_status` to learn which mode is running (`autopilot`, `ralph`, `ultrawork`, etc.) and whether dependent modes exist.
+2. For each session id, call `state_get_status` to learn which mode is running (`autopilot`, `forge`, `ultrawork`, etc.) and whether dependent modes exist.
 3. If a `session_id` was supplied to `/cancel`, skip legacy fallback entirely and operate solely within that session path; otherwise, consult legacy files in `.rcs/state/*.json` only if the state tools report no active session. Swarm remains a shared SQLite/marker mode outside session scoping.
-4. Any cancellation logic in this doc mirrors the dependency order discovered via state tools (autopilot → ralph → …).
+4. Any cancellation logic in this doc mirrors the dependency order discovered via state tools (autopilot → forge → …).
 
 ### 3A. Force Mode (if --force or --all)
 
@@ -216,24 +220,24 @@ Team "{team_name}" cancelled:
 Call `cancelAutopilot()` from `src/hooks/autopilot/cancel.ts:27-78`:
 
 ```bash
-# Autopilot handles its own cleanup + ralph + ultraqa
+# Autopilot handles its own cleanup + forge + ultraqa
 # Just mark autopilot as inactive (preserves state for resume)
 if [[ -f .rcs/state/autopilot-state.json ]]; then
-  # Clean up ralph if active
-  if [[ -f .rcs/state/ralph-state.json ]]; then
-    RALPH_STATE=$(cat .rcs/state/ralph-state.json)
-    LINKED_UW=$(echo "$RALPH_STATE" | jq -r '.linked_ultrawork // false')
+  # Clean up forge if active
+  if [[ -f .rcs/state/forge-state.json ]]; then
+    FORGE_STATE=$(cat .rcs/state/forge-state.json)
+    LINKED_UW=$(echo "$FORGE_STATE" | jq -r '.linked_ultrawork // false')
 
     # Clean linked ultrawork first
     if [[ "$LINKED_UW" == "true" ]] && [[ -f .rcs/state/ultrawork-state.json ]]; then
       rm -f .rcs/state/ultrawork-state.json
-      echo "Cleaned up: ultrawork (linked to ralph)"
+      echo "Cleaned up: ultrawork (linked to forge)"
     fi
 
-    # Clean ralph
-    rm -f .rcs/state/ralph-state.json
-    rm -f .rcs/state/ralph-verification.json
-    echo "Cleaned up: ralph"
+    # Clean forge
+    rm -f .rcs/state/forge-state.json
+    rm -f .rcs/state/forge-verification.json
+    echo "Cleaned up: forge"
   fi
 
   # Clean up ultraqa if active
@@ -252,34 +256,34 @@ if [[ -f .rcs/state/autopilot-state.json ]]; then
 fi
 ```
 
-#### If Ralph Active (but not Autopilot)
+#### If Forge Active (but not Autopilot)
 
-Call `clearRalphState()` + `clearLinkedUltraworkState()` from `src/hooks/ralph-loop/index.ts:147-182`:
+Call `clearForgeState()` + `clearLinkedUltraworkState()` from the active Forge cleanup path:
 
 ```bash
-if [[ -f .rcs/state/ralph-state.json ]]; then
+if [[ -f .rcs/state/forge-state.json ]]; then
   # Check if ultrawork is linked
-  RALPH_STATE=$(cat .rcs/state/ralph-state.json)
-  LINKED_UW=$(echo "$RALPH_STATE" | jq -r '.linked_ultrawork // false')
+  FORGE_STATE=$(cat .rcs/state/forge-state.json)
+  LINKED_UW=$(echo "$FORGE_STATE" | jq -r '.linked_ultrawork // false')
 
   # Clean linked ultrawork first
   if [[ "$LINKED_UW" == "true" ]] && [[ -f .rcs/state/ultrawork-state.json ]]; then
     UW_STATE=$(cat .rcs/state/ultrawork-state.json)
-    UW_LINKED=$(echo "$UW_STATE" | jq -r '.linked_to_ralph // false')
+    UW_LINKED=$(echo "$UW_STATE" | jq -r '.linked_to_forge // false')
 
-    # Only clear if it was linked to ralph
+    # Only clear if it was linked to forge
     if [[ "$UW_LINKED" == "true" ]]; then
       rm -f .rcs/state/ultrawork-state.json
-      echo "Cleaned up: ultrawork (linked to ralph)"
+      echo "Cleaned up: ultrawork (linked to forge)"
     fi
   fi
 
-  # Clean ralph state
-  rm -f .rcs/state/ralph-state.json
-  rm -f .rcs/state/ralph-plan-state.json
-  rm -f .rcs/state/ralph-verification.json
+  # Clean forge state
+  rm -f .rcs/state/forge-state.json
+  rm -f .rcs/state/forge-plan-state.json
+  rm -f .rcs/state/forge-verification.json
 
-  echo "Ralph cancelled. Persistent mode deactivated."
+  echo "Forge cancelled. Persistent mode deactivated."
 fi
 ```
 
@@ -289,12 +293,12 @@ Call `deactivateUltrawork()` from `src/hooks/ultrawork/index.ts:150-173`:
 
 ```bash
 if [[ -f .rcs/state/ultrawork-state.json ]]; then
-  # Check if linked to ralph
+  # Check if linked to forge
   UW_STATE=$(cat .rcs/state/ultrawork-state.json)
-  LINKED=$(echo "$UW_STATE" | jq -r '.linked_to_ralph // false')
+  LINKED=$(echo "$UW_STATE" | jq -r '.linked_to_forge // false')
 
   if [[ "$LINKED" == "true" ]]; then
-    echo "Ultrawork is linked to Ralph. Use /cancel to cancel both."
+    echo "Ultrawork is linked to Forge. Use /cancel to cancel both."
     exit 1
   fi
 
@@ -323,7 +327,7 @@ echo "No active RCS modes detected."
 echo ""
 echo "Checked for:"
 echo "  - Autopilot (.rcs/state/autopilot-state.json)"
-echo "  - Ralph (.rcs/state/ralph-state.json)"
+echo "  - Forge (.rcs/state/forge-state.json)"
 echo "  - Ultrawork (.rcs/state/ultrawork-state.json)"
 echo "  - UltraQA (.rcs/state/ultraqa-state.json)"
 echo ""
@@ -334,8 +338,8 @@ echo "Use --force to clear all state files anyway."
 
 The cancel skill runs as follows:
 1. Parse the `--force` / `--all` flags, tracking whether cleanup should span every session or stay scoped to the current session id.
-2. Use `state_list_active` to enumerate known session ids and `state_get_status` to learn the active mode (`autopilot`, `ralph`, `ultrawork`, etc.) for each session.
-3. When operating in default mode, call `state_clear` with that session_id to remove only the session’s files, then run mode-specific cleanup (autopilot → ralph → …) based on the state tool signals.
+2. Use `state_list_active` to enumerate known session ids and `state_get_status` to learn the active mode (`autopilot`, `forge`, `ultrawork`, etc.) for each session.
+3. When operating in default mode, call `state_clear` with that session_id to remove only the session’s files, then run mode-specific cleanup (autopilot → forge → …) based on the state tool signals.
 4. In force mode, iterate every active session, call `state_clear` per session, then run a global `state_clear` without `session_id` to drop legacy files (`.rcs/state/*.json`, compatibility artifacts) and report success. Swarm remains a shared SQLite/marker mode outside session scoping.
 5. Team artifacts (`.rcs/state/team/*/`, tmux sessions matching `rcs-team-*`) remain best-effort cleanup items invoked during the legacy/global pass.
 
@@ -347,7 +351,7 @@ Mode-specific subsections below describe what extra cleanup each handler perform
 | Mode | Success Message |
 |------|-----------------|
 | Autopilot | "Autopilot cancelled at phase: {phase}. Progress preserved for resume." |
-| Ralph | "Ralph cancelled. Persistent mode deactivated." |
+| Forge | "Forge cancelled. Persistent mode deactivated." |
 | Ultrawork | "Ultrawork cancelled. Parallel execution mode deactivated." |
 | Ecomode | "Ecomode cancelled. Token-efficient execution mode deactivated." |
 | UltraQA | "UltraQA cancelled. QA cycling workflow stopped." |
@@ -364,7 +368,7 @@ Mode-specific subsections below describe what extra cleanup each handler perform
 | Mode | State Preserved | Resume Command |
 |------|-----------------|----------------|
 | Autopilot | Yes (phase, files, spec, plan, verdicts) | `/autopilot` |
-| Ralph | No | N/A |
+| Forge | No | N/A |
 | Ultrawork | No | N/A |
 | UltraQA | No | N/A |
 | Swarm | No | N/A |
@@ -374,8 +378,8 @@ Mode-specific subsections below describe what extra cleanup each handler perform
 
 ## Notes
 
-- **Dependency-aware**: Autopilot cancellation cleans up Ralph and UltraQA
-- **Link-aware**: Ralph cancellation cleans up linked Ultrawork or Ecomode
+- **Dependency-aware**: Autopilot cancellation cleans up Forge and UltraQA
+- **Link-aware**: Forge cancellation cleans up linked Ultrawork or Ecomode
 - **Safe**: Only clears linked Ultrawork, preserves standalone Ultrawork
 - **Local-only**: Clears state files in `.rcs/state/` directory
 - **Resume-friendly**: Autopilot state is preserved for seamless resume
@@ -397,3 +401,6 @@ rm -rf .rcs/state/team/                  # All team state
 # Kill all rcs-team-* tmux sessions
 tmux list-sessions -F '#{session_name}' 2>/dev/null | grep '^rcs-team-' | while read s; do tmux kill-session -t "$s" 2>/dev/null; done
 ```
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"