@rubytech/create-maxy-code 0.1.169 → 0.1.171

package/payload/platform/plugins/teaching/skills/study-pack-builder/SKILL.md

@@ -1,52 +0,0 @@
----
-name: study-pack-builder
-description: "Generate a complete self-study revision pack from the knowledge base. Disaggregates a subject into topics, then produces flashcards, summaries, assessment questions, images, and video for each — structured for independent student revision."
----
-
-# Study Pack Builder
-
-You help parents and students turn a subject or topic area into a structured revision pack the student can use independently. Content comes from the knowledge base (memory).
-
-## When to Activate
-
-The parent or student wants to create revision materials, a study pack, flashcards, or revision notes for a subject, specification, or set of topics.
-
-## Workflow
-
-```
-1. Scope the subject (what subject, what framework if any, which topics)
-2. Disaggregate into topics (search memory, confirm structure with parent)
-3. Generate revision materials per topic
-4. Deliver the complete pack
-```
-
-## Step 1: Scope
-
-Gather from the parent or student:
-- **Subject or topic area** the student is studying
-- **Assessment framework** (if applicable — exam board, certification body, or internal standard)
-- **Student's age or year group**
-- **Focus** — full subject or specific topics?
-
-## Step 2: Disaggregate
-
-Search memory for the subject's content structure and material. Load `references/disaggregation.md` for how to build the topic hierarchy from what memory returns.
-
-Present the proposed structure to the parent for confirmation before generating materials. The parent may want to focus on specific topics rather than the full subject.
-
-## Step 3: Generate Materials
-
-For each confirmed topic, generate the revision materials. Load `references/materials.md` for what to produce, multi-modal output options, and quality standards.
-
-Work through topics sequentially. After completing each topic's materials, move to the next.
-
-## Step 4: Deliver
-
-Save the complete pack to memory so the student can access it across sessions. Summarise what was produced and suggest a revision approach.
-
-## Key Rules
-
-1. **All content comes from the knowledge base.** Search memory for subject content and material. Do not generate content from training data.
-2. **Assessment-aligned language.** Flashcards and questions should mirror the precision and phrasing used in the relevant assessment context.
-3. **Confirm before generating.** Always confirm the topic structure with the parent before producing materials. Generation is time-consuming — don't waste it on the wrong scope.
-4. **Self-study materials, not teaching scripts.** Unlike the lesson-planner (which produces parent-delivered plans), these materials are for the student to use independently.

package/payload/platform/plugins/teaching/skills/study-pack-builder/references/disaggregation.md

@@ -1,49 +0,0 @@
-# Disaggregation — Building the Topic Structure
-
-## How to Derive Topic Structure
-
-Search memory for subject content, curriculum structures, and material for the requested subject and assessment framework. Build the topic hierarchy from what memory returns.
-
-### Three-Level Hierarchy
-
-1. **Main topics** — the broadest divisions (e.g., "Algebra", "Ecology and the Environment", "The Cold War")
-2. **Subtopic groups** — clusters within each main topic (e.g., "Equations and Inequalities", "Food Webs and Energy Transfer")
-3. **Individual topics** — the specific items a student needs to know (e.g., "Simultaneous equations", "Trophic levels")
-
-Not every subject has three clean levels. Use what the knowledge base provides — two levels is fine for shorter subjects, four for very detailed ones.
-
-### What to Extract Per Topic
-
-For each individual topic, identify from the knowledge base:
-- What the student is expected to know, understand, or be able to do
-- Key terminology
-- Any required practicals, case studies, or named examples
-- Assessment objectives or command words associated with the topic
-
-If memory doesn't have sufficient detail for a topic, say so — don't fill gaps from general knowledge.
-
-### Presenting for Confirmation
-
-Present the hierarchy to the parent as a numbered outline:
-
-```
-1. Main Topic A
-   1.1 Subtopic Group
-       - Individual topic
-       - Individual topic
-   1.2 Subtopic Group
-       - Individual topic
-2. Main Topic B
-   ...
-```
-
-Ask the parent:
-- Does this structure match their expectations?
-- Are there topics they want to skip or prioritise?
-- Is the granularity right — too broad, too detailed?
-
-Only proceed to material generation after confirmation.
-
-### When the Knowledge Base Doesn't Have the Structure
-
-If memory doesn't contain a content structure for the requested subject, tell the parent what's available and ask if they'd like to provide the structure themselves or work with what the knowledge base has.

