@jstn-sdk/rcs 0.1.0 → 0.1.6

package/skills/.agents/skills/roblox-security/SKILL.md

@@ -0,0 +1,236 @@
+---
+name: roblox-security
+description: "Use when writing Roblox game scripts that handle player actions, currencies, stats, damage, or any RemoteEvent/RemoteFunction communication. Use when reviewing code for exploitable patterns, implementing anti-cheat logic, validating client requests on the server, or setting up rate limiting."
+---
+
+# Roblox Security: Anti-Exploit & Server-Side Validation
+
+## Core Principle
+
+**Never trust the client.** Every LocalScript runs on the player's machine and can be modified. All authoritative logic — damage, currency, stats, position changes — must live on the server.
+
+FilteringEnabled is always on in modern Roblox. Client-side changes do not replicate to the server or other clients unless the server explicitly applies them.
+
+---
+
+## Secure vs Insecure Patterns
+
+| Pattern | Insecure | Secure |
+|---|---|---|
+| Dealing damage | LocalScript sets `Humanoid.Health` | Server reduces health after validation |
+| Awarding currency | LocalScript increments leaderstats | Server validates action, then increments |
+| Leaderstats ownership | LocalScript owns the IntValue | Server creates and owns all leaderstats |
+| Position changes | LocalScript teleports character | Server validates and moves character |
+| Tool use | Client fires damage on hit | Server raycasts and applies damage |
+| Cooldowns | Client tracks cooldown locally | Server tracks cooldown per player |
+
+---
+
+## Secure Leaderstats Setup
+
+```lua
+-- Script in ServerScriptService — never LocalScript
+game.Players.PlayerAdded:Connect(function(player)
+    local leaderstats = Instance.new("Folder")
+    leaderstats.Name = "leaderstats"
+    leaderstats.Parent = player
+
+    local coins = Instance.new("IntValue")
+    coins.Name = "Coins"
+    coins.Value = 0
+    coins.Parent = leaderstats
+end)
+```
+
+---
+
+## Server-Side Sanity Checks
+
+### Distance Check
+
+```lua
+local MAX_INTERACT_DISTANCE = 10
+
+InteractRemote.OnServerEvent:Connect(function(player, targetPart)
+    if typeof(targetPart) ~= "Instance" or not targetPart:IsA("BasePart") then return end
+
+    local root = player.Character and player.Character:FindFirstChild("HumanoidRootPart")
+    if not root then return end
+
+    if (root.Position - targetPart.Position).Magnitude > MAX_INTERACT_DISTANCE then
+        warn(player.Name .. " sent interaction from invalid distance")
+        return
+    end
+
+    processInteraction(player, targetPart)
+end)
+```
+
+### Cooldown Validation
+
+```lua
+local ABILITY_COOLDOWN = 5
+local lastUsed = {}
+
+UseAbilityRemote.OnServerEvent:Connect(function(player)
+    local now = os.clock()
+    if now - (lastUsed[player] or 0) < ABILITY_COOLDOWN then return end
+    lastUsed[player] = now
+    applyAbility(player)
+end)
+
+game.Players.PlayerRemoving:Connect(function(player)
+    lastUsed[player] = nil
+end)
+```
+
+### Stat Bounds Check
+
+```lua
+local MAX_QUANTITY = 99
+local ITEM_COST = 50
+
+BuyItemRemote.OnServerEvent:Connect(function(player, quantity)
+    if type(quantity) ~= "number" then return end
+    quantity = math.clamp(math.floor(quantity), 1, MAX_QUANTITY)
+
+    local coins = player.leaderstats.Coins
+    if coins.Value < ITEM_COST * quantity then return end
+
+    coins.Value = coins.Value - (ITEM_COST * quantity)
+    -- award items server-side
+end)
+```
+
+---
+
+## Rate Limiting
+
+```lua
+local RATE_LIMIT = 10   -- max calls
+local RATE_WINDOW = 1   -- per second
+local callLog = {}
+
+local function isRateLimited(player)
+    local now = os.clock()
+    local log = callLog[player] or {}
+    local pruned = {}
+    for _, t in ipairs(log) do
+        if now - t < RATE_WINDOW then table.insert(pruned, t) end
+    end
+    if #pruned >= RATE_LIMIT then
+        callLog[player] = pruned
+        return true
+    end
+    table.insert(pruned, now)
+    callLog[player] = pruned
+    return false
+end
+
+ActionRemote.OnServerEvent:Connect(function(player)
+    if isRateLimited(player) then return end
+    handleAction(player)
+end)
+
+game.Players.PlayerRemoving:Connect(function(player)
+    callLog[player] = nil
+end)
+```
+
+---
+
+## Argument Validation Utility
+
+```lua
+-- ServerScriptService/Modules/Validate.lua
+local Validate = {}
+
+function Validate.number(value, min, max)
+    if type(value) ~= "number" then return false end
+    if value ~= value then return false end -- NaN check
+    if min and value < min then return false end
+    if max and value > max then return false end
+    return true
+end
+
+function Validate.instance(value, className)
+    if typeof(value) ~= "Instance" then return false end
+    if className and not value:IsA(className) then return false end
+    return true
+end
+
+function Validate.string(value, maxLength)
+    if type(value) ~= "string" then return false end
+    if maxLength and #value > maxLength then return false end
+    return true
+end
+
+return Validate
+```
+
+```lua
+-- Usage
+local Validate = require(script.Parent.Modules.Validate)
+
+remote.OnServerEvent:Connect(function(player, amount, targetPart)
+    if not Validate.number(amount, 1, 100) then return end
+    if not Validate.instance(targetPart, "BasePart") then return end
+    -- safe to proceed
+end)
+```
+
+---
+
+## Speed / Anti-Cheat Detection
+
+```lua
+local SPEED_LIMIT = 32
+local violations = {}
+
+task.spawn(function()
+    while true do
+        task.wait(2)
+        for _, player in ipairs(game.Players:GetPlayers()) do
+            local root = player.Character and player.Character:FindFirstChild("HumanoidRootPart")
+            if root and root.AssemblyLinearVelocity.Magnitude > SPEED_LIMIT then
+                violations[player] = (violations[player] or 0) + 1
+                if violations[player] >= 3 then
+                    player:Kick("Cheating detected.")
+                end
+            else
+                violations[player] = math.max(0, (violations[player] or 0) - 1)
+            end
+        end
+    end
+end)
+```
+
+---
+
+## ModuleScript Placement
+
+```
+ServerScriptService/
+  Modules/
+    DamageCalculator.lua   -- server-only, never exposed to client
+    EconomyManager.lua     -- server-only
+
+ReplicatedStorage/
+  Remotes/                 -- RemoteEvent/RemoteFunction instances only
+  SharedModules/           -- non-sensitive utilities only
+```
+
+Never put currency, damage, or DataStore logic in `ReplicatedStorage` modules — clients can `require()` them.
+
+---
+
+## Common Mistakes
+
+| Mistake | Why It's Exploitable | Fix |
+|---|---|---|
+| `FireServer(damage)` with server trusting it | Client sends any value | Server calculates damage from its own tool data |
+| Currency in LocalScript variable | Client can modify memory | Server-owned only |
+| Client-side distance check before firing | Check is bypassable | Server re-checks after receiving event |
+| No cooldown on RemoteEvent handlers | Spam = infinite resources | Per-player cooldown on server |
+| Trusting `WalkSpeed` set by client | Client sets arbitrarily high | Server owns and caps WalkSpeed |
+| Sensitive logic in ReplicatedStorage module | Clients can require it | Move to ServerScriptService |

