@jstn-sdk/rcs 0.1.0 → 0.1.1

package/skills/team/SKILL.md

@@ -1,11 +1,15 @@
 ---
 name: team
-description: N coordinated agents on shared task list using tmux-based orchestration
+description: N coordinated agents on a shared task list using tmux-based crew execution
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Team Skill
 
-`$team` is the tmux-based parallel execution mode for RCS. It starts real worker Codex and/or Claude CLI sessions in split panes and coordinates them through `.rcs/state/team/...` files plus CLI team interop (`rcs team api ...`) and state files.
+`$team` is the tmux-based parallel crew execution mode for RCS. It starts real worker Codex and/or Claude CLI sessions in split panes and coordinates them through `.rcs/state/team/...` files plus CLI team interop (`rcs team api ...`) and state files.
 
 This skill is operationally sensitive. Treat it as an operator workflow, not a generic prompt pattern. In Codex App or plain outside-tmux sessions, do not present `$team` / `rcs team` as directly available; launch RCS CLI from shell first, or stay on the nearest app-safe surface until the user explicitly wants the tmux runtime.
 
@@ -13,7 +17,7 @@ This skill is operationally sensitive. Treat it as an operator workflow, not a g
 
 - Use **Codex native subagents** for bounded, in-session parallelism where one leader thread can fan out a few independent subtasks and wait for them directly.
 - Use **`rcs team`** when you need durable tmux workers, shared task state, mailbox/dispatch coordination, worktrees, explicit lifecycle control, or long-running parallel execution that must survive beyond one local reasoning burst.
-- Native subagents can complement team/ralph execution, but they do **not** replace the tmux team runtime's stateful coordination contract.
+- Native subagents can complement team/forge execution, but they do **not** replace the tmux team runtime's stateful coordination contract.
 
 ## What This Skill Must Do
 
@@ -50,12 +54,11 @@ rcs team "ship end-to-end fix with verification"
 
 `rcs team ...` is now the canonical launch path for coordinated execution.
 Team mode should carry its own parallel delivery + verification lanes without
-requiring a separate linked Ralph launch up front.
+requiring a separate linked Forge launch up front.
 
 - **Canonical launch:** use plain `rcs team ...` / `$team ...` for coordinated workers.
 - **Verification ownership:** keep one lane focused on tests, regression coverage, and evidence before shutdown.
-- **Escalation:** start a separate `rcs ralph ...` / `$ralph ...` only when a later manual follow-up still needs a persistent single-owner fix/verification loop.
-- **Deprecation:** `rcs team ralph ...` has been removed. Use plain `rcs team ...` for team execution or run `rcs ralph ...` separately when you explicitly want a later Ralph loop.
+- **Escalation:** start a separate `rcs forge ...` / `$forge ...` only when a later manual follow-up still needs a persistent single-owner fix/verification loop.
 
 ### Claude teammates (v0.6.0+)
 
@@ -114,13 +117,13 @@ For simple read-only brownfield lookups during intake, follow active session gui
 
 ## Follow-up Staffing Contract
 
-When `$team` is used as a follow-up mode from ralplan, carry forward the approved plan's explicit **available-agent-types roster** and convert it into concrete staffing guidance before launch:
+When `$team` is used as a follow-up mode from blueprint, carry forward the approved plan's explicit **available-agent-types roster** and convert it into concrete staffing guidance before launch:
 
 - keep worker-role choices inside the known roster
 - state the recommended headcount and role counts
 - state the suggested reasoning level for each lane when available
 - explain why each lane exists (delivery, verification, specialist support)
-- include an explicit launch hint (`rcs team N "<task>"` / `$team N "<task>"`) for the coordinated team run; mention a later separate Ralph follow-up only when genuinely needed
+- include an explicit launch hint (`rcs team N "<task>"` / `$team N "<task>"`) for the coordinated team run; mention a later separate Forge follow-up only when genuinely needed
 - if the ideal role is unavailable, choose the closest role from the roster and say so
 
 ## Current Runtime Behavior (As Implemented)
