@rubytech/create-siteoffice-code 0.1.256

package/payload/platform/plugins/admin/skills/plugin-management/SKILL.md

@@ -0,0 +1,99 @@
+---
+name: plugin-management
+description: "Install, remove, enable, and configure plugins and account settings via conversation."
+---
+
+# Plugin Management
+
+Manage plugins and account settings at any time via conversation.
+
+## Claude Official Plugins
+
+External Claude Code plugins (Stripe, Playground):
+
+- Install: `claude plugin install <name>@claude-plugins-official`
+- Remove: `claude plugin uninstall <name>@claude-plugins-official`
+- List installed: `claude plugin list`
+- List available: `claude plugin marketplace list`
+
+## Claude Anthropic Verticals
+
+Three optional plugins from Anthropic's vertical marketplaces, registered by the installer alongside `claude-plugins-official`. None are auto-installed; the user picks each deliberately during onboarding or by name later.
+
+| Plugin | Marketplace | Install | Caveat |
+|--------|-------------|---------|--------|
+| `kyc-screener` | `claude-for-financial-services` | `claude plugin install kyc-screener@claude-for-financial-services` | Outputs are draft work product for human review. UK estate agents under MLR 2017 are AML-regulated; compliance specialist owns sign-off. |
+| `meeting-prep-agent` | `claude-for-financial-services` | `claude plugin install meeting-prep-agent@claude-for-financial-services` | Overlaps with the business-assistant calendar-prep flow with FSI-flavoured templates — pick one path deliberately. |
+| `pdf-viewer` | `knowledge-work-plugins` | `claude plugin install pdf-viewer@knowledge-work-plugins` | Interactive in-app viewer (v0.2.0). Click-through replaces conversation for this surface — different integration shape from the chat-driven skills. |
+
+Removal mirrors install: `claude plugin uninstall <name>@<marketplace>`.
+
+## {{productName}} Plugins
+
+Built-in plugins under `$PLATFORM_ROOT/plugins/`:
+
+- Enable: call `plugin-toggle-enabled` with `pluginName` and `action: "enable"`. Activates the plugin's behaviour embed and MCP server from the next session. Plugins with scheduled behaviour (declared via `lifecycle` in PLUGIN.md frontmatter) are activated automatically by the platform heartbeat within one minute — no separate setup command needed.
+- Disable: call `plugin-toggle-enabled` with `pluginName` and `action: "disable"`. Deactivates from the next session. Any scheduled Events owned by the plugin (`sourcePlugin` field) are cancelled automatically by the platform heartbeat.
+- The tool refuses core plugins (admin, memory, docs, cloudflare) and refuses plugins not installed under `$PLATFORM_ROOT/plugins/`. Direct `Edit` of `account.json` is forbidden by IDENTITY.md doctrine — `plugin-toggle-enabled` is the only legitimate path.
+
+## Premium Plugins
+
+Premium plugins are purchased separately and delivered from a staging area to the active plugin directory. Two MCP tools handle all premium plugin operations deterministically — no filesystem commands are delegated to the agent.
+
+### Browsing available premium plugins
+
+Call `premium-list`. It returns structured data for every plugin in the staging area: name, type (standalone/bundle), description, purchase status, and delivery status (per sub-plugin for bundles). Present the results as a plain numbered list, one entry per plugin, naming the plugin, its type, its description, its purchase status, and (for bundles) the delivery status of each sub-plugin.
+
+### Plugin info before purchase
+
+When the user asks about a specific premium plugin (e.g., "tell me about the teaching plugin"), check the staging directory for both `PLUGIN.md` (standalone) and `BUNDLE.md` (bundle). For standalone plugins, read `$PLATFORM_ROOT/../premium-plugins/{name}/PLUGIN.md`. For bundles, read `$PLATFORM_ROOT/../premium-plugins/{name}/BUNDLE.md` and present the bundle description, sub-plugin breakdown, and what each sub-plugin covers. This works before purchase — it helps the user decide.
+
+### Recording a purchase
+
+`purchasedPlugins` is an entitlement-bearing field: the effective list derives from the Rubytech-signed entitlement payload, not from raw `account.json`. IDENTITY.md doctrine forbids any agent write to `account.json`. Direct purchase recording is therefore unavailable to the agent.
+
+- **Production path:** the Rubytech-side issuance endpoint signs an updated entitlement payload after a Stripe purchase event and delivers it to `~/<configDir>/entitlement.json`. The verifier picks up the new payload at the next session start.
+- **Pre-launch / dev path:** the founder runs `node platform/scripts/generate-entitlement-fixture.mjs sign --account-id <id> --email <e> --tier <t> --plugins a,b,c --out ~/<configDir>/entitlement.json` to produce a signed test payload. The agent does not invoke this script.
+- **Personal-mode installs (`brand.json.commercialMode: false`, the default today):** purchasedPlugins is read from raw `account.json` via implicit-trust mode. Pre-launch the agent has no way to add purchases without operator intervention; this is intentional during the gap before signed-issuance ships.
+
+If the user asks the agent to record a purchase, explain that their purchase is processed by Rubytech billing and the entitlement payload arrives on their device automatically — no agent action is required.
+
+### Delivering a premium plugin
+
+Call `premium-deliver` with `pluginName` set to the plugin name. The tool handles everything:
+
+- Validates the plugin name and checks purchase status
+- Auto-detects standalone vs bundle (BUNDLE.md vs PLUGIN.md)
+- For bundles: copies each sub-plugin from staging to `$PLATFORM_ROOT/plugins/`
+- For standalone plugins: copies the single plugin directory
+- Skips already-delivered sub-plugins (idempotent)
+- Verifies each copy (PLUGIN.md exists and parses)
+- Updates `enabledPlugins` in account.json (only newly delivered names)
+- Scans for public agent templates
+- Returns a structured result with per-sub-plugin status and available templates
+
+Report the tool's result to the user. If templates are found, present them and ask whether the user wants to create any now. For template creation, run `skill-load skillName=public-agent-manager` and follow the "Create from Template" instructions, passing the template directory path from the tool's result.
+
+If the delivered plugin has specialist agents (files in `agents/` with the `{plugin-name}--{agent-name}.md` naming convention, distinct from template directories), load the specialist management skill and follow the premium plugin agent activation instructions.
+
+### On-demand template listing
+
+Call `premium-deliver` for the plugin — it re-scans templates without re-copying anything (idempotent). The `templates` array in the result contains each template's display name, description, suggested slug, and directory path. `premium-list` returns purchase and delivery status but does not scan templates.
+
+### Disabling a premium plugin or bundle
+
+For standalone plugins and individual sub-plugins: remove the name from `enabledPlugins`. If the plugin has an `agents/` directory, load specialist-management and follow the deactivation instructions. Plugin files remain in `$PLATFORM_ROOT/plugins/` (permanent ownership — never removed).
+
+When the user says "disable {bundle-name}" (e.g., "disable real-agent"), read the `BUNDLE.md` from staging, iterate the `plugins` array, and remove each sub-plugin name from `enabledPlugins`. When they say "disable {sub-plugin-name}" (e.g., "disable estate-coaching"), remove only that name.
+
+## Account Settings
+
+When the user asks to change output style, thinking view, effort, context mode, or model, call `account-update` with the field and value. Changes take effect on the next session.
+
+| Setting | Field | Values |
+|---------|-------|--------|
+| Admin model | `adminModel` | Any Anthropic model ID (e.g. `"claude-sonnet-4-6"`) |
+| Public model | `publicModel` | Any Anthropic model ID (e.g. `"claude-haiku-4-5"`) |
+| Output style | `outputStyle` | `"default"` \| `"explanatory"` |
+| Thinking view | `thinkingView` | `"default"` \| `"expanded"` \| `"collapsed"` |
+| Effort | `effort` | `"low"` \| `"medium"` \| `"high"` \| `"max"` \| `"auto"` |

