feat(plugin): native Claude Code plugin + dual-mode npx install

.claude-plugin/marketplace.json

@@ -0,0 +1,19 @@
+{
+  "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
+  "name": "seed",
+  "owner": {
+    "name": "ChristopherKahler"
+  },
+  "metadata": {
+    "description": "SEED — typed project incubator that guides ideation through graduation into buildable projects."
+  },
+  "plugins": [
+    {
+      "name": "seed",
+      "source": ".",
+      "description": "SEED — Structured Evaluation & Engineering Design: typed project incubator that guides ideation through graduation into buildable projects.",
+      "category": "framework",
+      "keywords": ["seed", "ideation", "project-planning", "incubator", "paul", "scaffold"]
+    }
+  ]
+}

.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "seed",
+  "version": "1.0.0",
+  "description": "SEED — Structured Evaluation & Engineering Design: typed project incubator that guides ideation through graduation into buildable projects.",
+  "license": "MIT",
+  "homepage": "https://github.com/ChristopherKahler/seed#readme",
+  "author": {
+    "name": "Chris Kahler"
+  }
+}

.github/workflows/plugin-install.yml

@@ -0,0 +1,26 @@
+name: plugin-install
+
+on:
+  push:
+  pull_request:
+  workflow_dispatch:
+
+jobs:
+  validate-and-install:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: '22'
+      - name: Install Claude Code CLI
+        run: npm install -g @anthropic-ai/claude-code
+      - name: Validate plugin + marketplace manifest (strict)
+        run: claude plugin validate . --strict
+      - name: Install smoke test (claude can install the plugin)
+        run: |
+          set -euo pipefail
+          claude plugin marketplace add ./
+          claude plugin install seed@seed
+          claude plugin list
+          claude plugin list | grep -i 'seed'

commands/checklists/planning-quality.md

@@ -0,0 +1,55 @@
+# Planning Quality Checklist
+
+Quality gate for `/seed graduate` and `/seed launch`. Determines if a PLANNING.md is rich enough for clean graduation and headless PAUL initialization.
+
+## Universal Checks (All Types)
+
+- [ ] **Type metadata** present in header (Application, Workflow, Client, Utility, Campaign, or custom)
+- [ ] **Problem statement** is specific — names the problem, the audience, and why it matters
+- [ ] **Design decisions** documented — at least 1 resolved decision with rationale
+- [ ] **Open questions** section exists (even if "None")
+- [ ] **Next actions** defined — at least 1 concrete next step
+- [ ] **Skill Loadout** noted — which ecosystem tools apply to this build
+
+## Type-Specific Checks
+
+Reference `data/{type}/config.md` for the authority on required vs optional sections.
+
+- [ ] **All required sections** (per config.md) have substantive content — not just headers or placeholders
+- [ ] **Optional sections** either covered or explicitly marked as N/A
+- [ ] **Section depth matches rigor** — tight types (utility) can be brief; deep types (application) need thorough coverage
+
+### Quick Reference
+
+| Type | Required Sections | Rigor |
+|------|------------------|-------|
+| Application | 8 of 10 | deep — thorough coverage expected |
+| Workflow | 6 of 8 | standard — balanced |
+| Client | 6 of 7 | standard — business-focused |
+| Utility | 6 of 6 | tight — all required, but brief |
+| Campaign | 6 of 7 | creative — can be loose, but measurable goal required |
+
+## PAUL-Readiness Checks (for /seed launch)
+
+These are only required if the user intends to run `/seed launch` (graduate + PAUL init). Skip for `/seed graduate` alone.
+
+- [ ] **Phase breakdown** exists with independently shippable milestones
+- [ ] **Each phase** has build, testable, and outcome defined
+- [ ] **Tech stack decisions** are resolved — no critical "TBD" items
+- [ ] **Enough detail** that PAUL can derive milestones, phases, and structure without re-asking questions
+
+## Assessment
+
+| Result | Criteria | Action |
+|--------|----------|--------|
+| **Pass** | All universal checks + all required type-specific sections | Proceed with graduation |
+| **Warn** | Missing optional sections or thin content in some areas | Note gaps, ask user if they want to flesh out or proceed |
+| **Fail** | Missing required sections or no problem statement | Recommend returning to `/seed` to complete ideation |
+
+## Usage
+
+This checklist is referenced by:
+- `tasks/graduate.md` — step `quality_check` (before creating app directory)
+- `tasks/launch.md` — inherited via graduate delegation
+
+It is NOT a scorecard with numbers. It's a qualitative assessment that the coach persona uses to decide whether to warn the user or proceed.