@@ -229,7 +232,7 @@ To avoid brittle behavior, **message/task delivery must not be driven by ad-hoc
 
 Required default path:
 
-1. Use `rcs team ...` runtime lifecycle commands for orchestration.
+1. Use `rcs team ...` runtime lifecycle commands for crew execution.
 2. Use `rcs team api ... --json` for mailbox/task mutations.
 3. Verify delivery via mailbox/state evidence (`mailbox/*.json`, task status, `rcs team status`).
 
@@ -470,13 +473,13 @@ Do not claim success without file/pane evidence.
 Do not claim clean completion if shutdown occurred with `in_progress>0`.
 Use `rcs sparkshell --tmux-pane ...` as an explicit opt-in operator aid for pane inspection and summaries; keep raw `tmux capture-pane` evidence available for manual intervention and proof.
 
-## Programmatic Team Orchestration
+## Programmatic Team Execution
 
 Use the `rcs team ...` CLI as the supported team-launch surface. For automation, drive the same CLI flow from scripts or supervising agents rather than relying on a separate MCP runner.
 
 ### Supported current surfaces
 
-- **`rcs team ...` CLI** — Primary method for interactive or automated team orchestration. Use this when you want direct tmux-pane visibility or a scriptable launch path.
+- **`rcs team ...` CLI** — Primary method for interactive or automated team execution. Use this when you want direct tmux-pane visibility or a scriptable launch path.
 - **Team state files** — Inspect `.rcs/state/team/<team>/` when you need status, task, or mailbox evidence after launch.
 
 ### Cleanup distinction
@@ -508,3 +511,6 @@ Two cleanup paths exist and must not be confused:
 **Good:** The user changes only the output shape or downstream delivery step (for example `make a PR`). Preserve earlier non-conflicting workflow constraints and apply the update locally.
 
 **Bad:** The user says `continue`, and the workflow restarts discovery or stops before the missing verification/evidence is gathered.
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/trace/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: trace
 description: Show agent flow trace timeline and summary
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Agent Flow Trace
@@ -31,3 +35,6 @@ Present the timeline first, then the summary. Highlight:
 - **Mode transitions** (how execution modes changed)
 - **Bottlenecks** (slow tools or agents)
 - **Flow patterns** (keyword -> skill -> agent chains)
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/ultraqa/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: ultraqa
 description: QA cycling workflow - test, verify, fix, repeat until goal met
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # UltraQA Skill
@@ -15,7 +19,7 @@ Use the shared workflow guidance pattern: outcome-first framing, concise visible
 
 You are now in **ULTRAQA** mode - an autonomous QA cycling workflow that runs until your quality goal is met.
 
-**Cycle**: qa-tester → architect verification → fix → repeat
+**Cycle**: test-engineer → architect verification → fix → repeat
 
 ## Goal Parsing
 
@@ -41,9 +45,9 @@ If no structured goal provided, interpret the argument as a custom goal.
    - `--lint`: Run the project's lint command
    - `--typecheck`: Run the project's type check command
    - `--custom`: Run appropriate command and check for pattern