package/payload/platform/plugins/admin/skills/professional-document/SKILL.md

@@ -0,0 +1,178 @@
+---
+name: professional-document
+description: >
+  Compose a print-ready A4 PDF of a generic business document — proposal, report
+  (market / analysis / strategic), brief, memo, white paper, plan (non-fundraise),
+  or case study — from an operator brief plus brand tokens and graph context.
+  Trigger phrases: "write me a proposal", "draft a proposal", "draft a report",
+  "produce a report", "compile a report", "draft a market report", "draft an
+  analysis report", "draft a strategic report", "write me a brief", "draft a
+  brief", "write me a memo", "draft a memo", "send a memo", "draft a white paper",
+  "write a white paper", "draft a plan", "write me a plan" (triggers a fundraise
+  vs non-fundraise gate), "write me a case study", "draft a case study". Refuses
+  and redirects briefs that are owned by another composer: fundraise documents
+  (prospectus / term sheet / business plan / data room) route to
+  `venture-studio:investor-data-room`; property brochures route to
+  `real-agent:property-brochure`; pre-valuation packs route to
+  `real-agent:property-preval`; slide decks route to `admin:deck-pages` (format
+  spec) and `venture-studio:investor-data-room` (composer). Does NOT trigger on
+  format-only phrasings ("PDF", "one-pager", "A4", "brochure", "executive
+  document", "market analysis") — those are owned by `admin:a4-print-documents`.
+---
+
+# Professional document
+
+Compose a single A4 PDF of a generic business document from an operator brief, brand tokens, and the graph. The skill body is the workflow contract; load it once via `Skill professional-document` at the start of the turn and follow it through to delivery.
+
+## Refusal taxonomy (run first, before any composition)
+
+These checks run in order against the operator brief. The first match wins and stops the workflow with a one-sentence refusal that names the correct composer. Do not compose when any refusal fires.
+
+| Brief mentions | Refuse, redirect to | Why |
+|---|---|---|
+| prospectus, term sheet, data room, business plan, investor, fundraise, raise, round, SEIS, EIS, cap table | `venture-studio:investor-data-room` | Owns the UK seed-raise pack end-to-end (16-section plan, prospectus, term sheet, FCA self-cert appendices). |
+| property brochure, property listing brochure | `real-agent:property-brochure` | Owns the estate-agent brochure pipeline (brand → property → A4 PDF). |
+| pre-valuation, preval, valuation pitch, pre-appraisal | `real-agent:property-preval` | Owns the 5-page pre-valuation pitch pack. |
+| deck, slides, slide deck, presentation, pitch deck | `admin:deck-pages` (format spec) and `venture-studio:investor-data-room` (composer) | Slide format and full-pitch composition are not A4 documents. |
+| noun is "plan" and none of the fundraise tokens above match | **Ask the operator** before proceeding: "Is this a fundraise plan (business plan for investors) or an operating / strategic / marketing / transition plan?" If fundraise → refuse, redirect to `venture-studio:investor-data-room`. If non-fundraise → proceed. | The word "plan" splits cleanly between the two composers; the precision doctrine requires asking rather than guessing. |
+
+Emit `[professional-document] refuse reason=<owned-by-other-composer> redirect=<skill-name>` on any refusal. Emit `[professional-document] plan-disambiguation asked` when the plan gate fires and `[professional-document] plan-disambiguation answered=<fundraise|non-fundraise>` once the operator answers.
+
+When a refusal fires, return a single sentence naming the correct composer: e.g. "That's a fundraise document — ask `venture-studio:investor-data-room` instead." Do not draft, do not outline, do not load `a4-print-documents`.
+
+## Document-type catalogue
+
+Each entry below names the document type, its purpose, the default section order, the length range (which determines the page count target for the A4 build), the default tone, and the existing skills it composes with. Pick the matching entry from the operator brief; if the brief is ambiguous between two types, ask which one before drafting.
+
+### `proposal`
+- **Purpose:** Persuade a named recipient (customer, partner, supplier) to accept a defined offer.
+- **Section order:** Cover / Summary of the offer / The problem we are solving for you / Proposed approach / What you get / Pricing and timeline / Why us / Next step.
+- **Length:** 4–8 pages.
+- **Tone:** Direct, customer-centred, second person ("you"). No filler.
+- **Composes with:** `memory-search` for the recipient's known context; `prose-craft` for sentence review when writer-craft is enabled; `a4-print-documents` for the A4 shell.
+
+### `report`
+- **Purpose:** Present findings on a defined subject (market, analysis, strategic) to a defined audience. Sub-types: market report, analysis report, strategic report.
+- **Section order:** Cover / Executive summary / Scope and method / Findings (numbered sections, one per finding) / Implications / Recommendations / Sources and references.
+- **Length:** 5–15 pages, depending on findings density.
+- **Tone:** Third person, evidence-led. Every quantitative claim cites a source (graph node id when grounded in the graph, named publication when grounded by research-assistant brief-back).
+- **Composes with:** `memory-search` for graph-known facts; `research-assistant` brief-back (via the admin agent) for facts not in the graph; `prose-craft` when writer-craft is enabled; `a4-print-documents` for the A4 shell. Numbered references render in the footer area per `a4-print-documents` page-margin patterns.
+
+### `brief`
+- **Purpose:** Hand off a defined unit of work or context to a named owner. Decision-ready.
+- **Section order:** Cover / Context (1 paragraph) / The ask (3-5 bullets) / Constraints / Out of scope / Owner and timing.
+- **Length:** 1–3 pages.
+- **Tone:** Imperative, terse. The reader should know what to do after one read.
+- **Composes with:** `memory-search` for the context paragraph; `a4-print-documents` for the A4 shell. `prose-craft` review is optional at this length and is skipped if it would add a turn for negligible benefit.
+
+### `memo`
+- **Purpose:** Internal communication of a decision, position, or update to a defined audience.
+- **Section order:** Header (To / From / Date / Subject) / Bottom line up front (1 paragraph) / Background / Decision or position / What changes / Open questions.
+- **Length:** 1–4 pages.
+- **Tone:** First person plural ("we") for organisational memos, first person singular ("I") for personal memos. Direct.
+- **Composes with:** `memory-search` for the background section; `a4-print-documents` for the A4 shell. `prose-craft` review optional.
+
+### `white-paper`
+- **Purpose:** Establish a position on a substantive topic for a broad professional audience. Often used to influence a market or regulatory conversation.
+- **Section order:** Cover / Abstract / Introduction / The problem in detail / Our analysis / Our position / Implications for [audience] / Conclusion / Citations.
+- **Length:** 8–20 pages.
+- **Tone:** Authoritative, third person, citation-dense.
+- **Composes with:** `memory-search`; `research-assistant` brief-back for any factual claim not in the graph; `prose-craft` when writer-craft is enabled; `a4-print-documents` for the A4 shell.
+
+### `plan` (non-fundraise)
+- **Purpose:** Define how a named outcome will be achieved over a stated horizon. Includes operating plans, strategic plans, marketing plans, transition plans, hiring plans, integration plans.
+- **Section order:** Cover / The outcome / Why now / Current state / Target state / Workstreams (numbered) / Milestones / Owners and cadence / Risks and mitigations / Out of scope.
+- **Length:** 5–15 pages.
+- **Tone:** Outcome-led, owner-named, dated.
+- **Composes with:** `memory-search` for owners, projects, and prior state; `prose-craft` when writer-craft is enabled; `a4-print-documents` for the A4 shell. The plan-disambiguation gate above must have fired and returned "non-fundraise" before this branch runs.
+
+### `case-study`
+- **Purpose:** Document a completed engagement (customer, project, internal initiative) as a credibility artefact for use elsewhere.
+- **Section order:** Cover / At-a-glance (1 paragraph + 3 numbers) / The situation / What we did / What changed / Quotes / What's next.
+- **Length:** 3–6 pages.
+- **Tone:** Narrative, named-subject. Numbers are dated. Quotes attributed by name and role.
+- **Composes with:** `memory-search` for the named subject and adjacent facts; `prose-craft` when writer-craft is enabled; `a4-print-documents` for the A4 shell.
+
+## Workflow
+
+Run these phases in order. Do not skip; do not parallelise. Each phase emits its observability line on completion.
+
+### 1. Resolve brand tokens
+
+Read `brand.json` for the active brand. Take colours from `defaultColors` (`primary`, `primaryHover`, `primarySubtle`, `primaryGlow`, `accent`, `background`, `agentBubble`) and fonts from `defaultFonts` (`display`, `body`). These feed the `:root` CSS variables in the A4 HTML built later. Do not invent colours; if a brand override is missing, fall back to the default brand's values rather than hard-coding hex.
+
+### 2. Ground in the graph
+
+Run `memory-search` against the brief's named subjects (people, organisations, projects, products). Pull every relevant property into the outline. If the brief depends on a fact the graph does not carry (a market figure, a regulatory citation, a named comparable), do not invent it: hand the admin agent a brief-back asking it to dispatch `research-assistant`, and pause until the fact is returned.
+
+### 3. Draft the outline
+
+Compose an outline using the section order from the document-type catalogue for the matched type. Number every section. For each section, write one line stating what it will say (the claim) and one line stating which graph facts or research-assistant returns will ground it.
+
+Emit `[professional-document] outline doc-type=<type> sections=<n>`.
+
+### 4. Operator-approve the outline
+
+Return the outline to the operator as a turn. Wait for the operator to answer "go" / "approve" / "yes" or to send revisions. If revisions are requested, re-draft the outline once and re-emit; if a second revision is requested, propose continuing inline rather than another full re-draft.
+
+Emit `[professional-document] outline-approval asked` when the outline goes to the operator, and `[professional-document] outline-approval answered=<approve|revise>` when the operator answers.
+
+Do not start section drafts until the outline is approved.
+
+### 5. Draft each section
+
+Draft section by section in outline order. Each section uses the brand tokens from phase 1, the graph facts from phase 2, and the section's stated claim from phase 3. Cite sources inline (graph node id for graph-grounded facts, named publication for research-assistant-returned facts).
+
+Emit `[professional-document] draft section=<i/n> wordcount=<n>` after each section.
+
+### 6. Optional prose review
+
+Attempt `skill-load skillName=prose-craft`. If it returns the skill body, apply it as a review pass over the draft and emit `[professional-document] prose-review applied`. If it returns skill-not-found (writer-craft not enabled on this brand or account), apply a one-shot self-review prompt against the doctrine in this skill and emit `[professional-document] prose-review skipped reason=writer-craft-not-enabled`. Never block the workflow on prose review.
+
+### 7. Build the A4 HTML
+
+The first tool call of this phase MUST be `Skill a4-print-documents`. Any browser tool call before that skill is loaded into context is a contract violation. Load `skill-load skillName=a4-print-documents` and follow its rules verbatim — page margins, glassmorphism fallback, page-break rules, dark-background colour-adjust, the cover and backpage pattern. Do not paraphrase those rules; the print-CSS contract lives in that skill.
+
+Emit `[professional-document] render → a4-print-documents`.
+
+### 8. Ask the operator for the output path
+
+Before saving the PDF, ask the operator where they want it saved. The operator names the path (file name and directory). Do not invent the path. The path the operator names is where the PDF is written and what the observability line records.
+
+### 9. Save the PDF
+
+`browser-navigate` to the served HTML, then `browser-pdf-save` to write the PDF to the operator-named path (on-device Chromium print pipeline; no Playwright).
+
+Emit `[professional-document] pdf-saved path=<operator-named-path> bytes=<n>`.
+
+### 10. Deliver
+
+The PDF you saved is the deliverable — there is no send-to-chat tool. In your reply, tell the operator its exact location: the full path where you saved it, and (when that path is under `accounts/<accountId>/output/`) that it is in the Artefacts panel, downloadable; it is also reachable on their file share if set up. State the complete path, never a vague pointer. See the `file-presentation` skill for the wording.
+
+## Doctrine
+
+- **Compose, do not duplicate.** `a4-print-documents` owns the print-CSS rules; this skill loads it and follows it. `prose-craft` owns sentence-level review; this skill invokes it when present. `memory-search` owns graph reads; this skill calls it for grounding. The seam is "this skill is the workflow; the loaded skills carry the rules."
+- **Refuse before composing.** Every brief runs through the refusal taxonomy first. A skill that drafts something it should have refused is a routing defect, not a quality issue.
+- **Operator-named output path.** The skill never invents the path. The operator names where the PDF lands. This matches how `investor-data-room` and the property composers work.
+- **Approve the outline before drafting.** Long documents whose structure is wrong cost more to re-draft than they cost to re-outline. The approval turn is cheap; the wasted draft is expensive.
+- **No invented facts.** Every quantitative or named claim grounds in `memory-search` or a `research-assistant` brief-back. If the graph does not carry the fact and the operator has not asked for research, draft a one-line gap statement in place ("[GAP: <description>]") and surface it in the outline-approval turn.
+- **No live web research from this skill.** If a fact is missing, ask the admin agent to dispatch `research-assistant`. This skill does not call `WebFetch` or `WebSearch` directly.
+- **Brand tokens or fallback, never hard-coded hex.** Colours and fonts come from `brand.json#defaultColors` / `defaultFonts`. If the active brand omits an override, use the default brand's value, not a literal hex.
+
+## Observability lines (full list)
+
+These are the lines this skill emits. They surface in `server.log` via the existing PTY stdout capture; no new log file, no new structured event.
+
+```
+[professional-document] refuse reason=<owned-by-other-composer> redirect=<skill-name>
+[professional-document] plan-disambiguation asked
+[professional-document] plan-disambiguation answered=<fundraise|non-fundraise>
+[professional-document] outline doc-type=<type> sections=<n>
+[professional-document] outline-approval asked
+[professional-document] outline-approval answered=<approve|revise>
+[professional-document] draft section=<i/n> wordcount=<n>
+[professional-document] prose-review applied
+[professional-document] prose-review skipped reason=writer-craft-not-enabled
+[professional-document] render → a4-print-documents
+[professional-document] pdf-saved path=<operator-named-path> bytes=<n>
+```

package/payload/platform/plugins/admin/skills/public-agent-manager/SKILL.md

@@ -0,0 +1,256 @@
+---
+name: public-agent-manager
+description: "Create, edit, clone, list, preview, and delete public agents, each a self-contained directory with its own identity, personality, knowledge, and model. Use when asked to manage, configure, or set up public agents."
+---
+
+# Public Agent Manager
+
+Create, edit, clone, list, preview, and delete public agents. Each public agent is a self-contained directory under `agents/` with its own identity, personality, knowledge, and model.
+
+## Agent Directory Structure
+
+Each agent lives at `{accountDir}/agents/{slug}/`:
+
+| File | Purpose | Required |
+|------|---------|----------|
+| `config.json` | Model, display name, status, image identity, knowledge keywords | Yes |
+| `IDENTITY.md` | Boundaries, behavioural rules — copied verbatim from the Rubytech template | Yes |
+| `SOUL.md` | Personality and the operator-defined role — tone, voice, warmth, greeting, and the role the operator gives the agent at creation | Yes |
+| `KNOWLEDGE.md` | The business's public-facing facts at landing-page detail — pricing, FAQs, services | Yes |
+| `KNOWLEDGE-SUMMARY.md` | Auto-generated summary when KNOWLEDGE.md exceeds context budget | No |
+| `assets/` | Per-agent images (logo, avatar, icon) | No |
+
+`SOUL.md` and `KNOWLEDGE.md` are authored entirely client-side by you at agent creation and must be **non-empty before the agent goes active** — a public spawn whose SOUL or KNOWLEDGE is empty or missing is refused at spawn (the visitor sees an unavailable state, never a dud agent), so neither ships as a template nor is seeded by the installer. `IDENTITY.md` is copied verbatim from the Rubytech-controlled template, never drafted.
+
+## Slug Rules
+
+- Lowercase a-z, 0-9, hyphens only
+- 3-50 characters, must start with a letter
+- Reserved (rejected): `admin`, `api`, `assets`, `agent-assets`, `brand`, `bot`, `privacy`
+- Shadowed by a static route, also rejected: `public`, `chat`, `graph`, `sessions`, `data` — a slug equal to one of these would 404 at `/{slug}`. If the operator asks for one, reject it and name the collision.
+- Public agents are optional — the platform operates without any.
+
+## config.json
+
+```json
+{
+  "slug": "sales",
+  "displayName": "Sales Agent",
+  "model": "claude-haiku-4-5",
+  "status": "active",
+  "knowledgeKeywords": [],
+  "image": "/agent-assets/sales/agent-image.png",
+  "imageShape": "circle",
+  "showAgentName": true
+}
+```
+
+### Toolless by construction
+
+The public agent has no tools (Task 615). It cannot search the graph, read files, run commands, or load skills mid-conversation. Everything it knows is the KNOWLEDGE.md and SOUL assembled into its system prompt at spawn time. There is no operator toggle for this — it is the fixed posture for every public agent on every channel. If the agent needs to surface graph content created after deployment, refresh its KNOWLEDGE.md (see Update knowledge below); the agent itself never reaches the live graph.
+
+### knowledgeKeywords
+
+Topic keywords the agent subscribes to. During an `update-knowledge` refresh, nodes matching these keywords are included automatically — even if they are not directly tagged for the agent.
+
+Maximum 5 keywords. Present during creation as a free-text input. Examples: `["climate science", "sustainability"]`, `["pricing", "services"]`.
+
+### Agent Image
+
+An optional image (avatar, icon, or logo) displayed in the public chat header instead of the account-level brand logo. Managed via the `agent-image` MCP tool.
+
+- `image` — URL path to the image (e.g. `/agent-assets/sales/agent-image.png`). Set automatically by the `agent-image` tool.
+- `imageShape` — `"circle"` for avatars and icons, `"rounded"` for logos. Controls the CSS border-radius applied to the image in the chat header.
+- `showAgentName` — `true`: chat header displays `displayName`; `false` (default): header shows the business name from branding data; `"none"`: no name displayed at all (logo-only header, useful when the logo already contains the brand name).
+
+**Fallback chain:** agent image → account brand logo → platform default icon. When no image is configured, the existing brand logo behaviour is preserved.
+
+During creation (Step 6) and editing, offer image upload when the user has an image ready. Use the `agent-image` tool with `action: "set"`, providing the file path and the appropriate shape. If the user wants the agent's name shown in the header, set `showAgentName: true` in config.json.
+
+### Knowledge Tagging
+
+Nodes in the graph can be directly tagged for a specific agent by adding the agent's slug to the node's `agents` array property. This is the explicit tagging mode — the admin decides exactly which nodes an agent can see. Direct tagging and keyword subscriptions (`knowledgeKeywords`) are independent routing mechanisms — each is configured and approved separately, and neither implies the other.
+
+To tag nodes: read the node's current `agents` array via `memory-search` (no `agentSlug` param), confirm with the operator which nodes get the new slug, and the recorder folds the slug onto each `agents` array in its next turn. To untag: same shape — read the current array, confirm removal, and the recorder rewrites the array without the slug. To see what's tagged for an agent: search with `memory-search` (no `agentSlug` param) and identify results whose `agents` property contains the target slug.
+
+### Model Options
+
+Present as a `select` field within the agent configuration `form` during creation:
+
+| Model | ID | Suitability | Cost |
+|-------|-----|------------|------|
+| Haiku | `claude-haiku-4-5` | Fast, cost-effective. FAQ, routing, high-volume. | Low |
+| Sonnet | `claude-sonnet-4-6` | Balanced. Nuanced conversation, qualification, support. | Standard |
+| Opus | `claude-opus-4-7` | Maximum intelligence. Complex sales, consultative selling. | Premium |
+
+## SOUL.md Scope Enforcement
+
+SOUL.md is personality and role. When the user provides content for SOUL.md, route content that belongs elsewhere to the correct file:
+
+- **Facts, pricing, services, FAQs** → KNOWLEDGE.md
+- **Personality and the operator-defined role — how the agent sounds and what the operator has tasked it to do** → SOUL.md (the role is whatever the operator specifies at creation; the public agent is toolless, so there are no plugins to embed)
+- **Boundaries and procedural rules** → IDENTITY.md (Rubytech-controlled and copied verbatim — the agent's hard limits live there, not in SOUL)
+
+SOUL.md answers "what does this agent feel like to talk to, and what is it here to do?" — tone, warmth, formality, greeting, and the operator-defined role the agent was created to fill. SOUL.md must not restate constraints from IDENTITY.md. When user-provided content could belong to either file, apply this test: "does this restrict what the agent does?" → IDENTITY.md. "Does this describe how the agent sounds?" → SOUL.md. If content does both (e.g. "always respond politely"), route to SOUL — the constraint is a consequence of tone, not an operational boundary. Present SOUL.md via `document-editor` for the user to review and approve. Follow the document-editor encoding constraint in IDENTITY.md when generating content.
+
+## KNOWLEDGE.md Population
+
+KNOWLEDGE.md is the public agent's baked, static knowledge surface — the facts the agent should always have on hand without a tool call. It is assembled into the system prompt at invocation time.
+
+Public agents run on the same native Claude Code PTY as the admin, dispatched via `dispatchOnce` with `role: 'public'`. The public agent is toolless (Task 615): KNOWLEDGE.md is its **only** knowledge source. There is no graph access mid-conversation. Every gap in KNOWLEDGE.md is a question the agent cannot answer, so the KNOWLEDGE.md you build below is the whole of what the agent will know — populate it thoroughly.
+
+The `memory-search` calls described below are **your** admin-time tool for populating KNOWLEDGE.md, not something the public agent ever runs. All `memory-search` queries for knowledge population use admin permissions — do not pass `agentSlug`. The `agentSlug` parameter is a runtime enforcement mechanism for the public agent's MCP server, not an admin-time discovery tool. At creation time, the agent may have zero tagged nodes — searching with `agentSlug` would return nothing.
+
+Query `memory-search` multiple times with targeted terms across all categories relevant to the agent's role. A single broad query will miss knowledge stored under specific labels or entity types. Common categories:
+
+- Services, pricing, availability
+- FAQs
+- Team / people (public-facing details only)
+- Policies (returns, cancellations, terms)
+- Products / catalogue
+- Location, hours, contact info
+
+For each category relevant to the agent, confirm that results were returned or that the graph genuinely has no data for that category. Write results as structured markdown under clear headings.
+
+After writing KNOWLEDGE.md, check the token budget. If the total system prompt exceeds 50% of the model's context window, summarise KNOWLEDGE.md and write the summary to `KNOWLEDGE-SUMMARY.md`. Present the summary to the user for review.
+
+## Context Budget
+
+The system prompt must leave room for conversation. After assembling all files, estimate the total token count. Present the breakdown to the user:
+
+```
+IDENTITY.md:     800 tokens
+SOUL.md:         400 tokens
+KNOWLEDGE.md:  8,200 tokens
+─────────────────────────
+Total:         9,400 / 40,000 (24%)
+```
+
+Warn if total exceeds 50% of the model's context window.
+
+## Operations
+
+### Create from Template
+
+When template context is provided (a path to a template directory containing `template.json` and a `SOUL.md` seed), the Create operation pre-populates its steps from the template. The user reviews and approves every file — the template is a starting point, not an automatic deployment.
+
+Read the template's `template.json` and seed files. If `template.json` is unreadable or missing required fields (`suggestedSlug`, `displayName`), report the error and fall back to the standard Create flow.
+
+The following Create steps are modified when a template is provided:
+
+- **Step 1** — use `suggestedSlug` from `template.json` as the initial slug. If an agent already exists at that slug, ask the user to choose a different name.
+- **Step 2** — skip. The agent name and role come from `template.json` `displayName` and `description`.
+- **Step 4** — unchanged: `IDENTITY.md` is always the Rubytech-controlled template copied verbatim, never the agent template's own identity.
+- **Step 5** — present the template's `SOUL.md` content via `document-editor` instead of drafting from conversation. The user can edit before approving.
+- **Step 6** — pre-populate form defaults: `model` from `template.json` (or `claude-haiku-4-5` if absent), `knowledgeKeywords` from `template.json` (or empty).
+
+All other steps (3, 7-13) proceed identically — knowledge discovery, direct tagging, KNOWLEDGE.md generation, config write, budget check, default-setting, and confirmation are unchanged.
+
+After creation, no template metadata persists in the agent's files. The resulting agent is indistinguishable from one created manually. The user owns it completely.
+
+### Create
+
+1. **Pre-creation check** — verify the target directory (`agents/{slug}/`) does not exist or is empty before proceeding. If remnant files exist from a prior incomplete deletion, flag the issue to the user: show what files remain and offer to clean them up before starting fresh. Do not silently inherit stale files — a leftover `config.json` from a previous agent would bypass the creation gate.
+2. Ask for the agent's name (becomes the slug) and role description
+3. **Knowledge discovery** — search the graph with admin permissions (no `agentSlug` — the agent doesn't exist yet) to find available knowledge. Present available content grouped by category for the user to select.
+4. **Install `IDENTITY.md`** — copy the Rubytech-controlled template verbatim to `agents/{slug}/IDENTITY.md`. It is fixed (the toolless public directive — Task 615) and is never drafted, edited, or presented for review.
+5. Present `SOUL.md` via document-editor with `filePath: "agents/{slug}/SOUL.md"` (draft personality and the operator-defined role from user conversation — tone plus the role the operator describes for the agent). Write on approval. Must be non-empty; an empty SOUL is refused at spawn.
+6. Present agent configuration via a single `form` component with these fields:
+   - `knowledgeKeywords` (`text`): label "Knowledge keywords (max 5, comma-separated)", placeholder with examples relevant to the agent's role
+   - `model` (`select`): label "Model", options with descriptions:
+     - `claude-haiku-4-5` — "Haiku — Fast, cost-effective. FAQ, routing, high-volume."
+     - `claude-sonnet-4-6` — "Sonnet — Balanced. Nuanced conversation, qualification, support."
+     - `claude-opus-4-7` — "Opus — Maximum intelligence. Complex sales, consultative selling."
+   - `showAgentName` (`select`): label "Chat header title", options: `false` — "Business name (default)", `true` — "Agent display name", `"none"` — "None (logo only)"
+   The `model` field should have a `defaultValue` of `"claude-haiku-4-5"`.
+   Wait for the user's response before proceeding.
+   After the form is submitted, ask the user if they have an image (avatar, icon, or logo) for the agent. If yes, ask the user to provide the file and select the shape (circle for avatars/icons, rounded for logos), then use the `agent-image` tool to upload it.
+7. **Direct slug tagging (optional, gated)** — keyword subscriptions (configured in Step 6) and direct slug tagging are independent routing mechanisms. Keyword subscriptions route content by topic — any matching node is visible, now or in the future. Direct slug tagging routes specific nodes by identity — only explicitly tagged nodes are visible via the slug search path. Neither implies the other.
+
+   Ask the user whether any specific knowledge nodes should be tagged with this agent's slug. Explain that direct tagging makes specific nodes always visible to this agent regardless of keyword matches, and is useful for content that doesn't match any keyword but should still be available. If keyword subscriptions already cover the desired content, tagging is unnecessary.
+
+   - If the user approves: present the knowledge discovery results from Step 3 for selection, read each node's current `agents` array first, and confirm the new slug-tag set with the user. The recorder folds the slug onto each node's `agents` array in its next turn.
+   - If the user declines: skip tagging entirely. Do not propose tagging without explicit approval.
+8. **KNOWLEDGE.md generation** — populate from the now-tagged set plus keyword matches using the `update-knowledge` skill workflow. KNOWLEDGE.md is required and must be non-empty; an empty or missing KNOWLEDGE is refused at spawn.
+9. Write `config.json` with selected model, status "active", and `knowledgeKeywords`. This is the last gated write — placed after IDENTITY.md, SOUL.md, and KNOWLEDGE.md to prevent cascade failure if one gate stalls.
+10. Check context budget — auto-summarise if over threshold
+11. **Project the agent into the graph** — delegate to the `specialists:database-operator` specialist with the instruction: "Project public agent `{slug}` into the graph by POSTing to `/api/admin/agents/{slug}/project`." The route reads the on-disk files and idempotently MERGEs the `:Agent` node, the four owned `:KnowledgeDocument` projections (IDENTITY/SOUL/KNOWLEDGE/KNOWLEDGE-SUMMARY when present, namespaced `attachmentId="agent:<slug>:<role>"`), the `HAS_*` edges, and the `USES_KNOWLEDGE` edges to every operator-tagged doc. Loud-fail: if the route returns non-2xx, surface the error to the user verbatim — the agent's files exist on disk but its graph projection is incomplete, which means the operator's /graph view will not show this agent. Re-running the projection is safe; it is the same idempotent MERGE.
+12. **Set the default if none exists.** Read `defaultAgent` from `account-manage`. If it is empty, set it to this new slug via `account-update` (`field: "defaultAgent"`, `value: "{slug}"`) — otherwise the agent answers at `/{slug}` but the bare root serves nothing. If a default already exists, do not change it silently: tell the operator the current default and ask whether to switch the root to this new agent; call `account-update` only if they say yes.
+13. Confirm creation: "Agent created and reachable at `/{slug}`." If you set or changed the default in step 12, add: "The site root also serves this agent." If a different default remains, add: "The site root still serves `{currentDefault}`."
+
+### List
+
+Read `defaultAgent` from `account-manage` to identify the current default. Read all directories under `agents/`. For each, read `config.json` and estimate total token budget. Present as a structured summary, marking the default agent:
+
+**sales** — Sonnet Standard * default
+11,500 / 200,000 tokens (6%) · active
+
+**support** — Haiku Low cost
+3,200 / 40,000 tokens (8%) · active
+
+**hello** — Haiku Low cost
+9,800 / 40,000 tokens (25%) · active
+
+### Clone
+
+Copy the source agent's directory to a new slug. The user modifies what's different — typically SOUL.md and KNOWLEDGE.md.
+
+### Edit
+
+Read any file in the agent's directory and present it via document-editor with `filePath` set to the file's path. Write back on approval. The document-editor includes a Download button — the user can review, edit, then download the file as `.md` without further agent action.
+
+For agent image changes:
+- Use the `agent-image` tool with `action: "set"` to upload or replace the image
+- Use the `agent-image` tool with `action: "remove"` to remove the image (falls back to brand logo)
+- To change the shape, use `agent-image` with `action: "set"` and the new `imageShape`
+- To change `showAgentName` (`true`, `false`, or `"none"`), update `config.json` directly
+
+For knowledge scope changes:
+- Show currently tagged nodes (search `memory-search` without `agentSlug`, identify results whose `agents` property contains the agent's slug) and active keyword subscriptions (from `config.json`).
+- Allow adding/removing direct tags. Read each node's current `agents` array first, confirm the change with the operator, and the recorder updates the arrays in its next turn.
+- Allow adding/removing keyword subscriptions (update `knowledgeKeywords` in `config.json`).
+- After changes, offer to refresh KNOWLEDGE.md using the `update-knowledge` skill.
+
+**After every Edit operation that touches IDENTITY/SOUL/KNOWLEDGE/KNOWLEDGE-SUMMARY/`config.json` (including `knowledgeKeywords` or direct-tag mutations), delegate to `specialists:database-operator` to re-project: POST `/api/admin/agents/{slug}/project`.** Without re-projection the on-disk files diverge from the graph state — the operator sees stale `:Agent` properties and stale `USES_KNOWLEDGE` edges in /graph. Loud-fail: surface non-2xx errors verbatim.
+
+### Delete
+
+Deletion removes the entire agent directory (`agents/{slug}/`) — not individual files. A partial deletion leaves ghost state that poisons future creation into the same slug.
+
+**Confirmation:** Before removing, show the user exactly what will be deleted — the slug, directory path, and the files present in it. Proceed only after explicit confirmation.
+
+**Default agent handling:** Read `defaultAgent` from `account.json` via `account-manage`. If the agent being deleted is the current default:
+- Scan `agents/` for other non-admin directories containing `config.json`. If other agents exist, offer to set one as the new default via `account-update`.
+- If no other agents remain (or the user declines to set a new default), clear the `defaultAgent` field by calling `account-update` with `field: "defaultAgent"`, `value: ""`. Tell the user that visitors to the root URL will see a "no agents" message until a new agent is created.
+
+**Cleanup sequence:**
+- Issue `DELETE /api/admin/agents/{slug}` — the route removes the `:Agent` node and its four owned `:KnowledgeDocument` projections FIRST, then deletes the directory. Loud-fail: if graph cleanup throws, files are preserved and a 500 is returned with the error text. Re-issuing the DELETE is safe (idempotent on both layers). Operator-tagged docs survive the projection delete — only the `USES_KNOWLEDGE` edges from this Agent are removed.
+- Verify the directory no longer exists
+- Report what was removed (list the files that were in the directory)
+
+**Graph tag cleanup (optional):** Knowledge nodes in the graph may have the deleted agent's slug in their `agents` array. These tags become orphaned after deletion — no agent will query them, so they are inert. Offer the operator the choice: clean up the orphaned tags (read each affected node's current `agents` array first, confirm the slug removal, and the recorder rewrites the arrays in its next turn) or leave them. If the operator declines, note that the tags are harmless and can be cleaned up later.
+
+### Set as Default
+
+Change which agent serves the root URL (`public.maxy.bot/`).
+
+1. Read the current `defaultAgent` from `account-manage`
+2. Confirm the change with the user — show the current default and the proposed new default
+3. Call `account-update` with `field: "defaultAgent"`, `value: "{slug}"`
+4. Report the result — the tool response includes both old and new default slug
+
+The new default takes effect on the next page load. The previous default agent remains accessible at its `/{slug}` URL.
+
+### Test Greet
+
+Invoke the agent with `[New session. Greet the visitor.]` and stream the response to the admin chat. The admin sees exactly what a visitor would see on first load.
+
+## Runtime Surface
+
+Public agents run on the same native Claude Code PTY as the admin, dispatched via `dispatchOnce` with `role: 'public'`. They are toolless by construction (Task 615): no filesystem access, no MCP tools, no subagents, no `memory-search`. Every public spawn resolves an empty `--allowed-tools`, runs in `dontAsk`, and carries a per-spawn `permissions.deny` covering every native, harness, and memory-MCP tool on every channel. Everything the agent needs to say comes from its directory files (IDENTITY.md, SOUL.md, KNOWLEDGE.md) assembled into the system prompt at invocation time — nothing else is reachable.
+
+## URL Routing
+
+On the `public.*` subdomain:
+- `public.maxy.bot/` → the agent set as `defaultAgent` in account.json
+- `public.maxy.bot/{slug}` → named agent

package/payload/platform/plugins/admin/skills/publish-site/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: publish-site
+description: "Move an already-extracted static-site tree into the per-account static-publish surface and emit one canonical path slug. Use when asked to publish, host, or put a site online."
+---
+
+# Publish Site
+
+Call `mcp__plugin_admin_admin__publish-site` to move an already-extracted static-site tree into the per-account static-publish surface (`<accountDir>/sites/<slug>/`) and emit one canonical path slug. Pair the slug with `mcp__plugin_admin_admin__public-hostname` to surface the full URL in the same turn.
+
+**Invoked from `specialists:content-producer`** when the brief carries a host-website / publish-site / put-online intent. The slug validation, symlink scan, refusal taxonomy, `mv`, canonical-path selection, and llms.txt refresh all run inside the typed tool — this skill is the intent router, not the implementer.
+
+## When to use
+
+Activate when **both** are true:
+
+- The current turn carries a "host this website" / "publish this site" / "put this online" / equivalent intent.
+- A directory tree of HTML + assets is already on disk under `<accountDir>/extracted/<attachmentId>/` (typical output of [unzip-attachment](../unzip-attachment/SKILL.md)), or the conversation already names a source directory under `<accountDir>/`.
+
+Do **not** activate for `.pdf`, `.docx`, slide decks, single-image attachments, or zips whose extracted output is not a directory tree of HTML + assets — those have their own skills (`a4-print-documents`, `deck-pages`, etc.).
+
+## Call
+
+```
+mcp__plugin_admin_admin__publish-site
+  source:           <absolute path to the extracted source directory>
+  slug:             <operator-supplied or operator-confirmed path under sites/>
+  siteName?:        <optional llms.txt header; defaults to the last slug segment>
+  siteDescription?: <optional one-line blockquote under the llms.txt header>
+```
+
+Confirm the slug with the operator before calling if it isn't already explicit in the conversation.
+
+## Surface the result
+
+- **On success** the tool returns `pathSlug` (e.g. `/sites/demo/` or `/sites/demo/brochure.html`). Call `mcp__plugin_admin_admin__public-hostname` next and surface `https://<hostname><pathSlug>` to the operator. The `aeo:` line on the response tells you whether `llms.txt` refresh succeeded; if it failed, the publish still succeeded — relay the URL anyway.
+- **On refusal** the tool returns a `refused: <kind>` body with a fixed `Operator action:` guidance line. Relay the guidance verbatim. The five refusal kinds are `unsafe-slug`, `destination-occupied`, `symlink-in-source`, `zero-html`, and `ambiguous-html`. No retry, no improvisation, no fallback server.
+
+## Out of scope
+
+- Extraction. `unzip-attachment` already owns the extract step; the source path is its output.
+- DNS, tunnels, certificates, or any public-host configuration. The route at `/sites/*` is the wire contract.
+- Cleanup of pre-existing synthetic files left by earlier sessions. A non-empty destination produces `destination-occupied` and the operator cleans up explicitly.

package/payload/platform/plugins/admin/skills/qr-code/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: qr-code
+description: >
+  Generate QR codes from URLs, Wi-Fi credentials, contacts (vCard), email/SMS links,
+  or plain text. Writes the PNG under output/qr/ and tells the operator its path.
+  Trigger phrases: "QR code", "generate a QR", "create a QR", "make a QR code for",
+  or any request to share data as a scannable code.
+---
+
+# QR Code Generation
+
+Generate QR codes from user-provided data and deliver by stating the file path.
+
+## When to Activate
+
+- User asks to generate, create, or make a QR code
+- User wants to share a URL, Wi-Fi password, or contact details as a scannable code
+- Any mention of "QR" in the context of creating one
+
+## Behaviour
+
+Infer the data type from the user's input. For structured types (Wi-Fi, vCard), collect any missing fields conversationally and confirm the structured data before encoding. For simple types (URL, plain text, email, SMS), encode directly.
+
+Generate the QR image by calling the `qr-generate` tool with the encoded data string as the `data` parameter. The tool writes the PNG under `output/qr/` and returns the path. Tell the operator the path so they can retrieve it from the Artefacts panel or file share.
+
+If the tool returns an error, report the message to the user and suggest corrections (e.g., data too long, invalid format).
+
+## Boundaries
+
+- Generates one QR code per request. Bulk generation is not supported.
+- No branded/styled QR codes (logo overlays, custom colours).
+- Does not scan or read existing QR codes.
+
+## References
+
+Load `references/data-formats.md` for encoding formats, CLI invocation patterns, and supported options.