package/skills/ai-slop-cleaner/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: ai-slop-cleaner
 description: Run an anti-slop cleanup/refactor/deslop workflow
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # AI Slop Cleaner Skill
@@ -22,11 +26,11 @@ Use this skill when:
 - Keep using inspection, tests, diagnostics, and verification until the cleanup is grounded.
 - Proceed automatically through clear, reversible cleanup steps; ask only when a choice materially changes scope or behavior.
 
-## Scoped File Lists and Ralph Workflow
+## Scoped File Lists and Forge Workflow
 
 - This skill can accept a **file list scope** instead of a whole feature area.
-- When the caller provides a changed-files list (for example, Ralph session-owned edits), keep the cleanup strictly bounded to those files.
-- In the **Ralph workflow**, the mandatory deslop pass should run this skill on Ralph's changed files only, in standard mode unless the caller explicitly requests otherwise.
+- When the caller provides a changed-files list (for example, Forge session-owned edits), keep the cleanup strictly bounded to those files.
+- In the **Forge workflow**, the mandatory deslop pass should run this skill on Forge's changed files only, in standard mode unless the caller explicitly requests otherwise.
 
 ## Procedure
 
@@ -50,8 +54,8 @@ Use this skill when:
      - **Masking fallback slop** — hides errors or evidence, bypasses the primary contract, suppresses tests or validation, swallows failures, silently defaults, or adds untested alternate paths
      - **Grounded compatibility/fail-safe fallback** — is scoped to an external/version/fail-safe boundary, documents the rationale, preserves failure evidence, and has regression tests for both the primary and fallback behavior
    - Prefer root-cause repair, deletion, boundary repair, or explicit failure behavior before preserving fallback paths