-   - `--interactive`: Use qa-tester for interactive CLI/service testing:
+   - `--interactive`: Use test-engineer for interactive runtime testing:
      ```
-     delegate(role="qa-tester", tier="STANDARD", task="TEST:
+     delegate(role="test-engineer", tier="STANDARD", task="TEST:
      Goal: [describe what to verify]
      Service: [how to start]
      Test cases: [specific scenarios to verify]")
@@ -141,3 +145,6 @@ Use MCP state cleanup rather than deleting files directly.
 ---
 
 Begin ULTRAQA cycling now. Parse the goal and start cycle 1.
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/ultrawork/SKILL.md

@@ -1,25 +1,29 @@
 ---
 name: ultrawork
 description: Parallel execution engine for high-throughput task completion
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 <Purpose>
-Ultrawork is a parallel execution engine for high-throughput task completion. It is a component, not a standalone persistence mode: it provides parallelism, context discipline, and smart delegation guidance, but not Ralph's persistence loop, architect sign-off, or long-running completion guarantees.
+Ultrawork is a parallel execution engine for high-throughput task completion. It is a component, not a standalone persistence mode: it provides parallelism, context discipline, and smart delegation guidance, but not Forge's persistent completion loop, architect sign-off, or long-running completion guarantees.
 </Purpose>
 
 <Use_When>
 - Multiple independent tasks can run simultaneously
 - User says "ulw", "ultrawork", or explicitly wants parallel execution
 - Task benefits from concurrent execution plus lightweight evidence before wrap-up
-- You need a direct-tool lane plus optional background evidence lanes without entering Ralph
+- You need a direct-tool lane plus optional background evidence lanes without entering Forge
 </Use_When>
 
 <Do_Not_Use_When>
-- Task requires guaranteed completion with persistence, architect verification, or deslop/reverification -- use `ralph` instead (Ralph includes ultrawork)
-- Task requires a full autonomous pipeline -- use `autopilot` instead (autopilot includes Ralph which includes ultrawork)
+- Task requires guaranteed completion with persistence, architect verification, or deslop/reverification -- use `forge` instead (Forge includes ultrawork)
+- Task requires a full autonomous pipeline -- use `autoforge` / `autopilot` instead (Autoforge includes Forge which includes ultrawork)
 - There is only one sequential task with no parallelism opportunity -- execute directly or delegate to a single `executor`
-- The request is still in plan-consensus mode -- keep planning artifacts in `ralplan` until execution is explicitly authorized
-- User needs session persistence for resume -- use `ralph`, which adds persistence on top of ultrawork
+- The request is still in plan-consensus mode -- keep planning artifacts in `blueprint` until execution is explicitly authorized
+- User needs session persistence for resume -- use `forge`, which adds persistence on top of ultrawork
 </Do_Not_Use_When>
 
 <Why_This_Exists>
@@ -138,8 +142,8 @@ Why bad: No verification output, no acceptance evidence, and no manual QA note w
 </Examples>
 
 <Escalation_And_Stop_Conditions>
-- When ultrawork is invoked directly (not via Ralph), apply lightweight verification only -- build/typecheck passes when relevant, affected tests pass, and manual QA notes are captured when needed.
-- Ralph owns persistence, architect verification, deslop, and the full verified-completion promise. Do not claim those guarantees from direct ultrawork alone.
+- When ultrawork is invoked directly (not via Forge), apply lightweight verification only -- build/typecheck passes when relevant, affected tests pass, and manual QA notes are captured when needed.
+- Forge owns persistence, architect verification, deslop, and the full verified-completion promise. Do not claim those guarantees from direct ultrawork alone.
 - If a task fails repeatedly across retries, report the issue rather than retrying indefinitely.
 - Escalate to the user when tasks have unclear dependencies, conflicting requirements, or a materially branching acceptance target.
 </Escalation_And_Stop_Conditions>
@@ -159,17 +163,20 @@ Why bad: No verification output, no acceptance evidence, and no manual QA note w
 ## Relationship to Other Modes
 
 ```
-ralph (persistence + verified completion wrapper)
+forge (persistence + verified completion wrapper)
  \-- includes: ultrawork (this skill)
      \-- provides: high-throughput execution + lightweight evidence
 