commands/data/application/config.md

@@ -0,0 +1,21 @@
+# Application — Configuration
+
+| Setting | Value |
+|---------|-------|
+| Rigor | deep |
+| Demeanor | Thorough and architectural — explore trade-offs, push for clarity on data model and deployment before moving on. Applications have the highest complexity ceiling, so don't rush. |
+| Sections | 10 |
+
+## Required Sections
+- Problem Statement
+- Tech Stack
+- Data Model
+- API Surface
+- Deployment Strategy
+- Security Considerations
+- UI/UX Needs
+- Phase Breakdown
+
+## Optional Sections
+- Integration Points
+- Skill Loadout

commands/data/application/guide.md

@@ -0,0 +1,51 @@
+# Application — Conversation Guide
+
+## Section 1: Problem Statement
+**Explore:** What does this solve? Who's it for — just you, a team, the public? Why build it instead of buying something off the shelf? What's the pain point that makes this worth the effort?
+**Suggest:** If the user is vague, try: "What's the one thing a user would do in their first 5 minutes?" If they're solving their own problem, that's valid — note it as "dogfooding" and move on.
+**Depth:** required
+
+## Section 2: Tech Stack
+**Explore:** Do you have a stack in mind, or are you exploring? What's the deployment target — local, cloud, edge? Any constraints from the team or existing infrastructure? Why this stack over alternatives?
+**Suggest:** For solo builders: Next.js + SQLite is fast to ship. For teams: consider what everyone knows. If they mention unfamiliar tech, suggest `/paul:discover` for research before committing.
+**Depth:** required
+
+## Section 3: Data Model
+**Explore:** What are the core things this app tracks? How do they relate to each other? What's the most important entity — the one everything else connects to?
+**Suggest:** Start with 3-5 entities max. Draw the relationships: "A User has many X, each X belongs to one Y." If it's getting complex, suggest starting with the minimum viable schema and evolving.
+**Depth:** required
+
+## Section 4: API Surface
+**Explore:** What endpoints does this need? Is there auth? Internal-only or public API? REST, GraphQL, or tRPC? What's the most critical endpoint — the one that delivers core value?
+**Suggest:** For MVPs: REST is fastest to build. Auth: start with JWT or session-based, don't over-engineer. If they need real-time: consider SSE over WebSockets for simplicity.
+**Depth:** required
+
+## Section 5: Deployment Strategy
+**Explore:** Where does this run? Local dev setup, staging, production — what's the plan for each? Docker or bare metal? CI/CD pipeline needed?
+**Suggest:** For solo projects: Railway or Vercel for zero-config deploys. For Docker: suggest a compose file early. If they need a database: managed > self-hosted for MVPs.
+**Depth:** required
+
+## Section 6: Security Considerations
+**Explore:** What's the auth model? What data is sensitive? Any compliance requirements (HIPAA, SOC2, GDPR)? What are the OWASP risks specific to THIS app?
+**Suggest:** At minimum: input validation, parameterized queries, CSRF protection, rate limiting. If handling PII: encryption at rest. Don't over-engineer security for internal tools.
+**Depth:** required
+
+## Section 7: UI/UX Needs
+**Explore:** What does the user see? Key views/pages? Design system or freestyle? Mobile-responsive needed? Any real-time UI requirements (dashboards, notifications)?
+**Suggest:** For MVPs: Tailwind + shadcn/ui gets you 80% there. If they have design ideas, suggest ui-ux-pro-max for implementation. If not, suggest starting with a wireframe conversation.
+**Depth:** required
+
+## Section 8: Integration Points
+**Explore:** What external systems does this talk to? APIs, webhooks, MCP servers, third-party services? What happens if an integration is down?
+**Suggest:** List each integration with: what data flows, which direction, what auth is needed. For MCP servers: check if one already exists in the workspace before building new.
+**Depth:** optional
+
+## Section 9: Phase Breakdown
+**Explore:** What's the minimum slice that proves the concept? What comes after that? Can you ship something useful in 3-5 phases? What's the "it works" moment for each phase?
+**Suggest:** Phase 1 should be the smallest thing that delivers value. Each phase should be independently testable. If they're planning more than 7 phases, the scope might be too big.
+**Depth:** required
+
+## Section 10: Skill Loadout
+**Explore:** Which ecosystem tools make sense for this build? Need code quality scanning? UI design help? Structured development workflow?
+**Suggest:** Load skill-loadout.md recommendations. For most applications: PAUL (required for managed build), AEGIS (recommended post-build audit), ui-ux-pro-max (if frontend-heavy).
+**Depth:** optional