-   - For broad, ambiguous, cross-layer, or architectural fallback-like code, invoke `$ralplan` for consensus resolution before edits
-   - Recursion guard: when already inside ralplan, ralph, team, or another RCS workflow, do not spawn a nested `$ralplan`; record the finding and attach it to the active ralplan, leader, or plan handoff instead
+   - For broad, ambiguous, cross-layer, or architectural fallback-like code, invoke `$blueprint` for consensus resolution before edits
+   - Recursion guard: when already inside blueprint, forge, team, or another RCS workflow, do not spawn a nested `$blueprint`; record the finding and attach it to the active blueprint, leader, or plan handoff instead
 
 4. **Categorize issues before editing**
    - **Fallback-like code** — masking fallbacks, workaround branches, bypasses, swallowed errors, silent defaults, broad shims, alternate execution paths
@@ -99,7 +103,7 @@ Cleanup Plan: [bounded smells and order]
 Fallback Findings: [none, or finding -> masking fallback slop / grounded compatibility/fail-safe fallback -> escalation status]
 
 Passes Completed:
-- Fallback-like code resolution gate - [root-cause repair, explicit failure behavior, preserved grounded fallback, or ralplan handoff]
+- Fallback-like code resolution gate - [root-cause repair, explicit failure behavior, preserved grounded fallback, or blueprint handoff]
 1. Pass 1: Dead code deletion - [concise fix]
 2. Pass 2: Duplicate removal - [concise fix]
 3. Pass 3: Naming/error handling cleanup - [concise fix]
@@ -118,7 +122,7 @@ Changed Files:
 Fallback Review:
 - Findings: [fallback-like findings detected]
 - Classification: [masking fallback slop | grounded fallback]
-- Escalation Status: [none | raised to leader/ralplan | no escalation]
+- Escalation Status: [none | raised to leader/blueprint | no escalation]
 
 Remaining Risks:
 - [none or short deferred item]
@@ -137,3 +141,6 @@ Remaining Risks:
 **Bad:** Keep a `fallback if it fails` branch that silently defaults after a swallowed error instead of fixing the root cause or making failure explicit.
 
 **Good:** A version-specific compatibility shim is narrow, documented, preserves error evidence, has primary and fallback regression tests, and is reported as a grounded compatibility/fail-safe fallback.
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/analyze/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: analyze
 description: "Run read-only deep repository analysis and return a ranked synthesis with explicit confidence, concrete file references, and clear evidence-vs-inference boundaries. Use when a user says 'analyze', 'investigate', 'why does', 'what's causing', or needs grounded cross-file explanation before any changes are proposed."
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Analyze — Read-Only Deep Analysis
@@ -25,7 +29,7 @@ Examples:
 ## Do not use `$analyze` when
 
 - the user explicitly wants code edits, a fix, or execution — use the appropriate implementation lane instead
