@jstn-sdk/rcs 0.1.0 → 0.1.1

package/skills/code-review/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: code-review
 description: Run a comprehensive code review
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Code Review Skill
@@ -167,20 +171,20 @@ HIGH (0)
 
 MEDIUM (7)
 ----------
-1. src/api/auth.ts:42
-   Issue: Email normalization logic is duplicated instead of reusing the shared helper
-   Risk: Validation rules can drift between authentication paths
-   Fix: Route both paths through the shared normalization helper
+1. ServerScriptService/Economy/PurchaseHandler.server.lua:42
+   Issue: Purchase receipt validation and grant logic are split across two modules with overlapping guards
+   Risk: Server-side economy rules can drift between grant paths
+   Fix: Route both paths through one verified grant helper after ProcessReceipt validation
 
-2. src/components/UserProfile.tsx:89
-   Issue: Derived permissions are recalculated on every render
-   Risk: Avoidable work during profile refreshes
-   Fix: Memoize the derived permissions list or compute it upstream
+2. ReplicatedStorage/UI/Leaderboard.client.lua:89
+   Issue: Client recomputes rank labels on every AttributeChanged for leaderstats
+   Risk: Avoidable work during high-churn leaderstat updates
+   Fix: Debounce UI refresh or compute display strings from a small server-provided snapshot
 
-3. src/utils/validation.ts:15
-   Issue: Form-layer and server-layer validation messages are defined separately
-   Risk: User-facing validation guidance can become inconsistent
-   Fix: Share one validation message helper across both call sites
+3. ServerScriptService/Inventory/Validation.lua:15
+   Issue: Client-visible error strings and server-only validation reasons are defined separately
+   Risk: Player-facing guidance diverges from what the server actually enforces
+   Fix: Share one message table for public errors; keep detailed reasons server-only
 
 LOW (5)
 -------
@@ -208,13 +212,12 @@ Address any WATCH concerns before treating the change as merge-ready.
 
 The `code-reviewer` lane checks:
 
-### Security
-- [ ] No hardcoded secrets (API keys, passwords, tokens)
-- [ ] All user inputs sanitized
-- [ ] SQL/NoSQL injection prevention
-- [ ] XSS prevention (escaped outputs)
-- [ ] CSRF protection on state-changing operations
-- [ ] Authentication/authorization properly enforced
+### Security (Roblox experience code)
+- [ ] No hardcoded secrets or API keys in **client** or **ReplicatedStorage**; sensitive tokens only on **server**
+- [ ] **RemoteEvents / RemoteFunctions:** arguments validated server-side; no trusting client for economy, inventory, or progression
+- [ ] **DataStore / persistence:** correct key scoping; no cross-player data leaks; safe retries / no double grants
+- [ ] **Economy:** purchase / entitlement paths verified on server; idempotent grants where duplicates are possible
+- [ ] **Anti-exploit:** high-risk gameplay (combat, trade, movement) assumes malicious clients; server is source of truth
 
 ### Code Quality
 - [ ] Functions < 50 lines (guideline)
@@ -227,7 +230,7 @@ The `code-reviewer` lane checks:
 - [ ] No N+1 query patterns
 - [ ] Appropriate caching where applicable
 - [ ] Efficient algorithms (avoid O(n²) when O(n) possible)
-- [ ] No unnecessary re-renders (React/Vue)
+- [ ] No unnecessary rerender churn or repeated UI tree rebuilds in Roact/Fusion/Studio GUI flows
 
 ### Best Practices
 - [ ] Error handling present and appropriate
@@ -265,15 +268,15 @@ The `architect` lane checks:
 
 **With Team:**
 ```
-/team "review recent auth changes and report findings"
+/team "review recent economy / RemoteEvent changes and report findings"
 ```
 Includes coordinated review execution across specialized agents.
 
-**With Ralph:**
+**With Forge:**
 ```
-/ralph code-review then fix all issues
+/forge code-review then fix all issues
 ```
