Unify RFS Skills and create/update authoring across workspace and Space scopes

[mydmdm]

Objective

Unify Huabu's RFS Skill delivery and create/update-skill authoring around workspace- and Space-scoped Prompt/Skill content, executed by external Agents rather than a dedicated built-in Skill model or Job.

This is an independent follow-up to #203. The user agreed to defer this integration out of that execution unit. Retirement of legacy built-in authoring execution belongs to #203; it was discussed but has not been implemented as of this issue's creation. Preserve existing user content and Space Prompt/Skill behavior.

Proposed content model

Treat scope and loading behavior as separate dimensions:

Scope	Prompt	Skill
Workspace	Cross-Space instructions and preferences	Reusable methods available across Spaces
Space	Local instructions, including existing Agent-targeting rules	Local task instructions represented by existing Skill Frames and Notes

Use this as a design starting point, not a mandate for a new registry or execution framework. Explicitly define stable identities, provenance, naming conflicts, content budgets, and supported storage backends.

Scope

• Extend existing RFS discovery/read delivery to make workspace and Space content discoverable without dumping all Skill bodies into the root guide.
• Keep the Huabu access guide and schema-derived capabilities distinct from user-authored Skills. User content must not masquerade as protocol authority.
• Integrate create/update authoring with the currently selected external Agent. Remove dependence on the built-in skill model role and its special Job/Deployment switching.
• For Space content, reuse Frame/Note editing and guarded Space operations rather than maintaining a duplicate Skill file.
• Evaluate reuse of existing workspace user-Skill files, with canonical read and controlled edit operations. Preserve existing content; distinguish system/merged read views from the editable user layer.
• Require an explicit edit target and scope. Cross-Space writes need a clear authorization contract; the current broad RFS bearer token and Space URL are not per-Space privilege isolation.
• Decide how authoring is exposed in the UI and/or slash workflow without intercepting or conflicting with harness-native commands.
• Preserve current loading semantics unless separately approved: Space Prompt is snapshotted on Agent realization, while Space Skills are discovered through live authenticated RFS reads. Define workspace equivalents explicitly.

Existing evidence and reuse

apps/server/src/modules/remote_fs/skill.ts already combines the bundled/override access guide with live Space Skill Frames. space-instruction-frames.ts already renders bounded Prompt/Skill modules and applies Agent targeting to Prompt Frames. Existing workspace Skills have system/user/merged views through the Skill loader.

Legacy /create-skill and /update-skill authoring uses a dedicated skill model role and fresh built-in Jobs via skill-model-routing.ts. Reuse the content and editing concepts, not that inference coupling.

Reference architecture: docs/architecture/agent-reachback.md, agent-architecture.md, and agent-memory.md.

Acceptance criteria

• Workspace and Space scopes are discoverable, distinguishable, and editable through explicit targets; same-name content cannot silently redirect a write.
• External Agents can create/update the supported content without Huabu's built-in inference runtime.
• Version conflicts, unsupported storage capabilities, unauthorized scope, invalid content, and unavailable targets fail explicitly.
• Existing Space Prompt targeting/snapshot behavior, live Skill delivery, anonymous bootstrap restrictions, and harness-native commands remain intact unless an intentional change is approved and documented.
• Existing user files, Space nodes, and historical records are preserved; no automatic destructive migration or silent conversion is required.
• Shared wire contracts, focused tests, and architecture documentation describe the final read/write and loading behavior.

Boundaries

This issue does not require automatic Memory curation. It supports explicit authoring independently; automatic Memory-to-Skill synthesis can integrate later. Do not absorb #110 capability enablement, #235 resource cleanup, or redesign the harness's own Skill system.