-- the user wants a new product plan or acceptance criteria — use `$plan` / `$ralplan`
+- the user wants a new product plan or acceptance criteria — use `$plan` / `$blueprint`
 - the request is a simple one-file fact lookup — read the file and answer directly
 - the request is purely about running the RCS tmux team runtime — use `$team` only when RCS runtime is active
 
@@ -87,7 +91,7 @@ Parallel exploration is allowed when it improves quality, but it must stay runti
 
 A good default split for complex analysis is:
 - one lane for primary code path / contracts
-- one lane for config / orchestration / generated surfaces
+- one lane for config / workflow / generated surfaces
 - one lane for tests / docs / secondary corroboration
 
 ## Execution policy
@@ -146,3 +150,6 @@ A good analyze response is:
 - concise for simple cases, broader only when the question truly needs it
 
 Task: {{ARGUMENTS}}
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/ask-claude/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: ask-claude
 description: Ask Claude via local CLI and capture a reusable artifact
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Ask Claude (Local CLI)
@@ -59,3 +63,6 @@ Minimum artifact sections:
 5. Action items / next steps
 
 Task: {{ARGUMENTS}}
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/ask-gemini/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: ask-gemini
 description: Ask Gemini via local CLI and capture a reusable artifact
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Ask Gemini (Local CLI)
@@ -59,3 +63,6 @@ Minimum artifact sections:
 5. Action items / next steps
 
 Task: {{ARGUMENTS}}
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/autoforge/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: autoforge
 description: Canonical end-to-end creator workflow surface for Roblox Creator Skills
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Autoforge
@@ -16,3 +20,6 @@ For Roblox implementation tasks, `$autoforge` must still obey the mandatory gate
 5. only then begin execution
 
 `PRE_ACTION_COMPLETE` must become `true` before any Roblox code generation.
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/autopilot/SKILL.md

@@ -1,16 +1,20 @@
 ---
 name: autopilot
-description: "[RCS] Strict autonomous loop: $ralplan -> $ralph -> $code-review"
+description: "[RCS] Strict autonomous loop: $blueprint -> $forge -> $code-review"
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 <Purpose>
 Autopilot is the strict autonomous delivery loop for non-trivial work. Its primary contract is exactly:
 
 ```text
-$ralplan -> $ralph -> $code-review
+$blueprint -> $forge -> $code-review
 ```
 
-If `$code-review` is not clean, Autopilot returns to `$ralplan` with the review findings as the next planning input, then continues again through `$ralph` and `$code-review` until the review is clean or a hard blocker is reported.
+If `$code-review` is not clean, Autopilot returns to `$blueprint` with the review findings as the next planning input, then continues again through `$forge` and `$code-review` until the review is clean or a hard blocker is reported.
 </Purpose>
 
 <Use_When>
@@ -20,37 +24,37 @@ If `$code-review` is not clean, Autopilot returns to `$ralplan` with the review
 </Use_When>
 
 <Do_Not_Use_When>
-- User wants to explore options or brainstorm -- use `$plan` / `$ralplan`
+- User wants to explore options or brainstorm -- use `$plan` / `$blueprint`
 - User says "just explain", "draft only", or "what would you suggest" -- respond conversationally
-- User wants a single focused code change -- use `$ralph` or direct executor work
+- User wants a single focused code change -- use `$forge` or direct executor work
 - User wants only review/critique of existing code -- use `$code-review`
 </Do_Not_Use_When>
 
 <Strict_Loop_Contract>
 Autopilot must not run a separate broad expansion/planning/execution/QA/validation lifecycle as its primary behavior. It delegates those concerns to the three canonical workflow phases below:
 
-1. **Phase `ralplan`** — consensus planning gate
+1. **Phase `blueprint`** — consensus planning gate
    - Ground the task with pre-context intake.
