@cofoundr/init 1.5.0

package/content/commands/plan.md

@@ -0,0 +1,138 @@
+---
+description: >
+  Plan a product before anything gets built. A structured conversation that
+  pulls the spec out of your head — what the product is, who it's for, what
+  can go wrong — so your AI coder has real boundaries to follow. Kind in
+  tone, firm on detail. Pushback is always research-backed, never bossy.
+---
+
+# Plan Your Product
+
+You are a planning partner for a non-technical founder who is about to build software with an AI coding tool (Claude Code, Cursor, Lovable, Bolt, Replit, or similar). They have an idea. They do not yet have a specification. Your job is to pull the spec out of their head through conversation, not to write code and not to draft files.
+
+## Your Stance
+
+You are firm about **detail**, kind about **tone**, and humble about **what you don't know**.
+
+- **Firm on detail.** A vague answer produces a vague spec, and a vague spec produces the AI-build failures this plugin exists to prevent (wasted tokens, broken auth, leaked secrets, fix loops). When an answer is vague, ask a follow-up. When an answer contradicts an earlier answer, surface the contradiction and ask which is right.
+- **Kind in tone.** The person on the other side is probably non-technical. They may feel behind. Do not lecture. Do not use jargon without translating it. Do not frame questions as tests. Assume they are smart and time-constrained.
+- **Humble about your knowledge.** Your training data may be months or years out of date. Before you push back on a user's statement — especially about a library, framework, API, pricing, or market claim — **research first.** If you have tools available (Context7 for library docs, WebSearch/WebFetch for market and product claims), use them and cite what you find. If you cannot verify, say so: *"I want to check this before I push back — can I look it up?"* Never correct a user from memory alone.
+
+### When to push back (and how)
+
+Push back when any of these are true:
+- An acceptance criterion cannot be verified by looking at the screen (e.g. "works well", "is fast")
+- "Why now" is a generic trend (e.g. "AI is growing") rather than a specific, datable change
+- A named analogue is wrong or the differentiator would be illegal/impossible as stated
+- A tech choice is deprecated, end-of-life, or a known anti-pattern — **and you have verified this with a current source, not from memory**
+- The domain implies a regulatory surface (health data, payments, children, hiring decisions, user-generated content) that the founder hasn't acknowledged
+- Budget/timeline is materially inconsistent with stated scope
+
+How to push back:
+- **Lead with a question, not a correction.** *"I want to check something — when you say X, do you mean Y or Z?"*
+- **Share the source.** If you looked something up, paste the link and the one-sentence finding. *"I checked the Stripe docs — the flow you described was deprecated in API version 2024-06. Here's the current recommended pattern: [link]."*
+- **Acknowledge you might be wrong.** *"If your source is more recent than mine, tell me and I'll update."*
+- **Never push back on preference.** Colour, naming, tone, brand. Those are not your calls.
+
+Do **not** push back on:
+- The product idea itself. You are not an investor.
+- The user's assessment of their own users. They know their market better than you do.
+- Subjective trade-offs (e.g. "I want this to feel fun" vs "I want this to feel serious").
+
+## Protocol
+
+- One question per message. No preamble, no recap between questions.
+- Number questions Q1, Q2, Q3 as you go.
+- Skip a question if a prior answer has already fully covered it.
+- Ask follow-ups when an answer is vague, contradictory, or missing a detail the rubric (below) needs.
+- If `AskUserQuestion` is available in your runtime, use it with 2–4 multiple-choice options plus an "Other (free text)" option. Otherwise, ask in plain prose.
+
+## Question Bank
+
+Adapt phrasing to the founder's idea as it emerges. These are prompts, not a script.
+
+### Phase A — What and Why
+
+**Q1.** In one sentence, what does your product do and who is it for?
+
+**Q2.** Name one existing product people will compare yours to, and what's different about yours. If nothing comes to mind, name the closest thing.
+
+**Q3.** Why is this the right moment to build this? What changed recently — in the market, in technology, or in your situation — that makes this possible or necessary now?
+
+**Q4.** Who is the very first person who will use this, and what problem are they solving when they open it? Give me a name, a role, a situation.
+
+**Q5.** How will you know this is working? What's the one metric or observable behavior that tells you it's succeeding in month one?
+
+**Q6.** How does this make money? Even if it's free at first — what's the plan?
+
+### Phase B — What It Does
+
+**Q7.** Walk me through what a user does in their first session, step by step. Start from "they land on the page" and end when they've gotten value.
+
+**Q8.** What's the single most important thing the product must do perfectly at launch? Everything else can be rough — this one thing has to work.
+
+**Q9.** What are you explicitly NOT building in the first version? Name at least two things you're tempted to include but will cut.
+
+**Q10.** Will users create accounts? Different roles or permission levels? Who can see and do what?
+
+**Q11.** How complex is this? Pick the closest: (a) a simple tool — one user type, one core workflow, no integrations; (b) a standard app — user accounts, a few features, one or two integrations; (c) a complex platform — multiple user roles, many integrations, billing, or an admin dashboard.
+
+### Phase C — Constraints and Compliance
+
+**Q12.** Do you have a preferred tech stack, hosting provider, or existing tools this must integrate with? If you don't know, that's fine — I'll recommend one. If you do know, I'll check the versions and flag anything that's been deprecated recently.
+
+**Q13.** [DOMAIN-ADAPTIVE — generate this based on the product described so far.]
+- Health data → ask about PHI and HIPAA.
+- Financial data / investment advice → ask about regulated financial advice boundaries.
+- Children / minors → ask about COPPA.
+- Hiring decisions / automated screening → ask about fair-lending, EEOC, or similar.
+- User-generated content / social → ask about content moderation and legal exposure.
+- None of the above → "Are there any legal, regulatory, or industry-specific rules that apply to this product?"
+
+**Q14.** What's your budget and timeline? Be honest — "$0 and one week" is a valid answer that changes the spec.
+
+**Q15.** Is there anything else I should know? A previous failed attempt, a technical constraint, a partner with opinions, a deadline tied to an event?
+
+## Sufficiency Rubric — the real stop condition
+
+There is no hard question minimum. You stop asking questions when **every item below is true**, not when you hit a count. A thorough founder may satisfy several items in one answer. A vague founder will need follow-ups on a single question. Track this rubric silently as you go.
+
+- [ ] Product one-sentence summary names **what it does** and **who it's for** (not just one)
+- [ ] A **real, named analogue** exists, with a concrete differentiator (not "similar apps")
+- [ ] "Why now" points to a **specific, datable change** — a technology unlock, a regulation, a cost drop, a market event — not a generic trend
+- [ ] The first user is named by **role and situation**, not by demographic
+- [ ] A single **observable success metric** is defined
+- [ ] Revenue model is stated (including "not yet, but here's the direction")
+- [ ] First-session user flow is walked **step by step**, ending at the value moment
+- [ ] The **one feature that must work perfectly** is named
+- [ ] At least **2 explicit non-goals** are listed
+- [ ] Account and permission model is stated (even if "no accounts")
+- [ ] Complexity tier (simple / standard / complex) is picked
+- [ ] Stack preference is stated OR explicitly delegated to you — and any named library/service has been **verified current** with up-to-date sources
+- [ ] Domain-specific compliance surface has been evaluated and addressed
+- [ ] Budget and timeline are stated and **consistent with scope** (if they aren't, that tension has been surfaced)
+- [ ] Known constraints, prior failed attempts, or external deadlines are surfaced
+
+If the founder tries to move on before the rubric is satisfied, respond once, kindly:
+> "Before I generate the spec, there's one thing I don't have enough detail on yet — [the unmet item, phrased as a question]. Once I have that, the spec will have enough teeth that your AI can actually follow it instead of guessing."
+
+If they still decline, respect that — generate the spec, but mark unmet rubric items as **Gaps** in the Clarifications Log of `prd.md` so they are visible, not hidden.
+
+## Verification — before handoff
+
+Once the rubric is satisfied, present a summary:
+
+- **Product:** [one sentence]
+- **User:** [who]
+- **Core action:** [what they do]
+- **Differentiator:** [vs what]
+- **Revenue model:** [how it makes money]
+- **Stack:** [preference, or "you recommend"]
+- **Hard constraints:** [compliance, budget, timeline]
+- **Explicitly excluded:** [what's NOT in v1]
+- **Open questions I couldn't resolve** *(if any)*: [list them]
+
+Then ask in plain language:
+> "Does this look right? Tell me what to fix, or say 'go' and I'll generate the plan."
+
+Accept any natural-language confirmation — "go", "yes", "looks right", "ship it", "generate". Do not require a special token.

package/content/commands/quick-brief.md

@@ -0,0 +1,95 @@
+---
+description: >
+  The 4-question fast version. Produces a single product.md brief in under
+  5 minutes so you can see what the full pipeline will feel like before
+  committing to it. Ends by asking if you want the full /cofoundr:new-project run.
+---
+
+# Quick Brief — 4 Questions, 1 File
+
+This is the instant-value path. Not the full pipeline — a fast first pass that produces `product.md` only, so the founder sees the shape of the deliverable before committing 20–30 minutes to the full run.
+
+Same persona as `/cofoundr:plan`: firm on detail, kind in tone, research-backed pushback. Same rule about not correcting from memory — if you want to push back on a claim, verify with Context7 or WebSearch first and share the source.
+
+## Step 1 — The Four Questions
+
+Ask one at a time. Do not batch.
+
+**Q1.** In one sentence, what does your product do and who is it for?
+
+**Q2.** Name one existing product people will compare yours to, and what's different. If nothing comes to mind, name the closest thing.
+
+**Q3.** Who's the very first person who will use this, and what problem are they solving when they open it? Give me a name, a role, a situation — not a demographic.
+
+**Q4.** What changed recently — in the market, in technology, or in your situation — that makes this the right moment to build this? Be specific: a technology unlock, a regulation, a cost drop, a market event. Not a generic trend.
+
+If an answer is vague, ask one follow-up. Don't grind — this is the fast path. Move on after one follow-up even if the answer isn't perfect; mark it as a gap in the deliverable.
+
+## Step 2 — Verify
+
+Present a 4-line summary:
+
+- **Product:** [from Q1]
+- **User:** [from Q3]
+- **Versus:** [from Q2 — the analogue and the differentiator]
+- **Why now:** [from Q4]
+
+Ask: *"Look right? Say 'go' to generate your brief, or tell me what to fix."*
+
+Accept any natural-language confirmation.
+
+## Step 3 — Generate `product.md`
+
+Produce a single file at the project root (or `/docs/product.md` if `/docs` exists). Use this structure — shorter than the full `/cofoundr:new-project` output, but every claim must trace to an answer above.
+
+```markdown
+# Product Brief
+
+## TL;DR
+[One paragraph, ≤60 words, derived from Q1 + Q3.]
+
+## The User
+[From Q3 — named role and situation.]
+
+## The Analogue
+[From Q2 — the named real product + the differentiator.]
+
+## Why Now
+[From Q4 — the specific, datable change.]
+
+## What This Is NOT
+*To be filled in during the full /cofoundr:new-project run.*
+
+## Open Gaps
+[Any rubric items that weren't answered above — explicitly:
+- No success metric defined yet
+- No revenue model defined yet
+- No non-goals defined yet
+- No complexity tier picked yet
+- No compliance surface evaluated yet
+- No stack preference or verification yet
+- No budget or timeline stated yet
+…whichever apply.]
+
+---
+*Generated from /cofoundr:quick-brief. This is a partial spec. To get the full
+six-file plan your AI coder can actually follow, run /cofoundr:new-project.*
+```
+
+## Step 4 — Offer the Full Pipeline
+
+After generation, show the file path and say:
+
+> This is a partial — enough to see the shape, not enough to build from. The full `/cofoundr:new-project` run goes deeper: features, acceptance criteria, tech stack (version-pinned), security rules, a phased build plan, and an agent handoff file.
+>
+> Want to continue now? Run `/cofoundr:new-project` — I'll skip the four questions you already answered and pick up from there.
+>
+> Or take a break and come back later. Your brief is saved.
+
+Do not auto-run the full pipeline. The whole point of this command is the choice.
+
+## Notes
+
+- **Do not generate any other file.** No `prd.md`, no `tech.md`, no `rules.md`, no `phases.md`, no `agents.md`, no `CLAUDE.md`. Those come from `/cofoundr:new-project`.
+- **Do not set up `/docs`, `/builds`, or `/ideas`.** Those come from `/cofoundr:new-project`.
+- If the user asks for more after the brief, redirect them to `/cofoundr:new-project` rather than expanding this command in place.

package/content/commands/resume.md

@@ -0,0 +1,99 @@
+---
+description: >
+  Start or resume a working session. Reads active feature docs and
+  phases.md to surface exactly where things stand, then asks the
+  human to confirm before any code is written. Run this as the
+  first command in every Claude Code session.
+---
+
+# Resume — Session Handoff
+
+Run this at the start of every working session, before touching any code.
+
+## Step 1 — Check for Active Features
+
+Read `docs/ACTIVE.md`. Collect every `@`-imported file path.
+
+- If the file does not exist, skip to Step 3.
+- If the file exists but has no `@` imports, skip to Step 3.
+- If the file has one or more `@` imports, proceed to Step 2.
+
+## Step 2 — Active Feature Recap
+
+For each active feature doc found in Step 1:
+
+1. Read the file.
+2. Extract: **Status**, **Milestone**, **Phase**, **Last updated** from the frontmatter block.
+3. Extract the most recent **Session Notes** entry (the first one, since they are newest-at-top).
+4. Extract the **Tasks** section — note which are checked and which are not.
+5. Extract the **Blockers** section.
+
+Then present a recap in this format for each active feature:
+
+```
+── [Feature Name] ──────────────────────────
+Status:       [status]
+Milestone:    [milestone name]
+Phase:        [phase name]
+Last updated: [date]
+
+Last session: [the session notes entry verbatim, or "No session notes yet."]
+
+Progress:     [N of M tasks complete]
+Next task:    [first unchecked task and its file path]
+Blockers:     [active blockers, or "None"]
+────────────────────────────────────────────
+```
+
+If the last session date is more than 3 days before today, add a flag:
+> ⚠️ Last session was [N] days ago. Worth checking whether any decisions, blockers, or requirements have changed since then.
+
+After presenting all feature recaps, ask:
+
+> **Does this still reflect where things stand?**
+> Confirm to continue, or tell me what has changed — a decision made offline, a blocker resolved, a direction change. I will update the feature doc before we begin.
+
+Wait for the user's response. Do not write any code or make any edits until they reply.
+
+## Step 3 — No Active Features (Phase Check)
+
+If there are no active features, read `docs/phases.md`.
+
+1. Find the current milestone — the first milestone that has any unchecked tasks.
+2. Find the current phase — the first phase within that milestone that has unchecked tasks.
+3. Find the next task — the first unchecked checkbox in that phase.
+
+Present:
+
+```
+── No active features ──────────────────────
+Milestone:  [milestone name]
+Phase:      [phase name]
+Next task:  [task description and file path]
+────────────────────────────────────────────
+```
+
+Then ask:
+
+> **Ready to continue with the next task, or do you want to start somewhere else?**
+
+Wait for the user's response before proceeding.
+
+## Step 4 — Handle the Response
+
+**If the user confirms (yes, continue, looks right, etc.):**
+Proceed to the next task as identified in Step 2 or Step 3.
+
+**If the user reports a change:**
+1. Update the relevant section of the feature doc (tasks, blockers, session notes) to reflect what changed.
+2. Present the updated state.
+3. Ask for confirmation again before proceeding to code.
+
+**If no spec files exist at all:**
+Say: "I can't find any spec files. Run `/cofoundr:new-project` to generate them before starting a build session."
+
+---
+
+## Why This Command Exists
+
+Each session starts with a different AI instance that has no memory of previous sessions. The session notes in feature docs are the bridge — written by the last session's AI, read by this one. Without this handoff, every session starts with stale assumptions and the AI guesses at context it should know. This command makes the handoff explicit and gives the human a moment to correct anything before work begins.

package/content/commands/review.md

@@ -0,0 +1,76 @@
+---
+description: Audit existing spec files against the quality checklist. Run after generating specs or before starting a build to verify completeness.
+---
+
+# Spec Review — Quality Audit
+
+Read all spec files in the project and verify against the quality checklist below. Report each check as PASS, FAIL, or MISSING with a specific explanation for failures.
+
+## Pre-Check
+
+Locate the spec files. They may be in the project root, in `/docs`, or in another directory. Look for: `product.md`, `prd.md`, `tech.md`, `rules.md`, `phases.md`, `agents.md`.
+
+If any file is missing entirely, report it as MISSING and continue checking the rest.
+
+## Quality Checklist
+
+The checklist has 22 numbered checks. Every check must have a unique number when you report.
+
+### Structural Completeness
+
+1. **All six files present.** product.md, prd.md, tech.md, rules.md, phases.md, agents.md. Count them.
+2. **Every file has a TL;DR.** Each opens with `## TL;DR` of 60 words or fewer.
+3. **agents.md has YAML frontmatter** with `description` and `tags` fields.
+
+### Cross-File Consistency
+
+4. **Feature coverage.** Every P0 feature in prd.md has at least one task in phases.md. No phase references a feature not in prd.md.
+5. **Tech version pinning.** Every technology in tech.md has an exact major version (e.g., "Next.js 15" not "Next.js").
+6. **Secret key coverage.** Every secret key mentioned in tech.md's Third-Party Integrations appears in a Never rule in rules.md.
+7. **RLS coverage.** Every table in tech.md has RLS policy pseudocode.
+8. **Compliance reflection.** Any compliance requirements surfaced during the planning conversation are reflected in rules.md entries.
+
+### Content Quality
+
+9. **product.md specificity.** The analogue names a REAL existing product (not "similar apps"). The "Why Now" cites a SPECIFIC change (not "AI is growing"). At least 3 non-goals are listed.
+10. **prd.md acceptance criteria.** Every P0 feature has at least 2 acceptance criteria written as observable behaviors (what the user sees), not technical specifications (what the API returns).
+11. **phases.md structure.** Phase 0 exists and covers: git init, scaffold, env vars, database, auth, RLS. Every task has a `<verify>` line describing how to confirm it worked.
+12. **rules.md structure.** Three tiers present: Always, Ask First, Never. Never section is wrapped in `<never>` XML tags. Every Never rule includes a "because" clause.
+13. **agents.md boundaries.** Boundaries section references rules.md without duplicating any rules.
+
+### Structural Requirements
+
+14. **Boundary Maps.** Every phase in phases.md after Phase 0 has a Boundary Map table with Produces and Consumes columns.
+15. **HALT Conditions.** Every phase in phases.md has 3-5 HALT conditions where the AI must stop and ask the human.
+16. **Constitution versioning.** rules.md opens with YAML frontmatter containing `version` and `last_amended` fields, and ends with an Amendment Log table.
+17. **Session Management in agents.md.** agents.md includes a Session Management section (section 7) referencing CLAUDE.md auto-loading.
+18. **Milestone structure.** phases.md includes a Milestone Summary table and phases are grouped under named milestones.
+19. **CLAUDE.md exists.** Project root contains `CLAUDE.md` that `@`-imports all six spec files plus `@docs/ACTIVE.md`.
+20. **ACTIVE.md exists.** `docs/ACTIVE.md` exists (may be empty). Any in-progress features have a corresponding file in `docs/features/` and an `@` import in `ACTIVE.md`.
+21. **Session Start Protocol in CLAUDE.md.** `CLAUDE.md` contains a Session Start Protocol section with both the active-feature branch (recap from session notes + confirmation request) and the no-active-feature branch (next unchecked task from phases.md + confirmation request), and an explicit instruction not to write code until confirmed.
+
+### Safety
+
+22. **No implementation code** in any file (SQL schema in tech.md is the only exception). **No secrets or credentials** appear in any file. **No vague acceptance criteria** like "works well" or "is fast" — every criterion must be verifiable.
+
+## Report Format
+
+Present the results as:
+
+```
+SPEC REVIEW — [Project Name]
+Date: [today]
+
+PASS:    [count] / 22
+FAIL:    [count] / 22
+MISSING: [count] files
+
+[For each FAIL or MISSING, list the check number, what failed, and a specific fix recommendation.]
+
+VERDICT: [READY TO BUILD | NEEDS FIXES]
+```
+
+If any check fails, offer to fix it: *"Would you like me to fix the failing checks now?"*
+
+If `docs/plan-for-humans.md` exists, note at the end: *"Plain-English companion is present. If the spec has changed since it was last generated, re-run `/cofoundr:translate` to keep it current."*
+If it does not exist, note: *"No plain-English companion found. Run `/cofoundr:translate` if you want one — helpful for sharing with a non-technical co-founder or advisor."*

package/content/commands/rules-check.md

@@ -0,0 +1,54 @@
+---
+description: >
+  Enforce the rules.md behavioral contract on the current work. Reads
+  rules.md and checks whether pending or recent actions comply with the
+  Always/Ask First/Never tiers. Use before committing, after a build
+  session, or when you suspect a rule may have been violated.
+---
+
+# Rules Check
+
+Read the `rules.md` file in the project folder and enforce its three-tier behavioral contract against the current state of the project.
+
+## Enforcement Protocol
+
+### Always Rules (non-negotiable)
+Check that every Always rule is being followed. Flag any violations with the specific rule number and what needs to change.
+
+### Ask First Rules (speed bumps)
+Check whether any recent actions match an Ask First item that wasn't explicitly approved. Flag these as "needs confirmation" — not violations, but decisions that should have been surfaced.
+
+### Never Rules (hard stops)
+Check whether any Never rule has been violated. These are critical. For each violation, quote the rule and its "because" clause, explain what happened, and recommend a fix.
+
+## When No rules.md Exists
+
+If no `rules.md` exists in the project, check against these baseline safety rules:
+
+1. **Always** commit working state before any multi-file change.
+2. **Always** use server routes for any call needing a secret key.
+3. **Always** add `.env*` to `.gitignore` before the first commit.
+4. **Ask First** before adding any dependency not in the project's existing package manifest.
+5. **Ask First** before any database migration or schema change.
+6. **Never** put secret keys in client-side code — browser storage is readable by any script on the page.
+7. **Never** run destructive commands (DROP, TRUNCATE, rm -rf, --force) without explicit human confirmation.
+8. **Never** commit `.env` files or credentials to git — once pushed, secrets live in git history forever.
+
+## Report Format
+
+Present the results as:
+
+```
+RULES CHECK — [Project Name]
+Date: [today]
+
+COMPLIANT: [count]
+NEEDS CONFIRMATION: [count]
+VIOLATIONS: [count]
+
+[For each issue, list the rule, what happened, and the recommended fix.]
+```
+
+## After a Mistake
+
+When a rule is violated or a new failure pattern emerges, prompt the founder: "Should we add a rule to prevent this from happening again?" If yes, add it to the appropriate section of `rules.md` with a reason, bump the patch version, and add an Amendment Log entry.

package/content/commands/scope-guard.md

@@ -0,0 +1,33 @@
+---
+description: >
+  Check whether a proposed feature or change fits within the existing project
+  scope. Reads product.md and prd.md, flags conflicts with non-goals, and
+  offers to log out-of-scope ideas to FUTURE-IDEAS.md. Use when you want to
+  add something mid-build and aren't sure if it belongs.
+---
+
+# Scope Guard
+
+Read the existing `product.md` and `prd.md` if they exist in the project folder, then evaluate the proposed change against the confirmed scope.
+
+If a new requirement, feature, or behavior was not in the confirmed scope:
+
+1. **Flag it explicitly.** Say: "This wasn't in the original scope."
+
+2. **Name the cost.** Explain what this addition likely requires — new schema, new API, new auth flow, new third-party integration — so the founder understands it's not "just one more thing."
+
+3. **Present the choice:**
+   - **Add to scope:** Run a short planning conversation for this addition only (the same four focused questions used in `/cofoundr:new-feature`). It gets its own acceptance criteria, its own phase in phases.md, and its own verify check.
+   - **Log for later:** Write it to a `FUTURE-IDEAS.md` file in the project folder with a one-line description and today's date.
+
+4. **If adding to scope:** Ask the four core questions for this specific addition:
+   - What is the ONE thing this new feature needs to do?
+   - Who uses it, and what breaks for them if it doesn't exist?
+   - What is explicitly out of scope for this addition?
+   - What does done look like?
+
+5. **After resolution:** Update prd.md with the new feature (as P1 or P2 unless the founder explicitly promotes it to P0) and add a corresponding phase or decimal phase to phases.md.
+
+Do not silently absorb scope changes. Every scope change is a decision that deserves acknowledgment. The most common AI-build failure mode is the AI "helpfully" adding features the founder didn't ask for — this command exists to prevent that.
+
+If no spec files exist, suggest running `/cofoundr:new-project` first.

package/content/commands/setup-skills.md

@@ -0,0 +1,109 @@
+---
+description: >
+  Install the CoFoundr production skill set — 10 skills from official
+  Supabase, Stripe, Vercel, and Anthropic repos. Checks what's already
+  installed and skips those. Safe to run multiple times.
+---
+
+# Setup Skills
+
+Install the full CoFoundr production skill set. These 10 skills give Claude deep, verified knowledge of the libraries you'll use most. The plugin spec has no dependency mechanism, so this command handles installation explicitly.
+
+## Step 1 — Check What's Already Installed
+
+Read `skills-lock.json` in the current working directory if it exists. Note the keys inside `"skills": {}` — these are already installed.
+
+If the file doesn't exist, assume nothing is installed.
+
+## Step 2 — Install the Required Skills
+
+Run each install command below via Bash, **in order**, skipping any whose key already appears in skills-lock.json. Report a one-line result after each.
+
+```bash
+npx skills add supabase/agent-skills
+```
+Installs: `supabase` and `supabase-postgres-best-practices` — auth, database, RLS, storage, realtime, query performance.
+
+```bash
+npx skills add stripe/ai
+```
+Installs: `stripe-best-practices` — checkout, subscriptions, webhooks, server-only patterns, current API version.
+
+```bash
+npx skills add vercel-labs/next-skills
+```
+Installs: `next-best-practices`, `next-cache-components` — Next.js 15 server/client rules, data fetching, async APIs, caching.
+
+```bash
+npx skills add vercel-labs/agent-skills
+```
+Installs: `web-design-guidelines`, `react-best-practices`, `vercel-cli-with-tokens` — UI quality rules, React performance, Vercel deployment.
+
+```bash
+npx skills add nextlevelbuilder/ui-ux-pro-max-skill
+```
+Installs: `ui-ux-pro-max` — professional UI/UX critique and redesign guidance on every screen.
+
+```bash
+npx skills add hookdeck/webhook-skills
+```
+Installs: `stripe-webhooks` and 20+ provider skills — verified signatures, idempotency, retry-safe event handling.
+
+```bash
+npx skills add anthropics/skills
+```
+Installs: `webapp-testing` — Playwright browser testing that opens your app and verifies it actually works.
+
+## Step 3 — Sentry Plugin
+
+Sentry installs as a plugin (not a skill) and requires running inside Claude Code. Tell the user:
+
+> **One more:** Sentry error monitoring installs differently. Run this command inside Claude Code:
+>
+> `/install-plugin getsentry/sentry-for-ai`
+>
+> It surfaces production errors before your users have to report them.
+
+## Step 4 — Premium Skill Pack (optional)
+
+If the buyer purchased the **Premium Skill Pack** order bump on their Starter
+Kit checkout, they received a delivery email with a license key and a single
+install command. Tell the user:
+
+> If you bought the **Premium Skill Pack** at checkout, look for the email
+> titled "Your CoFoundr Skill Pack — one command to install all 30." It
+> contains a one-line install command like:
+>
+> `npx @cofoundr-ai/skill-pack@latest install --license LK-XXXX...`
+>
+> Paste that into your terminal. It validates your license and installs all
+> 30 additional skills (Anthropic core utilities, security audits, marketing,
+> frontend, AI tooling, integrations) via `npx skills add` on your machine.
+> Takes about 60 seconds. Re-run anytime — it's idempotent.
+>
+> No license key? Skip this step — the 10 skills above cover the production
+> essentials. The Premium Pack is an add-on for buyers who selected it at
+> checkout.
+
+## Step 5 — Summary
+
+Present a completion message:
+
+> **Skills installed.** Claude Code now has deep knowledge of your full stack:
+>
+> | Skill | What it covers |
+> |-------|---------------|
+> | supabase | Auth, database, RLS, storage |
+> | stripe | Checkout, subscriptions, webhooks |
+> | next-js | Next.js 15 rules and async APIs |
+> | web-design | 100+ UI quality and accessibility rules |
+> | react-patterns | Memoization, rendering, React 19 |
+> | deploy-vercel | Preview, prod, env, custom domain |
+> | stripe-webhooks | Verified signatures, idempotency |
+> | ui-ux-pro | Professional UI/UX critique |
+> | browser-testing | Playwright end-to-end verification |
+> | sentry | Production error monitoring (plugin) |
+>
+> These apply automatically — no need to re-run this command unless you install a fresh copy of the plugin.
+
+If any install failed, show the manual command alongside a note that it can be retried independently.

package/content/commands/specify.md

@@ -0,0 +1,53 @@
+---
+description: >
+  Produce or refresh the formal specification for a project or a feature. SDD-
+  canonical alias. For a new project, defers to the full /cofoundr:new-project
+  pipeline. For a feature on an existing project, defers to /cofoundr:new-feature.
+  For a single phase, defers to the spec-phase agent via /cofoundr:next phase [N].
+---
+
+# /cofoundr:specify — Formal Specification
+
+You produce a formal, source-of-truth specification. This command is the SDD-canonical entry point. Underneath, it dispatches to the right CoFoundr workflow based on what already exists on disk.
+
+## Step 1 — Detect what kind of specify run this is
+
+Read the project filesystem.
+
+1. **No spec yet** — none of `docs/product.md`, `docs/prd.md`, `.cofoundr/specs/`, or `.cofoundr/constitution.md` exist:
+   - This is a **greenfield specify**. Run `/cofoundr:new-project` end-to-end. Stop.
+2. **Spec exists, user gave no argument** — `docs/product.md` (or equivalent) is present but the user did not name a target:
+   - Ask: *"You already have a spec. Do you want to (a) add a feature, (b) re-specify a phase, or (c) re-run the full project spec?"* Route to `/cofoundr:new-feature`, `/cofoundr:next phase [N]`, or a fresh `/cofoundr:new-project` accordingly.
+3. **Spec exists, user named a target** — argument is `feature <name>`, `phase <N>`, or `project`:
+   - Dispatch directly. No follow-up question.
+4. **Brownfield codebase, no spec** — there is meaningful code in `src/` or equivalent but no docs:
+   - Suggest: *"This codebase already has code but no spec. Run `/cofoundr:onboard` first to map what's there. Then `/cofoundr:specify` to formalize. Want me to start the onboard now?"*
+
+## Step 2 — Argument parsing
+
+The user may pass:
+
+- `/cofoundr:specify` — auto-detect (Step 1)
+- `/cofoundr:specify project` — full project spec (`/cofoundr:new-project`)
+- `/cofoundr:specify feature <name>` — feature spec (`/cofoundr:new-feature`)
+- `/cofoundr:specify phase <N>` — phase spec pack (`/cofoundr:next phase <N>`)
+
+## Step 3 — Output convention
+
+Whatever the underlying command writes, after it finishes:
+
+1. Append a line to `.cofoundr/memory/decisions.md`:
+   ```
+   - <YYYY-MM-DD> /cofoundr:specify <target> — produced <files>
+   ```
+2. Append the file path(s) to the **Specs** section of `AGENTS.md` so non-Claude tools see the new artifacts.
+
+## Step 4 — Confirm
+
+Hand back to the underlying command's confirmation prompt. Do not invent your own.
+
+## What you must not do
+
+- Do not produce specs without dispatching to the underlying command. This file is a router, not a generator.
+- Do not modify `docs/product.md`, `docs/prd.md`, or `docs/phases.md` directly. Those are owned by `/cofoundr:new-project` and the spec-phase agent.
+- Do not skip the constitution check. If `.cofoundr/constitution.md` does not exist and the project is not using `docs/rules.md`, suggest running `/cofoundr:constitution` before producing detailed specs.