-autopilot (autonomous execution)
- \-- includes: ralph
+autoforge / autopilot (autonomous execution)
+ \-- includes: forge
      \-- includes: ultrawork (this skill)
 
 ecomode (token efficiency)
  \-- modifies: ultrawork's model selection
 ```
 
-Ultrawork is the parallelism and execution-discipline layer. Ralph adds persistence, architect verification, deslop, and retry-until-done behavior. Autopilot adds the broader autonomous lifecycle pipeline. Ecomode adjusts ultrawork's model routing to favor cheaper models.
+Ultrawork is the parallelism and execution-discipline layer. Forge adds persistence, architect verification, deslop, and retry-until-done behavior. Autoforge adds the broader autonomous lifecycle pipeline. Ecomode adjusts ultrawork's model routing to favor cheaper models.
 </Advanced>
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/{visual-ralph → visual-forge}/SKILL.md

@@ -1,25 +1,31 @@
 ---
-name: visual-ralph
-description: "Visual Ralph orchestration for frontend UI from generated references, static references, or live URL targets, using $ralph with $visual-verdict and pixel-diff evidence until the implementation matches and leaves a reproducible design system."
+name: visual-forge
+description: "Compatibility visual-delivery runtime for Roblox creator UI, HUD, and plugin work; the canonical completion owner is now Forge."
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
-# Visual Ralph Skill
+# Visual Forge Skill
 
-Use this skill when the user wants Codex to build or restyle frontend UI through a Visual Ralph loop: an approved generated reference, static reference, or live URL-derived baseline becomes the target, Ralph implements, and Visual Verdict drives measured iteration rather than subjective description alone.
+Legacy compatibility surface. Public creator language should prefer **Visual Forge** concepts and `$forge` as the persistent implementation owner.
+
+Use this skill when the user wants Codex to build or restyle Roblox creator UI through a compatibility visual-delivery loop: an approved generated reference, static reference, or captured inspiration baseline becomes the target, Forge implements, and Visual Verdict drives measured iteration rather than subjective description alone.
 
 ## Purpose
 
-Create a measured frontend delivery loop from either a generated reference, a static reference, or a live URL:
+Create a measured Roblox UI delivery loop from either a generated reference, a static reference, or a captured inspiration baseline:
 
-`user description / live URL -> approved visual reference -> $ralph implementation -> $visual-verdict + pixel diff -> reproducible design system`.
+`creator brief / captured reference -> approved visual source of truth -> $forge implementation -> $visual-verdict + pixel diff -> reusable Studio-native design layer`.
 
-For live URL cloning requests, Visual Ralph owns the migrated `$web-clone` use case. Do not route new URL-driven website cloning work to `$web-clone`; preserve the URL, viewport, fidelity requirements, and interaction notes inside the Visual Ralph loop.
+If a user brings an external website or app screenshot as inspiration, treat it only as a visual reference source for a Roblox HUD, menu, storefront, onboarding screen, or Studio plugin panel. Do not drift into generic website-cloning language or stack assumptions.
 
-This is an orchestration skill. It composes existing skills and must not add runtime commands, dependencies, or app-specific assumptions by itself.
+This is a workflow-composition skill. It composes existing skills and must not add runtime commands, dependencies, or app-specific assumptions by itself.
 
 ## Use when
 
-- The user describes a desired web/app UI and wants implementation, not just design advice.
+- The user describes a desired creator HUD, menu, storefront, launcher page, or companion UI and wants implementation, not just design advice.
 - The user provides a live URL and wants a visual implementation or clone through measured Visual Verdict iteration.
 - A generated raster mockup/reference image would make the target clearer.
 - The task needs pixel-level visual iteration with a pass/fail threshold.
@@ -27,9 +33,9 @@ This is an orchestration skill. It composes existing skills and must not add run
 
 ## Do not use when
 
-- The user only wants design critique or general frontend advice; use `$frontend-ui-ux` or a designer lane.
-- The task is a non-visual backend/API implementation with no UI reference target.
-- The user already supplied a final static reference image and only needs comparison/fixes; hand directly to `$ralph` with `$visual-verdict` guidance.
+- The user only wants design critique or general creator UI advice; use a designer lane.
+- The task is a non-visual gameplay/runtime implementation with no UI reference target.
+- The user already supplied a final static reference image and only needs comparison/fixes; hand directly to `$forge` with `$visual-verdict` guidance.
 - The requested output is a deterministic SVG/vector/code-native asset rather than a raster reference.
 
 ## Workflow
@@ -37,24 +43,24 @@ This is an orchestration skill. It composes existing skills and must not add run
 ### 1. Ground the target repo
 
 Before stack-specific choices, inspect local evidence:
-- package manager and scripts,
-- frontend framework and routing structure,
-- styling system and design-token conventions,
+- ScreenGui / plugin widget hierarchy,
+- Roact / ReactLua / Fusion usage,
+- styling/token conventions,
 - screenshot/test tooling,
-- existing components that should be reused.
+- existing HUD/menu/panel components that should be reused.
 
-Do not hardcode React, Vue, Tailwind, Playwright, or any other stack unless the repository evidence supports it.
+Do not hardcode React web assumptions, Tailwind, router concepts, or website-specific stacks unless the repository evidence actually supports an off-Studio surface.
 
 ### 2. Establish the visual reference
 
-For live URL requests, capture or document the URL-derived reference inside the Visual Ralph artifacts and carry forward viewport, content-state, and interaction constraints. Do not invoke `$web-clone`; that standalone skill is hard-deprecated.
+If external inspiration is used, capture or document that reference inside the visual-delivery artifacts and carry forward the relevant viewport, content-state, and interaction constraints. Do not invoke `$web-clone`; that standalone skill is hard-deprecated.
 
 Live URL reference artifacts must include:
 - source URL and permission/scope note,
 - viewport(s), route/state, and any seed/login assumptions,
 - captured baseline screenshot path or documented capture command/tool,
 - interaction parity notes for visible controls,
-- known exclusions such as backend/API/auth, personalized data, multi-page crawling, and third-party widget parity.
+- known exclusions such as server/account plumbing, personalized data, multi-page crawling, and third-party widget parity.
 
 For generated UI concepts, use `$imagegen` to produce the reference from the user's UI description.
 
@@ -65,30 +71,30 @@ Prompt requirements:
 - forbid logos/watermarks/unrequested brand marks,
 - ask imagegen to avoid impossible UI details or unreadable text.
 
-For project-bound implementation, copy the approved reference into the workspace, for example under `.rcs/artifacts/visual-ralph/<slug>/reference.png`. Never leave the implementation reference only in `$CODEX_HOME/generated_images/...`.
+For project-bound implementation, copy the approved reference into the workspace, for example under `.rcs/artifacts/visual-forge/<slug>/reference.png`. Never leave the implementation reference only in `$CODEX_HOME/generated_images/...`.
 
 ### 3. Require explicit user approval
 
 Stop after reference generation or URL-derived reference capture and ask the user to approve one reference image/state or request a targeted regeneration/capture adjustment.
 
 Before approval:
-- do not start frontend implementation,
-- do not invoke `$ralph`,
+- do not start UI implementation,
+- do not invoke `$forge`,
 - do not treat a rough image as final.
 
 After approval, the confirmed image or URL-derived baseline becomes the visual source of truth. Major design pivots, replacing the reference, or changing the design direction require an explicit user request.
 
-### 4. Hand off to `$ralph` for implementation
+### 4. Hand off to `$forge` for implementation
 
-Invoke `$ralph` with:
+Invoke `$forge` with:
 - the approved reference image path or URL-derived baseline artifact,
 - source URL, viewport(s), content state, and interaction parity notes for live URL tasks,
 - the user description,
-- the detected repo/frontend context,
+- the detected repo/UI-stack context,
 - exact screenshot command/viewport requirements,
 - the completion checklist below.
 
-Ralph may iterate autonomously after approval. It should edit code, run the app, capture screenshots, and keep improving until the approved reference is matched or a real blocker exists.
+Forge may iterate autonomously after approval. It should edit code, run the app, capture screenshots, and keep improving until the approved reference is matched or a real blocker exists.
 
 ### 5. Use `$visual-verdict` before every next edit
 
@@ -136,7 +142,7 @@ Do not declare done until all are true:
 ## Handoff template
 
 ```text