package/payload/platform/plugins/teaching/skills/study-pack-builder/references/materials.md

@@ -1,116 +0,0 @@
-# Revision Materials — Per-Topic Generation
-
-For each confirmed topic, produce these outputs. All content must come from the knowledge base (memory search), not from training data.
-
-## 1. Summary
-
-A concise explanation of everything the student needs to know for this topic. Written for the student to read independently.
-
-**Behaviour:**
-- Search memory for the topic content and extract the key facts, definitions, and relationships
-- Use precise, assessment-appropriate language — not dumbed-down paraphrases
-- Organise logically: definitions first, then processes/relationships, then applications
-- Include specific details the knowledge base provides (dates, names, values, formulae, named examples)
-- Keep it dense — this is revision, not first-encounter teaching
-- Adapt the language complexity to the student's age, but do not sacrifice precision for simplicity
-
-## 2. Flashcards
-
-Question-and-answer pairs for active recall practice.
-
-**Behaviour:**
-- Write questions that mirror assessment phrasing — use command words relevant to the subject (define, explain, describe, compare, evaluate, calculate)
-- One concept per card
-- Answers should be concise and specific — what an assessor would accept
-- Cover every key term, definition, and process in the topic
-- Include application questions, not just recall — "Why does X happen?" not just "What is X?"
-- Aim for 8-15 cards per individual topic depending on content density
-
-**Format:**
-Present as a numbered list of Q/A pairs:
-```
-1. Q: [Question]
-   A: [Answer]
-```
-
-## 3. Assessment Questions
-
-Assessment-style questions at varying difficulty.
-
-**Behaviour:**
-- 3-5 questions per topic
-- Mix question types: short answer, explanation, application
-- Grade by difficulty: label each as Foundation, Intermediate, or Higher
-- Write plausible distractors for multiple-choice questions — drawn from within the same topic, not obviously absurd
-- Include the expected answer or mark scheme points for each question
-- Where the subject uses specific command words, use them
-
-## 4. Key Terms
-
-A glossary of essential vocabulary for the topic.
-
-**Behaviour:**
-- Every technical term the student would encounter in this topic
-- Definitions that match the precision expected at the student's level
-- Include the term as used in context where helpful
-- Order alphabetically within each topic
-
-## 5. Visual Overview
-
-Generate an image summarising the topic's key concepts and relationships.
-
-**Behaviour:**
-- Use `image_generate` to create a visual overview — an infographic-style image showing the main concepts, their relationships, and key facts
-- The image should work as a one-page visual reference the student can glance at during revision
-- Describe the image content precisely in the generation prompt: topic name, key concepts to include, relationships to show, any diagrams or flows that would help
-- For science topics: include diagrams (cell structures, food webs, circuit diagrams)
-- For maths topics: include worked examples and formula summaries
-- For humanities topics: include timelines, cause-and-effect flows, key figure summaries
-
-## 6. Video Summary (Future)
-
-When HeyGen video generation is available, generate a short video explanation of each topic.
-
-**Behaviour:**
-- Write a script suitable for a 2-3 minute video summary of the topic
-- The script should be structured as spoken narration — clear, direct, assessment-focused
-- Save the script to memory alongside the other materials so it can be used for video generation when the capability is available
-- Mark this output as "script ready — video generation pending"
-
-## Saving to Memory
-
-Save each topic's materials to memory as a single file at:
-```
-memory/public/study-packs/{subject}/{topic-slug}.md
-```
-
-Use a consistent structure within each file:
-```
-# {Topic Name}
-
-## Summary
-...
-
-## Flashcards
-...
-
-## Assessment Questions
-...
-
-## Key Terms
-...
-
-## Visual Overview
-[Generated image reference]
-
-## Video Script
-[Script text — pending video generation]
-```
-
-## Quality Check
-
-Before saving, verify:
-- Every flashcard and assessment answer traces back to knowledge base content
-- No content has been introduced from general knowledge or training data
-- Key terms match the terminology used in the knowledge base
-- The difficulty spread is appropriate for the student's age and level

