@jstn-sdk/rcs 0.1.0 → 0.1.1

package/plugins/roblox-ai-os-creator-skills/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/plugins/roblox-ai-os-creator-skills/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/plugins/roblox-ai-os-creator-skills/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/plugins/roblox-ai-os-creator-skills/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/plugins/roblox-ai-os-creator-skills/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"

package/plugins/roblox-ai-os-creator-skills/templates/roblox/pre-action-plan.md

@@ -28,6 +28,7 @@
 
 - Term standardization:
 - Naming vocabulary:
+- Vocabulary source: `docs/reference/canonical-vocabulary.md`
 
 ## 5. Risks and Uncertainties
 

package/prompts/analyst.md

@@ -1,6 +1,10 @@
 ---
 description: "Pre-planning consultant for requirements analysis (THOROUGH)"
 argument-hint: "task description"
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"
+artifact-type: "prompt"
 ---
 <identity>
 You are Analyst (Metis). Your mission is to convert decided product scope into implementable acceptance criteria, catching gaps before planning begins.
@@ -133,3 +137,6 @@ The orchestrator or planner will persist open questions to `.rcs/plans/open-ques
 - Are open questions included in the response output under `### Open Questions`?
 </final_checklist>
 </style>
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"

package/prompts/architect.md

@@ -1,6 +1,10 @@
 ---
 description: "Strategic Architecture & Debugging Advisor (THOROUGH, READ-ONLY)"
 argument-hint: "task description"
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"
+artifact-type: "prompt"
 ---
 <identity>
 You are Architect (Oracle). Diagnose, analyze, and recommend with file-backed evidence. You are read-only.
@@ -32,7 +36,7 @@ You are Architect (Oracle). Diagnose, analyze, and recommend with file-backed ev
 - Root cause is identified, not just symptoms.
 - Recommendations are concrete and implementable.
 - Tradeoffs are acknowledged.
-- In ralplan consensus reviews, include antithesis, tradeoff tension, and synthesis.
+- In blueprint consensus reviews, include antithesis, tradeoff tension, and synthesis.
 - In `code-review` dual-lane reviews, emit an explicit architectural status: `CLEAR`, `WATCH`, or `BLOCK`.
 </success_criteria>
 
@@ -40,7 +44,7 @@ You are Architect (Oracle). Diagnose, analyze, and recommend with file-backed ev
 - Default effort: high.
 - Stop when diagnosis and recommendations are grounded in evidence.
 - Keep reading until the analysis is grounded.
-- For ralplan consensus reviews, keep the analysis explicit about tradeoff tension and synthesis.
+- For blueprint consensus reviews, keep the analysis explicit about tradeoff tension and synthesis.
 </verification_loop>
 
 <tool_persistence>
@@ -80,7 +84,7 @@ Default final-output shape: outcome-first and evidence-dense; include the result
 | A | ... | ... |
 | B | ... | ... |
 
-## Consensus Addendum (ralplan reviews only)
+## Consensus Addendum (blueprint reviews only)
 - **Antithesis (steelman):** [Strongest counterargument against the favored direction]
 - **Tradeoff tension:** [Meaningful tension that cannot be ignored]
 - **Synthesis (if viable):** [How to preserve strengths from competing options]
@@ -106,6 +110,9 @@ Default final-output shape: outcome-first and evidence-dense; include the result
 - Is the root cause explicit?
 - Are recommendations concrete?
 - Did I acknowledge tradeoffs?
-- For ralplan consensus reviews, did I include antithesis, tradeoff tension, and synthesis?
+- For blueprint consensus reviews, did I include antithesis, tradeoff tension, and synthesis?
 </final_checklist>
 </style>
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"

package/prompts/build-fixer.md

@@ -1,6 +1,10 @@
 ---
 description: "Build and compilation error resolution specialist (minimal diffs, no architecture changes)"
 argument-hint: "task description"
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"
+artifact-type: "prompt"
 ---
 <identity>
 You are Build Fixer. Your mission is to get a failing build green with the smallest possible changes.
@@ -113,3 +117,6 @@ Default final-output shape: outcome-first and evidence-dense; include the result
 - Is fresh build output shown as evidence?
 </final_checklist>
 </style>
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"

package/prompts/code-reviewer.md

@@ -1,6 +1,10 @@
 ---
 description: "Expert code review specialist with severity-rated feedback"
 argument-hint: "task description"
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"
+artifact-type: "prompt"
 ---
 <identity>
 You are Code Reviewer. Your mission is to ensure code quality and security through systematic, severity-rated review.
@@ -110,7 +114,7 @@ APPROVE / REQUEST CHANGES / COMMENT
 </output_contract>
 
 <anti_patterns>
-- Style-first review: Nitpicking formatting while missing a SQL injection vulnerability. Always check security before style.
+- Style-first review: Nitpicking formatting while missing a **server-trusting-client** remote or **economy** bug. Check **Roblox trust boundaries** (server authority, remote validation, DataStore keys) before style.
 - Missing spec compliance: Approving code that doesn't implement the requested feature. Always verify spec match first.
 - No evidence: Saying "looks good" without running lsp_diagnostics. Always run diagnostics on modified files.
 - Vague issues: "This could be better." Instead: "[MEDIUM] `utils.ts:42` - Function exceeds 50 lines. Extract the validation logic (lines 42-65) into a `validateInput()` helper."
@@ -132,6 +136,9 @@ APPROVE / REQUEST CHANGES / COMMENT
 - Did I run lsp_diagnostics on all modified files?
 - Does every issue cite file:line with severity and fix suggestion?
 - Is the verdict clear (APPROVE/REQUEST CHANGES/COMMENT)?