-   - Run or resume `$ralplan` to produce/update PRD and test-spec artifacts.
-   - When returning from a non-clean review, include `return_to_ralplan_reason` and the review findings as first-class planning input.
-   - Required handoff artifact: an approved plan/test spec suitable for `$ralph`.
+   - Run or resume `$blueprint` to produce/update PRD and test-spec artifacts.
+   - When returning from a non-clean review, include `return_to_blueprint_reason` and the review findings as first-class planning input.
+   - Required handoff artifact: an approved plan/test spec suitable for `$forge`.
 
-2. **Phase `ralph`** — implementation + verification loop
-   - Run `$ralph` from the approved ralplan artifacts.
-   - Ralph owns implementation, tests, build/lint/typecheck evidence, deslop where applicable, and architect verification.
+2. **Phase `forge`** — implementation + verification loop
+   - Run `$forge` from the approved blueprint artifacts.
+   - Forge owns implementation, tests, build/lint/typecheck evidence, deslop where applicable, and architect verification.
    - Required handoff artifact: implementation evidence and changed-file summary suitable for `$code-review`.
 
 3. **Phase `code-review`** — merge-readiness gate
-   - Run `$code-review` on the diff/artifacts produced by `$ralph`.
+   - Run `$code-review` on the diff/artifacts produced by `$forge`.
    - A clean review means final recommendation `APPROVE` with architectural status `CLEAR`.
    - `COMMENT`, `REQUEST CHANGES`, any architectural `WATCH`/`BLOCK`, or any unresolved finding is not clean.
-   - If not clean, increment the review cycle, persist `review_verdict`, set `return_to_ralplan_reason`, and transition back to Phase `ralplan`.
+   - If not clean, increment the review cycle, persist `review_verdict`, set `return_to_blueprint_reason`, and transition back to Phase `blueprint`.
 
 The only normal terminal state is `complete` after a clean code review. Cancellation, blocked credentials, unrecoverable repeated failures, or explicit user stop may terminate earlier with preserved state.
 </Strict_Loop_Contract>
 
 <Pre-context Intake>
-Before Phase `ralplan` starts or resumes:
+Before Phase `blueprint` starts or resumes:
 1. Derive a task slug from the request.
 2. Reuse the latest relevant `.rcs/context/{slug}-*.md` snapshot when available.
 3. If none exists, create `.rcs/context/{slug}-{timestamp}.md` (UTC `YYYYMMDDTHHMMSSZ`) with:
@@ -60,16 +64,16 @@ Before Phase `ralplan` starts or resumes:
    - constraints
    - unknowns/open questions
    - likely codebase touchpoints
-4. If ambiguity remains high, run `explore` first for brownfield facts, then run the Socratic `$deep-interview --quick <task>` before `$ralplan`.
+4. If ambiguity remains high, run `explore` first for brownfield facts, then run the Socratic `$deep-interview --quick <task>` before `$blueprint`.
 5. Carry the snapshot path in Autopilot state and all handoff artifacts.
 </Pre-context Intake>
 
 <Execution_Policy>
-- Always execute phases in order: `ralplan`, then `ralph`, then `code-review`.
-- Never skip directly from vague/freeform expansion to implementation; unclear input must be clarified or planned through `$ralplan`.
-- A non-clean `$code-review` always returns to `$ralplan`; do not patch findings ad hoc outside the loop.
+- Always execute phases in order: `blueprint`, then `forge`, then `code-review`.
+- Never skip directly from vague/freeform expansion to implementation; unclear input must be clarified or planned through `$blueprint`.
+- A non-clean `$code-review` always returns to `$blueprint`; do not patch findings ad hoc outside the loop.
 - Each phase must write/update Autopilot state before handing off.
-- Use existing hooks, `.rcs/state`, `$ralplan`, `$ralph`, `$code-review`, and pipeline primitives; do not invent a separate execution framework.
+- Use existing hooks, `.rcs/state`, `$blueprint`, `$forge`, `$code-review`, and pipeline primitives; do not invent a separate execution framework.
 - Continue automatically through safe reversible phase transitions. Ask only for destructive, credential-gated, or materially preference-dependent branches.
 - Apply the shared workflow guidance pattern: outcome-first framing, concise visible updates for multi-step execution, local overrides for the active workflow branch, validation proportional to risk, explicit stop rules, and automatic continuation for safe reversible steps. Ask only for material, destructive, credentialed, external-production, or preference-dependent branches.
 </Execution_Policy>
