@se-studio/skills 1.9.9 → 1.9.11

package/CHANGELOG.md

@@ -1,5 +1,17 @@
 # @se-studio/skills
 
+## 1.9.11
+
+### Patch Changes
+
+- 3ecda13: Document that different UI/behaviour needs distinct `componentType` / `collectionType`; `cmsLabel` is for authors (+ trackingLocation), never a runtime layout/renderer switch. Update create-component, create-collection, and contentful-cms-core (synced into contentful-cms bundled `core` skill).
+
+## 1.9.10
+
+### Patch Changes
+
+- e737e76: Allow agents to promote se-core-product `dev` → `main` (npm Release Main) only after the same ask + second-confirm gate as customer production. Updates `production-merge.md`, agent-session skill, and related docs.
+
 ## 1.9.9
 
 ### Patch Changes

package/LICENSE.pstack

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Lauren Tan
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -89,6 +89,10 @@ Do not edit `packages/contentful-cms/skills/` directly. See `packages/contentful
 
 **Do not use `.claude/skills/` in the repo** as a skill source — it is untracked and local. Use `.agents/skills/` (via `pnpm skills:sync`) or `cms-edit skill install`.
 
+## Vendored pstack (trial)
+
+SE Studio may vendor a **subset** of [cursor/plugins pstack](https://github.com/cursor/plugins/tree/main/pstack) skills under `skills/` for a se-core-product-only trial. See [`VENDOR_PSTACK.md`](./VENDOR_PSTACK.md) for the pin, adopt/exclude list, Auto-only adaptations, and MIT attribution (`LICENSE.pstack`). Gate rule: [`.cursor/rules/pstack-trial-gates.mdc`](../../.cursor/rules/pstack-trial-gates.mdc). Do **not** run `/setup-pstack` or install excluded skills (`poteto-mode`, `arena`, `swarm`, Benny, etc.). No npm release of these trial skills until Nick approves a customer rollout.
+
 ## References
 
 - [Anthropic skill authoring best practices](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices)

package/VENDOR_PSTACK.md

@@ -0,0 +1,52 @@
+# Vendored pstack skills (SE Studio trial)
+
+**Status:** se-core-product Project trial only. Not a customer rollout.  
+**Upstream:** [cursor/plugins `pstack/`](https://github.com/cursor/plugins/tree/main/pstack)  
+**Pinned commit:** `1b6d44ff26d4e242f4e8f68c391e6d2f7ca16def` (`main` as of vendor date)  
+**Plugin version observed:** `0.15.20` (`pstack/plugin.json`)  
+**License:** MIT — see [`LICENSE.pstack`](./LICENSE.pstack)
+
+## What was vendored
+
+Canonical copies live under `packages/skills/skills/<name>/` (synced to `.agents/skills/` via `pnpm skills:sync`).
+
+### Skills (6)
+
+| Directory | Adaptation |
+|-----------|------------|
+| `interrogate` | Auto-only reviewers; panel ≤1–2; no `pstack-models.mdc` / setup-pstack; no xhigh/max |
+| `blast-radius` | Dual-Auto optional instead of arena; soft refs to uninstalled skills |
+| `how` | Auto/`inherit-parent` for explorers and explainers; complex path capped at ≤4 explorers + 1 explainer (≈5 Auto Tasks); soft-dep `why` skip-if-missing |
+| `architect` | **Arena disabled** — single Auto sketch agent; still requires ≥2 design candidates; Phase C does not waive SE gates; runner-prompt aligned to single-Auto; soft-deps skip-if-missing |
+| `typescript-best-practices` | Frontmatter only (`paths` / `disable-model-invocation` moved to body notes) |
+| `tdd` | Frontmatter only |
+
+### Principles (12)
+
+`principle-type-system-discipline`, `principle-prove-it-works`, `principle-test-behavior-not-implementation`, `principle-fix-root-causes`, `principle-boundary-discipline`, `principle-subtract-before-you-add`, `principle-make-operations-idempotent`, `principle-sequence-verifiable-units`, `principle-minimize-reader-load`, `principle-encode-lessons-in-structure`, `principle-guard-the-context-window`, `principle-model-the-domain`
+
+## Explicitly not vendored
+
+| Category | Names |
+|----------|-------|
+| Modes / setup | `poteto-mode`, `setup-pstack` |
+| Principles | `principle-never-block-on-the-human`, `principle-migrate-callers-then-delete-legacy-apis` |
+| Benny | `automations/benny/**` |
+| Fan-out | `swarm`, `arena` |
+| Adapt later | `recall`, `create-verification-skill`, `maintain-verification-skill` |
+
+## Frontmatter contract
+
+Upstream `SKILL.md` files used extra keys (`disable-model-invocation`, `paths`). SE Studio allows **only** `name` and `description` (see `packages/skills/README.md`). Extra keys were moved into an “SE Studio vendoring notes” section in each skill body.
+
+## Gate rule
+
+Repo always-applied rule: [`.cursor/rules/pstack-trial-gates.mdc`](../../.cursor/rules/pstack-trial-gates.mdc). SE Studio approval gates win over any pstack principle.
+
+## Publish posture
+
+**No** `@se-studio/skills` changeset for this trial. Skills sync in this monorepo only. Customer Project rollout is a separate decision after the two-week trial.
+
+## Operator note (not in repo)
+
+Do not run `/setup-pstack` or `/add-plugin pstack` for this trial. If `~/.cursor/rules/pstack-models.mdc` exists on a machine, delete or replace it with an Auto-only stub before trial chats.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@se-studio/skills",
-  "version": "1.9.9",
+  "version": "1.9.11",
   "description": "SE Studio agent skills for marketing site development with Contentful CMS",
   "repository": {
     "type": "git",

package/references/agent-session/customer-agents-block.md

@@ -19,7 +19,7 @@ Default mode for this repo: **site-first**.
 - Agents may commit and push **`develop`** and **`feature/*`**.
 - Merge feature → `develop` only when Nick approves **in chat** (no `nick-go` GitHub label).
 - Customer production (`main`, HSD `production`) **only** after the human-ask + confirm gate (`production-merge.md` in `@se-studio/skills`). The human must ask to merge integration → production in this conversation; the agent must restate site, branches, and that it publishes production; then wait for a second **yes**.
-- **Never** treat “deploy”, “ship it”, or “rollout” as permission. **Never** ship from a production checkout (e.g. HSD `production-hsd-website`). Use the develop checkout only. **Never** merge se-core-product `main`.
+- **Never** treat “deploy”, “ship it”, or “rollout” as permission. **Never** ship from a production checkout (e.g. HSD `production-hsd-website`). Use the develop checkout only. se-core-product `dev` → `main` (npm promote) is ask + confirm in a **core** session — do not promote core from this customer session.
 - Prefer **draft PRs** to `develop` over direct pushes when `gh` is available.
 
 ### Core vs customer placement
@@ -48,8 +48,8 @@ State placement in chat (and the PR) before smoke/server-config commits aimed at
 
 When work depends on a new `@se-studio/*` npm release:
 
-1. Release from `se-core-product` (`dev` → CI publish)
-2. Confirm version on npm
+1. Release from `se-core-product` (integrate + version on `dev` → promote to `main` → Release Main publishes)
+2. Confirm version on npm (from that `main` release)
 3. `pnpm update @se-studio/<package>@<version> -r` in this repo
 4. Then push / merge to `develop` after chat approval
 
@@ -88,3 +88,5 @@ Site-local learnings: `docs/AGENT_PROCESS_NOTES.md`. Say **“promote process no
 ### Production handoff
 
 When **marketing** work is ready, agents **stop** and hand off. Merge `develop` → production only after ask + confirm (`production-merge.md`). One site at a time. No `vercel deploy`. cms-edit host extra gate: `cms-edit-prod-merge.md`.
+
+When the promote depends on new/changed Contentful content, complete **release verification** (`release-verification.md` in `@se-studio/skills`): publish state (CDA vs CPA), content smoke (not HTTP-only), preview compare (≥3 pages on published-only build), and no unresolved failed production build. Nick override never skips publish-state or content smoke.

package/references/agent-session/customer-architecture.mdc

@@ -37,7 +37,7 @@ Source of truth: `se-core-product` `docs/PHILOSOPHY.md`. Code review: `CODE_REVI
 
 - Consent and analytics go through core adapters. No direct `dataLayer` pushes.
 - Never send names, emails, phones, form answers, or raw errors to analytics/URLs.
-- Forms submit server-side via core. Preview/develop must not post to production HubSpot or GTM.
+- Forms submit server-side (provider is site-chosen; core has no default). Preview/develop must not post to production CRM/forms destinations or production GTM.
 - No secrets in code/tests/logs. Avoid new `NEXT_PUBLIC_*` unless the browser must see the value.
 
 ## Tests / ship / review

package/references/agent-session/customer-code-review.md

@@ -27,7 +27,7 @@ Run all five lenses. Skip a lens only when the diff clearly cannot touch it (say
 - [ ] CMS routes stay static (`●`). No `headers()`/`cookies()` in a layout that forces the tree dynamic without measured justification.
 - [ ] Fetches go through core helpers with cache tags. No raw CDA `fetch`.
 - [ ] Images/video use core `Visual` + `calculateVisualSizes` (values match layout; mobile vs laptop not reversed).
-- [ ] Preview/develop must not post to production HubSpot or GTM.
+- [ ] Preview/develop must not post to production CRM/forms destinations or production GTM.
 
 ### 3. Performance and size
 
@@ -50,7 +50,7 @@ Run all five lenses. Skip a lens only when the diff clearly cannot touch it (say
 - Secrets, tokens, or `.env` values in code, tests, comments, or logs. Avoid new `NEXT_PUBLIC_*` unless the browser must see the value.
 - Personal data or form field values in events, dataLayer, HubSpot payloads, or URLs.
 - Consent granted by default where a CMP decides, or bypassing site consent gating.
-- Forms: preview posting to production HubSpot/GTM, or bypassing core server-side submit.
+- Forms: preview posting to production CRM/forms destinations or GTM, or bypassing server-side submit.
 - Hard-coded heading skips, `Visual` without size helpers, or needless duplicate mobile/desktop content.
 - Failing typecheck, lint, or tests; new behaviour with no test where the site already tests that layer.
 - Smoke/discovery/`server-config` hacks to unblock deploy smoke (belongs in `@se-studio/site-check`).

package/references/agent-session/production-merge.md

@@ -1,30 +1,35 @@
-# Customer production merge (human ask + confirm)
+# Production and core `main` merge (human ask + confirm)
 
-Agents may merge a **customer** integration branch to that site’s production branch **only** when this gate passes. The point is **no automatic or accidental publishing**.
+Agents may merge a **customer** integration branch to that site’s production branch, **or** promote **se-core-product** `dev` → `main`, **only** when this gate passes. The point is **no automatic or accidental publishing**.
 
 This is **not** a silent exception. Two human messages in **this conversation** are required: an explicit merge request, then a separate confirmation after the agent restates what will publish.
 
-**se-core-product `main` stays never-agent.** Package releases go `dev` → CI. Do not merge core `main`.
+**se-core-product `main` is ask + confirm** (same pattern as customer production). Package releases integrate and version on `dev` (CI Dev), then publish when promoted to `main` (Release Main / OIDC). Agents may run that promote **only** after ask + second confirm below.
 
 Canonical skill: `site-workflows-agent-session`. Customer `AGENTS.md` copies the short form from `customer-agents-block.md`.
 
-## Production branches
+## Production / promote branches
 
-| Repo | Integration | Production (Git-connected Vercel) |
-|------|-------------|-----------------------------------|
-| Customer marketing sites | `develop` | usually `main` |
+| Repo | Integration | Target (what merges) |
+|------|-------------|----------------------|
+| Customer marketing sites | `develop` | usually `main` (Git-connected Vercel production) |
 | HopSkipDrive | `develop` | **`production`** |
+| **se-core-product** | `dev` | **`main`** (Release Main → npm publish; may deploy anything on `main`) |
 
-Never ship from a registry `productionPath` checkout. Merge with `gh` from the **develop** checkout.
+Never ship customer production from a registry `productionPath` checkout. Merge with `gh` from the **develop** checkout (customers) or the se-core primary / approved checkout (core promote).
 
 ## Gate (all must hold)
 
-1. **Ask.** In this conversation the human named the **site or repo** and asked to merge **integration → production** (e.g. “merge develop to main”, “merge develop into production for OM1”).
+1. **Ask.** In this conversation the human named the **site or repo** and asked to merge:
+   - **Customer:** integration → production (e.g. “merge develop to main”, “merge develop into production for OM1”).
+   - **se-core-product:** `dev` → `main` / npm promote (e.g. “promote to main”, “merge dev to main”, “publish packages”).
 2. **Confirm.** The agent **stops**, restates the exact merge, and waits for a **second** affirmative reply (`yes` / `confirm` / `do it`) to **that** restatement. The original ask is not confirmation.
-3. **One repo.** Merge one customer repo at a time. Do not fan out “all sites to production”.
-4. **Git only.** `gh pr merge` or equivalent to `origin/<productionBranch>`. **Never** `vercel deploy`, `pnpm cms-edit:deploy`, or Netlify promote.
+3. **One repo.** Merge one customer repo at a time. Do not fan out “all sites to production”. Core promote is one `dev` → `main` merge (do not also merge customer production in the same step unless asked and confirmed separately).
+4. **Git only.** `gh pr merge` or equivalent to `origin/<targetBranch>`. **Never** `vercel deploy`, `pnpm cms-edit:deploy`, or Netlify promote. Do **not** run `pnpm release` / `npm publish` from a laptop unless the human explicitly asked for a **manual** publish (normal path is Release Main on push to `main`).
+5. **Prerequisites (core promote).** Version bumps must already be on `dev` (pending `.changeset/*.md` consumed by CI Dev). Do not promote while changesets remain. Post `## Merge approval` on the promote PR (who, where, when Europe/London, head SHA, review). Merge approval is **in addition to** ask + confirm — not a substitute.
+6. **Release verification (customer).** When the customer promote depends on new or changed Contentful entries, complete [`release-verification.md`](./release-verification.md) (publish state via CDA vs CPA, content smoke, preview compare, no unresolved failed production build). Record results on the promote PR. A Nick override never skips publish-state or content smoke.
 
-### Restatement (required before merge)
+### Restatement — customer production (required before merge)
 
 Send this shape, filled in, then wait:
 
@@ -33,29 +38,40 @@ Send this shape, filled in, then wait:
 > That publishes **production** (Git-connected Vercel).  
 > I will not merge until you reply **yes** to this message.
 
-If they say no, stop. If they name a different repo, restate again.
+### Restatement — se-core-product `main` (required before merge)
+
+Send this shape, filled in, then wait:
+
+> You asked to merge **se-core-product**  
+> `origin/dev` → `origin/main`.  
+> That runs **Release Main** and **publishes npm packages** (and may deploy anything on `main`).  
+> I will not merge until you reply **yes** to this message.
+
+If they say no, stop. If they name a different repo or target, restate again.
 
 ## Not permission (do not merge)
 
 These are **not** an ask, and never count as confirmation:
 
 - “ship it”, “deploy”, “rollout”, “publish”, “go live”, “it’s ready”
-- Opening or merging a PR to `develop`
-- A production PR already existing
+- Opening or merging a PR to `develop` / `dev`
+- A production or `main` PR already existing
 - “when Vercel is green, merge it” (pre-authorisation)
 - Scheduler / previous-session leftovers
 - CI needing `main`, default-branch workflows
 - cms-edit host “must be on production” without an explicit merge request
+- “version packages” / merge to `dev` alone (does **not** publish npm)
 
 ## After a confirmed merge
 
-- Wait for that site’s marketing (and cms-edit host, if Git-connected) Vercel **production** Ready.
-- Do not merge a second site until the first is Ready or the human asks again and confirms again.
+**Customer:** Wait for that site’s marketing (and cms-edit host, if Git-connected) Vercel **production** Ready. Do not merge a second site until the first is Ready or the human asks again and confirms again.
+
+**se-core-product:** Wait for Release Main to finish; confirm versions on npm (`npm view @se-studio/<pkg> version`) before bumping customer lockfiles.
 
 ## cms-edit-only extra gate
 
-Hosted cms-edit rollouts still use [`cms-edit-prod-merge.md`](./cms-edit-prod-merge.md) **in addition** to this confirm gate (path allowlist, npm version, health check). Confirmation is required there too.
+Hosted cms-edit rollouts still use [`cms-edit-prod-merge.md`](./cms-edit-prod-merge.md) **in addition** to this confirm gate (path allowlist, npm version, health check). Confirmation is required there too. That path is **customer** `develop` → production only — not se-core `main`.
 
 ## If the gate fails
 
-Do **not** merge. Open a PR targeting production if useful, hand off, and wait.
+Do **not** merge. Open a PR targeting production / `main` if useful, hand off, and wait.

package/references/agent-session/release-verification.md

@@ -0,0 +1,82 @@
+# Release verification (promote to production)
+
+Standing rules from Nick, **7 Oct 2026** (19:41 BST), after Brightline provider pages went live without a published Contentful template Hero (missing headshots).
+
+These rules apply to **every tool** — Cursor agents, Grok Build, and other local tools on Nick's Mac. A **Nick override** may skip review, but **never** skips rules **1** and **2**.
+
+Canonical pointers: `AGENTS.md` § Release verification, `.cursor/rules/release-verification.mdc`, promote PR template section.
+
+## Rules
+
+### 1. Check publish state before promoting
+
+Before any promote to production that depends on **new or changed Contentful entries**:
+
+1. List every **entry**, **template**, **person** / person-type, and **content stack** the new/changed pages render through.
+2. Confirm each is **published** in the production Contentful environment (usually `master`) with **no pending draft changes**.
+3. Compare **CDA** (published / Delivery API) vs **CPA** (preview / Preview API).
+4. Record the result in the **promote PR** (entry ids, content types, pass/fail).
+
+Helper: `@se-studio/site-check/publish-state` (`checkPublishState`, CLI `check-publish-state`).
+
+cms-edit: before a promote, verify linked **templates** and **person** entries are published (not draft-only). See `contentful-cms-core` publish guidance and `publish-handoff.md`.
+
+### 2. Smoke tests check content, not just status
+
+Live / production smoke must assert that **key page blocks render**, not only HTTP 200.
+
+Examples:
+
+- Person pages: headshot image + name in the hero
+- Listing cards: card images present and loadable
+
+Use `contentAssert` on `smoke.cases.json` cases (`mustInclude`, `mustHaveSelector`, `imagesMustLoad`). Requires `@se-studio/site-check` with content-assert support.
+
+### 3. Compare against the approved preview before merging a promote
+
+Before merging a promote PR:
+
+1. Run a build / preview against **published** content (Delivery token only — **no** preview token / CPA).
+2. Compare **at least 3 representative pages** with the signed-off preview.
+3. Note the comparison in the promote PR.
+
+### 4. A failed production build blocks further merges to main
+
+If a production build fails (Vercel or equivalent):
+
+- **Do not** merge further PRs to that site’s production branch (`main` / HSD `production`) until the cause is found.
+- Write the cause in the PR (e.g. unresolved / unpublished entry, missing template).
+- Fix publish state or code, then re-verify rules 1–2 before retrying.
+
+### 5. Applies to every tool; override limits
+
+- Cursor, Grok Build, scripts, and humans follow the same checklist.
+- `## Merge approval` with `none, Nick override` skips **review**, not rules **1** and **2**.
+
+## Promote PR checklist (paste into the PR)
+
+```markdown
+## Release verification
+
+- [ ] **Publish state (rule 1):** Listed entries/templates/people/content stack; CDA vs CPA clean; results recorded below
+- [ ] **Content smoke (rule 2):** Live smoke asserts key blocks (not HTTP-only)
+- [ ] **Preview compare (rule 3):** ≥3 pages vs signed-off preview on published-only build
+- [ ] **Production build (rule 4):** No open failed production build; or cause documented and fixed
+
+### Publish-state results
+| Entry / type | Role | CDA | CPA | Pending draft? |
+|--------------|------|-----|-----|----------------|
+| | | | | |
+
+### Preview compare
+| Page URL | Matches signed-off preview? | Notes |
+|----------|-------------------------------|-------|
+| | | |
+```
+
+## Related
+
+- [`production-merge.md`](./production-merge.md) — ask + confirm gate (still required)
+- [`cms-edit-prod-merge.md`](./cms-edit-prod-merge.md) — cms-edit-only path allowlist
+- `docs/CONSUMER_SITE_TESTING.md` — smoke setup
+- `docs/RELEASE_VERIFICATION.md` — short index in the repo

package/skills/architect/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: architect
+description: "Sketch types, signatures, and module structure before code, then stay in the loop while implementation fills in. Use for /architect, 'architect this', 'design this', or non-trivial work where jumping to code would lock in the wrong shape."
+---
+
+# Architect
+
+Sketch types, function signatures, class shapes, and module boundaries with `not implemented` bodies and pseudocode. Synthesize across multiple model perspectives, then fill in code against the chosen sketch.
+
+## SE Studio vendoring notes
+
+- Upstream frontmatter `disable-model-invocation: true` moved out of YAML (SE Studio skills allow only name + description).
+- **SE Studio trial: arena disabled.** Phase B uses a single sketch agent on the parent/`auto` model. Do not invoke the `arena` or `swarm` skills. Do not create or read `~/.cursor/rules/pstack-models.mdc` / `setup-pstack`. Never use `xhigh` or `max` model tiers.
+- Skills / principles referenced but not in this trial install (`why`, `exhaust-the-design-space`, `foundational-thinking`, `outcome-oriented-execution`, `redesign-from-first-principles`, `laziness-protocol`, `separate-before-serializing-shared-state`): **skip if missing** — apply the idea inline; do not hunt for, install, or fail the workflow because the skill directory is absent.
+- **SE gates win over Phase C.** “No human checkpoint before implement” covers design sketch → code fill-in only. It does **not** waive merge approval, cms-edit publish, production ask+confirm, release verification, or design-review-before-build for placement / schema / caching / analytics-forms (`AGENTS.md`, `.cursor/rules/pstack-trial-gates.mdc`, architecture R9.2).
+
+## Start
+
+Open a todolist with one entry per phase before starting.
+
+1. Ground
+2. Sketch
+3. Agree
+4. Implement
+5. Scrap
+
+## Phase A: Ground the problem
+
+Build a real mental model of every system the new code touches. Run the **how** skill over the relevant subsystems (respect `/how` trial Task caps). Naming a file isn't grounding. Produce the architectural explanation `how` prescribes. If the design redefines ownership or layering and a **why** skill is available, also run it on the existing shape so the rationale becomes a constraint, not a guess. **`why` is not in this trial — skip if missing:** ground with `how` plus PR/commit history and say so.
+
+Skip Phase A only when the work is genuinely greenfield with no surrounding system to integrate.
+
+## Phase B: Sketch
+
+**SE Studio trial fork (no arena):** spawn **one** Task subagent (`subagent_type: generalPurpose`, `readonly: true`) on the parent model. Omit `model` (treat as `auto` / `inherit-parent`). Pass `references/runner-prompt.md` as the runner prompt, plus Phase A grounding artifacts.
+
+Do **not** run the `arena` skill. Do **not** fan out multiple model runners. Do **not** look up `architect runners` / `arena runners` in a `pstack-models.mdc` rule — that file must not exist for this trial; if it does, ignore it and stay on Auto.
+
+The single sketch agent must still produce **at least two structurally distinct candidates** before synthesis (whole-shape alternatives, not point fixes). This keeps the exhaust-the-design-space pressure without multi-model spend. Screen every candidate against [`references/design-red-flags.md`](references/design-red-flags.md) before synthesis. Assume the next contributor is an agent that sees only the files it opened, copies the nearest example, and takes the shortest path that compiles. Prefer the design where a change that looks right from one file is right for the whole repo.
+
+Compare viable candidates on interface depth. Prefer the design that hides more complexity behind a smaller, simpler public surface. A rich interface can keep call chains short by concentrating capability instead of scattering it across layers.
+
+The sketch agent returns one synthesized design package. Its synthesis decision fills the rationale's "Synthesis decision" section.
+
+## Phase C: Agree (opt-in for design; SE gates still bind)
+
+Default for **ordinary** implement-from-sketch work: proceed to Phase D with the synthesized design without pausing for a design sign-off.
+
+That default is **not** “never block on the human.” SE Studio approval gates still win:
+
+- Do **not** merge, push `main`, publish Contentful, or promote production without the usual Nick / `## Merge approval` / ask+confirm / release-verification rules.
+- For changes that need a **design review before build** (placement, schema, caching, analytics/forms — architecture R9.2 / Project design-review), surface the synthesized design, post or prepare `## Design review`, and **pause** until that gate is satisfied — even when the invoker did not say “with checkpoint.”
+- Opt in to an extra checkpoint anytime the invoker asks: "/architect with checkpoint," "stop and show me before implementing," or similar. Then surface the synthesized design and pause for sign-off.
+
+The synthesis can ship as its own commit either way (scaffold first), subject to the gates above. Planned and scoped breakage during fill-in is fine. For adversarial pressure on the design before implementing, run the **interrogate** skill on the synthesized sketch (Auto reviewers only; see interrogate skill).
+
+If the human pushes back on the shape (in a checkpoint or after the fact), treat that as Phase A evidence. Re-ground and re-run Phase B before writing more code.
+
+## Phase D: Implement against the sketch
+
+Replace `not implemented` bodies with code, pseudocode with logic. The synthesized sketch is the contract. Deviations from it are signal to surface, not friction to absorb silently. If a function needs a parameter the sketch didn't anticipate, ask whether the sketch was wrong, the requirement was missed, or the implementation is overreaching.
+
+## Phase E: Scrap when the architecture is wrong
+
+If implementation keeps producing friction the sketch can't absorb, throw the sketch out. Don't bolt fixes onto a wrong design.
+
+The signal is a *pattern*, not single instances. Tells:
+
+- The same shape of workaround appearing repeatedly across unrelated code.
+- Multiple unrelated edge cases that all need special-case branches.
+- Types that need escape hatches (`any`, casts, optional fields always set in practice) to compile.
+- The "we need a lock" reflex when the sketch said the state wasn't shared.
+- Callers having to know the abstraction's internal rules to use it.
+- Two or more independent Phase D deviations of the same shape across the implementation.
+
+Use judgment. A few edge cases don't condemn an architecture. Some problems are legitimately complex. Complexity in the data is not complexity in the design.
+
+When you scrap:
+
+1. Re-run the **how** skill over what's been built.
+2. Redesign as if the new constraints had been day-one assumptions.
+3. Subtract before adding, per the **subtract-before-you-add** principle skill. The new sketch should be smaller than the old one before it grows.
+4. Return to Phase B and re-run the **single-model** sketch path (still no arena).
+
+## Outputs
+
+The caller's usage is written first and the type sketch derived from it. One file with new types and signatures for small changes. Module map plus type definitions for larger work. The rationale ships alongside, shaped per `references/rationale-template.md`, including the usage sketch and the synthesis decision.

package/skills/architect/references/design-red-flags.md

@@ -0,0 +1,57 @@
+# Design red flags
+
+Screen every candidate before synthesis. A red flag is a reason to revise or reject the shape.
+
+## Shallow module
+
+A shallow module exposes a large interface while hiding little complexity. Judge depth by the capability and policy hidden behind the public surface relative to the size of that surface. Prefer a simple interface backed by substantial behavior.
+
+Do not confuse a deep module with a deep call chain. A deep call chain scatters understanding across layers. A deep module concentrates capability behind one interface.
+
+Look for these signs:
+
+- Callers coordinate several methods to complete one operation.
+- Public options expose internal stages or implementation choices.
+- Learning the interface does not save the caller from learning the implementation.
+
+## Information leakage
+
+Information leakage makes multiple modules depend on the same internal decision. A representation, policy, or protocol detail appears in more than one place, so changing it requires coordinated edits.
+
+Public re-exports of transport or wire types are leakage. Parse external data into domain types behind the interface. Keep storage schemas, framework objects, and protocol details private.
+
+## Temporal decomposition
+
+Temporal decomposition organizes modules by execution order instead of the knowledge they own. Separate load, validate, transform, and save stages often repeat one representation and its invariants across several boundaries.
+
+Group code around domain knowledge and ownership. Methods that run at different times can still belong to one module when they protect the same decisions.
+
+## Pass-through method
+
+A pass-through method forwards the same arguments to another method with the same shape. It adds a layer without hiding complexity.
+
+Remove it or move responsibility to the module that can complete the operation. Keep a forwarding boundary only when it adds policy, adaptation, or a distinct abstraction.
+
+## Split ownership
+
+More than one module writes the same state or keeps its own copy of it. An agent that edits one writer can't see the others, so their rules diverge.
+
+Give each piece of state one owner. Other modules read it or ask the owner to change it.
+
+## Two ways to do one task
+
+The design supports more than one way to do the same task. An agent copies whichever way it finds first, so every way keeps gaining callers.
+
+Keep one way. Move callers off the others and delete them in the same change.
+
+## Importable internals
+
+A caller can import a module's internals. An agent takes the shortest path that compiles, so it imports them directly and they become part of the interface.
+
+Make internals unreachable from outside the module, so an import from outside fails the build.
+
+## Hand-synced list
+
+Two or more places list the same items, and adding an item means editing every list. An agent that sees one list updates only that one.
+
+Keep one list and derive the others from it. If a list can't be derived, make the build fail when the lists disagree.

package/skills/architect/references/rationale-template.md

@@ -0,0 +1,35 @@
+# Rationale template
+
+The prose that ships alongside the type sketch. One page. Sentence-case headings, no boilerplate. Replace the italic notes with actual content.
+
+## Problem
+
+*One paragraph. What we're trying to do, and what about the existing system or constraints makes the shape non-obvious. If [Phase A](../SKILL.md#phase-a-ground-the-problem) surfaced constraints the design must honor (existing types to interop with, callers we can't break, invariants that crossed our boundary), name them here so the reader sees the same constraints you saw.*
+
+## Usage (caller's view)
+
+*Write this first, before the type sketch. Show the README or quickstart the consumer reads, plus two or three realistic call sites in their own code. What they import, what they call, what comes back. The type sketch in [Shape](#shape) is derived from this. The two must agree. When they diverge, reconcile the sketch to the usage, not the reverse. The caller's experience is the spec. The types serve it.*
+
+## Shape
+
+*The recommended architecture. Data structures first. Then how data flows through the signatures. Name the load-bearing decisions. State which invariants are encoded in types, where validation lives, and what the system deliberately does not do. Judge interface depth explicitly. State what complexity the public surface hides, what remains exposed to callers, and why the interface is no larger than needed. Cite the principle behind each decision (e.g., `per boundary-discipline`). Don't restate it.*
+
+## Synthesis decision
+
+*Filled in by the Phase B single-model sketch pass (SE Studio trial: arena disabled). Records which candidate became the base and why, what was adapted from each of the others, and what was rejected and why.*
+
+## Tradeoffs accepted
+
+*One bullet per tradeoff the chosen shape makes. Form: "we accept X in exchange for Y." Name anything a future reader might mistake for an oversight, including things that look like premature optimization or premature simplification.*
+
+## Alternatives considered
+
+*Required. Name at least one concrete alternative shape, with one line on why it lost. Judge each alternative on interface depth, not implementation simplicity alone. Name the complexity it exposes to callers and the complexity it hides. Two or three alternatives belong here when the design space had real contenders. One is fine when the constraints forced the answer, with the conclusion phrased as "this was the only viable shape because..." Avoid listing flavors of the same shape. This section covers design alternatives the chosen shape considered and rejected, not other runner candidates.*
+
+## Open questions and risks
+
+*Things you noticed during the sketch that the human needs to weigh in on, and risks worth flagging before implementation starts. Phrase as questions, not assertions, so the human's answer is the resolution rather than a comment.*
+
+## Next implementation step
+
+*The first thing to build against the sketch. One sentence. What you'd start writing immediately after synthesis (or after Phase D sign-off, if a checkpoint was opted into).*

package/skills/architect/references/runner-prompt.md

@@ -0,0 +1,20 @@
+# Architect runner prompt
+
+**SE Studio trial:** Phase B uses a **single** Auto/`inherit-parent` sketch agent (arena disabled). The orchestrator passes this file to that one agent and fills in the variable inputs: the task, the Phase A grounding artifacts, the working directory, and the path to write outputs. The working directory is a git worktree when available, otherwise a subdirectory under the sketch dir.
+
+You are producing candidate designs in architect's single-model sketch pass. Read the **architect** skill in full first. That's the workflow you're inside. Produce **at least two structurally distinct** candidate design packages (whole-shape alternatives, not point fixes), then synthesize one recommended package: type sketch, function signatures, module map, and prose rationale shaped per [`rationale-template.md`](rationale-template.md). Do not spawn further Task agents or invoke `arena` / `swarm`.
+
+Apply the following discipline. Compare candidates on these axes when synthesizing.
+
+- Caller's usage first. Write the README-style usage and two or three real call sites before the types, then derive the type sketch from them. The usage is the spec. The two must agree, so reconcile the sketch to the usage, not the reverse.
+- Data structures first. Get the core types right and the code becomes obvious. Trace each dominant access pattern through the proposed structure. If the answer is "we'll add a map / index / cache later," the structure is wrong.
+- Interface depth. Compare the capability hidden behind the public surface relative to the size of that surface. Prefer a simple interface that pulls complexity into the callee, even when the implementation becomes less simple. Do not put transport or wire types on the public API. Parse into domain types behind the interface.
+- Shared state: if two actors might both write, ask "what happens?" If the answer isn't "nothing," default to per-actor state with a merge at the read boundary. If a **separate-before-serializing-shared-state** principle skill is installed, follow it; otherwise apply that idea inline and do not hunt for or install the missing skill.
+- Make boundaries visible. `not implemented` errors for bodies, `// TODO` pseudocode for tricky logic, doc comments stating intent and invariants. A reader should trace data from input to output by reading types and signatures alone.
+- Encode invariants in types: hard-to-misuse types > runtime checks > prose comments, per the **encode-lessons-in-structure** principle skill.
+- Validate at boundaries, trust types inside, per the **boundary-discipline** principle skill. Business logic as pure functions. The shell stays thin.
+- Single source of truth per invariant. Derive instead of sync.
+- Idempotent state transitions where applicable, per the **make-operations-idempotent** principle skill. Ask what happens if the operation runs twice or crashes halfway.
+- Short call chains. If tracing the flow needs more than three files, flatten the hierarchy. Prefer **minimize-reader-load**. If a **laziness-protocol** principle skill is installed, also follow it; otherwise apply the short-call-chain idea inline and do not hunt for or install the missing skill.
+
+Produce the best designs you can on this model. Keep the candidates structurally distinct so synthesis has a real signal — converging on a safe-looking middle before exploring alternatives defeats the sketch.

package/skills/blast-radius/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: blast-radius
+description: "Find what a change could break somewhere else before it ships, beyond the diff, and prove the one fact it's safe because of by running real code instead of writing it up. Use for 'blast radius of X', 'what could this break', or reviewing a small diff you don't trust."
+---
+
+# Blast radius
+
+
+## SE Studio vendoring notes
+
+- Upstream frontmatter `disable-model-invocation: true` moved out of YAML (SE Studio skills allow only name + description).
+- **SE Studio trial:** no `arena` / `swarm`; optional second Auto reviewer only. Soft-deps **`why`** / **`unslop`**: **skip if not installed** (neither is in this trial). Apply the idea inline; do not hunt for, install, or fail because the skill directory is missing. Do not run `setup-pstack`.
+
+Find what a change breaks somewhere else, before it ships. Use for "blast radius of X", "what could this break", or reviewing a small diff you don't trust yet.
+
+Companion to `how` and (when installed) `why`. `how` tells you what the code does. `why` (if present) tells you why it's shaped that way; if `why` is missing, infer motivation from PR/commit history. Blast radius tells you what it breaks somewhere else.
+
+Listing the callers is not the job. The agent can grep those in a second. The job is the breakage grep won't show you.
+
+## Don't trust your own writeup
+
+A blast-radius writeup that sounds right is worthless. It reads as convincing whether or not it's true. So don't hand back the writeup. Find the one or two facts the whole thing depends on and prove them by running code.
+
+### How sure are you
+
+For each fact the change's safety depends on, get it as far down this list as is cheap, and say where it stopped.
+
+1. You said so. Worthless on its own.
+2. You pointed at the line. A real `file:line`, or the library's own source.
+3. You showed the bad case can't happen. You walked the failure step by step and it doesn't reach.
+4. You ran it. A script or test that calls the real code and fails loud if you're wrong.
+5. You reproduced it in the running app.
+
+Step 4 is usually one small script that imports the same library the app ships and calls the exact function you're worried about.
+
+## Steps
+
+1. Read the change. The diff, the symbols it adds, changes, and deletes, and what it now does differently, including the part the diff doesn't spell out. If a **`why`** skill is installed, use its step 2 to pull the PR and commits; otherwise pull PR/commit history yourself (**skip if `why` missing**).
+2. Find the one fact it's safe because of. Most changes that look risky are safe because of a single fact, like "this call only drops already-dead cache entries and does nothing else". Find that fact. If it holds, most risky cases are cleared at once. Spend your time here, not on a long list of maybes.
+3. Look where grep stops. Read the source of the library you call, and check its pinned version and any local patch. Work out when things run: microtasks, unmount and teardown, Solid versus React. Follow what a symbol search misses: the JSON an API returns, a DB column, a wire format, another language reading the same bytes, a feature flag, code three hops downstream.
+4. Be honest about each risk. Give it a real chance of happening and a real cost if it does. Keep the risks you confirmed. List the ones you checked and cleared separately. Same honesty bar as `why` (cite real `file:line`, a search that finds nothing is still an answer, never invent callers) — apply that bar yourself when **`why` is not installed**.
+5. Prove the one fact. Write a script or test that runs the real code, run it, and paste what happened.
+6. For a big or wide change, spawn a second Auto/`inherit-parent` readonly Task with the same question and merge the answers (panel ≤2). Do **not** invoke the `arena` or `swarm` skills.
+
+## What to hand back
+
+- **What it does.** What changed, including the part that isn't obvious.
+- **The one fact it's safe because of.** State it, say which step you got it to, and show the proof. If you couldn't prove it, write unproven.
+- **Risks.** Each names how it breaks, the `file:line`, how likely and how bad, and how to check. Paste the proof for the ones that matter.
+- **Cleared.** What you checked and why it's fine.
+- **Before you merge.** The cheapest test or repro that catches the real bug, including the script you wrote.
+
+Cite real code, strip private material before anything goes public, and keep the writeup tight (no filler). **`unslop` is not in this trial** — **skip if missing**; apply that tight-writeup bar yourself.
+
+**Reply:** the writeup above, with the one safety fact either proven or marked unproven.