commands/data/application/skill-loadout.md

@@ -0,0 +1,11 @@
+# Application — Skill Loadout
+
+## Recommended Tools
+
+| Tool | Priority | Why |
+|------|----------|-----|
+| PAUL | required | Structured milestones and phases for managed build — applications are too complex for ad-hoc development |
+| AEGIS | recommended | Post-build security and quality audit — catches OWASP issues, scalability gaps |
+| ui-ux-pro-max | recommended | Frontend design system, component patterns, responsive layouts — if the app has a UI |
+| sonarqube | optional | Continuous code quality scanning — useful for larger codebases or team projects |
+| use-railway | optional | If deploying to Railway — handles project creation, env vars, domains |

commands/data/campaign/config.md

@@ -0,0 +1,18 @@
+# Campaign — Configuration
+
+| Setting | Value |
+|---------|-------|
+| Rigor | creative |
+| Demeanor | Loose and generative — let ideas flow, explore angles, brainstorm freely. But always anchor back to the measurable goal. Campaigns are timeline-driven, not architecture-driven. |
+| Sections | 7 |
+
+## Required Sections
+- Strategy & Goal
+- Audience
+- Deliverables List
+- Channels & Platforms
+- Timeline
+- Success Metrics
+
+## Optional Sections
+- Skill Loadout

commands/data/campaign/guide.md

@@ -0,0 +1,36 @@
+# Campaign — Conversation Guide
+
+## Section 1: Strategy & Goal
+**Explore:** What's the specific measurable objective? Not "grow the channel" — something like "launch 10 shorts in 2 weeks" or "generate 50 leads from webinar." What's the thesis?
+**Suggest:** If the goal is vague, push for a number: "How will you know this worked? What's the metric?" If they can't answer, the campaign isn't ready to plan — it needs more strategic thinking first.
+**Depth:** required
+
+## Section 2: Audience
+**Explore:** Who is this for — existing audience or new acquisition? What are their pain points? What language do they use? Where do they hang out online?
+**Suggest:** Be specific: "Agency owners who use GoHighLevel and feel overwhelmed by AI" is better than "business owners." If targeting existing audience, note the platform where they already are.
+**Depth:** required
+
+## Section 3: Deliverables List
+**Explore:** Enumerate EVERY output. For each: format, length, platform, due date. What gets created first? What depends on what?
+**Suggest:** Table it: Deliverable | Format | Platform | Length | Due Date. If the list is longer than 15 items, consider splitting into multiple campaigns. If it's under 3, it might not need SEED — just do it.
+**Depth:** required
+
+## Section 4: Channels & Platforms
+**Explore:** Where does each deliverable go? Cross-posting strategy? Platform-specific adaptations needed? What's the primary channel vs amplification?
+**Suggest:** Pick one primary channel and 2-3 amplification channels. Don't try to be everywhere. For shortform: IG Reels → TikTok → YT Shorts → FB Reels is the standard cross-post chain.
+**Depth:** required
+
+## Section 5: Timeline
+**Explore:** What are the dates? What depends on what? What's the critical path? Any external deadlines (launches, events, partner commitments)?
+**Suggest:** Work backwards from the launch date. Build in buffer for content creation (it always takes longer). If there are dependencies (e.g., "can't post until site launches"), mark them as blockers.
+**Depth:** required
+
+## Section 6: Success Metrics
+**Explore:** Define metrics BEFORE execution, not after. What's the baseline? What's the target? How will you measure?
+**Suggest:** Pick 2-3 metrics max. For content: views, engagement rate, conversion to next step. For launches: signups, revenue, retention. Don't track everything — track what matters.
+**Depth:** required
+
+## Section 7: Skill Loadout
+**Explore:** Which ecosystem tools help with this campaign? Content strategy? Distribution optimization? Script writing?
+**Suggest:** Load skill-loadout.md recommendations. For most campaigns: content-flywheel-strategist (for multi-platform strategy).
+**Depth:** optional