@@ -83,35 +87,35 @@ Required fields:
 {
   "mode": "autopilot",
   "active": true,
-  "current_phase": "ralplan",
+  "current_phase": "blueprint",
   "iteration": 1,
   "review_cycle": 0,
   "max_iterations": 10,
-  "phase_cycle": ["ralplan", "ralph", "code-review"],
+  "phase_cycle": ["blueprint", "forge", "code-review"],
   "handoff_artifacts": {
     "context_snapshot_path": ".rcs/context/<slug>-<timestamp>.md",
-    "ralplan": null,
-    "ralph": null,
+    "blueprint": null,
+    "forge": null,
     "code_review": null
   },
   "review_verdict": null,
-  "return_to_ralplan_reason": null
+  "return_to_blueprint_reason": null
 }
 ```
 
-- **On start**: `state_write({mode:"autopilot", active:true, current_phase:"ralplan", iteration:1, review_cycle:0, state:{phase_cycle:["ralplan","ralph","code-review"], handoff_artifacts:{context_snapshot_path, ralplan:null, ralph:null, code_review:null}, review_verdict:null, return_to_ralplan_reason:null}})`
-- **On ralplan -> ralph**: set `current_phase:"ralph"`, persist the plan/test-spec paths under `handoff_artifacts.ralplan`.
-- **On ralph -> code-review**: set `current_phase:"code-review"`, persist implementation/test evidence under `handoff_artifacts.ralph`.
+- **On start**: `state_write({mode:"autopilot", active:true, current_phase:"blueprint", iteration:1, review_cycle:0, state:{phase_cycle:["blueprint","forge","code-review"], handoff_artifacts:{context_snapshot_path, blueprint:null, forge:null, code_review:null}, review_verdict:null, return_to_blueprint_reason:null}})`
+- **On blueprint -> forge**: set `current_phase:"forge"`, persist the plan/test-spec paths under `handoff_artifacts.blueprint`.
+- **On forge -> code-review**: set `current_phase:"code-review"`, persist implementation/test evidence under `handoff_artifacts.forge`.
 - **On clean review**: set `active:false`, `current_phase:"complete"`, persist `review_verdict:{recommendation:"APPROVE", architectural_status:"CLEAR", clean:true}` and `completed_at`.
-- **On non-clean review**: increment `iteration` and `review_cycle`, set `current_phase:"ralplan"`, persist `review_verdict:{..., clean:false}`, persist `handoff_artifacts.code_review`, and set `return_to_ralplan_reason` to a concise review-driven reason.
+- **On non-clean review**: increment `iteration` and `review_cycle`, set `current_phase:"blueprint"`, persist `review_verdict:{..., clean:false}`, persist `handoff_artifacts.code_review`, and set `return_to_blueprint_reason` to a concise review-driven reason.
 - **On cancellation**: run `$cancel`; preserve progress for resume rather than deleting handoff artifacts.
 </State_Management>
 
 <Continuation_And_Resume>
 When the user says `continue`, `resume`, or `keep going` while Autopilot is active, read `autopilot-state.json` and continue from `current_phase`:
-- `ralplan`: run/update consensus planning from current handoffs and any `return_to_ralplan_reason`.
-- `ralph`: execute the approved plan and record verification evidence.
-- `code-review`: review the current diff and decide clean vs return-to-ralplan.
+- `blueprint`: run/update consensus planning from current handoffs and any `return_to_blueprint_reason`.
+- `forge`: execute the approved plan and record verification evidence.
+- `code-review`: review the current diff and decide clean vs return-to-blueprint.
 - `complete`: report completion evidence; do not restart.
 
 Do not restart discovery or discard handoff artifacts on continuation.
@@ -121,10 +125,10 @@ Do not restart discovery or discard handoff artifacts on continuation.
 Autopilot may be represented by the configurable pipeline orchestrator (`src/pipeline/`) when useful. The Autopilot pipeline contract is:
 
 ```text