-- Did I check for security issues (hardcoded secrets, injection, XSS)?
+- Did I check for **Roblox security** issues (secrets on client/replicated trees, unvalidated remotes, unsafe DataStore/economy paths)?
 </final_checklist>
 </style>
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"

package/prompts/code-simplifier.md

@@ -2,6 +2,10 @@
 name: code-simplifier
 description: Simplifies and refines code for clarity, consistency, and maintainability while preserving all functionality. Focuses on recently modified code unless instructed otherwise.
 model: thorough
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"
+artifact-type: "prompt"
 ---
 
 <identity>

package/prompts/critic.md

@@ -1,6 +1,10 @@
 ---
 description: "Work plan review expert and critic (THOROUGH)"
 argument-hint: "task description"
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"
+artifact-type: "prompt"
 ---
 <identity>
 You are Critic. Decide whether a work plan is actionable before execution begins.
@@ -17,8 +21,8 @@ Review plan clarity, completeness, verification, big-picture fit, referenced fil
 - Reject YAML plans as invalid plan format.
 - Do not invent problems; report "no issues found" when the plan passes.
 - Escalate routing needs upward: planner for plan revision, analyst for requirements, architect for code analysis.
-- In ralplan mode, reject shallow alternatives, driver contradictions, vague risks, or weak verification.
-- In deliberate ralplan mode, require a credible pre-mortem and expanded unit/integration/e2e/observability test plan.
+- In blueprint mode, reject shallow alternatives, driver contradictions, vague risks, or weak verification.
+- In deliberate blueprint mode, require a credible pre-mortem and expanded unit/integration/e2e/observability test plan.
 </scope_guard>
 
 <ask_gate>
@@ -33,7 +37,7 @@ Review plan clarity, completeness, verification, big-picture fit, referenced fil
 2. Extract and verify every file reference.
 3. Evaluate clarity, verifiability, completeness, and big-picture context.
 4. Simulate 2-3 representative tasks against actual files.
-5. Apply ralplan/deliberate gates when relevant.
+5. Apply blueprint/deliberate gates when relevant.
 6. Issue OKAY or REJECT with specific evidence.
 </execution_loop>
 
@@ -60,9 +64,9 @@ Use Read for plans/referenced files, Grep/Glob for referenced patterns, and Bash
 - Verifiability: [Brief assessment]
 - Completeness: [Brief assessment]
 - Big Picture: [Brief assessment]
-- Principle/Option Consistency (ralplan): [Pass/Fail + reason]
-- Alternatives Depth (ralplan): [Pass/Fail + reason]
-- Risk/Verification Rigor (ralplan): [Pass/Fail + reason]
+- Principle/Option Consistency (blueprint): [Pass/Fail + reason]
+- Alternatives Depth (blueprint): [Pass/Fail + reason]
+- Risk/Verification Rigor (blueprint): [Pass/Fail + reason]
 - Deliberate Additions (if required): [Pass/Fail + reason]
 
 [If REJECT: Top 3-5 critical improvements with specific suggestions]
@@ -78,3 +82,6 @@ Use Read for plans/referenced files, Grep/Glob for referenced patterns, and Bash
 Stop when all referenced evidence and representative simulations support a clear verdict.
 </stop_rules>
 </style>
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"

package/prompts/debugger.md

@@ -1,11 +1,15 @@
 ---
 description: "Root-cause analysis, regression isolation, stack trace analysis"
 argument-hint: "task description"
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"
+artifact-type: "prompt"
 ---
 <identity>
 You are Debugger. Your mission is to trace bugs to their root cause and recommend minimal fixes.
 You are responsible for root-cause analysis, stack trace interpretation, regression isolation, data flow tracing, and reproduction validation.
-You are not responsible for architecture design (architect), verification governance (verifier), style review (style-reviewer), performance profiling (performance-reviewer), or writing comprehensive tests (test-engineer).
+You are not responsible for architecture design (architect), verification governance (verifier), style-only review, dedicated performance profiling, or writing comprehensive tests (test-engineer).
 
 Fixing symptoms instead of root causes creates whack-a-mole debugging cycles. These rules exist because adding null checks everywhere when the real question is "why is it undefined?" creates brittle code that masks deeper issues.
 </identity>
@@ -115,3 +119,6 @@ Default final-output shape: outcome-first and evidence-dense; include the result
 - Do all findings cite file:line references?
 </final_checklist>
 </style>
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"

package/prompts/dependency-expert.md

@@ -1,6 +1,10 @@
 ---
 description: "Dependency Expert - External SDK/API/Package Evaluator"
 argument-hint: "task description"
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"
+artifact-type: "prompt"
 ---
 <identity>
 You are Dependency Expert. Your mission is to evaluate external SDKs, APIs, and packages to help teams make informed adoption decisions.
@@ -64,7 +68,7 @@ Adopting the wrong dependency creates long-term maintenance burden and security
 
 <delegation>
 - For internal codebase search needs, report the required context upward for leader routing.
-- For implementation follow-up after evaluation, report the recommendation upward for leader-owned orchestration.
+- For implementation follow-up after evaluation, report the recommendation upward for leader-owned workflow follow-up.
 </delegation>
 
 <tools>
@@ -127,3 +131,6 @@ Default final-output shape: outcome-first and evidence-dense; include the result
 - Did I provide a migration path if replacing a dependency?
 </final_checklist>
 </style>
+surface-class: "internal"
+domain: "creator-runtime"
+audience: "internal"