@zalom/plastic 2.0.0-alpha.27 → 2.0.0-alpha.29

package/skills/intent-speccing/SKILL.md

@@ -1,136 +0,0 @@
----
-name: plastic-intent-speccing
-description: >-
-  Thinking mode for an intent: the conversation that turns an idea into rulings, the
-  research that backs them, and the action files that say how the work runs. Use when the
-  user wants to think a request through before building it, says "let's design this",
-  "brainstorm", "grill me", "research this first", "spec this intent", "write the spec",
-  or when a prompt is too vague to run directly and the direct skill routes here. Also
-  fires on an indirect ask that never names a spec, such as "turn what we just discussed
-  into the contract the work runs from." Absorbs what the former intent-brainstorming,
-  intent-grilling, and intent-researching skills used to do (intent 304).
-user-invocable: true
----
-
-# Intent Speccing: thinking mode
-
-Speccing is optional: a ruled or small-enough intent skips straight to How/Exec, and this
-skill runs only when the request genuinely needs a design conversation first.
-
-One skill for the whole thinking conversation on an intent. It asks one question at a time,
-records every owner ruling the moment it lands, grills when asked, deposits research in
-`resources/`, and ends by writing the action files the work runs from and consolidating the
-rulings into `spec.md`. There is no separate brainstorm, grill, or research skill; those are
-the modes below.
-
-## Active intent
-
-Resolve the active intent before anything else: read `~/.plastic/projects.yml`, match the
-working directory against registered project paths (a match means the project store at
-`~/.plastic/projects/{slug}/store/`, no match means `~/.plastic/store/`), then read that
-store's `INDEX.md` under `## Active`. Exactly one active intent is the one to work; several
-means ask which; none means stop and say so ("No active intent. Create one first with
-/plastic-intent-creating"). Every artifact goes into `{store}/{id}--{slug}/`; never write
-outside it.
-
-## The conversation
-
-QMD-first: before scanning the store by hand for prior decisions, specs, or research, run
-`ruby ~/.plastic/scripts/qmd-sync search "<terms>"` and open the authoritative intent file for
-any hit you act on. The command is a no-op when QMD is absent.
-
-1. **Context first.** Check the project state (files, docs, recent commits) and the intent's
-   `## Context` and `## Insights`. Assess scope: a request that describes several independent
-   subsystems is decomposed first, one thinking conversation per piece, before any detail
-   question is spent.
-2. **One question per message, in prose.** No multiple-choice chips; a short menu of named
-   options is fine when the choice is genuinely enumerable, phrased as a sentence. Focus on
-   purpose, constraints, and success criteria. Before asking how something works, look:
-   in a codebase the answer is usually on disk.
-3. **Propose two or three approaches** with trade-offs, leading with the recommendation and
-   the reason for it. YAGNI: strip what the design does not need.
-4. **Present the design in sections** scaled to their complexity (a few sentences when
-   straightforward, up to 300 words when nuanced): architecture, components, data flow,
-   error handling, testing. Get a ruling after each section. Read
-   `references/design-principles.md` before proposing a design for the unit-boundary and
-   existing-codebase guidance (follow established patterns, no unrelated refactoring).
-5. **Record every ruling as it lands.** The moment the owner rules, before the next question:
-   ```
-   ruby ~/.plastic/scripts/insight-append {intent_dir} "<ruling text>" --stage Why --author human
-   ```
-   Never batch. A later ruling that conflicts with an earlier one gets a new insight naming
-   the superseded one; both stay on record and the later wins. When presenting a batch of
-   options for the owner to pick from, read `~/.plastic/_decision-tables.md` and follow the
-   numbered-table procedure.
-
-No implementation starts until a design has been presented and ruled on. That holds for a
-config change and a one-function utility as much as for a subsystem; the design can be three
-sentences, but it is presented.
-
-### Grill mode
-
-When the owner says "grill me" or asks to stress-test a plan or design, the same conversation
-turns relentless. Identify the root in one sentence and restate it. Walk the decision tree
-branch by branch: state the branch, ask a specific question, lead with your own recommended
-answer, resolve before moving on, name dependencies between decisions and resolve the
-upstream one first. Do not accept "it depends" without "on what?"; do not skip edge cases; do
-not assume when you can verify; challenge assumptions ("why not the alternative?"). Every
-three or four questions, summarize what is decided. At natural checkpoints, about every ten
-questions, offer to continue or to pause and capture what is decided; a pause records every
-ruling so far and stops. When all branches are resolved, list the decisions and the deferred
-items, then offer the hand-off below.
-
-### Research mode
-
-When a question needs evidence rather than a ruling, research it and deposit the report in
-`{intent_dir}/resources/{type}--{topic}.md`, with `{type}` one of `deep-research`,
-`competitive-analysis`, `technical-spike`, `reference`, `landscape-survey` and `{topic}` in
-kebab-case. Choose the depth and say why: shallow (one or two searches plus a look at the
-code, minutes) for a narrow factual question; deep (several sources, cross-checked, a
-landscape or an architectural decision, or when a wrong answer would cause an architectural
-mistake) through the harness's deep-research capability when it has one, else a manual
-fan-out of searches. The report carries a summary, findings with citations, sources, and a
-"Relevance to intent" section; tables for findings and comparisons. Log one line in the
-intent's `## Insights` naming the file and the key finding. Research does not chain to
-another step; the conversation decides what to do with it.
-
-## Closing the conversation
-
-When the rulings are enough to build from:
-
-1. **Write the action files.** Every ruling that says how the work runs lands in
-   `actions/ACTION_N.md` (at least one real file, no placeholder): the files to touch, the
-   order, the tests that prove each step, the rules. The action files are what direct mode or
-   an auto team executes; they exist before the work runs.
-2. **Consolidate `spec.md`** from the rulings, section by section in template order. Read
-   `references/per-section-fill-rules.md` when filling the template. Build the ruling ledger
-   in fixed order first: `## Context` and `### Decisions`, then `## Insights` newest-last so a
-   later ruling supersedes an earlier one, then `resources/discovery--<slug>.md`, then any
-   other `resources/*.md`. Encode every ruling into its section; a collapsed single-line
-   section is complete when it names everything. If a section cannot be filled from the
-   ledger, stop and ask for the missing ruling; never invent scope. A spec.md left as the
-   placeholder is backfilled from the record at close (`## Problem`, `## Decisions`,
-   `## Acceptance Criteria`; the rest stays stub text), so consolidate only when the
-   rulings say more than the record already does.
-3. **Self-verify.** Read `references/self-verify-checklist.md` before presenting; fix any
-   failing check and re-verify from the top.
-4. **Present and hand off.** Print `ruby ~/.plastic/scripts/report-screen plan <intent_dir>` as
-   the first characters of the reply: nothing before it, no fence, or the hook cannot paint it.
-   It carries Asked, Decisions, Steps, Mode, Reviewer, then the Steps and Risks tables, filled
-   from `spec.md` and the action files just written, never restated by eye. Then offer the
-   routes: run it now inline when the work is small enough for direct mode; hand to
-   `plastic-auto` when the owner says auto and the checklist above passes (all decisions
-   resolved, scope bounded, dependencies named, success criteria defined); or keep thinking.
-
-Report, in this order: which files were written (`spec.md` new or rewritten, the action
-files), the count of acceptance criteria, which `## Insights` rulings superseded an earlier
-decision and where each landed, and the route chosen. If step 2 stopped for a missing
-ruling, report that instead: which section, what is missing, the question put to the owner.
-
-## References
-
-| Trigger | Read |
-|---|---|
-| Before proposing a design (unit boundaries, existing codebases) | `references/design-principles.md` |
-| Filling the spec template (closing step 2) | `references/per-section-fill-rules.md` |
-| Self-verifying before presenting (closing step 3) | `references/self-verify-checklist.md` |

package/skills/intent-speccing/evals/evals.json

@@ -1,126 +0,0 @@
-{
-  "skill_name": "plastic-intent-speccing",
-  "notes": "Intent 163. Scopes: description triggering (1-4) and behavior (5-8: all-8-sections output, mandatory superseding-ruling case, STOP-and-ask gap rule, tabular alternatives with no em-dash). No dedicated Ruby test file backs this skill yet (natural-language guided command), so all assertions are result: expect-pass pending a real observed run, per the evals.json convention.",
-  "evals": [
-    {
-      "id": 1,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "The active intent is at Why with Context and Decisions recorded. Consolidate the enriched Why into spec.md.",
-      "expected_output": "Activates plastic-intent-speccing (the user-typed Why-to-How consolidation command).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-intent-speccing",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 2,
-      "scope": "triggering",
-      "set": "train",
-      "prompt": "Turn what we just discussed into the contract the planner builds from.",
-      "expected_output": "Activates plastic-intent-speccing; an indirect trigger that names neither the skill nor spec.md.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE == plastic-intent-speccing",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 3,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "Brainstorm this intent.",
-      "expected_output": "Activates plastic-intent-speccing (brainstorming is a mode of the thinking conversation since intent 304).",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE != plastic-intent-speccing",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 4,
-      "scope": "triggering",
-      "set": "validation",
-      "prompt": "Write the plan.",
-      "expected_output": "Does NOT activate plastic-intent-speccing; a plan is written from the action files by the executing skill.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "code",
-          "check": "router CHOICE != plastic-intent-speccing",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 5,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "Intent Y is at Why: Context describes the problem and goal, and 5 Decisions are recorded resolving scope, approach, and one rejected alternative. Consolidate into spec.md.",
-      "expected_output": "Produces spec.md starting at the Spec heading; all 8 template sections present once, in template order (Problem, Goals, Non-Goals, Approach, Alternatives Considered, Decisions, Acceptance Criteria, Open Questions); no template placeholder text remains; every recorded Decision is encoded into its matching section.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "The file starts at the Spec heading; all 8 sections appear once each, in template order; no placeholder text; every Decision traces to a section",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 6,
-      "scope": "behavior",
-      "set": "train",
-      "prompt": "Intent Z has Decisions recording D4: ship the setting as a CLI flag. A later Insights entry, timestamped after D4, reads: superseding ruling, ship as a config-file setting instead of a CLI flag, per user correction. Consolidate into spec.md.",
-      "expected_output": "The produced spec Approach and Decisions sections encode the LATER ruling (config-file setting); the superseded earlier Decision (CLI flag) does not stand as the shipped design in any section. The Decisions section notes that the later Insight supersedes D4.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "Approach and Decisions state the config-file setting, not the CLI flag; no section still asserts the CLI-flag path as the shipped design",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 7,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "Intent W is at Why. Context says the team wants error handling that is more resilient, but no Decision or Insight states which specific mechanism (retry, circuit breaker, or fallback) was chosen. Consolidate into spec.md.",
-      "expected_output": "Stops at step 5 (the gap rule) instead of inventing an Approach; asks the user which error-handling mechanism was decided, naming the missing ruling and the section it blocks.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "no invented Approach or Decisions content fills the gap; the agent asks for the missing ruling instead of guessing a default mechanism",
-          "result": "expect-pass"
-        }
-      ]
-    },
-    {
-      "id": 8,
-      "scope": "behavior",
-      "set": "validation",
-      "prompt": "Intent V has Decisions recording 3 rejected alternatives, each with a one-line reason it lost. Consolidate into spec.md.",
-      "expected_output": "Alternatives Considered renders as a table (Alternative, Not chosen because), not the bullet-dash form shown in the template; the produced spec file contains no em-dashes or en-dashes anywhere in the file.",
-      "files": [],
-      "assertions": [
-        {
-          "type": "human",
-          "check": "Alternatives Considered is a two-column table with one row per rejected alternative; a full-file dash-glyph scan of the produced spec file finds none",
-          "result": "expect-pass"
-        }
-      ]
-    }
-  ]
-}