commands/data/campaign/skill-loadout.md

@@ -0,0 +1,8 @@
+# Campaign — Skill Loadout
+
+## Recommended Tools
+
+| Tool | Priority | Why |
+|------|----------|-----|
+| content-flywheel-strategist | recommended | Multi-platform content strategy — transform core content into platform-specific formats |
+| PAUL | optional | Only if the campaign has a complex build component (e.g., landing page + email sequence + webinar) |

commands/data/client/config.md

@@ -0,0 +1,18 @@
+# Client — Configuration
+
+| Setting | Value |
+|---------|-------|
+| Rigor | standard |
+| Demeanor | Business-focused and practical — understand the client's goals, push for conversion clarity, keep tech decisions simple. The client cares about results, not architecture. |
+| Sections | 7 |
+
+## Required Sections
+- Business Context
+- Competitor Analysis
+- Conversion Strategy
+- Content Needs
+- Tech Approach
+- Timeline & Deliverables
+
+## Optional Sections
+- Skill Loadout

commands/data/client/guide.md

@@ -0,0 +1,36 @@
+# Client — Conversation Guide
+
+## Section 1: Business Context
+**Explore:** Who's the client? What industry? Who's the target audience? What's the brand personality? Do they have an existing site?
+**Suggest:** Build the context from conversation: industry, audience demographics, competitive positioning. If they have an existing site, browse it for additional details.
+**Depth:** required
+
+## Section 2: Competitor Analysis
+**Explore:** Who are 3-5 competitors? What are they doing well? Where's the positioning opportunity — what gap can this client fill? What's the differentiator?
+**Suggest:** Focus on positioning, not feature comparison. "They all do X, but none of them do Y" is the goal. If the user doesn't know competitors, suggest searching the client's industry + location.
+**Depth:** required
+
+## Section 3: Conversion Strategy
+**Explore:** What's the primary CTA? What's the funnel — visitor → lead → customer? What objections does the audience have? How does the site overcome them?
+**Suggest:** Every page needs a clear next step. For service businesses: contact form or calendar booking. For products: add to cart or free trial. Map the objection → response pairs.
+**Depth:** required
+
+## Section 4: Content Needs
+**Explore:** What content exists already? What needs to be written? Who writes it — the client, you, AI-assisted? Any brand guidelines or tone requirements?
+**Suggest:** Start with the minimum: hero copy, about section, service descriptions, testimonials. Don't plan a blog unless the client will actually write posts. Real content > placeholder content.
+**Depth:** required
+
+## Section 5: Tech Approach
+**Explore:** site-launcher-wp or custom build? What's the hosting situation? Domain owned? Any existing tech constraints (CMS, hosting provider)?
+**Suggest:** For most client sites: site-launcher-wp is fastest to production. Custom only if the client needs something the template can't handle. Always ask about domain and hosting first.
+**Depth:** required
+
+## Section 6: Timeline & Deliverables
+**Explore:** What's the deadline? Are there client review checkpoints? What are the deliverables at each stage? Who approves what?
+**Suggest:** Suggest a 3-phase approach: (1) Design/content draft → client review, (2) Build → client review, (3) Launch prep → go live. Build in buffer for client feedback cycles.
+**Depth:** required
+
+## Section 7: Skill Loadout
+**Explore:** Which ecosystem tools will speed up this project? Need business context extraction? Conversion copywriting help? Design system?
+**Suggest:** Load skill-loadout.md recommendations. For most client sites: ui-ux-pro-max (for design), PAUL (for structured phases).
+**Depth:** optional