-$ralph "Implement the approved frontend reference.
+$forge "Implement the approved Roblox creator UI reference.
 Reference: <workspace-reference-image-or-url-derived-artifact>
 Source URL (if URL-derived): <url and permission/scope note>
 Viewport/content state: <viewport, route/state, seed/login assumptions>
@@ -151,3 +157,6 @@ Do not make major design pivots unless explicitly requested."
 ```
 
 Task: {{ARGUMENTS}}
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/visual-verdict/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: visual-verdict
 description: Structured visual QA verdict for screenshot-to-reference comparisons
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 <Purpose>
@@ -16,7 +20,7 @@ Use this skill to compare generated UI screenshots against one or more reference
 <Inputs>
 - `reference_images[]` (one or more image paths)
 - `generated_screenshot` (current output image)
-- Optional: `category_hint` (e.g., `hackernews`, `sns-feed`, `dashboard`)
+- Optional: `category_hint` (e.g., `hackernews`, `sns-feed`, `studio-widget`)
 </Inputs>
 
 <Output_Contract>
@@ -44,7 +48,7 @@ Rules:
 <Threshold_And_Loop>
 - Target pass threshold is **90+**.
 - If `score < 90`, continue editing and rerun `$visual-verdict` before any further code edits in the next iteration.
-- Persist the verdict in `.rcs/state/{scope}/ralph-progress.json` with both:
+- Persist the verdict in `.rcs/state/{scope}/forge-progress.json` with both:
   - numeric signal (`score`, threshold pass/fail)
   - qualitative signal (`reasoning`, `suggestions`, `next_actions`)
 </Threshold_And_Loop>
@@ -74,3 +78,6 @@ When mismatch diagnosis is hard:
 }
 ```
 </Example>
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/web-clone/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: web-clone
-description: "DEPRECATED: URL-driven website cloning has moved into $visual-ralph; use $visual-ralph for live-URL visual implementation workflows."
+description: "DEPRECATED: URL-driven website cloning has moved into $visual-forge; use $visual-forge for live-URL visual implementation workflows."
+surface-class: "historical"
+domain: "archive"
+audience: "archive"
+artifact-type: "skill"
 ---
 
 # Web Clone Skill (Hard Deprecated)