-ralplan -> ralph -> code-review
+blueprint -> forge -> code-review
 ```
 
-Pipeline state should use `current_phase` values that match the same phase names (`ralplan`, `ralph`, `code-review`, `complete`, `failed`) and should carry `iteration`, `review_cycle`, `handoff_artifacts`, `review_verdict`, and `return_to_ralplan_reason` alongside stage results.
+Pipeline state should use `current_phase` values that match the same phase names (`blueprint`, `forge`, `code-review`, `complete`, `failed`) and should carry `iteration`, `review_cycle`, `handoff_artifacts`, `review_verdict`, and `return_to_blueprint_reason` alongside stage results.
 </Pipeline_Orchestrator>
 
 <Escalation_And_Stop_Conditions>
@@ -135,11 +139,11 @@ Pipeline state should use `current_phase` values that match the same phase names
 </Escalation_And_Stop_Conditions>
 
 <Final_Checklist>
-- [ ] Phase `ralplan` produced/updated approved planning artifacts
-- [ ] Phase `ralph` implemented and verified the plan with fresh evidence
+- [ ] Phase `blueprint` produced/updated approved planning artifacts
+- [ ] Phase `forge` implemented and verified the plan with fresh evidence
 - [ ] Phase `code-review` returned a clean verdict (`APPROVE` + `CLEAR`)
-- [ ] `review_verdict.clean` is true and `return_to_ralplan_reason` is null
-- [ ] Tests/build/lint/typecheck evidence from Ralph is available in handoff artifacts
+- [ ] `review_verdict.clean` is true and `return_to_blueprint_reason` is null
+- [ ] Tests/build/lint/typecheck evidence from Forge is available in handoff artifacts
 - [ ] Autopilot state is marked `complete` or cancellation state is preserved coherently
 - [ ] User receives a concise summary with plan, implementation, verification, and review evidence
 </Final_Checklist>
@@ -147,17 +151,20 @@ Pipeline state should use `current_phase` values that match the same phase names
 <Examples>
 <Good>
 User: `$autopilot implement GitHub issue #42`
-Flow: create/load context snapshot -> `$ralplan` issue plan -> `$ralph` implementation + tests -> `$code-review`; if review requests changes, return to `$ralplan` with findings.
+Flow: create/load context snapshot -> `$blueprint` issue plan -> `$forge` implementation + tests -> `$code-review`; if review requests changes, return to `$blueprint` with findings.
 </Good>
 
 <Good>
 User: `continue`
 Context: Autopilot state says `current_phase:"code-review"`.
-Flow: run `$code-review` on current diff, persist verdict, finish if clean or transition to `ralplan` with findings if not clean.
+Flow: run `$code-review` on current diff, persist verdict, finish if clean or transition to `blueprint` with findings if not clean.
 </Good>
 
 <Bad>
 Autopilot invents independent "Expansion", "QA", and "Validation" phases and treats them as the primary lifecycle.
-Why bad: this bypasses the strict `$ralplan -> $ralph -> $code-review` contract.
+Why bad: this bypasses the strict `$blueprint -> $forge -> $code-review` contract.
 </Bad>
 </Examples>
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/autoresearch/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: autoresearch
 description: Stateful validator-gated research loop with native-hook persistence
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Autoresearch
@@ -9,7 +13,7 @@ Autoresearch is the skill-first replacement for the deprecated `rcs autoresearch
 It keeps the useful measured-research loop, but it now runs as a native-hook stateful workflow instead of a direct CLI or tmux launch surface.
 
 ## Use when
-- You want a Ralph-ish persistent research loop
+- You want a Forge-like persistent research loop
 - The task should keep nudging until explicit validation evidence exists
 - You want init-time choice between script validation and prompt+architect validation
 
@@ -66,3 +70,6 @@ The completion artifact must include both an architect approval verdict and an o
 - No direct CLI launch.
 - No tmux split-pane launch.
 - No noop-count completion gate.
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"