commands/data/client/skill-loadout.md

@@ -0,0 +1,9 @@
+# Client — Skill Loadout
+
+## Recommended Tools
+
+| Tool | Priority | Why |
+|------|----------|-----|
+| ui-ux-pro-max | recommended | Design system, responsive layouts, component patterns for the site build |
+| PAUL | recommended | Structured phases if the project has multiple deliverables or a complex timeline |
+| geo | optional | SEO/GEO audit after launch — optimize for AI search visibility |

commands/data/utility/config.md

@@ -0,0 +1,18 @@
+# Utility — Configuration
+
+| Setting | Value |
+|---------|-------|
+| Rigor | tight |
+| Demeanor | Fast and constrained — resist scope creep actively, push for single-purpose clarity, challenge any expansion. Utilities should be done in one session. |
+| Sections | 6 |
+
+## Required Sections
+- Problem Statement
+- Scope Guard
+- User & Distribution
+- Dependencies
+- Interface
+- Done Criteria
+
+## Optional Sections
+None — all sections are required for utilities. Keeping it tight means covering everything, just briefly.

commands/data/utility/guide.md

@@ -0,0 +1,31 @@
+# Utility — Conversation Guide
+
+## Section 1: Problem Statement
+**Explore:** What does this tool do? One sentence. If it takes more than one sentence, it might not be a utility.
+**Suggest:** Push for brevity: "It takes X and produces Y." If the description is getting complex, ask: "Is this actually an application?" Utilities resist expansion — that's a feature, not a limitation.
+**Depth:** required
+
+## Section 2: Scope Guard
+**Explore:** One file or multiple? One function or a system? What does this explicitly NOT do? Where's the boundary?
+**Suggest:** Actively resist expansion. If the user says "and it could also..." — stop them. "That sounds like a separate tool. Let's keep this one focused." The best utilities do one thing well.
+**Depth:** required
+
+## Section 3: User & Distribution
+**Explore:** Who uses this — just you, your team, the community? Where does it live — tools/personal, tools/shareable, tools/mcp-servers?
+**Suggest:** Personal tools go in tools/personal/. If it's useful to others: tools/shareable/. If it's an MCP server: tools/mcp-servers/production/. Distribution affects how much documentation you need.
+**Depth:** required
+
+## Section 4: Dependencies
+**Explore:** What does this depend on? External APIs, npm packages, system tools? Can you minimize dependencies?
+**Suggest:** Fewer deps = less maintenance. If a dependency is heavy (e.g., puppeteer for a simple scrape), consider whether a lighter alternative exists. Zero-dep utilities are the gold standard.
+**Depth:** required
+
+## Section 5: Interface
+**Explore:** How is it invoked? CLI args, stdin, function call, MCP tool? What's the input format? What's the output format?
+**Suggest:** Define the contract: "Input: X (format), Output: Y (format), Errors: Z." If you can't define the interface cleanly, the scope might be too broad.
+**Depth:** required
+
+## Section 6: Done Criteria
+**Explore:** What are 3-5 test cases that prove this works? Can you define them now? If you can't, the scope might be too vague.
+**Suggest:** Write the test cases as: "Given X, expect Y." If every test case is different, the tool might be doing too many things. 3 test cases is the sweet spot for utilities.
+**Depth:** required