@@ -9,16 +13,19 @@ description: "DEPRECATED: URL-driven website cloning has moved into $visual-ralp
 
 ## Migration
 
-Use `$visual-ralph` for the migrated live-URL use case. Visual Ralph now owns URL-driven visual implementation loops alongside generated-image and static-reference workflows:
+Use `$visual-forge` for the migrated live-URL use case. Visual Forge now owns URL-driven visual implementation loops alongside generated-image and static-reference workflows:
 
-- live URL or website cloning request -> `$visual-ralph`
-- generated mockup/reference request -> `$visual-ralph` with `$imagegen`
-- static screenshot/reference comparison -> `$ralph` with `$visual-verdict`
+- live URL or website cloning request -> `$visual-forge`
+- generated mockup/reference request -> `$visual-forge` with `$imagegen`
+- static screenshot/reference comparison -> `$forge` with `$visual-verdict`
 
 ## Behavior
 
-If this skill is selected by older routing, stop the standalone web-clone pipeline and reroute the task to `$visual-ralph` instead. Preserve the user's target URL, fidelity requirements, viewport constraints, and functional parity notes in the Visual Ralph handoff.
+If this skill is selected by older routing, stop the standalone web-clone pipeline and reroute the task to `$visual-forge` instead. Preserve the user's target URL, fidelity requirements, viewport constraints, and functional parity notes in the Visual Forge handoff.
 
 ## Rationale
 
-The URL extraction, visual iteration, and implementation verification responsibilities are now part of Visual Ralph's broader visual-delivery workflow. Keeping a second standalone cloning skill would split guidance and make verification behavior drift.
+The URL extraction, visual iteration, and implementation verification responsibilities are now part of Visual Forge's broader visual-delivery workflow. Keeping a second standalone cloning skill would split guidance and make verification behavior drift.
+surface-class: "historical"
+domain: "creator-runtime"
+audience: "internal"

package/skills/wiki/SKILL.md

@@ -2,6 +2,10 @@
 name: wiki
 description: Persistent markdown project wiki stored under .rcs/wiki with keyword search and lifecycle capture
 triggers: ["wiki add", "wiki lint", "wiki query", "wiki read", "wiki delete"]
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Wiki
@@ -12,12 +16,12 @@ Persistent, self-maintained markdown knowledge base for project and session know
 
 ### Ingest
 ```text
-wiki_ingest({ title: "Auth Architecture", content: "...", tags: ["auth", "architecture"], category: "architecture" })
+wiki_ingest({ title: "Economy & remotes", content: "...", tags: ["roblox", "security"], category: "architecture" })
 ```
 
 ### Query
 ```text
-wiki_query({ query: "authentication", tags: ["auth"], category: "architecture" })
+wiki_query({ query: "DataStore player profile", tags: ["roblox", "data"], category: "architecture" })
 ```
 
 ### Lint