package/skills/intent-speccing/references/design-principles.md

@@ -1,44 +0,0 @@
-# Design Principles: Unit Boundaries and Existing Codebases
-
-General good-developer guidance behind two parts of the Process: how to design for
-isolation and clarity, and how to behave in an existing codebase. Also holds the
-Process Flow diagram (the same ordered flow the Checklist already states as numbered
-steps).
-
-## Design for isolation and clarity
-
-- Break the system into smaller units that each have one clear purpose, communicate through well-defined interfaces, and can be understood and tested independently
-- For each unit, you should be able to answer: what does it do, how do you use it, and what does it depend on?
-- Can someone understand what a unit does without reading its internals? Can you change the internals without breaking consumers? If not, the boundaries need work.
-- Smaller, well-bounded units are also easier for you to work with - you reason better about code you can hold in context at once, and your edits are more reliable when files are focused. When a file grows large, that's often a signal that it's doing too much.
-
-## Working in existing codebases
-
-- Explore the current structure before proposing changes. Follow existing patterns.
-- Where existing code has problems that affect the work (e.g., a file that's grown too large, unclear boundaries, tangled responsibilities), include targeted improvements as part of the design - the way a good developer improves code they're working in.
-- Don't propose unrelated refactoring. Stay focused on what serves the current goal.
-
-## Process Flow (diagram)
-
-The Checklist above already states this ordered flow as numbered steps 1-6; this
-diagram is the same flow in a visual form.
-
-```dot
-digraph brainstorming {
-    "Explore project context" [shape=box];
-    "Grill in prose" [shape=box];
-    "Propose 2-3 approaches" [shape=box];
-    "Present design sections" [shape=box];
-    "Owner rules?" [shape=diamond];
-    "Collect rulings\n(persist each immediately)" [shape=box];
-    "Invoke /plastic-intent-speccing" [shape=doublecircle];
-
-    "Explore project context" -> "Grill in prose";
-    "Grill in prose" -> "Propose 2-3 approaches";
-    "Propose 2-3 approaches" -> "Present design sections";
-    "Present design sections" -> "Owner rules?";
-    "Owner rules?" -> "Present design sections" [label="no, revise"];
-    "Owner rules?" -> "Collect rulings\n(persist each immediately)" [label="yes"];
-    "Collect rulings\n(persist each immediately)" -> "Invoke /plastic-intent-speccing";
-}
-```

package/skills/intent-speccing/references/per-section-fill-rules.md

@@ -1,92 +0,0 @@
-# Per-Section Fill Rules
-
-The single shared method for turning the rulings into `spec.md`. `plastic-intent-speccing`
-(the thinking conversation) and the auto orchestrator both point here; neither restates these
-rules. One fill rule per template section, in template order.
-
-Read the ruling ledger first (built in step 2 of the SKILL.md sequence): `## Context` plus
-`### Decisions`, then `## Insights` newest-last (a later ruling supersedes an earlier
-conflicting one), then `resources/discovery--<slug>.md`, then any other `resources/*.md`.
-Every rule below names which part of that ledger feeds the section.
-
-## 1. Problem
-
-Source: the intent's `## Intent` line plus the problem narrative in `## Context`.
-
-State the problem as a problem, not a solution: what is broken, missing, or costly today, for
-whom. Do not describe the fix here, that belongs in Approach. If `## Insights` records a later
-reframe of the problem (a scope correction, a retargeted root cause), the later framing wins.
-
-## 2. Goals
-
-Source: explicit goal statements in `## Context`, plus any `### Decisions` entry that commits to
-delivering a specific outcome.
-
-One bullet per goal, each a concrete, observable outcome the delivery must reach. Encode every
-Decision that commits to an outcome as its own bullet, do not compress two Decisions into one
-vague goal. A single-line collapsed Goals section is complete if it names every
-outcome; do not pad it with restated Problem text.
-
-## 3. Non-Goals
-
-Source: `### Decisions` entries that name something explicitly out of scope, and `## Insights`
-rulings that narrowed scope after the initial brainstorm.
-
-One bullet per excluded item, each naming what is out and, briefly, why (a sibling intent owns
-it, a scope-reframe ruling cut it, it is a future intent). If a later Insight narrows scope
-further than an earlier Decision, the Insight's narrower boundary is the one recorded.
-
-## 4. Approach
-
-Source: every `### Decisions` entry that describes HOW, resolved into one coherent narrative.
-
-Write prose, not a decision list. Synthesize the chosen path so it reads as one design: what
-gets built, in what shape, and how the pieces fit. Every Decision that shapes the approach must
-be traceable to a sentence here, but do not restate each Decision by its Dn label, that
-enumeration belongs in the Decisions section. Use a table only where the Approach itself compares
-options inline (rare; usually that comparison belongs in Alternatives Considered instead).
-
-## 5. Alternatives Considered
-
-Source: `### Decisions` entries and `## Insights` rulings that name a rejected path and the
-reason it lost.
-
-Render as a table, not the template's bullet-dash form, so the reason column stays uniform and
-free of dash-glyph punctuation:
-
-| Alternative | Not chosen because |
-|---|---|
-| <rejected path> | <the ruling's stated reason, paraphrased> |
-
-One row per rejected alternative. If two Decisions reject variants of the same alternative, merge
-them into one row rather than duplicating it. Never use an em-dash or en-dash in the reason
-column; write "because" or a colon instead.
-
-## 6. Decisions
-
-Source: `### Decisions` verbatim, in the order recorded, one entry per Decision.
-
-One bullet per decision, each keeping its `Dn` label and its ruling in paraphrase or verbatim.
-Do not drop a decision because it seems minor: every Decision must appear here even if its effect
-on the shipped Approach or Goals is small. When `## Insights` records a later ruling that
-supersedes an earlier Decision, add or amend the bullet to state the later ruling and note which
-earlier Decision it supersedes.
-
-## 7. Acceptance Criteria
-
-Source: any criteria named directly in `### Decisions` or `## Insights`, plus one inferred
-criterion per Goal that has no explicit criterion on record.
-
-One checkbox bullet per criterion, each concretely checkable: a fact a reviewer can confirm true
-or false by inspection, a command, or a file, never a vague quality judgment. Every Goal must map
-to at least one criterion. A criterion that cannot be checked without more interpretation is not
-done, rewrite it or ask (the gap rule, SKILL.md step 5).
-
-## 8. Open Questions
-
-Source: any question raised during Why that has no matching Decision or Insight resolving it.
-
-List each unresolved question as its own bullet. If every question raised during Why has a
-resolving Decision or Insight, write `None` and, directly under it, one line per resolved
-question naming which Decision or Insight resolved it (so a reader can audit the resolution
-instead of taking "None" on faith).

package/skills/intent-speccing/references/self-verify-checklist.md

@@ -1,37 +0,0 @@
-# Self-Verify Checklist
-
-Run this before presenting spec.md (SKILL.md step 7). Ten checks: the four points of
-brainstorming's proven Spec Self-Review, merged with the six binding output checks this skill
-adds. Fix any failing check, then re-verify from the top; do not present a spec that fails one of
-these.
-
-## Brainstorming's four Spec Self-Review points
-
-1. **Placeholder scan.** Any "TBD", "TODO", incomplete section, or vague requirement left in the
-   draft? Fix it before moving on.
-2. **Internal consistency.** Do any two sections contradict each other? Does the Approach
-   actually match what Goals and Acceptance Criteria describe?
-3. **Scope check.** Is this spec focused enough for a single implementation plan, or does the
-   Problem actually describe more than one independent piece of work that needs decomposing
-   first?
-4. **Ambiguity check.** Could any requirement be read two different ways? If so, pick one
-   reading and rewrite the line so only that reading survives.
-
-## The six binding output checks
-
-5. **No template placeholder text remains.** No literal `<intent name>`, `<alternative>`, `...`,
-   sample bracket text, or other template filler from `templates/spec.md` survives anywhere in
-   the artifact.
-6. **No header line.** The file starts at the `# Spec:` heading; there is no `Tier:` line (removed in 2.0, intent 304).
-7. **All 8 sections present, in template order.** Problem, Goals, Non-Goals, Approach,
-   Alternatives Considered, Decisions, Acceptance Criteria, Open Questions, each present once, in
-   that order, none merged into another.
-8. **Every `## Insights` ruling is traceable to a spec line.** Walk the Insights log entry by
-   entry: each one lands in some section of the spec. Where two rulings conflict, the later one
-   (further down the log) is the one that landed, and the earlier one does not silently persist
-   in a different section.
-9. **Acceptance criteria are concretely checkable.** Each Acceptance Criteria bullet reads as a
-   fact a reviewer can confirm true or false by inspection, a command, or a named file, not a
-   quality judgment a reviewer would have to interpret.
-10. **No em-dashes or en-dashes anywhere in the artifact.** Scan the full file; replace any dash
-    glyph with a comma, period, parenthesis, or colon.

package/skills/project-creating/SKILL.md

@@ -1,162 +0,0 @@
----
-name: plastic-project-creating
-description: >-
-  Create a new project from an implementation intent. Sets up project directory,
-  git init, AGENTS.md with founding intent decisions, plastic-install --local,
-  tactical mirror, projects.yml registration, and framework scaffolding.
-  Use when an implementation intent spawns a project, or manually by user.
-user-invocable: true
----
-
-# Creating a Project
-
-## Precondition
-
-An active intent must exist with enough context to define a project — at minimum: name/slug, path, and key decisions from `## Context > ### Decisions`.
-
-## Workflow
-
-### 1. Determine Project Identity
-
-- **Slug:** derived from intent name (kebab-case, 2-4 words) or user-specified
-- **Path:** from `~/.plastic/config.yml` `project_roots` (first entry as default), or user-specified
-- Confirm path with user before creation
-
-### 2. Create Project Directory
-
-```bash
-mkdir -p <project_root>/<slug>
-cd <project_root>/<slug>
-git init
-```
-
-### 3. Run `plastic-install --local`
-
-Invoke `plastic-install --local` in the project directory. This creates:
-```
-.plastic/
-├── store/
-├── INDEX.md
-└── config.yml
-```
-
-### 4. Populate AGENTS.md
-
-Create `AGENTS.md` in the project root from the skeleton in
-`references/project-scaffolding.md` ("AGENTS.md skeleton"): read it now and fill in
-the project name, governing intent IDs, decisions, and project-specific rules.
-
-### 5. Create Tactical Mirror
-
-Create the first intent in the project's store at `~/.plastic/projects/{slug}/store/`
-using the frontmatter, sections, and INDEX.md line in `references/project-scaffolding.md`
-("Tactical mirror intent"), including the Hub multi-intent variant if there is more
-than one founding intent.
-
-**Directory:** `~/.plastic/projects/{slug}/store/1--{slug}/`
-**File:** `~/.plastic/projects/{slug}/store/1--{slug}/1--{slug}.md`
-
-### 6. Register in projects.yml
-
-Read `~/.plastic/projects.yml` and add the entry shown in
-`references/project-scaffolding.md` ("projects.yml registration block"). For
-Hub-spawned projects, `parent` references the primary founding intent.
-
-### 7. Provision the Project Store
-
-The `provision-project-store` verb is the single source of truth for store
-creation. Run it after the project is registered in step 6 (the provisioner
-requires registration), and before the QMD step:
-
-```bash
-ruby ~/.plastic/scripts/provision-project-store <slug>
-```
-
-This ensures `~/.plastic/projects/<slug>/store/` exists with `.gitkeep`, and
-writes `INDEX.md` and `project.yml` only if missing. It is idempotent, so it is
-safe even when the tactical mirror in step 5 already created the store directory.
-Do not create the store with an inline `mkdir`; the provisioner is the only place
-a store is made. For a project that is already registered but store-less, use the
-`plastic-doctor` skill's provisioning section instead.
-
-### 8. Mark Global Intent(s) Completed
-
-For each founding intent:
-
-1. Write `## Outcome` in the intent file:
-   > "Spawned project `<slug>` at `<path>`. Decisions carried to AGENTS.md. Tactical mirror: `project-<slug>:1`."
-2. Write `outcome.md` with full details (all decisions, project path, tactical mirror ID)
-3. Update `chain` to include `project-<slug>:1`
-4. Move from `## Active` to `## Completed` in `~/.plastic/INDEX.md` (with today's date)
-
-### 9. Framework Scaffolding
-
-If decisions specify a framework, run the appropriate scaffolding command AFTER steps 3-4 (so scaffolding doesn't overwrite Plastic files or AGENTS.md):
-
-| Framework | Command |
-|---|---|
-| Rails | `rails new <slug> [options from decisions] --skip-git` (skip git — already initialized) |
-| Node/npm | `npm init -y` |
-| Ruby gem | `bundle gem <slug>` |
-| Other | As specified in decisions |
-
-After scaffolding, verify AGENTS.md and `.plastic/` still exist. If scaffolding overwrote them, restore.
-
-### 10. Auto-commit Both Stores
-
-```bash
-cd ~/.plastic && git add . && git commit -m "feat: spawn project <slug> from intent <ID>"
-cd <project> && git add . && git commit -m "feat: initialize project from intent <ID>"
-```
-
-### 11. Register the project store with QMD (optional)
-
-If QMD is installed, register the new project's store as a search collection:
-
-```bash
-ruby ~/.plastic/scripts/qmd-sync register --store ~/.plastic/projects/<slug>/store
-```
-
-`qmd-sync` no-ops when QMD is absent, so run it unconditionally. This adds the
-`plastic-<slug>` collection and indexes it.
-
-### 12. Self-Check with validate-project
-
-Before announcing, verify the spawn actually landed everything it claims to
-have created. Run:
-
-```bash
-ruby ~/.plastic/scripts/validate-project <slug>
-```
-
-If this exits 0, proceed to step 13. If it exits non-zero, STOP: do not
-proceed to Announce. Read the `missing:` and error lines it printed to
-stderr, fix the named gap(s), for example:
-
-- missing `project.yml` or `INDEX.md` or `store/`: re-run
-  `ruby ~/.plastic/scripts/provision-project-store <slug>` (step 7), then
-  re-check
-- missing project-root `AGENTS.md`: repeat step 4 (populate AGENTS.md at the
-  project root, not `~/.plastic/projects/<slug>/`)
-- project directory missing on disk: repeat step 2
-- not registered in projects.yml: repeat step 6
-
-Re-run `validate-project <slug>` after each fix until it exits 0. Only a
-project spawn that passes this self-check moves on to be announced as
-created. A spawn that never verifies itself is exactly the bug this step
-exists to close (intent 190; the intent-26 spawn shipped with no
-`project.yml` and no root `AGENTS.md`, caught only weeks later by a doctor
-sweep).
-
-### 13. Announce
-
-Log in `## Insights` of each founding intent:
-> "Project `<slug>` created at `<path>`. Tactical mirror: `project-<slug>:1` (autonomous)"
-
-Announce to user:
-> "Project `<slug>` created at `<path>`. AGENTS.md populated with [N] decisions from [founding intent IDs]. Tactical mirror `1` is now the active intent in the project store."
-
-## References
-
-- Read `references/project-scaffolding.md` before steps 4-6, for the AGENTS.md skeleton, the tactical mirror intent format, and the projects.yml registration block
-- Read `references/hubs-projects.md` for the full hub/project relationship model, project creation flow, and cross-linking conventions

package/skills/project-creating/references/hubs-projects.md

@@ -1,55 +0,0 @@
-# Hubs and Projects
-
-## Hubs
-
-A Hub is a cloud of intents around related topics. Hubs emerge naturally from
-Folgezettel branching — intents that spawn in the same direction cluster.
-
-- A Hub can spawn a Project. The Hub holds the founding ideas.
-- A single intent can also spawn a Project.
-- Hub-spawned projects revolve around different ideas around related topics.
-- Intent-spawned projects revolve around the single founding intent.
-- A Project is the deliverable outcome of one or more intents.
-
-Hubs are represented as clusters in INDEX.md.
-
-## Projects — Full Detail
-
-A Project is a deliverable grouping of intents. Projects have two stores:
-
-- **Global store** (`~/.plastic/store/`): strategic intents
-- **Project store** (`~/.plastic/projects/{slug}/store/`): tactical intents
-
-`projects.yml` maps project slugs to codebase paths:
-```yaml
-projects:
-  plastic:
-    path: "/path/to/plastic"
-    remote: "git@github.com:org/plastic.git"
-    registered: '2026-05-26'
-    status: active
-```
-
-Config resolution: `~/.plastic/projects/{slug}/config.yml` overrides `~/.plastic/config.yml`.
-
-Cross-linking: project intents reference global intents via `[[global:ID]]`. Global intents reference project intents via `[[project-slug:ID]]`.
-
-## Privacy and Collaboration
-
-**Plastic is personal.** All intent data lives under `~/.plastic/` — one location,
-one git repo, never pushed. Each person has their own intent store.
-
-Collaboration happens through pull requests and project conventions, not shared intents.
-When an intent delivers something that changes how a project works, the decision gets
-written into the project's shared files (README, docs, config). The intents themselves
-are private working memory.
-
-## Project Creation Flow
-
-When an implementation intent spawns a project:
-1. Determine project path from config `project_roots` or intent context
-2. `gh repo create --private` (agent-created repos are always private by default)
-3. Set up project directory, git init, AGENTS.md with founding intent decisions
-4. Register in `projects.yml`
-5. Create tactical mirror in project store
-6. The global intent completes; the tactical mirror becomes the active intent