-On the explicit Ralph path, review findings should flow into automatic fix follow-up without another permission prompt. Plain `code-review` itself remains read-only and does **not** promise auto-fix.
+On the explicit Forge path, review findings should flow into automatic fix follow-up without another permission prompt. Plain `code-review` itself remains read-only and does **not** promise auto-fix.
 
 **With Ultrawork:**
 ```
@@ -288,3 +291,6 @@ Parallel code review across multiple files.
 - **Address CRITICAL/HIGH first** - Fix security and bugs immediately
 - **Consider context** - Some "issues" may be intentional trade-offs
 - **Learn from reviews** - Use feedback to improve coding practices
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/configure-notifications/SKILL.md

@@ -20,6 +20,10 @@ triggers:
   - "discord webhook"
   - "telegram bot"
   - "slack webhook"
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Configure RCS Notifications
@@ -285,3 +289,6 @@ Show:
 - Whether explicit `notifications.openclaw` exists (and therefore overrides aliases)
 - Verbosity + idle cooldown + reply listener state
 - Config path (`~/.codex/.rcs-config.json`)
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/crew/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: crew
 description: Canonical multi-role creator workflow surface for Roblox Creator Skills
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Crew
@@ -8,3 +12,6 @@ description: Canonical multi-role creator workflow surface for Roblox Creator Sk
 Use `$crew` when the work needs coordinated creator lanes such as systems design, economy review, social design, and implementation planning in parallel.
 
 For Roblox tasks, the crew should not fan out implementation until the shared pre-action artifact exists and `PRE_ACTION_COMPLETE` is `true`.
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/deep-interview/SKILL.md

@@ -2,6 +2,10 @@
 name: deep-interview
 description: Socratic deep interview with mathematical ambiguity gating before execution
 argument-hint: "[--quick|--standard|--deep] [--autoresearch] <idea or vague description>"
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 <Purpose>
@@ -12,7 +16,7 @@ Deep Interview is an intent-first Socratic clarification loop before planning or
 - The request is broad, ambiguous, or missing concrete acceptance criteria
 - The user says "deep interview", "interview me", "ask me everything", "don't assume", or "ouroboros"
 - The user wants to avoid misaligned implementation from underspecified requirements
-- You need a requirements artifact before handing off to `ralplan`, `autopilot`, `ralph`, or `team`
+- You need a requirements artifact before handing off to `blueprint`, `autopilot`, `forge`, or `team`
 </Use_When>
 
 <Do_Not_Use_When>
@@ -124,7 +128,7 @@ If no flag is provided, use **Standard**.
 Repeat until ambiguity `<= threshold`, the pressure pass is complete, the readiness gates are explicit, the user exits with warning, or max rounds are reached.
 
 ### 2a) Generate next question
-If the initial context is oversized and no prompt-safe summary has been recorded yet, the next question must be only a summary request. Do not score ambiguity, do not run readiness gates, and do not hand off to `$ralplan`, `$autopilot`, `$ralph`, or `$team` until that summary answer is captured.
+If the initial context is oversized and no prompt-safe summary has been recorded yet, the next question must be only a summary request. Do not score ambiguity, do not run readiness gates, and do not hand off to `$blueprint`, `$autopilot`, `$forge`, or `$team` until that summary answer is captured.
 
 Use:
 - Original idea
@@ -184,7 +188,7 @@ Canonical bounded single-choice payload:
   "options": [
     {
       "label": "Plan first",
-      "value": "ralplan",
+      "value": "blueprint",
       "description": "Need architecture and test-shape review before execution"
     },
     {
@@ -239,9 +243,9 @@ Canonical answer-shape reminders:
 {
   "answer": {
     "kind": "option",
-    "value": "ralplan",
+    "value": "blueprint",
     "selected_labels": ["Plan first"],
-    "selected_values": ["ralplan"]
+    "selected_values": ["blueprint"]
   }
 }
 ```
@@ -298,13 +302,13 @@ When threshold is met (or user exits with warning / hard cap):
 
 1. Write interview transcript summary to:
    - `.rcs/interviews/{slug}-{timestamp}.md`  
-     (kept for ralph PRD compatibility)
+     (kept for Forge PRD compatibility)
 2. Write execution-ready spec to:
    - `.rcs/specs/deep-interview-{slug}.md`
 
 Spec should include:
 - Metadata (profile, rounds, final ambiguity, threshold, context type)
-- Context snapshot reference/path (for ralplan/team reuse)
+- Context snapshot reference/path (for blueprint/team reuse)
 - Prompt-safe initial-context summary when oversized context was provided, plus references to any full source documents
 - Clarity breakdown table
 - Intent (why the user wants this)