@@ -33,7 +37,7 @@ wiki_add({ title: "Page Title", content: "...", tags: ["tag1"], category: "decis
 ### List / Read / Delete
 ```text
 wiki_list()
-wiki_read({ page: "auth-architecture" })
+wiki_read({ page: "economy-remotes" })
 wiki_delete({ page: "outdated-page" })
 wiki_refresh()
 ```
@@ -55,3 +59,6 @@ At session end, discoveries can be captured as `session-log-*` pages. Configure
 ## Hard Constraints
 - No vector embeddings — query uses keyword + tag matching only
 - Wiki files remain local project state under `.rcs/wiki/`
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/worker/SKILL.md

@@ -1,11 +1,17 @@
 ---
 name: worker
-description: Team worker protocol (ACK, mailbox, task lifecycle) for tmux-based RCS teams
+description: Compatibility worker protocol for tmux-based crew execution sessions
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"
+artifact-type: "skill"
 ---
 
 # Worker Skill
 
-This skill is for a Codex session that was started as an RCS Team worker (a tmux pane spawned by `$team`).
+> Legacy compatibility surface. Public creator language should prefer `crew` / coordinated execution terminology. This file remains the internal worker-runtime protocol surface for tmux-managed crew panes.
+
+This skill is for a Codex session that was started as a coordinated crew worker pane under `rcs team` / `$team`.
 
 ## Identity
 
@@ -15,7 +21,7 @@ You MUST be running with `RCS_TEAM_WORKER` set. It looks like:
 
 Example: `alpha/worker-2`
 
-## Load Worker Skill Path (Claude/Codex)
+## Load Crew Worker Skill Path (Claude/Codex)
 
 When a worker inbox tells you to load this skill, resolve the first existing path:
 
@@ -34,7 +40,7 @@ When a worker inbox tells you to load this skill, resolve the first existing pat
    - Body: one short deterministic line (recommended: `ACK: <workerName> initialized`).
 3. After ACK, proceed to your inbox instructions.
 
-The lead will see your message in:
+The crew lead will see your message in:
 
 `<team_state_root>/team/<teamName>/mailbox/leader-fixed.json`
 
@@ -67,7 +73,7 @@ rcs team api send-message --input "{\"team_name\":\"<teamName>\",\"from_worker\"
 8. Complete/fail the task via lifecycle transition CLI interop (`rcs team api transition-task-status --json`) from `in_progress` to `completed` or `failed`.
    - Do NOT directly write lifecycle fields (`status`, `owner`, `result`, `error`) in task files.
 9. Use `rcs team api release-task-claim --json` only for rollback/requeue to `pending` (not for completion).
-10. Update your worker status:
+10. Update your crew-worker status:
    `<team_state_root>/team/<teamName>/workers/<workerName>/status.json` with `{"state":"idle", ...}`
 
 ## Mailbox
@@ -95,7 +101,7 @@ rcs team api mailbox-mark-delivered --input "{\"team_name\":\"<teamName>\",\"wor
 
 ## Dispatch Discipline (state-first)
 
-Worker sessions should treat team state + CLI interop as the source of truth.
+Crew worker sessions should treat team state + CLI interop as the source of truth.
 
 - Prefer inbox/mailbox/task state and `rcs team api ... --json` operations.
 - Do **not** rely on ad-hoc tmux keystrokes as a primary delivery channel.
@@ -103,4 +109,7 @@ Worker sessions should treat team state + CLI interop as the source of truth.
 
 ## Shutdown
 
-If the lead sends a shutdown request, follow the shutdown inbox instructions exactly, write your shutdown ack file, then exit the Codex session.
+If the crew lead sends a shutdown request, follow the shutdown inbox instructions exactly, write your shutdown ack file, then exit the Codex session.
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"