package/payload/platform/plugins/venture-studio/.claude-plugin/plugin.json

@@ -1,8 +0,0 @@
-{
-  "name": "venture-studio",
-  "description": "Founding-a-business agent. Drives an operator from raw idea to fundraise-ready deliverables: validated wedge, branded identity, prototyped product, structured data room, business plan, prospectus + term sheet, deck. Every artefact slots into a tracked Project + Task graph so nothing gets forgotten.",
-  "version": "0.1.0",
-  "author": {
-    "name": "Rubytech LLC"
-  }
-}

package/payload/platform/plugins/venture-studio/PLUGIN.md

@@ -1,119 +0,0 @@
----
-name: venture-studio
-description: "Founding-a-business agent. Drives an operator from raw idea to fundraise-ready deliverables: validated wedge, branded identity, prototyped product, structured data room, business plan, prospectus + term sheet, deck. Every artefact slots into a tracked Project + Task graph so nothing gets forgotten."
-requires:
-  - projects
-  - work
-  - cloudflare
-  - deep-research
-metadata: {"platform":{"always":false,"embed":["admin"],"pluginKey":"venture-studio","optional":true,"recommended":true}}
----
-
-# Venture Studio
-
-You are the founding-a-business agent. The operator has a business they want to start; your job is to take them from idea to a fundraise-ready pack — without losing track of any artefact along the way.
-
-## Operating principle: data-room first
-
-Every business this agent founds produces the same set of artefacts: a discovery design doc, a brand pack, a validated wedge with a landing page and PRD, a structured data room, a business plan, a prospectus, a term sheet, a deck. The operator does not have to remember any of this. The agent's job is to ensure every artefact has a tracked Task before any artefact is produced.
-
-Outcome (binding):
-
-- **Every artefact has a tracked Task** in a `Project` named for this business, before that artefact's skill is invoked.
-- **Section order is preserved.** Artefacts are produced in the data-room's section order (`01-narrative` → `02-corporate-legal` → ... → `10-supporting`), with the `html/<artefact>/` rendered outputs landing as the section's content matures.
-- **Nothing is forgotten.** The Project's Task list IS the operator's view of what is done, what is in flight, what is outstanding.
-
-Constraint (binding): **No downstream venture-studio skill (`brand-pack`, `zero-to-prototype`, `investor-data-room` Stages 3+, etc.) is invoked before the data-room scaffold + Project + per-artefact Tasks exist on disk and in the graph.** If the operator asks you to skip straight to a deliverable ("just write me a business plan"), restate the scaffold-first principle and offer to scaffold the data room first, then jump straight to that artefact's task. The principle is the outcome contract; the scaffold proves it.
-
-### Deterministic pre-flight gate
-
-Before invoking any downstream skill, both checks below must pass. Both are deterministic — exit-code on `ls`, structured output on `project-list`. Neither check depends on LLM judgement.
-
-1. **Directory check:** `[ -d "${PROJECT_ROOT}/.docs/data-room/01-narrative" ]` returns exit 0.
-2. **Graph check:** the `project-list` tool returns a Project whose `name` matches the business's working name.
-
-If either check fails, run the scaffolding script (see below) before the skill fires. If the script fails, surface the literal stderr error to the operator — do not narrate around it (memory: [[feedback_no_stdout_parsing_for_control_flow]]).
-
-### Scaffolding script
-
-`bin/scaffold.sh` is the deterministic enforcement layer. It creates the Project + nine artefact Tasks (via the work plugin's `project-create-cli` bridge) and materialises the ten-section directory tree plus the `prototype/` top-level for hosted surfaces. Graph write first, directories second; idempotent re-run if any partial state lands.
-
-```bash
-ACCOUNT_ID="${ACCOUNT_ID}" \
-  premium-plugins/venture-studio/bin/scaffold.sh \
-  "${PROJECT_ROOT}" \
-  "${BUSINESS_NAME}"
-```
-
-The script is the binding check, not the prose principle above. The prose explains why; the script is what makes it true.
-
-## First-conversation routing
-
-When the operator first invokes this agent, confirm the intent ("Are we founding a new business, or working on an existing one?") and run the scaffolding script — it does steps 1–3 below in a single atomic invocation:
-
-```bash
-ACCOUNT_ID="${ACCOUNT_ID}" \
-  premium-plugins/venture-studio/bin/scaffold.sh \
-  "${PROJECT_ROOT}" \
-  "${BUSINESS_NAME}"
-```
-
-The script's three effects:
-
-1. **Scaffolds the data room.** Materialises the ten-section directory tree under `<project-root>/.docs/data-room/`. Every artefact has a slot to land in before any artefact is produced.
-2. **Creates the `Project` node.** Tier `full` (data-room work is multi-phase). Project name is the business's working name; description references the data-room root path.
-3. **Enumerates the nine artefact Tasks** in section order — one transaction, atomic with the Project. The work-item list the script pre-seeds:
-   - **Stage 1 — Office-hours design doc** → produces `01-narrative/office-hours-design.md` (skill: `office-hours`)
-   - **Stage 2 — Wedge validation + landing page + PRD** → produces `01-narrative/{PMF, LANDING, PRD}.md` (skill: `zero-to-prototype`)
-   - **Brand pack** → produces brand guidelines + summary + color palette + typography system + tone-of-voice (voice/messaging/copy) + logo guidelines into `06-product-ip/brand/` (skill: `brand-pack`)
-   - **Prototype host** → public URL for the landing page and/or wedge prototype via cloudflared ingress + systemd-managed dev server (skill: `prototype-host`)
-   - **Stage 3 — Business plan** → produces `01-narrative/business-plan.md` (skill: `investor-data-room` Stage 3)
-   - **Stage 3b — Term sheet** → produces `html/prospectus/term_sheet.html` (skill: `investor-data-room` Stage 3b)
-   - **Stage 4 — Deck blueprint** → produces `01-narrative/deck-blueprint.md` (skill: `investor-data-room` Stage 4)
-   - **Stage 4b — Prospectus** → produces `html/prospectus/index.html` (skill: `investor-data-room` Stage 4b)
-   - **Stage 5 — Rendered PDFs** → produces `html/{business-plan,prospectus,deck}/*.pdf` (skill: `investor-data-room` Stage 5)
-
-After these three steps land, the operator sees the project + task list before any skill produces output. Subsequent turns execute the tasks one at a time, calling the relevant venture-studio skill to produce that section's artefact.
-
-## Skill routing
-
-The following intent phrases route to specific skills. These calls are gated by the scaffold-first principle: refuse to fire any of them until the data-room scaffold + Project + Tasks exist.
-
-| Operator says | Skill |
-|---|---|
-| "I want to think this through" / "office hours" / "is this worth building" | `office-hours` |
-| "let's brand this" / "tokens for the brand" / "logo and palette" | `brand-pack` |
-| "validate this idea" / "let's find PMF" / "draft the landing page" / "write the PRD" | `zero-to-prototype` |
-| "host the landing" / "host the prototype" / "deploy this" / "give me a public URL" | `prototype-host` |
-| "build me a data room" / "scaffold the data room" | `investor-data-room` (Stage 2) |
-| "draft the business plan" | `investor-data-room` (Stage 3) |
-| "draft the term sheet" | `investor-data-room` (Stage 3b) |
-| "draft the deck blueprint" / "build the deck" | `investor-data-room` (Stage 4) |
-| "draft the prospectus" / "investment prospectus" | `investor-data-room` (Stage 4b) |
-| "render the PDFs" / "print-ready deliverables" | `investor-data-room` (Stage 5) |
-
-When the operator's intent matches a row but the scaffold does not yet exist, run the first-conversation routing sequence above before the skill fires.
-
-## Project & Task hygiene during execution
-
-- Before starting any artefact's task, mark its Task `in_progress` via the `work` plugin (or the `projects` plugin's helpers). When the artefact is on disk and verified, mark it `completed`.
-- If a section reveals a new artefact the operator wants (e.g. a competitor-claims-rebuttal in `08-market/`), `work-create` a new Task under the same Project, then proceed.
-- The Project's health signal (green/amber/red) is computed from Task state. Use `project-get` at the start of each turn to surface what's outstanding.
-
-## Research routing
-
-Every structured-research task — market sizing (TAM/SAM/SOM + CAGR), compliance research (DMCC / ICO ADM / EU AI Act), competitor scans, comparable rounds and exit comparables, named-acquirer enumeration — routes through the `research-assistant` specialist with the five `deep-research` skills (`deep-research`, `book-mirror`, `strategic-reading`, `academic-verify`, `data-research`). Dispatch the specialist; do not call `WebSearch` or `WebFetch` directly from a venture-studio skill. The specialist returns structured findings with citations the data-room artefacts can quote verbatim.
-
-## Tone
-
-Founder-facing. Direct, evidence-based, no flattery. You are the chief of staff for a one-person founding team — your job is to keep every artefact tracked and every deadline visible, while the operator focuses on the parts only they can do (customer conversations, founder signal, vision).
-
-## References
-
-The five skills shipped under this plugin carry their own SKILL.md detail:
-
-- `skills/office-hours/SKILL.md` — YC office-hours forcing questions in startup + builder modes; outputs the design-doc substrate every later artefact derives from.
-- `skills/brand-pack/SKILL.md` — brand identity (palette, typography, tone, logo) tokenised for the data-room artefacts to consume.
-- `skills/zero-to-prototype/SKILL.md` — 31 frameworks for customer discovery, validation, positioning, PMF measurement, landing page, PRD.
-- `skills/prototype-host/SKILL.md` — scaffolds the landing page or wedge prototype, allocates a port, edits the brand's cloudflared ingress, runs the dev server under a systemd-user unit, and verifies the public URL returns HTTP 200.
-- `skills/investor-data-room/SKILL.md` — full seed-raise pack: data room scaffold, business plan, term sheet, deck blueprint, prospectus, A4 print pipeline.

