@thebassclef/lite 1.1.0 → 1.2.0-alpha.1

package/dist/lite/.claude/skills/autonomous/SKILL.md

@@ -0,0 +1,300 @@
+---
+tier: lite
+name: autonomous
+description: "Start or check an autonomous SDLC session. Two axes: who approves handoffs (you vs. the agent) and how work runs (one session vs. parallel agents). Defaults to operator-gated + sequential. Entry point for shipping features hands-off."
+problem: "Some sessions need SDLC discipline but no operator to run each step. Ceremony blocks flow."
+value: "Starts or checks an autonomous SDLC session. Two axes \u2014 who approves handoffs and how sequential the work is."
+inputs: [start or check mode, Optional approver axis and sequence flags]
+outputs: [Session goal doc, Handoff sequence, Approval gate list]
+user_invocable: true
+disable_model_invocation: false
+requires:
+  cli: [git, gh]
+  network: true
+---
+
+# Autonomous Development
+
+Entry point for autonomous and semi-autonomous development sessions.
+Invoke at any point in any repo that inherits bassclef.
+
+This file is a thin dispatcher. Deep procedural detail lives in:
+
+- `strategy/autonomous-dry-run.md` — read-only boot-sequence preview
+- `strategy/autonomous-boot-sequence.md` — `/autonomous start` scaffold +
+  activate, including Step 0–9, Construction automation A–E, pre-build
+  gates, branch stacking, context management, transition hierarchy
+
+## Usage
+
+```
+/autonomous              → about + current readiness (default)
+/autonomous dry-run      → full boot sequence validation, read-only
+/autonomous start        → scaffold + activate (asks for choices below)
+```
+
+### Two choices at boot
+
+The agent asks these during Step 1. They are independent axes.
+
+**1. Gating** — who approves handoffs between phases:
+
+| Gating | What happens | Best for |
+|--------|-------------|----------|
+| **operator-gated** (default) | Agent pauses between phases for your approval. You steer. | Daytime supervised sessions, learning the system |
+| **orchestrator-gated** | Agent chains through all phases autonomously, no pauses | Overnight runs, trusted workflows |
+
+**2. Execution mode** — how work is performed:
+
+| Mode | What happens | Burst cost | Best for |
+|------|-------------|-----------|----------|
+| **sequential** (default) | One session plays all roles in order. Persona switches, not subagent spawns. | $0 (Pro plan) | Overnight runs, budget-conscious, simpler debugging |
+| **parallel** (opt-in) | Orchestrator spawns subagents per role. Independent work fans out to worktrees. | Burst tokens | Throughput, multi-branch parallel work |
+
+### The 2x2
+
+| | Sequential | Parallel |
+|---|---|---|
+| **Operator-gated** | You drive. All agents available, you approve each phase. One session, persona switches. | Agents fan out to worktrees. You approve each PR/handoff before next starts. |
+| **Orchestrator-gated** | Agent chains through all roles in one session. No pauses. Reviews PRs after. | Full autonomy. Worktree fan-out. Agent merges on Reviewer approval. |
+
+Default is **operator-gated + sequential**.
+
+**Agent roster**: All agents are always available (Shaper, PM, Designer,
+Architect, Builder, Reviewer, Creative Director, Deployer, Closer). The
+two axes control HOW they run and WHO approves — not which agents exist.
+
+In operator-gated mode, YOU decide which agents to invoke and when. In
+orchestrator-gated mode, the system chains through the full choreography.
+
+**How sequential mode works:**
+- One continuous session (interactive or headless via `claude -p`)
+- The agent reads the choreography and plays each role in order
+- Between roles, it writes the handoff artifact, then switches persona
+  (e.g., "I am now acting as Architect" → reads Architect agent definition
+  → produces ADRs → writes handoff → "I am now acting as Builder")
+- If operator-gated: pauses between phases for approval
+- If orchestrator-gated: chains through all phases without pausing
+
+---
+
+## /autonomous (default — about + readiness)
+
+Show what autonomous development is, how the 2x2 works, and how ready
+this repo is right now.
+
+### 0. Lead with `/value-prop flash` + `/kiss words` summary (bassclef#357)
+
+If the repo has a most-recently-completed goal (read via
+`state_iteration_bet_active` / chronicle / git log), open with:
+
+- **Flash line** (`/value-prop flash` mode, ≤180 chars): one-sentence
+  claim of what last shipped. Plain language. The operator sees this
+  before any 2x2 axis explanation.
+- **Kiss summary** (`/kiss words` mode, 2-3 sentences, grade-10
+  vocabulary): what delivered last, current readiness shape, and
+  what `/autonomous start` would do next. The grounding paragraph.
+
+If there's no completed goal (fresh repo, first session), skip this
+step and proceed to Step 1. Don't fabricate a flash where there's no
+delivery to summarize.
+
+This is bassclef#357's discipline: every autonomous-run status
+surface opens with delivery, not methodology. Walls of tables come
+AFTER this block, not before.
+
+### 1. Explain the two axes
+
+**Gating** — who approves handoffs (default: operator-gated):
+
+| Gating | When to use |
+|--------|-----------|
+| operator-gated | Daytime sessions, learning the system, steering |
+| orchestrator-gated | Overnight runs, trusted workflows |
+
+**Execution mode** — how work runs (default: sequential):
+
+| Mode | Burst cost | How it works |
+|------|-----------|-------------|
+| sequential | $0 (Pro plan) | One session, persona switches between roles |
+| parallel | Burst tokens | Subagents spawned per role, worktrees for branches |
+
+**Cost**: Sequential mode is $0 burst (Max plan covers everything).
+Parallel mode adds burst cost per subagent spawn.
+
+**All agents are always available.** The combination controls behavior:
+
+| Combination | Behavior |
+|-------------|----------|
+| Operator + sequential | You drive, invoke agents as needed. Substrate assists with gates. |
+| Operator + parallel | Agents fan out, you approve handoffs. Full ceremony with human steering. |
+| Orchestrator + sequential | Agent chains all roles in one session. No pauses. Best overnight value. |
+| Orchestrator + parallel | Max autonomy and throughput. Subagent spawns, worktree branches. |
+
+### 2. Quick readiness check
+
+Scan the repo for the key artifacts and report status:
+
+```
+## Readiness
+
+| Artifact | Status | Path |
+|----------|--------|------|
+| Manifest (substrate.config.md) | ✅ Found / ❌ Missing | ... |
+| Phase state (docs/whereami.md) | ✅ / ❌ | ... |
+| Iteration bet | ✅ / ❌ | ... |
+| Risk register (docs/risk-register.md) | ✅ / ❌ / ⚠️ Disabled | ... |
+| Deploy targets | ✅ Configured / ⚠️ Local only | ... |
+| Skills | ✅ N local + M inherited | .claude/skills/ |
+| Session lock | ✅ Clear / ⚠️ Active | ... |
+| Chronicle (current) | ✅ / ⚠️ Stale — resolved during boot | ... |
+| Architect review | ✅ / ⚠️ Overdue — resolved during boot | ... |
+```
+
+**What NOT to surface in readiness** (these create noise, not signal):
+- Untracked skill symlinks from bassclef-sync — these are expected, not a problem
+- Stale dev processes on ports — only relevant if they'll conflict with the
+  current session. If you surface them, make it actionable: "Kill PIDs X, Y, Z?
+  They may conflict with dev server." Don't just list PIDs with no guidance.
+- Auto-save checkpoint files (.test-baseline, etc.) — transient, not readiness-relevant
+
+### 3. Show available capabilities
+
+All skills and agents are available at any configuration. The gating axis
+controls who decides when to invoke them:
+
+| Gating | How skills/agents are invoked |
+|--------|------------------------------|
+| Operator-gated | You invoke skills explicitly (/canvas, /spec, /architect-review). Agent runs Builder + Reviewer automatically, pauses for approval on everything else. |
+| Orchestrator-gated | Agent invokes skills per choreography. Full chain runs automatically: Shaper → PM → Architect → Designer → Builder → Reviewer. |
+
+Key skills available in any mode:
+- `/temperance`, `/verify`, `/diagnose`, `/chronicle` — gates that fire regardless
+- `/canvas`, `/spec`, `/architect-review` — thinking/design skills
+- `/riff-prototypes` — 2-3 visual variants with different dominant luminaries
+- `/deploy-prod`, `/release-notes`, `/retro` — transition skills
+- `/visual-review`, `/visual-qa`, `/synthetic-user` — verification skills
+
+### 4. Show next steps
+
+**MUST gates apply in ALL configurations:**
+/temperance before building, /verify after, /diagnose before fixing,
+tests with code, chronicle at phase transitions. These are not optional
+in any configuration. The gating choice controls who approves handoffs,
+not which gates fire.
+
+Based on readiness, tell the operator what to do. Use the AskUserQuestion
+tool to offer choices:
+
+> Ready to start an autonomous session?
+> 1. **Operator + sequential** (default) — you drive, agent assists
+> 2. **Orchestrator + sequential** — agent chains all roles, no pauses
+> 3. **Operator + parallel** — agents fan out, you approve each handoff
+> 4. **Orchestrator + parallel** — full autonomy, max throughput
+
+Note: stale artifacts (overdue chronicles, architect reviews) will be
+resolved automatically during the `/autonomous start` boot sequence.
+Don't present them as blockers — say "resolved during boot."
+
+---
+
+## /autonomous dry-run
+
+Full boot sequence validation, **read-only**. No files created, no
+agents activated. Use this to validate the boot works in the current
+environment before committing to `/autonomous start`.
+
+**Procedure + output format + rules** → see
+`strategy/autonomous-dry-run.md`.
+
+Summary: runs all 8 boot steps from `strategy/agent-choreography.md`
+Section 1, reports PASS / FAIL / WARN per step, produces a boot report
+identical in shape to what `/autonomous start` Step 8 would emit.
+
+---
+
+## /autonomous start [gating] [mode] [flags]
+
+Scaffold missing artifacts and boot the session with the requested
+configuration. This is where autonomous work begins.
+
+**Full procedure** → see `strategy/autonomous-boot-sequence.md`.
+
+That doc covers:
+
+- **The full chain** — ASCII diagram of Steps 1–9
+- **CRITICAL EXECUTION RULES** — sequential exchanges, verbatim prompts,
+  confirmation, context-aware examples, smart defaults, recommended
+  configs, error recovery, permission pre-check
+- **Step-by-step detail**:
+  - Step 0 — argument validation (rejects `standard`, `fast`, etc.)
+  - Selective-gate flag `gate-ux` — pulls UX decisions back under operator
+    gate in an otherwise-auto orchestrator-gated run
+  - Step 1 — determine gating and execution mode (AskUserQuestion)
+  - Step 2 — scaffold manifest (`substrate.config.md`)
+  - Step 3 — scaffold phase state
+  - Step 4 — scaffold iteration goal
+  - Step 5 — scaffold risk register
+  - Step 6 — resolve stale artifacts (chronicle, architect review, danger)
+  - Step 7 — execute 8-step boot
+  - Step 8 — report + confirm (personalized execution chain)
+  - Step 9 — activate choreography
+    - **Construction automation** A–E: parse scope → create issues →
+      write stack manifest → sequential execution → parallel execution
+- **Pre-build gates** — spec exists, issues exist, stack manifest,
+  branches created
+- **Branch stacking** — per-configuration table, rollback guidance
+- **Context management** — survival kit re-read after compaction
+- **Transition hierarchy** — role handoff / phase transition / iteration
+  complete: what fires when
+- **Rules** — the hard invariants
+
+**Valid args (fast reference; full validation in the boot-sequence doc):**
+
+| Position | Accepted | Rejects |
+|----------|----------|---------|
+| gating | `operator-gated`, `orchestrator-gated`, short aliases | `standard`, `full`, `core` (those are `process_level`) |
+| mode | `sequential`, `parallel` | `headless`, `napkin-mode`, etc. |
+| selective-gate flags | `gate-ux` (orchestrator-gated only) | `pick-ux` etc. |
+| PR strategy override | `bundle` (collapse N issues into 1 PR; default is stacked per `.claude/rules/pr-strategy.md`) | `stacked` (it's the default — explicit value not needed) |
+
+Unknown args are rejected with a helpful message; the command does NOT
+silently proceed with defaults.
+
+---
+
+## Rules
+
+- Never start work without operator confirmation
+- Never assume iteration_ceiling — always ask
+- If any boot step fails, scaffold the missing artifact before proceeding
+- The Orchestrator coordinates but does not implement
+- Spec and issues MUST exist before any Construction branch is created
+- **Issue-first branch creation** (per bassclef#295): if a stack manifest
+  was pre-staged with `BASSCLEF-NNN` placeholder branch names, file the
+  issues + update the manifest with real numbers BEFORE creating the
+  branch. The placeholder-then-rename anti-pattern produces orphaned
+  gate markers because hooks fire against the placeholder filename. See
+  `strategy/autonomous-boot-sequence.md` Step D step 1 for the full
+  protocol.
+- Every autonomous session ends with `/chronicle` + memory update
+- **Prose output (per bassclef#790 — operator-facing-prose discipline):**
+  /autonomous handoff briefs, status reports, and turn-level prose
+  surface shorthand (WU-N, F-X.Y, ADR-NNN, #NNN, LF-N) with a plain-
+  language gloss at first mention per response. See
+  `standards/operator-facing-prose-discipline.md` for format examples.
+  Reserved-name allowlist per bassclef#763 holds.
+- **PR-body scrub (per bassclef#787 — pr-body-discipline):** every
+  PR body authored by /autonomous-dispatched agents passes through
+  scrub before push. Three criteria: no `docs/operator-private/*`
+  path citations, no operator-strategic deliberation as PR
+  justification (mechanical framing only), plain-language gloss +
+  /kiss pass per bassclef#790. See `standards/pr-body-discipline.md`
+  for stub-framing examples.
+- **SKILL.md edit meta-discipline (per bassclef#790 Rule 2):** any
+  /autonomous SKILL.md edit applies a /kiss pass to the whole file
+  in the same change.
+
+## Output discipline
+
+Dispatch `/kiss words --rewrite` on your skill output before you return it. See `standards/skill-output-discipline.md` for the contract.

package/dist/lite/.claude/skills/bind-subdomain/SKILL.md

@@ -0,0 +1,232 @@
+---
+tier: lite
+name: bind-subdomain
+description: "Bind a friendly URL to a deployed sunj-labs app. Reads substrate.config.md, calls the deploy-host and DNS adapters. Creates records and polls cert validation. Replaces clickops per standards/domain-and-dns.md."
+problem: "Deployed apps at sunj-labs need friendly URLs. Every operator sets it up by hand each time."
+value: "One command binds a friendly URL to a deployed app. Reads config and calls deploy-host plus DNS."
+inputs: [App name, Target subdomain, Optional deploy-host override]
+outputs: [DNS record created, Deploy-host mapping, Verified URL]
+user_invocable: true
+disable_model_invocation: false
+---
+
+# /bind-subdomain — Bassclef DNS + TLS Binding
+
+Binds `<subdomain>` to a deployed app via Amplify (or future host
+adapters) + Cloudflare (or future DNS adapters). One command, no
+clickops, idempotent.
+
+First consumer wired (`your-app.apps.your-domain.com` → Amplify app
+`d154l5usyc80nk` in `eu-north-1`).
+
+## When to invoke
+
+- Setting up a friendly URL for a new sunj-labs app after its deploy
+  host (Amplify, etc.) is provisioned
+- Re-running against an already-bound app (safe no-op — returns
+  current binding state)
+- Troubleshooting a stuck binding (polls status, surfaces actionable
+  errors)
+
+## When NOT to invoke
+
+- Before the deploy host exists — this skill binds an existing app
+  to a subdomain, it doesn't create the app. Provision the Amplify
+  app first (via console or future `/provision-app` skill).
+- If the DNS zone isn't owned by the operator in the configured
+  `dns_provider`. This skill doesn't create zones; it writes records
+  into existing zones.
+
+## Sources read
+
+- `standards/domain-and-dns.md` — the convention (subdomain pattern
+  + TLS ownership + DNS automation) that this skill operationalizes
+- `standards/substrate-config-schema.md` — field conventions the
+  script reads from consumer's `substrate.config.md`
+- `scripts/bind-subdomain.sh` — main entry point
+- `scripts/adapters/deploy/*.sh` — host-specific adapters (amplify)
+- `scripts/adapters/dns/*.sh` — DNS-provider adapters (cloudflare)
+- `docs/learnings/2026-04-19-mobile-to-preview.md` — manual pattern
+  this skill automates
+- Bassclef #254 — ticket this skill closes
+
+## Prerequisites
+
+1. Consumer repo's `substrate.config.md` must declare:
+   ```
+   hosting_platform: amplify           # bassclef default per ADR-008
+   amplify_app_id: <app-id>
+   amplify_region: <aws-region>
+   amplify_branch: main                # optional, defaults to main
+   subdomain: <full-dns-name>
+   dns_provider: cloudflare
+   dns_zone: <zone-root>
+   cloudflare_token_env: CLOUDFLARE_API_TOKEN
+   ```
+
+   `hosting_platform` enum: `amplify | ec2-tailscale | vercel | netlify | cloudflare-pages | none`. `none` is the explicit opt-out for docs-only / no-UI repos — bind-subdomain refuses with exit 3 + directive (bassclef#449). `BIND_SUBDOMAIN_OVERRIDE=1` bypasses the refusal. `vercel`, `netlify`, `cloudflare-pages` are reserved enum values; their adapters have not yet shipped (use `amplify` until they do).
+2. AWS CLI authenticated with access to:
+   - `amplify:GetApp`
+   - `amplify:CreateDomainAssociation`
+   - `amplify:GetDomainAssociation`
+   - `amplify:UpdateBranch`
+3. Env var named by `cloudflare_token_env` exported with a CF API
+   token that has:
+   - Zone → Zone:Read on the configured `dns_zone`
+   - Zone → DNS:Edit on the configured `dns_zone`
+4. DNS zone exists in Cloudflare (or configured provider)
+
+## Usage
+
+```bash
+# From the consumer repo root:
+bash scripts/bind-subdomain.sh
+
+# Or with explicit config path:
+bash scripts/bind-subdomain.sh path/to/substrate.config.md
+```
+
+The script lives in bassclef's `scripts/` directory and is
+distributed to consumer repos via bassclef-sync (symlinked to
+`.claude/hooks/` peer directory — TBD per bassclef-sync extension
+work; for now consumer repos invoke via the bassclef path in their
+local clone, or copy-paste until distribution lands).
+
+## Behavior
+
+1. Read `substrate.config.md` from current directory (or argument)
+2. Validate required fields present
+3. Validate AWS CLI auth + Cloudflare token
+4. Check if binding already exists:
+   - **Exists + AVAILABLE** → no-op, print URL, exit 0
+   - **Exists + not AVAILABLE** → poll to AVAILABLE (up to 20 min)
+   - **Does not exist** → proceed
+5. Create Amplify domain association
+6. Poll up to 2 min for validation records to populate
+7. For each record, create in Cloudflare (idempotent: skip if exact
+   match exists; fail if name collision with different value)
+8. Poll Amplify until `domainStatus: AVAILABLE` (up to 20 min)
+9. Enable auto-build on the bound branch
+10. Print the live URL
+
+## Exit codes
+
+| Code | Meaning |
+|------|---------|
+| 0 | Success (new binding OR already-bound no-op) |
+| 1 | Config missing or invalid |
+| 2 | Credentials missing or invalid |
+| 3 | Deploy adapter failure (Amplify API error, timeout) |
+| 4 | DNS adapter failure (Cloudflare API error, zone missing, record conflict) |
+
+## Error recovery
+
+### "Cannot access Amplify app"
+
+- Check `amplify_app_id` matches the console
+- Check `amplify_region` is correct (default eu-north-1)
+- Run `aws amplify list-apps --region <region>` to verify access
+
+### "Cloudflare token verification failed"
+
+- Check env var named by `cloudflare_token_env` is set
+- Verify token permissions (Zone:Read + DNS:Edit on the zone)
+- Test independently: `curl -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" https://api.cloudflare.com/client/v4/user/tokens/verify`
+
+### "Cannot resolve zone ID"
+
+- Check `dns_zone` matches exactly (e.g., `your-domain.com`, not
+  `www.your-domain.com` or trailing dot)
+- Check zone is in the same Cloudflare account the token was issued in
+
+### "Record exists with different value"
+
+Existing record conflicts with what this script wants to create.
+Resolve manually in Cloudflare, then re-run:
+1. Log into Cloudflare, locate the conflicting record
+2. Decide whether existing value is correct (keep) or stale (delete)
+3. If deleting: remove in CF console, then re-run script
+4. If keeping: investigate why Amplify wants a different value
+   (possibly a stale prior binding; delete the Amplify domain
+   association first via console)
+
+### "Timeout waiting for cert validation"
+
+ACM cert validation typically completes in 5-15 min. Timeout after
+20 min means one of:
+- DNS records not propagating (check CF records are `proxied=false`)
+- Conflicting records pointing to wrong target
+- Zone not delegated correctly (if using nested subdomain)
+
+Check Amplify console → Custom domains → see error detail. Fix,
+then re-run.
+
+## Adapter pattern
+
+Two axes of variation, each with a separate adapter:
+
+- **Deploy host** (`scripts/adapters/deploy/<host>.sh`): amplify, netlify (future), vercel (future), cloudflare-pages (future)
+- **DNS provider** (`scripts/adapters/dns/<provider>.sh`): cloudflare, route53 (future)
+
+Each adapter exposes a standard function set; the main script
+dispatches without knowing platform details. Adding a new host/DNS
+provider = new adapter file, no changes to the main script.
+
+### Deploy adapter contract
+
+```
+deploy_check_auth                        → 0 if authenticated
+deploy_binding_exists <subdomain>        → 0 if exists
+deploy_binding_status <subdomain>        → prints status string
+deploy_create_binding <subdomain>        → creates association
+deploy_get_records <subdomain>           → prints <type>\t<name>\t<value> lines
+deploy_wait_for_binding <subdomain>      → polls to AVAILABLE
+deploy_enable_auto_build                 → (optional) enables push-to-deploy
+```
+
+### DNS adapter contract
+
+```
+dns_check_auth                           → 0 if authenticated; resolves zone ID
+dns_create_record <type> <name> <value>  → idempotent create
+```
+
+## Relationship to other skills
+
+| Skill | Relationship |
+|-------|-------------|
+| `/onboard-repo` | Peer — provisions bassclef substrate for a new repo; `/bind-subdomain` binds its friendly URL after deploy host exists |
+| `/deploy-prod` | Peer — handles deployment to the bound URL (POA's EC2+Tailscale pattern); orthogonal to this skill's DNS work |
+| `/substrate-check` | Validates `substrate.config.md` schema; its checks cover the new fields added for this skill |
+
+## Chain position
+
+```
+(deploy host provisioned externally)
+    ↓
+substrate.config.md declares hosting_platform + subdomain fields
+    ↓
+/bind-subdomain (this skill)
+    ↓
+friendly URL live
+    ↓
+/deploy-prod pushes code (or Amplify auto-build on push)
+```
+
+## Provenance
+
+Filed: bassclef #254 (shaping)
+Shipped: iteration goal 2026-04-23a-bind-subdomain
+First consumer wired (`your-app.apps.your-domain.com`), 2026-04-23
+
+Replaces manual clickops documented in
+`docs/learnings/2026-04-19-mobile-to-preview.md` §Step 2.
+
+## Closes
+
+- bassclef #254
+- Integration-tests the domain + DNS strategy against a live binding
+
+## Output discipline
+
+Dispatch `/kiss words --rewrite` on your skill output before you return it. See `standards/skill-output-discipline.md` for the contract.

package/dist/lite/.claude/skills/canvas/SKILL.md

@@ -0,0 +1,41 @@
+---
+tier: lite
+name: canvas
+description: "Create a new product canvas \u2014 three-stage template (Thesis \u2192 Shape \u2192 Build Sequence)."
+problem: "Product canvases get authored ad-hoc. Structure drifts. Downstream skills can't parse them."
+value: "Creates a new product canvas using the three-stage template \u2014 Thesis and Shape and Build Sequence."
+inputs: [Product name or scope description]
+outputs: [Canvas doc at strategy/canvases/, Thesis section, Shape section, Build Sequence section]
+user_invocable: true
+disable_model_invocation: false
+---
+
+# Canvas — Create Product Canvas
+
+Create a new product canvas following the three-stage template.
+
+## Steps
+
+1. Ask the user for the initiative name (or infer from context)
+2. Read `templates/product-canvas.md` for the template structure
+3. Read the most recent canvas in `strategy/canvases/` for style reference
+4. Walk through each stage with the user:
+   - **Stage 1: Thesis** (5 min) — one-sentence value proposition, audience scope, the problem, the bet
+   - **Stage 2: Shape** (30 min) — detailed design of the approach, data sources, architecture
+   - **Stage 3: Build Sequence** — phased implementation plan with checkboxes
+
+## Output
+
+Write to `strategy/canvases/{YYYY-MM-DD}-{slug}.md`
+
+## Rules
+
+- Do not skip stages — each forces a different kind of clarity
+- Value proposition must be one sentence
+- The Goal section must be concrete enough to falsify
+- Build Sequence must have phased checkboxes
+- If the user hasn't thought through a stage, help them — don't fill in assumptions silently
+
+## Output discipline
+
+Dispatch `/kiss words --rewrite` on your skill output before you return it. See `standards/skill-output-discipline.md` for the contract.

package/dist/lite/.claude/skills/deploy-prod/SKILL.md

@@ -0,0 +1,106 @@
+---
+tier: lite
+name: deploy-prod
+description: "Production deployment procedure \u2014 test, build, push, CI, verify. Template for any project."
+problem: "Production deploys go different every time. Steps get missed. Rollbacks take manual rediscovery."
+value: "Standardized production deployment procedure \u2014 test then build then push then CI then verify."
+inputs: [Optional deploy-host override]
+outputs: [Deploy log, Verify status per step, Rollback procedure]
+user_invocable: true
+disable_model_invocation: false
+requires:
+  cli: [git, gh, node]
+  files: [substrate.config.md]
+  network: true
+  gating: orchestrator-gated
+---
+
+# Deploy to Production
+
+Standard deployment procedure. Run after code is reviewed and ready to ship.
+
+## Procedure
+
+### Step 1: Pre-flight
+
+- Working tree clean? (`git status`)
+- All tests pass? (`npm run test` or project equivalent)
+- Build succeeds? (`npm run build` or project equivalent)
+- On the correct branch? (feature branch → merge to main, or main directly)
+
+### Step 2: Push and CI
+
+- Push to remote: `git push`
+- **MUST watch CI until completion** (#529) — after every main-branch
+  merge on a deploy-configured repo, run:
+  ```
+  gh run watch --exit-status
+  ```
+  (or poll `gh run list --limit 1 --json status,conclusion` until
+  `status=completed`). Do NOT proceed to next work until CI finishes.
+  Why: silent CI failures age into the next session as BLOCKED items
+  or production drift. Surface immediately.
+- Verify all checks pass: secret scan → lint → typecheck → SAST → audit → test → build → deploy
+- If CI fails: fire `/diagnose` before any retry. Don't brute-force
+  retry without understanding the failure.
+
+### Step 3: Post-deploy Verification
+
+Run `/smoke-test` against production:
+
+1. **Health check** — API health endpoint returns healthy
+2. **Auth flow** — sign-in/sign-out cycle works
+3. **Core pages** — main pages load with data
+4. **API contracts** — key endpoints return expected shapes
+5. **Pipeline** — background jobs running, recent jobs successful
+
+### Step 4: Rollback (if verification fails)
+
+- Revert the merge commit: `git revert <commit> && git push`
+- CI redeploys previous version
+- Run `/diagnose` on the failure before attempting again
+
+## Pass Criteria
+
+All post-deploy checks pass. If any fail, rollback and diagnose.
+
+## Retroactive version tags (defer when capability missing)
+
+When a version tag (`vX.Y.Z`) should be written for an already-deployed
+release but the current session lacks the `git-tag` capability
+(typical: ephemeral-mobile, cloud-web, or a desktop session whose
+remote lacks push credentials), DO NOT silently skip. Write a
+deferred-action entry so the next capable session creates the tag:
+
+```bash
+TS=$(date -u +"%Y-%m-%dT%H-%M-%SZ")
+ID="${TS}-retro-tag-vX.Y.Z"
+cp templates/deferred-action-template.md \
+   "docs/deferred-actions/${ID}.md"
+# Fill frontmatter:
+#   pending_action: write-retroactive-version-tag
+#   requires_capability: [git-push, git-tag]
+#   priority: low
+#   origin_skill: /deploy-prod
+#   resolves_when: |
+#     git tag -l vX.Y.Z shows the tag; GitHub release created if policy requires it.
+# Body: cite the commit SHA, release notes path, date-deployed.
+git add "docs/deferred-actions/${ID}.md"
+git commit -m "chore: defer retroactive version tag vX.Y.Z"
+```
+
+See `.claude/rules/deferred-actions.md`. Silent skip violates
+`session-artifacts.md` ("silence is not deferral").
+
+## App-Specific Override
+
+Your project's deploy-prod skill should specify:
+- Production URL and health endpoint
+- SSH/access commands for server verification
+- CI job names and expected durations
+- Worker/queue verification commands
+- Rollback-specific steps for your infrastructure
+
+## Output discipline
+
+Dispatch `/kiss words --rewrite` on your skill output before you return it. See `standards/skill-output-discipline.md` for the contract.