@@ -348,14 +352,14 @@ When the clarified task is specifically about `$autoresearch`, or the skill is i
 
 Present execution options after artifact generation using explicit handoff contracts. Treat the deep-interview spec as the current requirements source of truth and preserve intent, non-goals, decision boundaries, acceptance criteria, and any residual-risk warnings across the handoff.
 
-### 1. **`$ralplan` (Recommended)**
+### 1. **`$blueprint` (Recommended)**
 - **Input Artifact:** `.rcs/specs/deep-interview-{slug}.md` (optionally accompanied by the transcript/context snapshot for traceability)
 - **Invocation:** `$plan --consensus --direct <spec-path>`
 - **Consumer Behavior:** Treat the deep-interview spec as the requirements source of truth. Do not repeat the interview by default; refine architecture/feasibility around the clarified intent and boundaries instead.
 - **Skipped / Already-Satisfied Stages:** Requirements discovery, ambiguity clarification, and early intent-boundary elicitation
 - **Expected Output:** Canonical planning artifacts under `.rcs/plans/`, especially `prd-*.md` and `test-spec-*.md`
 - **Best When:** Requirements are clear enough to stop interviewing, but architectural validation / consensus planning is still desirable
-- **Next Recommended Step:** Use the approved planning artifacts with `$autopilot`, `$ralph`, or `$team` depending on the desired execution style
+- **Next Recommended Step:** Use the approved planning artifacts with `$autopilot`, `$forge`, or `$team` depending on the desired execution style
 
 ### 2. **`$autopilot`**
 - **Input Artifact:** `.rcs/specs/deep-interview-{slug}.md`
@@ -364,25 +368,25 @@ Present execution options after artifact generation using explicit handoff contr
 - **Skipped / Already-Satisfied Stages:** Initial requirement discovery and ambiguity reduction
 - **Expected Output:** Planning/execution progress, QA evidence, and validation artifacts produced by autopilot
 - **Best When:** The clarified spec is already strong enough for direct planning + execution without an additional consensus gate
-- **Next Recommended Step:** Continue through autopilot's execution/QA/validation flow; if coordination-heavy execution emerges, prefer a follow-up `$team` or `$ralph` lane as appropriate
+- **Next Recommended Step:** Continue through autoforge/autopilot's execution/QA/validation flow; if coordination-heavy execution emerges, prefer a follow-up `$team` or `$forge` lane as appropriate
 
-### 3. **`$ralph`**
+### 3. **`$forge`**
 - **Input Artifact:** `.rcs/specs/deep-interview-{slug}.md`
-- **Invocation:** `$ralph <spec-path>`
+- **Invocation:** `$forge <spec-path>`
 - **Consumer Behavior:** Use the spec's acceptance criteria and boundary constraints as the persistence target. Do not reopen requirements discovery unless the user explicitly asks to refine further.
 - **Skipped / Already-Satisfied Stages:** Requirement interview, ambiguity clarification, and initial scope-definition work
 - **Expected Output:** Iterative execution progress and verification evidence tracked against the clarified criteria
 - **Best When:** The task benefits from persistent sequential completion pressure and the user wants execution to keep moving until the criteria are satisfied or a real blocker exists
-- **Next Recommended Step:** Continue Ralph's persistence loop; if work expands into coordination-heavy lanes, hand off to `$team` and keep Ralph for verification continuity
+- **Next Recommended Step:** Continue Forge's persistence loop; if work expands into coordination-heavy lanes, hand off to `$team` and keep Forge for verification continuity
 
 ### 4. **`$team`**
 - **Input Artifact:** `.rcs/specs/deep-interview-{slug}.md`
 - **Invocation:** `$team <spec-path>`
 - **Consumer Behavior:** Treat the spec as shared execution context for coordinated parallel work. Preserve the clarified intent, non-goals, decision boundaries, and acceptance criteria as common lane constraints.
 - **Skipped / Already-Satisfied Stages:** Requirement clarification and early ambiguity reduction
-- **Expected Output:** Coordinated multi-agent execution against the shared spec, with evidence that can later feed a Ralph verification pass when appropriate
+- **Expected Output:** Coordinated multi-agent execution against the shared spec, with evidence that can later feed a Forge verification pass when appropriate
 - **Best When:** The task is large, multi-lane, or blocker-sensitive enough to justify coordinated parallel execution instead of a single persistent loop
-- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; escalate to a separate Ralph loop only when a later persistent verification/fix owner is still needed
+- **Next Recommended Step:** Follow the team verification path when the coordinated execution phase finishes; escalate to a separate Forge loop only when a later persistent verification/fix owner is still needed
 
 ### 5. **Refine further**
 - **Input Artifact:** Existing transcript, context snapshot, and current spec draft
@@ -431,7 +435,7 @@ Present execution options after artifact generation using explicit handoff contr
 - [ ] Transcript written to `.rcs/interviews/{slug}-{timestamp}.md`
 - [ ] Spec written to `.rcs/specs/deep-interview-{slug}.md`
 - [ ] Brownfield questions use evidence-backed confirmation when applicable
-- [ ] Handoff options provided (`$ralplan`, `$autopilot`, `$ralph`, `$team`)
+- [ ] Handoff options provided (`$blueprint`, `$autopilot`, `$forge`, `$team`)
 - [ ] No direct implementation performed in this mode
 </Final_Checklist>
 
@@ -457,12 +461,15 @@ If interrupted, rerun `$deep-interview`. Resume from persisted mode state via `s
 ## Recommended 3-Stage Pipeline
 
 ```
-deep-interview -> ralplan -> autopilot
+deep-interview -> blueprint -> autopilot
 ```
 
 - Stage 1 (deep-interview): clarity gate
-- Stage 2 (ralplan): feasibility + architecture gate
+- Stage 2 (blueprint): feasibility + architecture gate
 - Stage 3 (autopilot): execution + QA + validation gate
 </Advanced>
 
 Task: {{ARGUMENTS}}
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/deepsearch/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: deepsearch
 description: Thorough codebase search
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Deep Search Mode
@@ -36,3 +40,6 @@ Perform thorough search of the codebase for the specified query, pattern, or con
 - **Key Insights** (patterns, conventions, gotchas)
 
 Focus on being comprehensive but concise. Cite file paths and line numbers.
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/doctor/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: doctor
 description: Diagnose and fix Roblox Creator Skills installation issues
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Doctor Skill
@@ -237,3 +241,6 @@ rm -rf ~/.agents/skills
 
 After applying fixes, inform user:
 > Fixes applied. **Restart Codex CLI** for changes to take effect.
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/ecomode/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: ecomode
 description: Token-efficient model routing modifier
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"
+artifact-type: "skill"
 ---
 
 # Ecomode Skill
@@ -19,7 +23,7 @@ Overrides default model selection to prefer cheaper tiers:
 
 ## What Ecomode Does NOT Do
 
-- **Persistence**: Use `ralph` for "don't stop until done"
+- **Persistence**: Use `forge` for "don't stop until done"
 - **Parallel Execution**: Use `ultrawork` for parallel agents
 - **Delegation Enforcement**: Always active via core orchestration
 
@@ -29,7 +33,7 @@ Ecomode is a modifier that combines with execution modes:
 
 | Combination | Effect |
 |-------------|--------|
-| `eco ralph` | Ralph loop with cheaper agents |
+| `eco forge` | Forge loop with cheaper agents |
 | `eco ultrawork` | Parallel execution with cheaper agents |
 | `eco autopilot` | Full autonomous with cost optimization |
 
@@ -112,3 +116,6 @@ Use `rcs_state` MCP tools for ecomode lifecycle state.
   `state_write({mode: "ecomode", active: false})`
 - **On cancellation/cleanup**:
   run `$cancel` (which should call `state_clear(mode="ecomode")`)
+surface-class: "operator"
+domain: "creator-runtime"
+audience: "operator"

package/skills/forge/SKILL.md

@@ -1,23 +1,173 @@
 ---
 name: forge
-description: Canonical creator forging surface for Roblox Creator Skills
+description: Persistent Roblox Studio execution loop that carries an approved creator plan to verified completion
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Forge
 
-Use `$forge` to generate concrete creator-facing deliverables and system specs.
+Forge is the canonical creator execution workflow in RCS.
 
-For Roblox tasks, `$forge` is gated by the pre-action protocol.
+Use `$forge` when an approved Roblox creator plan needs one owner who keeps pushing until the work is actually complete, verified, and internally consistent.
 
-Do not generate implementation code until:
-- `PRE_ACTION_COMPLETE` is `true`
-- the modular file tree exists
-- categories and naming are standardized
-- unsafe Roblox assumptions have been called out and minimized
+## Purpose
 
-If the pre-action artifact is missing, stop and produce it first using:
-- `docs/reference/roblox-pre-action-protocol.md`
-- `templates/roblox/pre-action-plan.md`
+Forge exists to finish Roblox Studio work without drifting back into generic web-enterprise habits:
+- keep the implementation grounded in Roblox services, Instance hierarchies, Luau constraints, and client/server trust boundaries
+- keep naming aligned with Roblox concepts such as `RemoteEvent`, `RemoteFunction`, `ModuleScript`, `Attribute`, `DataStore`, `CollectionService`, and `Humanoid`
+- keep verification real: play the exact changed flow, run the relevant tests/tools, and confirm the experience behavior rather than stopping at prose confidence
+
+## Use When
+
+- A `$blueprint` plan is approved and now needs implementation.
+- The task crosses multiple Roblox scripts/services and should not stop at partial completion.
+- The work needs repeated fix/verify loops: remotes, persistence, replication, economy, combat, UI state, or gameplay systems.
+- The user is effectively saying “ship this fully” or “keep going until it’s actually done.”
+
+## Do Not Use When
+
+- The task is still ambiguous. Use `$brief` or `$blueprint` first.
+- The user only wants design artifacts, loop specs, or monetization frameworks rather than code changes.
+- The task needs coordinated parallel staffing. Use `$crew`, then return to `$forge` only if a persistent single-owner closeout loop is still useful.
+
+## Roblox-Native Guardrails
+
+- Default to Luau/Studio concepts before generic backend/web abstractions.
+- Name systems by gameplay or engine behavior, not enterprise platform jargon.
+- Respect server authority:
+  - clients request
+  - servers validate
+  - servers mutate canonical state
+- Prefer concrete Roblox touchpoints in reasoning:
+  - `ServerScriptService`
+  - `ReplicatedStorage`
+  - `StarterPlayer`
+  - `StarterGui`
+  - `Workspace`
+  - `CollectionService`
+  - `MarketplaceService`
+  - `TeleportService`
+  - `DataStoreService`
+- Do not invent fake type systems or DTO-heavy ceremony when normal Luau tables, typed Luau annotations, and ModuleScripts are enough.
+- Do not import enterprise “service/repository/controller” structure by reflex when the codebase or experience model does not need it.
+
+## Execution Loop
+
+### Pre-context intake
+
+Before execution begins, create or load a context snapshot at `.rcs/context/{task-slug}-{timestamp}.md`.
+
+Minimum snapshot fields:
+- task statement
+- desired outcome
+- known facts/evidence
+- constraints
+- unknowns/open questions
+- likely codebase touchpoints
+
+If the request is still ambiguous, run `$deep-interview --quick <task>` before the implementation loop and reuse the resulting context instead of improvising from memory.
+Do not begin Forge execution work until that grounding context exists.
+
+1. Re-read the approved blueprint and extract the exact Roblox services, scripts, remotes, data tables, UI objects, and replication edges involved.
+2. Confirm the ownership split:
+   - server scripts
+   - client scripts
+   - shared ModuleScripts
+   - assets/instances/config data
+3. Implement the smallest complete vertical slice first.
+4. Re-run the most relevant proof immediately:
+   - targeted unit/test harness
+   - build/lint/typecheck where present
+   - exact gameplay/runtime path affected
+5. Continue iterating until the changed flow is green and consistent across touched files.
+6. End only after verification evidence is fresh and the touched surfaces use one coherent Roblox-native vocabulary.
+
+### MCP/state fallback guidance
+
+If an MCP state call fails, do **not** retry the same MCP call blindly. Use the CLI parity path instead:
+
+`rcs state write --input '<json>' --json`
+
+When falling back, do so while preserving `workingDirectory` and `session_id` so state stays scoped to the current Forge run.
+
+## Verification Standard
+
+At minimum, capture the smallest evidence that proves the change:
+- remote validation path works
+- replicated state updates correctly
+- DataStore/economy logic preserves server authority
+- UI logic reflects authoritative state rather than stale client guesses
+- changed scripts/modules still pass repo checks where applicable
+
+Do not claim completion from static inspection alone when the behavior depends on runtime replication, remotes, or Studio-side state.
+
+## Lua Script Reference Layer
+
+This repo also carries a raw Lua-script corpus under `templates/roblox-scripts/`.
+
+Treat that corpus as a **reference layer only**:
+- mine it for naming patterns, UI ideas, anti-pattern detection, and legacy idioms worth translating
+- never assume the scripts are production-safe or architecture-safe
+- never paste raw scripts into shipped code without rewriting them into Roblox-native, server-authoritative, repo-consistent structures
+- prefer first-party repo patterns, typed Luau, ModuleScripts, and approved creator architecture over raw script dumps
+
+## Visual iteration gate
+
+When screenshot or reference-image work is in scope:
+- run `$visual-verdict` before every next edit
+- require structured JSON with `score`, `verdict`, `category_match`, `differences[]`, `suggestions[]`, and `reasoning`
+- persist numeric + qualitative feedback to `.rcs/state/{scope}/forge-progress.json`
+- default pass threshold: `score >= 90`
+
+Forge accepts repeatable image inputs:
+- `-i <image-path>`
+- `--images-dir <directory>`
+
+## Pre-Action Dependency
+
+For creator-domain work, Forge expects the pre-action groundwork to exist:
+- clear creator goal
+- normalized Roblox terminology
+- agreed file/module layout
+- explicit risk notes for unsafe assumptions
+
+If that groundwork is missing, produce it first through the creator planning lane instead of improvising a code pass from memory.
+Do not generate implementation code until that creator planning groundwork is present.
+
+## PRD mode
+
+When Forge is launched in PRD mode, run deep-interview in quick mode before creating PRD artifacts.
+
+- Run deep-interview in quick mode before creating PRD artifacts
+- Invoke `$deep-interview --quick <task>`
+- Persist the interview to `.rcs/interviews/{slug}-{timestamp}.md`
+- `--no-deslop` is supported; when present, skip the deslop pass for that Forge run
+
+`skills/forge-init` remains aligned with the current startup compatibility contract while `.rcs/prd.json` is still the machine-readable validation source.
+
+## Final deslop contract
+
+Step 7.5: Mandatory Deslop Pass
+- run `roblox-ai-os-creator-skills:ai-slop-cleaner`
+- changed files only
+- standard mode
+- not `--review`
+
+Step 7.6: Regression Re-verification
+- re-run all tests/build/lint
+- roll back cleaner changes or fix and retry if regression fails
+
+## Forge completion checklist
+
+- [ ] ai-slop-cleaner pass completed on changed files (or --no-deslop specified)
+- [ ] Post-deslop regression tests pass
+
+## Follow-On Creator Design Lanes
+
+Forge can hand off or cross-check with the creator design skills when the implementation depends on product logic clarity:
 
 Follow with:
 - `$forge:reward-loop`
@@ -28,3 +178,16 @@ Follow with:
 - `$forge:fomo`
 - `$forge:mastery`
 - `$forge:community`
+
+## Example
+
+```text
+$forge "Implement the approved trading system:
+- server validates every trade offer and acceptance
+- inventory replication stays authoritative
+- StarterGui trade UI only mirrors server-confirmed state
+- verify duplicate acceptance cannot double-grant items"
+```
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/forge-community/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: forge-community
 description: Creator workflow for `$forge:community`
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Forge Community
@@ -14,3 +18,6 @@ Generate a **Community Stickiness Spec**.
 - group progression or co-op loops
 - social presence surfaces
 - anti-spam and anti-abuse guardrails
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/forge-daily-loop/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: forge-daily-loop
 description: Creator workflow for `$forge:daily-loop`
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Forge Daily Loop
@@ -13,3 +17,6 @@ Generate a **Daily Return Loop Spec** for short-return Roblox play.
 - rotating goals or offers
 - event hooks
 - fairness and anti-burnout guardrails
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/forge-event-loop/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: forge-event-loop
 description: Creator workflow for `$forge:event-loop`
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Forge Event Loop
@@ -13,3 +17,6 @@ Generate an **Event / FOMO Plan** using `templates/psychology/event-fomo-design-
 - include re-entry logic
 - include rerun policy
 - call out frustration risks
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"

package/skills/forge-fomo/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: forge-fomo
 description: Creator workflow for `$forge:fomo`
+surface-class: "canonical"
+domain: "roblox-studio"
+audience: "creator"
+artifact-type: "skill"
 ---
 
 # Forge FOMO
@@ -14,3 +18,6 @@ Generate a **Fair Urgency Review** for limited-time mechanics.
 - fairness guardrails
 - comeback or rerun path
 - anti-frustration notes
+surface-class: "canonical"
+domain: "creator-runtime"
+audience: "creator"