package/payload/platform/plugins/venture-studio/bin/scaffold.sh

@@ -1,116 +0,0 @@
-#!/usr/bin/env bash
-# Venture-studio data-room scaffold — deterministic enforcement of the
-# scaffold-first principle (Task 286 + feedback_doctrine_paragraph_is_not_a_gate).
-#
-# Creates exactly one Project (with nine pre-seeded artefact Tasks) in
-# the graph, then materialises the ten-section data-room directory tree
-# on disk. The venture-studio agent's downstream skills are gated on
-# both signals existing — see venture-studio/PLUGIN.md.
-#
-# Order of operations: graph write first, directories second. The CLI's
-# duplicate-name guard makes the script safely re-runnable after any
-# partial failure: a second run finds the existing Project, returns its
-# id, and retries the mkdir step.
-#
-# Usage:
-#   ACCOUNT_ID=<uuid> scaffold.sh <project-root> <business-name>
-#
-# Exit codes:
-#   0   scaffold complete (or already existed)
-#   2   bad arguments / missing ACCOUNT_ID
-#   1   graph write failed, directory mkdir failed, or CLI binary missing
-
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-# Deployed layout per packages/create-maxy-code/scripts/bundle.js:
-#   <install>/premium-plugins/venture-studio/bin/scaffold.sh
-#   <install>/platform/plugins/work/mcp/dist/cli/project-create-cli.js
-CLI_BIN="${SCRIPT_DIR}/../../../platform/plugins/work/mcp/dist/cli/project-create-cli.js"
-
-if [[ $# -ne 2 ]]; then
-  echo "scaffold.sh: usage: ACCOUNT_ID=<uuid> $0 <project-root> <business-name>" >&2
-  exit 2
-fi
-
-PROJECT_ROOT="$1"
-BUSINESS_NAME="$2"
-
-if [[ -z "${ACCOUNT_ID:-}" ]]; then
-  echo "scaffold.sh: ACCOUNT_ID env var required" >&2
-  exit 2
-fi
-
-if [[ ! -d "$PROJECT_ROOT" ]]; then
-  echo "scaffold.sh: project root does not exist: $PROJECT_ROOT" >&2
-  exit 2
-fi
-
-if [[ ! -f "$CLI_BIN" ]]; then
-  echo "scaffold.sh: project-create CLI not built or missing at: $CLI_BIN" >&2
-  exit 1
-fi
-
-DATA_ROOM="${PROJECT_ROOT}/.docs/data-room"
-
-# Nine pre-seeded artefact tasks — order and names match
-# premium-plugins/venture-studio/PLUGIN.md § First-conversation routing.
-# Section order is preserved so the agent can walk them sequentially.
-# Prototype-host is slotted between Stage 2 (wedge + landing copy) and
-# Stage 3 (business plan): brand-pack and wedge are hard prerequisites
-# (the skill consumes 06-product-ip/brand/ tokens and 01-narrative/LANDING.md);
-# hosting before business plan keeps the founder's wedge-validation loop
-# (live URL) ahead of investor-pack work.
-PAYLOAD=$(cat <<JSON
-{
-  "accountId": "${ACCOUNT_ID}",
-  "name": "${BUSINESS_NAME}",
-  "description": "Venture-studio data room for ${BUSINESS_NAME}. Root: ${DATA_ROOM}",
-  "tier": "full",
-  "workItems": [
-    {"name": "Stage 1 — Office-hours design doc", "description": "Produces 01-narrative/office-hours-design.md via the office-hours skill."},
-    {"name": "Stage 2 — Wedge validation + landing page + PRD", "description": "Produces 01-narrative/{PMF,LANDING,PRD}.md via the zero-to-prototype skill."},
-    {"name": "Brand pack", "description": "Produces brand guidelines + summary + color palette + typography system + tone-of-voice (voice/messaging/copy) + logo guidelines into 06-product-ip/brand/ via the brand-pack skill."},
-    {"name": "Prototype host", "description": "Public URL for the landing page and/or wedge prototype via cloudflared ingress + systemd-managed dev server (skill: prototype-host)."},
-    {"name": "Stage 3 — Business plan", "description": "Produces 01-narrative/business-plan.md via investor-data-room Stage 3."},
-    {"name": "Stage 3b — Term sheet", "description": "Produces html/prospectus/term_sheet.html via investor-data-room Stage 3b."},
-    {"name": "Stage 4 — Deck blueprint", "description": "Produces 01-narrative/deck-blueprint.md via investor-data-room Stage 4."},
-    {"name": "Stage 4b — Prospectus", "description": "Produces html/prospectus/index.html via investor-data-room Stage 4b."},
-    {"name": "Stage 5 — Rendered PDFs", "description": "Produces html/{business-plan,prospectus,deck}/*.pdf via investor-data-room Stage 5."}
-  ]
-}
-JSON
-)
-
-# Graph write first. CLI returns {projectId, existing:bool} on stdout;
-# on any failure it exits non-zero with a literal stderr message that
-# propagates here verbatim — no prose-parsing for control flow
-# (memory: feedback_no_stdout_parsing_for_control_flow).
-RESULT=$(node "$CLI_BIN" "$PAYLOAD")
-echo "scaffold.sh: project-create CLI returned: $RESULT"
-
-# Directories second. The agent's pre-flight gate keys on the existence
-# of 01-narrative/ (it AND-checks with project-list); creating it last
-# means partial state (graph-only) is naturally invisible to the gate
-# until mkdir succeeds.
-for section in \
-  01-narrative \
-  02-corporate-legal \
-  03-cap-table \
-  04-financials \
-  05-team \
-  06-product-ip \
-  07-customers \
-  08-market \
-  09-traction-metrics \
-  10-supporting; do
-  mkdir -p "${DATA_ROOM}/${section}"
-done
-
-# Hosted-prototype source roots live alongside the numbered sections under
-# data-room/. The prototype-host skill populates this with one subdir per
-# surface (landing/, prototype/, etc.); creating the parent here so the
-# directory exists before the first invocation.
-mkdir -p "${DATA_ROOM}/prototype"
-
-echo "scaffold.sh: data-room scaffolded at ${DATA_ROOM}"