diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json new file mode 100644 index 0000000..f4b4681 --- /dev/null +++ b/.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"] + } + ] +} diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json new file mode 100644 index 0000000..d974f10 --- /dev/null +++ b/.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" + } +} diff --git a/.github/workflows/plugin-install.yml b/.github/workflows/plugin-install.yml new file mode 100644 index 0000000..684fd23 --- /dev/null +++ b/.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' diff --git a/commands/checklists/planning-quality.md b/commands/checklists/planning-quality.md new file mode 100644 index 0000000..ea39b54 --- /dev/null +++ b/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. diff --git a/commands/data/application/config.md b/commands/data/application/config.md new file mode 100644 index 0000000..19edc04 --- /dev/null +++ b/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 diff --git a/commands/data/application/guide.md b/commands/data/application/guide.md new file mode 100644 index 0000000..2a19926 --- /dev/null +++ b/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 diff --git a/commands/data/application/skill-loadout.md b/commands/data/application/skill-loadout.md new file mode 100644 index 0000000..1df9ba7 --- /dev/null +++ b/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 | diff --git a/commands/data/campaign/config.md b/commands/data/campaign/config.md new file mode 100644 index 0000000..b43bc81 --- /dev/null +++ b/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 diff --git a/commands/data/campaign/guide.md b/commands/data/campaign/guide.md new file mode 100644 index 0000000..a3f6ff5 --- /dev/null +++ b/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 diff --git a/commands/data/campaign/skill-loadout.md b/commands/data/campaign/skill-loadout.md new file mode 100644 index 0000000..13adf6e --- /dev/null +++ b/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) | diff --git a/commands/data/client/config.md b/commands/data/client/config.md new file mode 100644 index 0000000..b70bad4 --- /dev/null +++ b/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 diff --git a/commands/data/client/guide.md b/commands/data/client/guide.md new file mode 100644 index 0000000..515f1ec --- /dev/null +++ b/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 diff --git a/commands/data/client/skill-loadout.md b/commands/data/client/skill-loadout.md new file mode 100644 index 0000000..0fe0dba --- /dev/null +++ b/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 | diff --git a/commands/data/utility/config.md b/commands/data/utility/config.md new file mode 100644 index 0000000..fb3bdf3 --- /dev/null +++ b/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. diff --git a/commands/data/utility/guide.md b/commands/data/utility/guide.md new file mode 100644 index 0000000..3c453ac --- /dev/null +++ b/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 diff --git a/commands/data/utility/skill-loadout.md b/commands/data/utility/skill-loadout.md new file mode 100644 index 0000000..dafe5c3 --- /dev/null +++ b/commands/data/utility/skill-loadout.md @@ -0,0 +1,8 @@ +# Utility — Skill Loadout + +## Recommended Tools + +| Tool | Priority | Why | +|------|----------|-----| +| PAUL | optional | Only if the utility is complex enough to warrant phases — most utilities are built in one session without PAUL | +| AEGIS | optional | Post-build quality check — useful if the utility will be distributed or handles sensitive data | diff --git a/commands/data/workflow/config.md b/commands/data/workflow/config.md new file mode 100644 index 0000000..f230325 --- /dev/null +++ b/commands/data/workflow/config.md @@ -0,0 +1,19 @@ +# Workflow — Configuration + +| Setting | Value | +|---------|-------| +| Rigor | standard | +| Demeanor | Balanced and systems-aware — understand integrations, push for clear boundaries, but don't over-architect. Workflows should be lean. | +| Sections | 8 | + +## Required Sections +- Problem Statement +- Scope Definition +- Integration Map +- Interaction Design +- Output Artifacts +- Edge Cases & Constraints + +## Optional Sections +- Downstream Handoff +- Tool Discovery diff --git a/commands/data/workflow/guide.md b/commands/data/workflow/guide.md new file mode 100644 index 0000000..be20264 --- /dev/null +++ b/commands/data/workflow/guide.md @@ -0,0 +1,41 @@ +# Workflow — Conversation Guide + +## Section 1: Problem Statement +**Explore:** What workflow pain or gap does this solve? What's the current process, and where does it break down? Is this a new capability or improving an existing one? +**Suggest:** Frame it as "before vs after" — what does the user do today vs what they'll do with this workflow. If it's replacing manual steps, list them. +**Depth:** required + +## Section 2: Scope Definition +**Explore:** What components does this include? Commands, skills, BASE domains, hooks, MCP tools, templates? What's the boundary — what does this workflow NOT do? +**Suggest:** Use a checklist: "Does this need a slash command? A BASE domain? An MCP server? A hook?" Most workflows are 2-3 of these, not all. If they're building all of them, the scope may be too big. +**Depth:** required + +## Section 3: Integration Map +**Explore:** What existing systems does this touch? BASE v2, PAUL, Skillsmith? What files does it read or write? What doesn't it touch? +**Suggest:** Draw the integration map as a table: System | Reads | Writes | Why. If touching more than 3 systems, consider whether this is really one workflow or two. +**Depth:** required + +## Section 4: Interaction Design +**Explore:** What's the entry point? User says X, Claude does Y. What's the conversation flow? Where are the decision points? What does "done" look like? +**Suggest:** Write 2-3 example interactions: "User runs /command, Claude responds with..., user confirms..., Claude produces..." This is the spec that drives implementation. +**Depth:** required + +## Section 5: Output Artifacts +**Explore:** What files get created or modified? What format? Where do they live? Are outputs consumed by other workflows? +**Suggest:** Table it: File | Format | Location | Consumed By. If outputs feed other systems, that's an integration point — note it. +**Depth:** required + +## Section 6: Downstream Handoff +**Explore:** How does the output of this workflow connect to the next stage? Does it feed into PAUL, BASE, another command? Is there a manual step between? +**Suggest:** If the handoff is manual, consider whether it should be automated. If it feeds PAUL, ensure the output format matches what PAUL expects. +**Depth:** optional + +## Section 7: Tool Discovery +**Explore:** What's missing from the ecosystem that would make this workflow better? Any MCP servers needed? Any skills that should exist but don't? +**Suggest:** Check existing tools first — search MCP servers, slash commands, skills. Don't build what already exists. If something is missing, note it as a dependency or future work. +**Depth:** optional + +## Section 8: Edge Cases & Constraints +**Explore:** What shouldn't this workflow do? What happens with bad input? What if a dependency is missing? What's the failure mode? +**Suggest:** List 3-5 "what ifs" and how the workflow handles each. If you can't answer a "what if," that's a design gap to resolve now. +**Depth:** required diff --git a/commands/data/workflow/skill-loadout.md b/commands/data/workflow/skill-loadout.md new file mode 100644 index 0000000..2e8ad6b --- /dev/null +++ b/commands/data/workflow/skill-loadout.md @@ -0,0 +1,9 @@ +# Workflow — Skill Loadout + +## Recommended Tools + +| Tool | Priority | Why | +|------|----------|-----| +| PAUL | required | Structured phases for building multi-component workflows (commands + hooks + domains) | +| Skillsmith | recommended | If the workflow produces a skill — ensures Skillsmith compliance from the start | +| BASE v2 | recommended | If the workflow needs dynamic rules or touches workspace state — domains are graph-native in v2 | diff --git a/commands/seed.md b/commands/seed.md new file mode 100644 index 0000000..6192214 --- /dev/null +++ b/commands/seed.md @@ -0,0 +1,83 @@ +--- +name: seed +type: standalone +version: 1.0.0 +category: operations +description: Typed project incubator — guided ideation through graduation into buildable projects. Part of the Agentic OS by Chris AI Systems. +allowed-tools: [Read, Write, Glob, Grep, Edit, Bash, AskUserQuestion] +--- + + +## What +Typed project incubator — takes raw ideas through collaborative exploration, produces structured PLANNING.md documents, and graduates mature plans into buildable project directories with optional PAUL initialization. + +## When to Use +- Starting a new project (any type) +- Have a vague idea that needs shaping before committing +- Ready to graduate or launch an ideated project +- Want to add a custom project type + +## Not For +- Building the project (use `/paul:init` or `/seed launch` after ideation) +- Auditing existing code (use `/aegis:audit`) +- Creating Claude Code skills (use `/skillsmith`) + + + +## Role +Project coach — helps shape raw ideas into structured, buildable plans. + +## Style +- Collaborative, not interrogative — brainstorms alongside the user, offers concrete suggestions when stuck +- Pushes toward decisions when it's time, lets ideas breathe when they need space +- Adapts rigor and demeanor to project type — tight for utilities, deeper for applications, creative for campaigns +- Knows the Agentic OS ecosystem — suggests BASE v2, PAUL, Skillsmith where relevant + +## Expertise +- Composable via `data/{type}/` — expertise loads based on selected project type +- Core: project scoping, feasibility assessment, ecosystem integration (BASE v2, PAUL, Skillsmith) +- Application architecture, Claude Code workflows, conversion/content strategy (type-specific depth) + + + +| Command | Description | Routes To | +|---------|-------------|-----------| +| `/seed` | Default — type-first guided ideation | tasks/ideate.md | +| `/seed graduate` | Graduate ideation → `apps/` with git repo | tasks/graduate.md | +| `/seed launch` | Graduate + PAUL install/init (headless, no re-asking) | tasks/launch.md | +| `/seed status` | Show all `projects/` and their ideation state | tasks/status.md | +| `/seed add-type` | Add a custom project type to SEED's data layer | tasks/add-type.md | + + + +## Always Load +Nothing — SEED is lightweight until a command is invoked. + +## Load on Command +@tasks/ideate.md (when user runs /seed or /seed ideate) +@tasks/graduate.md (when user runs /seed graduate) +@tasks/launch.md (when user runs /seed launch) +@tasks/status.md (when user runs /seed status) +@tasks/add-type.md (when user runs /seed add-type) + +## Load on Demand +@data/{type}/guide.md (after type selection during ideation — conversation sections) +@data/{type}/config.md (after type selection — rigor level, demeanor, section requirements) +@data/{type}/skill-loadout.md (during skill loadout step — ecosystem tool recommendations) +@templates/planning-{type}.md (during PLANNING.md generation) +@checklists/planning-quality.md (before graduate/launch — quality gate) + + + +SEED loaded. + +- **Ideate** — Shape a new project idea (default) +- **Graduate** — Move a completed ideation to apps/ +- **Launch** — Graduate + initialize PAUL in one step +- **Status** — See all projects in the pipeline +- **Add Type** — Create a custom project type + +What are you building? + +*SEED v1.0 · Part of the Agentic OS · Chris AI Systems · https://chrisai.cv/skool* + diff --git a/commands/tasks/add-type.md b/commands/tasks/add-type.md new file mode 100644 index 0000000..6d28967 --- /dev/null +++ b/commands/tasks/add-type.md @@ -0,0 +1,250 @@ + +Guide the creation of a new project type for SEED's composable data layer — produces guide.md, config.md, and skill-loadout.md in a new data/{type}/ directory. + + + +As a builder with a project category SEED doesn't cover, I want to add a custom type with its own conversation guide and rigor settings, so that /seed ideate gives me type-appropriate guidance for my specific kind of project. + + + +- The 5 default types (application, workflow, client, utility, campaign) don't fit your project +- You have a recurring project category that deserves its own guided flow +- You want type-specific rigor, demeanor, and section structure + + + +@data/application/guide.md (reference for guide structure) +@data/application/config.md (reference for config structure) +@data/application/skill-loadout.md (reference for loadout structure) + + + + + +## Name the Type + +Ask for the new type name — lowercase, hyphenated, singular (e.g., "microservice", "chrome-extension", "course"). + +Check if `data/{name}/` already exists: +- **If exists:** "{name} already exists as a type. Want to edit it, or pick a different name?" +- **If new:** Proceed. + +Show existing types for reference: +> "Current types: application, workflow, client, utility, campaign" +> "What's the new type called?" + +Wait for response. + + + +## Define Conversation Sections + +Ask the user to define the conversation sections for this type. These become the guide.md structure. + +> "What sections should the ideation conversation cover for a **{type}** project?" +> +> For reference, here's how existing types are structured: +> - Application: 10 sections (Problem, Stack, Data Model, API, Deployment, Security, UI/UX, Integrations, Phases, Skill Loadout) +> - Utility: 6 sections (Problem, Scope Guard, User, Dependencies, Interface, Done Criteria) +> +> List your sections in order of importance. Each will get an Explore prompt and a Suggest prompt. + +Wait for response. + + + +## Configure Rigor and Demeanor + +Ask about the type's personality: + +> "How should SEED behave during **{type}** ideation?" +> +> **Rigor level:** (how thorough) +> - `tight` — Fast, resist expansion (like utilities) +> - `standard` — Balanced exploration (like workflows, clients) +> - `deep` — Thorough, architecture matters (like applications) +> - `creative` — Loose, generative (like campaigns) +> +> **Demeanor:** One sentence describing the coaching style for this type. +> +> **Required sections:** Which of your sections must be covered? (Others become optional) + +Wait for response. + + + +## Create Guide File + +Generate `data/{type}/guide.md` with the user's sections. For each section: + +```markdown +## Section {N}: {Name} +**Explore:** {question prompts based on what the user described} +**Suggest:** {coaching suggestions — what to offer when the user is stuck} +**Depth:** {required | optional} +``` + +Present the draft guide for review: + +> "Here's the conversation guide I drafted for **{type}**. Each section has an Explore prompt and a Suggest prompt. Anything to adjust?" + +Wait for response. + +Apply any edits the user requests before writing. + + + +## Create Config and Skill Loadout + +**Create data/{type}/config.md:** +```markdown +# {Type} — Configuration + +| Setting | Value | +|---------|-------| +| Rigor | {from step 3} | +| Demeanor | {from step 3} | +| Sections | {count} | + +## Required Sections +- {list from step 3} + +## Optional Sections +- {list from step 3} +``` + +**Create data/{type}/skill-loadout.md:** + +> "Which ecosystem tools are useful for **{type}** projects? Here are some options:" +> - PAUL, AEGIS, Skillsmith, ui-ux-pro-max, sonarqube +> - content-flywheel-strategist, geo +> +> "List the relevant ones with priority (required/recommended/optional)." + +Wait for response. + +Write the skill-loadout.md with the user's selections. + + + +## Generate Planning Template + +Generate `templates/planning-{type}.md` from the user's defined sections so the full ideate → graduate round-trip works immediately. + +**Structure:** + +1. **YAML frontmatter** (same as built-in types): + ```yaml + --- + description: "{One-line description from ideation}" + type: Planning + about: "{project-name}" + project_type: "{type}" + seed_version: "1.0.0" + seed_source: "https://chrisai.cv/skool" + --- + ``` + +2. **Title and metadata block:** + ```markdown + # {Project Name} + + > {One-line description} + + **Created:** {date} + **Type:** {Type (capitalized)} + **Skill Loadout:** {from skill-loadout.md selections} + **Quality Gates:** {infer from type or use "TBD"} + ``` + +3. **For each section defined in guide.md**, create a corresponding template section: + ```markdown + --- + + ## {Section Name} + + {Placeholder prompt derived from the section's Explore question} + ``` + +4. **Common closing sections** (all types get these): + ```markdown + --- + + ## Implementation Phases + + {High-level phase breakdown — or "TBD during /paul:plan"} + + --- + + ## Open Questions + + - {Unresolved items from ideation} + + --- + + ## Design Decisions + + | # | Decision | Rationale | + |---|----------|-----------| + + --- + + ## References + + - {Links, related files, prior art} + + --- + + *Last updated: {date}* + *Planned with SEED v1.0 · Chris AI Systems · For the official Agentic OS and to permanently remove attribution, visit https://chrisai.cv/skool* + ``` + +Present the generated template to the user: +> "Here's the planning template I generated for **{type}**. Anything to adjust?" + +Wait for response. Apply edits if requested. + +Write to `templates/planning-{type}.md`. + + + +## Confirm + +Report what was created: + +``` +New type created: {type} + +Files: + data/{type}/guide.md ({N} sections) + data/{type}/config.md (rigor: {level}) + data/{type}/skill-loadout.md + templates/planning-{type}.md ({N} sections from guide) + +The type is immediately available. Run /seed {type} to try it. +Template, guide, config, and skill loadout — full round-trip ready. + +SEED v1.0 · Chris AI Systems · https://chrisai.cv/skool · https://youtube.com/@chris-ai-systems +``` + + + + + +- `data/{type}/guide.md` — conversation sections with Explore + Suggest +- `data/{type}/config.md` — rigor, demeanor, required/optional sections +- `data/{type}/skill-loadout.md` — ecosystem tool recommendations +- `templates/planning-{type}.md` — PLANNING.md template with frontmatter and sections from guide + + + +- [ ] New type name validated (lowercase, no collision) +- [ ] Guide created with Explore + Suggest per section +- [ ] Config created with rigor level and required/optional sections +- [ ] Skill loadout created with prioritized tool recommendations +- [ ] Planning template auto-generated from guide sections with standard frontmatter +- [ ] Template includes provenance footer +- [ ] Wait points at every user input boundary +- [ ] New type immediately usable — full ideate → graduate round-trip works +- [ ] Existing types shown as reference during creation + diff --git a/commands/tasks/graduate.md b/commands/tasks/graduate.md new file mode 100644 index 0000000..ab9ba64 --- /dev/null +++ b/commands/tasks/graduate.md @@ -0,0 +1,244 @@ + +Graduate a completed ideation from projects/{name}/ into apps/{name}/ with its own git repo, type-aware README, and workspace tracking updates. + + + +As a builder with a completed PLANNING.md, I want to graduate my project into a proper app directory with git and a synthesized README, so that I can start building without manual setup. + + + +- Ideation is complete and PLANNING.md exists in projects/{name}/ +- Ready to move from planning to building +- Want a clean app directory with git repo and project brief + + + +@seed.md +@checklists/planning-quality.md (quality gate — loaded before graduation) + + + + + +## Detect BASE Version + +Check for BASE v2 (Rust binary) for ecosystem integration. + +1. Check for base binary: + ```bash + which base 2>/dev/null + ``` + +2. **If base binary found:** + ```bash + base --version 2>/dev/null + ``` + - If output contains a semver (e.g., "base 0.1.0") → Rust binary (v2) detected + - Store `base_v2_available = true` + - Silent pass — continue + - If output is empty, errors, or doesn't match semver → v1/Python detected + - **HARD STOP.** Display: + ``` + ════════════════════════════════════════ + ⛔ BASE v1 detected — not compatible with SEED v1.0+ + ════════════════════════════════════════ + + BASE v1 (Python/MCP) is no longer supported. + SEED now integrates with BASE v2 (Rust) for the + full Agentic OS experience. + + Upgrade: https://chrisai.cv/skool + + SEED · Chris AI Systems + ════════════════════════════════════════ + ``` + - Do NOT proceed + +3. **If no base binary on PATH:** + - Store `base_v2_available = false` + - Display: + ``` + ℹ️ BASE not detected. SEED works standalone, but for the + full Agentic OS — workspace intelligence, proactive context, + knowledge graph — get BASE v2: https://chrisai.cv/skool + ``` + - Continue with graduation (not a hard stop) + +4. **Additional v1 artifact check** (even if no base binary): + - Check for `.base/data/*.json` files (v1's JSON store): + ```bash + ls .base/data/*.json 2>/dev/null + ``` + - If found: display v1 warning (same hard stop as step 2) + + + +## Validate Project + +Check `$ARGUMENTS` for a project name. + +**If no argument provided:** +Scan `projects/` for directories containing PLANNING.md. List them: + +> "Available projects ready for graduation:" +> - {name} ({type from PLANNING.md}) +> - {name} ({type}) +> +> "Which one? Or provide a name." + +Wait for response. + +**If argument provided:** +1. Confirm `projects/{name}/PLANNING.md` exists — if not: "No PLANNING.md found at `projects/{name}/`. Run `/seed` to create one first." +2. Confirm `apps/{name}/` does NOT exist — if it does: "`apps/{name}/` already exists. This project was already graduated." +3. If either check fails, stop. + + + +## Quality Gate + +Read `projects/{name}/PLANNING.md` and extract: +- **Type** metadata field (application, workflow, client, utility, campaign) +- Overall content depth + +Reference `checklists/planning-quality.md` to assess whether the PLANNING.md is rich enough for a clean graduation and potential headless PAUL init. + + +Infer type from content, or ask: "I can't find a Type field in this PLANNING.md. What type of project is this? (application, workflow, client, utility, campaign)" + +Wait for response. + + + +Warn the user: + +> "This PLANNING.md looks light — it may not have enough detail for a strong README or future PAUL init. Want to go back to `/seed` to flesh it out, or graduate as-is?" + +Wait for response. If user wants to proceed, continue. If not, exit with suggestion to run `/seed`. + + + + +## Create App Directory + +1. Create the app directory: + ```bash + mkdir -p apps/{name} + ``` + +2. Initialize git repo: + ```bash + cd apps/{name} + git init -b main + ``` + + + +## Synthesize README + +Read `projects/{name}/PLANNING.md` fully. Generate `apps/{name}/README.md` by **synthesizing** (not copying) a clean project brief. + +**Common sections (all types):** +- Title and one-line description +- Type, Skill Loadout, Quality Gates metadata +- Overview — concise summary of what and why +- Design Decisions — resolved decisions (numbered) +- Implementation Phases — phase breakdown (or "N/A" for small projects) +- Open Questions — unresolved items +- References + +**Type-specific sections to add:** + +| Type | Additional Sections | +|------|-------------------| +| Application | Stack, Deploy, Data Model, API Surface, Architecture, UI/UX | +| Workflow | Scope Definition, Integration Map, Interaction Design, Output Artifacts | +| Client | Client name, Business Context, Conversion Strategy, Timeline, Tech Approach | +| Utility | Location, Interface (invocation/input/output), Done Criteria | +| Campaign | Goal, Deliverables List, Timeline, Success Metrics | + +**Synthesis guidelines:** +- Remove brainstorming artifacts, iteration history, abandoned ideas +- Keep all resolved design decisions +- Keep technical architecture details +- Keep implementation phases +- Preserve tables and structured data (information-dense) +- Preserve Type and Skill Loadout metadata — PAUL uses this for configuration +- The README should be comprehensive enough to run `/paul:init` against + +Present the generated README to the user: + +> "Here's the README I synthesized from your PLANNING.md. Take a look — anything to adjust?" + +Wait for response. + + +Apply edits and re-present until approved. + + + + +## Finalize Graduation + +1. **Write README.md** to `apps/{name}/README.md` + +2. **Initial commit:** + ```bash + cd apps/{name} + git add README.md + git commit -m "Initial commit: project brief from graduation" + ``` + +3. **Register in BASE graph (if `base_v2_available`):** + ```bash + base project add --name "{name}" --path "apps/{name}" + ``` + If the project was already registered during ideation (at `projects/{name}`), update the path: + ```bash + base project update {name} --path "apps/{name}" --status active + ``` + +4. **Note graduation in PLANNING.md** — append to `projects/{name}/PLANNING.md`: + ``` + --- + **Graduated:** {today's date} + **Location:** `apps/{name}/` + **README:** `apps/{name}/README.md` + ``` + +5. **Report:** + ``` + Graduated: projects/{name}/ → apps/{name}/ + README: apps/{name}/README.md + Git: Initialized with initial commit + + Next steps: + - `/paul:init` in apps/{name}/ to start a managed build + - `/seed launch {name}` does this automatically (graduate + PAUL init) + + SEED v1.0 · Chris AI Systems · https://chrisai.cv/skool · https://youtube.com/@chris-ai-systems + ``` + + + + + +- `apps/{name}/` — new app directory with git repo +- `apps/{name}/README.md` — type-aware synthesized project brief +- BASE graph entity updated (if BASE v2 available) +- Graduation note appended to `projects/{name}/PLANNING.md` + + + +- [ ] BASE v2 detection runs before graduation begins +- [ ] BASE v1 triggers hard stop with upgrade link +- [ ] No BASE shows promotion message then continues +- [ ] Input validated: PLANNING.md exists, apps/ doesn't +- [ ] Quality gate checked before graduation +- [ ] Type extracted from PLANNING.md metadata +- [ ] README synthesized with type-specific sections (not copied verbatim) +- [ ] Git repo initialized with initial commit +- [ ] Graph registration/update on graduation (if BASE v2 available) +- [ ] Graduation date noted in original PLANNING.md +- [ ] Wait points present at key decisions (quality warning, README review) + diff --git a/commands/tasks/ideate.md b/commands/tasks/ideate.md new file mode 100644 index 0000000..cb91d84 --- /dev/null +++ b/commands/tasks/ideate.md @@ -0,0 +1,343 @@ + +Guide a user through type-aware collaborative ideation, producing a populated PLANNING.md document ready for graduation or PAUL-managed build. + + + +As a builder with a raw idea, I want guided exploration shaped by my project type, so that I produce a structured PLANNING.md without missing critical design decisions. + + + +- Starting a new project and need to shape the idea before building +- Have a vague concept that needs structure and scoping +- Want type-specific guidance (app vs utility vs campaign needs different depth) +- Ready to produce a PLANNING.md for `/seed graduate` or `/seed launch` + + + +@seed.md +@data/{type}/guide.md (loaded after type selection) +@data/{type}/config.md (loaded after type selection) +@data/{type}/skill-loadout.md (loaded during skill loadout step) +@templates/planning-{type}.md (loaded during output generation) +@checklists/planning-quality.md (referenced as quality gate before output) + + + + + +## SEED-STATE.md Checkpoint Format + +When saving checkpoints during ideation, write `projects/{name}/SEED-STATE.md` in this format: + +```markdown +# SEED State: {name} + +## Meta +- **Type:** {type} +- **Started:** {ISO timestamp} +- **Last Updated:** {ISO timestamp} +- **Position:** Section {N} of {total} — "{section_name}" +- **BASE v2:** {true|false} + +## Gathered Data + +### Project Name +{name} + +### Core Description +{description from early conversation} + +### Sections Completed +| Section | Status | Summary | +|---------|--------|---------| +| {section_name} | complete | {1-2 line summary of what was decided} | +| {section_name} | complete | {summary} | +| {section_name} | pending | — | + +### Raw Responses +{section_name}: {user's response text or summarized key points} +{section_name}: {response} +``` + +This captures enough to restore full conversation state without replaying it. + + + +## Detect BASE Version + +Check for BASE v2 (Rust binary) for ecosystem integration. + +1. Check for base binary: + ```bash + which base 2>/dev/null + ``` + +2. **If base binary found:** + ```bash + base --version 2>/dev/null + ``` + - If output contains a semver (e.g., "base 0.1.0") → Rust binary (v2) detected + - Store `base_v2_available = true` + - Silent pass — continue + - If output is empty, errors, or doesn't match semver → v1/Python detected + - **HARD STOP.** Display: + ``` + ════════════════════════════════════════ + ⛔ BASE v1 detected — not compatible with SEED v1.0+ + ════════════════════════════════════════ + + BASE v1 (Python/MCP) is no longer supported. + SEED now integrates with BASE v2 (Rust) for the + full Agentic OS experience. + + Upgrade: https://chrisai.cv/skool + + SEED · Chris AI Systems + ════════════════════════════════════════ + ``` + - Do NOT proceed + +3. **If no base binary on PATH:** + - Store `base_v2_available = false` + - Display: + ``` + ℹ️ BASE not detected. SEED works standalone, but for the + full Agentic OS — workspace intelligence, proactive context, + knowledge graph — get BASE v2: https://chrisai.cv/skool + ``` + - Continue with ideation (not a hard stop) + +4. **Additional v1 artifact check** (even if no base binary): + - Check for `.base/data/*.json` files (v1's JSON store): + ```bash + ls .base/data/*.json 2>/dev/null + ``` + - If found: display v1 warning (same hard stop as step 2) + + + +## Check for Resumable Ideations + +Scan `projects/` for directories containing `SEED-STATE.md`: +```bash +find projects/*/SEED-STATE.md 2>/dev/null +``` + +**If none found:** Skip silently — proceed to `determine_type`. + +**If found:** Parse each SEED-STATE.md for name, type, position, and last updated timestamp. Present: + +``` +Resumable ideations found: + +[1] {name} ({type}) — stopped at "{section_name}" ({date}) +[2] {name} ({type}) — stopped at "{section_name}" ({date}) +[3] Start fresh + +Which one? +``` + +Wait for response. + +**If resume chosen:** +1. Read `projects/{name}/SEED-STATE.md` fully +2. Restore: type, project name, `base_v2_available` flag, all gathered section data +3. Load type context — read `data/{type}/guide.md` and `data/{type}/config.md` +4. Adopt coach persona as normal +5. Skip directly to the first section marked `pending` in the Sections Completed table +6. Acknowledge the resume briefly: "Picking up where we left off on **{name}**. We covered {N} sections — next up is **{section_name}**." +7. Continue `guided_conversation` from that point + +**If start fresh:** Proceed to `determine_type` as normal. Do NOT delete existing SEED-STATE.md files — the user may return to them later. + + + +## Determine Project Type + +Check `$ARGUMENTS` for a type match: + +| Input | Type | +|-------|------| +| `application`, `app` | application | +| `workflow` | workflow | +| `client` | client | +| `utility`, `tool` | utility | +| `campaign`, `content` | campaign | + +**If match found:** Confirm with user — "Sounds like an **{type}** project. That right?" + +**If no match or empty:** Ask the user to describe what they're building in a sentence or two. Then suggest the best-fit type with reasoning: + +> "Based on what you described, this sounds like a **{type}** project — {one-line reason}. Does that fit?" + +Use these signals to route: + +| Type | Signals | +|------|---------| +| Application | Has UI, data model, API, deployment — software people use | +| Workflow | Commands, hooks, domains, templates — Claude Code tooling | +| Client | Website for a client — business context, conversion, content | +| Utility | Small tool, script, single-purpose — resists expansion | +| Campaign | Content, marketing, launches — timeline-driven, not code-driven | + +Wait for response before proceeding. + +**Checkpoint:** After type is confirmed, write initial `projects/{name}/SEED-STATE.md` (if project name is already known from `$ARGUMENTS`) or queue for write after `get_project_name`. + + + +## Get Project Name + +Ask for a project name — lowercase, hyphenated. This becomes the directory name under `projects/`. + +Check if `projects/{name}/` already exists: +- **If exists:** "There's already a `projects/{name}/` directory. Want to continue that existing ideation, or pick a different name?" +- **If new:** Create `projects/{name}/` directory. + +Wait for response. + +**Checkpoint:** After project directory is created and type is confirmed, write initial `projects/{name}/SEED-STATE.md` with type, project name, and timestamp. All sections marked `pending`. + + + +## Load Type Context + +Read the composable data files for the selected type: + +1. Read `data/{type}/guide.md` — conversation sections for this type +2. Read `data/{type}/config.md` — rigor level, demeanor, required vs optional sections + +**Adopt the coach persona for the rest of this session:** + +You are a project coach. Brainstorm alongside the user — offer concrete suggestions when they're stuck, push toward decisions when it's time, let ideas breathe when they need space. You are NOT an interrogator firing questions. You're a thinking partner who happens to know the ecosystem. + +Adapt your approach based on config.md: +- **Tight rigor** (utilities): Move fast, resist scope creep, keep it small +- **Standard rigor** (workflows, clients): Balanced exploration, clear boundaries +- **Deep rigor** (applications): Thorough exploration, architecture matters +- **Creative rigor** (campaigns): Loose, generative, timeline-focused + + + +## Guided Exploration + +Work through the sections defined in `data/{type}/guide.md`. These are conversation prompts, not a questionnaire. + +**Rules of engagement:** +- Present 1-2 related sections at a time, not all at once +- Adapt based on discussion flow — skip sections the user has already addressed naturally +- Circle back to sections that need more depth +- Offer concrete suggestions: "For this type of app, most teams use X because..." or "Given your audience, you might consider Y" +- If the user is stuck, propose a direction: "Here's one way this could work: ..." +- If the user is going too broad, gently constrain: "That's ambitious — what's the minimum slice that proves the concept?" + +**Section groups (from guide.md):** + +Work through the guide sections in logical groups. After presenting each group and discussing: + +Wait for response. + +**Checkpoint:** After each section group response, silently update `projects/{name}/SEED-STATE.md` — mark completed sections, store response summaries, advance position. No user notification needed. + +Continue until all required sections (per config.md) are covered, or the user signals they're ready to wrap up. + + +Check config.md for required vs optional sections. If required sections are missing, note them: "We haven't covered {section} yet — that's usually important for {type} projects. Want to hit that quickly, or skip it?" + + + + +## Skill Loadout + +Read `data/{type}/skill-loadout.md` for recommended ecosystem tools. + +Present the recommended skills for this project type: + +> "For a **{type}** project, these tools from the ecosystem are worth considering:" +> - {skill 1} — {why} +> - {skill 2} — {why} + +Ask if any resonate or if they want to note specific tools for the build phase. + +Wait for response. + + + +## Generate PLANNING.md + +When the user is ready (all sections covered or user signals completion): + +1. Read `templates/planning-{type}.md` for output structure +2. Reference `checklists/planning-quality.md` — verify the content is rich enough for headless PAUL init +3. Populate the template with content from the conversation +4. Write to `projects/{name}/PLANNING.md` +5. Fill in the metadata block (Type, Skill Loadout, Quality Gates) + +Present the completed PLANNING.md to the user for review. + +> "Here's the PLANNING.md I've drafted from our conversation. Take a look — anything to adjust before we lock it in?" + +Wait for response. + + +Apply edits and re-present. Repeat until user approves. + + +**Cleanup:** After user approves PLANNING.md, delete the checkpoint — state has graduated: +```bash +rm projects/{name}/SEED-STATE.md 2>/dev/null +``` +Silent — no user notification needed. + + + +## Update Tracking & Report + +After user approves the PLANNING.md: + +1. **If `base_v2_available`:** Register the ideation project in the graph: + ```bash + base project add --name "{name}" --path "projects/{name}" + ``` + This makes the project visible in `base project list` and the BASE dashboard. + +2. **If not `base_v2_available`:** Skip graph registration silently (promotion was already shown at session start). + +3. Report completion: + ``` + Created: projects/{name}/PLANNING.md ({type} template) + {if base_v2_available: "Registered: {name} in BASE graph"} + + Next steps: + - `/seed graduate {name}` — move to apps/ with git init + - `/seed launch {name}` — graduate + initialize PAUL for managed build + + SEED v1.0 · Chris AI Systems · https://chrisai.cv/skool · https://youtube.com/@chris-ai-systems + ``` + + + + + +- `projects/{name}/PLANNING.md` — populated type-specific planning document +- BASE graph entity (if BASE v2 available) +- Location: `projects/{name}/` + + + +- [ ] BASE v2 detection runs before ideation begins +- [ ] BASE v1 triggers hard stop with upgrade link +- [ ] No BASE shows promotion message then continues +- [ ] Type determined before any substantive ideation begins +- [ ] Type-specific data files loaded and used to shape conversation +- [ ] Conversation is collaborative (coach), not interrogative (questionnaire) +- [ ] Wait points present at every user input boundary +- [ ] Existing project detection prevents silent overwrites +- [ ] PLANNING.md generated from type-specific template +- [ ] Planning quality checklist referenced before output +- [ ] Graph registration on completion (if BASE v2 available) +- [ ] SEED-STATE.md checkpoint written after type selection, project name, and each section group +- [ ] Resumable ideations detected and offered on re-entry +- [ ] Resume restores type, persona, gathered data, and skips to next pending section +- [ ] SEED-STATE.md deleted after PLANNING.md is approved (cleanup) + diff --git a/commands/tasks/launch.md b/commands/tasks/launch.md new file mode 100644 index 0000000..088ad35 --- /dev/null +++ b/commands/tasks/launch.md @@ -0,0 +1,219 @@ + +Graduate a project and initialize PAUL in one step — the "easy button" from ideation to managed build. + + + +As a builder ready to start building, I want to graduate my project and set up PAUL in a single command, so that I don't have to run separate graduation and initialization steps. + + + +- Ideation is complete and you want to start building immediately +- You want PAUL-managed development (structured phases, plans, progress tracking) +- You prefer one command over running `/seed graduate` then `/paul:init` separately + + + +@seed.md +@tasks/graduate.md (delegation target — launch wraps this flow) + + + + + +## Detect BASE Version + +Check for BASE v2 (Rust binary) for ecosystem integration. + +1. Check for base binary: + ```bash + which base 2>/dev/null + ``` + +2. **If base binary found:** + ```bash + base --version 2>/dev/null + ``` + - If output contains a semver (e.g., "base 0.1.0") → Rust binary (v2) detected + - Store `base_v2_available = true` + - Silent pass — continue + - If output is empty, errors, or doesn't match semver → v1/Python detected + - **HARD STOP.** Display: + ``` + ════════════════════════════════════════ + ⛔ BASE v1 detected — not compatible with SEED v1.0+ + ════════════════════════════════════════ + + BASE v1 (Python/MCP) is no longer supported. + SEED now integrates with BASE v2 (Rust) for the + full Agentic OS experience. + + Upgrade: https://chrisai.cv/skool + + SEED · Chris AI Systems + ════════════════════════════════════════ + ``` + - Do NOT proceed + +3. **If no base binary on PATH:** + - Store `base_v2_available = false` + - Display: + ``` + ℹ️ BASE not detected. SEED works standalone, but for the + full Agentic OS — workspace intelligence, proactive context, + knowledge graph — get BASE v2: https://chrisai.cv/skool + ``` + - Continue with launch (not a hard stop) + +4. **Additional v1 artifact check** (even if no base binary): + - Check for `.base/data/*.json` files (v1's JSON store): + ```bash + ls .base/data/*.json 2>/dev/null + ``` + - If found: display v1 warning (same hard stop as step 2) + +**Note:** `base_v2_available` is passed through to the graduate delegation and to the PAUL init step so paul.toml gets domain tags if BASE is present. + + + +## Run Graduation + +Execute the full graduation flow from `tasks/graduate.md` first. + +All validation, quality checks, README synthesis, git init, and tracking updates happen there. Do NOT duplicate that logic here — delegate entirely. + +Pass `$ARGUMENTS` through as the project name. + +After graduation completes successfully, proceed to PAUL integration below. + + +Stop here. Do not proceed to PAUL integration. The graduate task handles its own error reporting. + + + + +## Offer PAUL Integration + +After graduation is complete, ask the user: + +> "Project graduated to `apps/{name}/`. Want to initialize PAUL for a managed build?" +> +> PAUL gives you structured milestones, phases, plans, and progress tracking. Your PLANNING.md has enough detail to set up PAUL without re-answering questions. +> +> **Yes** — initialize PAUL now +> **No** — just the graduation is fine (you can run `/paul:init` later) + +Wait for response. + + +Report graduation-only result: + +> "Graduated: `apps/{name}/`" +> "Run `/paul:init` in `apps/{name}/` if you change your mind." + +Exit. + + + + +## Check PAUL Availability + +Check if PAUL is installed via multiple paths: + +1. **Skill path (preferred):** + ```bash + ls ~/.claude/commands/paul/plan.md 2>/dev/null + ``` + +2. **Legacy framework path (fallback):** + ```bash + ls ~/.claude/paul-framework/ 2>/dev/null + ``` + + +Check for v1.4+ features (paul.toml support): +```bash +grep -l "paul.toml\|paul-toml" ~/.claude/commands/paul/*.md 2>/dev/null || grep -l "paul.toml\|paul-toml" ~/.claude/paul-framework/src/templates/*.md 2>/dev/null +``` + +- **If paul.toml references found:** PAUL v1.4+ detected. Pass `base_v2_available` context to PAUL init so it can set domain tags and create paul.toml (not paul.json). +- **If not found:** PAUL pre-v1.4 detected. Display: + ``` + ⚠️ PAUL detected but may be an older version. For full Agentic OS + integration (paul.toml, BASE v2 graph sync, domain tags), update PAUL: + npx paul-framework@latest + + Proceeding with init using current version. + ``` + Continue with init. + + + +Inform the user: + +> "PAUL isn't installed yet." +> +> ``` +> Install: npx paul-framework +> ``` +> +> "Want to install it now, or skip PAUL for now? You can run `/paul:init` later." + +Wait for response. + +If user wants to install: run `npx paul-framework --global` then proceed. +If user declines: exit gracefully with graduation-only result. + + + + +## Headless PAUL Init + +Run `/paul:init` in the graduated `apps/{name}/` directory with headless context: + +1. Read `apps/{name}/README.md` (synthesized from PLANNING.md during graduation) +2. Also read the original `projects/{name}/PLANNING.md` for full depth + +Pass this context to PAUL init with the instruction: + +> "Use the PLANNING.md and README.md as the project brief. Derive milestones, phases, and project structure from them. Do NOT re-ask questions that SEED already answered during ideation — the answers are in these documents. Propose the project structure and ask for approval." + +PAUL will propose a structure (milestones, phases, tech stack). The user reviews and approves — headless means no redundant questions, NOT no approval. + +Wait for response (user approves or adjusts PAUL's proposed structure). + + + +## Report Completion + +After PAUL initialization is approved: + +``` +Launched: {name} +Location: apps/{name}/ +PAUL: Initialized with {milestone} — {N} phases + +Your project is ready for managed development. +Run /paul:plan to start Phase 1. + +SEED v1.0 · Chris AI Systems · https://chrisai.cv/skool · https://youtube.com/@chris-ai-systems +``` + + + + + +- Everything from tasks/graduate.md (app directory, git repo, README, tracking) +- `.paul/` directory in `apps/{name}/` (PROJECT.md, ROADMAP.md, STATE.md) +- Project ready for `/paul:plan` + + + +- [ ] Delegates to tasks/graduate.md without duplicating logic +- [ ] Asks user about PAUL (not filesystem scan for decision) +- [ ] Checks PAUL framework availability before attempting init +- [ ] Prompts installation if PAUL not found +- [ ] Headless PAUL init passes PLANNING.md as context +- [ ] User still approves PAUL's proposed structure +- [ ] Graceful exit if user declines PAUL at any point +- [ ] Wait points at PAUL offer and structure approval + diff --git a/commands/tasks/status.md b/commands/tasks/status.md new file mode 100644 index 0000000..97ea294 --- /dev/null +++ b/commands/tasks/status.md @@ -0,0 +1,124 @@ + +Show the project ideation pipeline — what's in projects/, what's ready to graduate, and what's already been graduated. + + + +As a builder with multiple ideas in progress, I want to see which projects are in ideation, which are ready to graduate, and which have already moved to apps/, so that I can decide what to work on next. + + + +- Want to see all projects in the pipeline +- Deciding which ideation to continue or graduate +- Checking if a project has already been graduated + + + + + +## Detect BASE Version + +Check for BASE v2 (Rust binary) for ecosystem integration. + +1. Check for base binary: + ```bash + which base 2>/dev/null + ``` + +2. **If base binary found:** + ```bash + base --version 2>/dev/null + ``` + - If output contains a semver (e.g., "base 0.1.0") → Rust binary (v2) detected + - Store `base_v2_available = true` + - If output is empty, errors, or doesn't match semver → v1/Python detected + - Display v1 warning (non-blocking for status — read-only command): + ``` + ⚠️ BASE v1 detected. SEED v1.0+ integrates with BASE v2. + Upgrade: https://chrisai.cv/skool + ``` + - Store `base_v2_available = false` + - Continue with filesystem scan + +3. **If no base binary on PATH:** + - Store `base_v2_available = false` + - Display: + ``` + ℹ️ BASE not detected. For the full Agentic OS — workspace + intelligence, proactive context, knowledge graph — get + BASE v2: https://chrisai.cv/skool + ``` + - Continue with filesystem scan + + + +## Scan Pipeline + +**If `base_v2_available`:** + +1. Query the graph for SEED-originated projects: + ```bash + base project list + ``` +2. Filter for projects with paths starting with `projects/` (ideation) or that have PLANNING.md origins +3. Supplement with filesystem scan of `projects/` for any projects not yet in the graph +4. Check `apps/` for graduated projects — cross-reference with graph data + +**If not `base_v2_available`:** + +Filesystem scan (original behavior): + +Scan `projects/` for directories containing `PLANNING.md`. For each project found, extract: + +1. **Name** — directory name +2. **Type** — read Type metadata from PLANNING.md header +3. **Created** — file creation date of PLANNING.md +4. **Graduated** — check if PLANNING.md contains a `**Graduated:**` line at the bottom + +Also check `apps/` for directories that match project names — these are graduated projects. + +If `projects/` doesn't exist or is empty: "No projects in the pipeline. Run `/seed` to start one." + + + +## Display Pipeline + +Present results as a formatted table: + +``` +Project Pipeline +═══════════════════════════════════════════════════ +Name Type Status +─────────────────────────────────────────────────── +{name} {type} Ready for /seed graduate +{name} {type} Graduated → apps/{name}/ +{name} {type} In progress (no Type yet) +═══════════════════════════════════════════════════ +{N} projects | {M} ready to graduate | {K} graduated +``` + +**Status logic:** +- Has Type + content depth → "Ready for /seed graduate" +- Has graduation note → "Graduated → apps/{name}/" +- Missing Type or very thin → "In progress" + +If any projects are ready to graduate, suggest: "Run `/seed graduate {name}` to move to apps/." + + + + + +- Formatted pipeline table displayed to user +- No files created or modified (read-only) + + + +- [ ] BASE v2 detection runs first +- [ ] No BASE shows promotion message then continues with filesystem scan +- [ ] BASE v2 available: queries graph first, supplements with filesystem +- [ ] Scans projects/ for directories with PLANNING.md +- [ ] Extracts name, type, and graduation status per project +- [ ] Displays formatted pipeline table +- [ ] Identifies graduated projects (checks for graduation note) +- [ ] Read-only — does not modify any files +- [ ] Handles empty pipeline gracefully + diff --git a/commands/templates/planning-application.md b/commands/templates/planning-application.md new file mode 100644 index 0000000..8f5dc23 --- /dev/null +++ b/commands/templates/planning-application.md @@ -0,0 +1,203 @@ +--- +description: "{One-line description from ideation}" +type: Planning +about: "{project-name}" +project_type: "application" +seed_version: "1.0.0" +seed_source: "https://chrisai.cv/skool" +--- + +# {Project Name} + +> {One-line description of what this application does} + +**Created:** {date} +**Type:** Application +**Stack:** {framework + language + db + cache + deployment} +**Skill Loadout:** ui-ux-pro-max, /paul:audit, sonarqube scan +**Quality Gates:** test coverage, security scan, accessibility, performance + +--- + +## Problem Statement + +{What does this solve? Who's it for (solo, team, public)? Why build vs buy?} + +--- + +## Tech Stack + +{Framework, language, database, caching, deployment platform. Include "Why this stack?" rationale.} + +| Layer | Choice | Rationale | +|-------|--------|-----------| +| Frontend | {e.g., Next.js, React, Vue} | {why} | +| Backend | {e.g., Laravel, Node, Python} | {why} | +| Database | {e.g., SQLite, Postgres, MySQL} | {why} | +| Cache | {e.g., Redis, none} | {why} | +| Deployment | {e.g., Docker, Vercel, VPS} | {why} | + +### Research Needed +{If exploring unfamiliar tech: what's known, what needs research, what reference architectures exist.} + +--- + +## Data Model + +{Core entities and relationships. Can be rough at ideation stage — refine during PAUL planning.} + +### Entities + +| Entity | Key Fields | Relationships | +|--------|-----------|---------------| +| {e.g., User} | {id, email, role} | {has many Projects} | + +### Notes +- {JSON column candidates, polymorphic relationships, soft deletes, etc.} + +--- + +## API Surface + +{Key route groups, auth strategy, versioning approach.} + +### Auth Strategy +{Sanctum, JWT, session, API key — and why} + +### Route Groups + +| Group | Methods | Auth | Purpose | +|-------|---------|------|---------| +| {e.g., /api/users} | {GET, POST} | {required} | {description} | + +### Internal vs External +- **Public endpoints:** {list} +- **Internal/admin endpoints:** {list} +- **MCP integration points:** {if applicable} + +--- + +## Deployment Strategy + +### Local Development +{Docker Compose services, dev server setup, seed data} + +| Service | Image/Runtime | Port | Purpose | +|---------|--------------|------|---------| +| {e.g., app} | {node:20} | {3000} | {main application} | + +### Staging / Production +{CI/CD approach, environment management, hosting} + +--- + +## Security Considerations + +{Per-app security concerns — not a generic checklist. What's specific to THIS application?} + +- **Auth/Authz model:** {description} +- **Input validation:** {key areas} +- **OWASP concerns:** {relevant items for this app} +- **Secrets management:** {approach} +- **Rate limiting:** {if applicable} + +--- + +## UI/UX Needs + +{Frontend requirements, design approach, key views.} + +### Design System +{Tailwind, shadcn, custom components — and why} + +### Key Views / Pages + +| View | Purpose | Complexity | +|------|---------|------------| +| {e.g., Dashboard} | {primary workspace} | {high — real-time data} | + +### Real-Time Requirements +{WebSockets, SSE, polling — if applicable} + +### Responsive Needs +{Desktop-first, mobile-first, both, or desktop-only} + +--- + +## Integration Points + +{External APIs, MCP servers, webhooks, third-party services.} + +| Integration | Type | Purpose | Auth | +|------------|------|---------|------| +| {e.g., Stripe} | {API} | {payments} | {API key} | + +--- + +## Phase Breakdown + +{Independently shippable milestones. Each phase: what's built, what's testable, what's the user-facing outcome. Maps directly to PAUL milestones.} + +### Phase 1: {Name} +- **Build:** {what gets built} +- **Testable:** {what can be verified} +- **Outcome:** {user-facing result} + +### Phase 2: {Name} +- **Build:** {what gets built} +- **Testable:** {what can be verified} +- **Outcome:** {user-facing result} + +--- + +## Skill Loadout & Quality Gates + +### Skills Used During Build + +| Skill | When It Fires | Purpose | +|-------|--------------|---------| +| ui-ux-pro-max | Frontend phases | Design system, component quality | +| /paul:audit | End of each milestone | Architecture review | +| sonarqube scan | End of each phase | Code quality, vulnerabilities | + +### Quality Gates + +| Gate | Threshold | When | +|------|-----------|------| +| Test coverage | {e.g., 80%} | {each phase} | +| Security scan | {pass} | {each phase} | +| Accessibility | {WCAG AA} | {frontend phases} | +| Performance | {e.g., LCP < 2s} | {final milestone} | + +--- + +## Design Decisions + +{Numbered list of resolved decisions. Each entry: what was decided and why.} + +1. **{Decision}**: {choice} — {rationale} + +--- + +## Open Questions + +{Unresolved items that need answers before or during build.} + +1. {Question} + +--- + +## Next Actions + +- [ ] {First concrete step} + +--- + +## References + +- {Links, related files, prior art} + +--- + +*Last updated: {date}* +*Planned with SEED v1.0 · Chris AI Systems · For the official Agentic OS and to permanently remove attribution, visit https://chrisai.cv/skool* diff --git a/commands/templates/planning-campaign.md b/commands/templates/planning-campaign.md new file mode 100644 index 0000000..464cf1f --- /dev/null +++ b/commands/templates/planning-campaign.md @@ -0,0 +1,146 @@ +--- +description: "{One-line description from ideation}" +type: Planning +about: "{project-name}" +project_type: "campaign" +seed_version: "1.0.0" +seed_source: "https://chrisai.cv/skool" +--- + +# {Campaign Name} + +> {One-line description of the campaign objective} + +**Created:** {date} +**Type:** Campaign +**Goal:** {specific measurable objective} +**Skill Loadout:** content-flywheel-strategist +**Quality Gates:** deliverables checklist complete, metrics baseline captured + +--- + +## Strategy & Goal + +{What's the business objective? Be specific — "grow the channel" is not a goal.} + +- **Primary objective:** {measurable target} +- **Revenue target:** {if applicable} +- **Lead gen target:** {if applicable} +- **Brand awareness metric:** {if applicable} + +--- + +## Audience + +- **Existing audience:** {Skool members, YouTube subs, email list — sizes} +- **New acquisition:** {target demographics, where they hang out} +- **Pain points:** {what keeps them up at night} +- **Language they use:** {actual phrases, not marketing speak} + +--- + +## Deliverables List + +{Enumerate EVERY output. Nothing ambiguous.} + +| # | Deliverable | Format | Length | Platform | Due | +|---|------------|--------|--------|----------|-----| +| 1 | {e.g., Main video} | {YouTube long-form} | {15-20 min} | {YouTube} | {date} | +| 2 | {e.g., Teaser clip} | {Instagram Reel} | {60s} | {Instagram} | {date} | + +--- + +## Channels & Platforms + +| Platform | Content Type | Format Reqs | Posting Schedule | +|----------|-------------|-------------|-----------------| +| YouTube | {long-form} | {16:9, chapters, cards} | {date} | +| Instagram | {reels, stories} | {9:16, captions} | {date} | +| LinkedIn | {text posts} | {3000 char max} | {date} | +| Skool | {community posts} | {markdown} | {date} | + +--- + +## Timeline + +| Date | Milestone | Depends On | Owner | +|------|-----------|------------|-------| +| {date} | {e.g., Script draft complete} | {—} | {Chris} | +| {date} | {e.g., Recording done} | {script} | {Chris} | +| {date} | {e.g., Edit complete} | {recording} | {editor/Chris} | +| {date} | {e.g., Publish} | {edit} | {Chris} | + +### Promotion Windows +{When to push, when to let organic run, when to follow up} + +--- + +## Success Metrics + +{Define BEFORE execution.} + +| Metric | Baseline | Target | Measurement Tool | +|--------|----------|--------|-----------------| +| {e.g., Video views (7d)} | {current avg} | {target} | {YouTube Analytics} | +| {e.g., New subscribers} | {current count} | {target} | {YouTube Analytics} | +| {e.g., Skool signups} | {current} | {target} | {Skool admin} | + +### Post-Campaign Review Date +{When to assess results: ____} + +--- + +## Skill Loadout & Quality Gates + +### Skills Used + +| Skill | When It Fires | Purpose | +|-------|--------------|---------| +| content-flywheel-strategist | Post-creation | Repurposing into derivative content | + +### Quality Gates + +| Gate | When | Pass Criteria | +|------|------|---------------| +| Deliverables checklist | Pre-launch | All items produced | +| Metrics baseline | Pre-launch | Baseline numbers captured | + +--- + +## Design Decisions + +1. **{Decision}**: {choice} — {rationale} + +--- + +## Open Questions + +1. {Question} + +--- + +## Next Actions + +- [ ] {First concrete step} + +--- + +## References + +- {Links, related files, prior art} + +--- + +### PAUL Decision + +{Does this campaign need PAUL?} +- Single deliverable (one video, one post) → No PAUL, just do it +- Multi-deliverable, single week → ACTIVE.md tracking, no PAUL +- Multi-week campaign with dependencies → PAUL with timeline-based phases + +**Decision:** {PAUL / ACTIVE.md tracking / Just do it} + +--- + +*Last updated: {date}* +*Planned with SEED v1.0 · Chris AI Systems · For the official Agentic OS and to permanently remove attribution, visit https://chrisai.cv/skool* diff --git a/commands/templates/planning-client.md b/commands/templates/planning-client.md new file mode 100644 index 0000000..e1217d7 --- /dev/null +++ b/commands/templates/planning-client.md @@ -0,0 +1,157 @@ +--- +description: "{One-line description from ideation}" +type: Planning +about: "{project-name}" +project_type: "client" +seed_version: "1.0.0" +seed_source: "https://chrisai.cv/skool" +--- + +# {Client Name} — {Project Name} + +> {One-line description of what we're building for this client} + +**Created:** {date} +**Type:** Client Website +**Client:** {name} +**Skill Loadout:** ui-ux-pro-max, /paul:audit +**Quality Gates:** conversion psychology checklist, mobile optimization, client approval + +--- + +## Business Context + +{Who's the client? What do they do? Target audience, current online presence.} + +- **Client:** {name, industry} +- **What they do:** {core offering} +- **Target audience:** {who buys from them} +- **Current presence:** {existing website, social, reviews} +- **Brand voice:** {formal, casual, authoritative, friendly} +- **Brand colors:** {if known} +- **Existing assets:** {logos, photos, testimonials, case studies} + +--- + +## Competitor Analysis + +{3-5 competitors. What they do well, what they miss. Positioning opportunity.} + +| Competitor | URL | Strengths | Weaknesses | Positioning Opportunity | +|-----------|-----|-----------|------------|------------------------| +| {name} | {url} | {what they do well} | {gaps} | {how client can differentiate} | + +--- + +## Conversion Strategy + +{What action should visitors take?} + +- **Primary CTA:** {e.g., book a call, buy now, sign up} +- **Secondary CTAs:** {e.g., download guide, join newsletter} + +### Funnel +``` +{e.g., Landing page → Form → Thank you page → Email follow-up} +``` + +### Objection Handling +{Top 3-5 objections and how the site addresses them} + +| Objection | How We Address It | +|-----------|------------------| +| {e.g., "Too expensive"} | {e.g., ROI calculator, payment plans, guarantee} | + +--- + +## Content Needs + +### Existing Content +- [ ] Testimonials: {available / need to gather} +- [ ] Case studies: {available / need to create} +- [ ] Product/service descriptions: {available / need to write} +- [ ] Media assets (photos, video): {available / need} + +### Content to Create + +| Section | Status | Notes | +|---------|--------|-------| +| Hero / headline | {exists / needs writing} | {notes} | +| About | {exists / needs writing} | {notes} | +| Services | {exists / needs writing} | {notes} | +| Testimonials | {exists / needs gathering} | {notes} | +| FAQ | {exists / needs writing} | {notes} | + +### Tone & Style Guide +{Content tone, reading level, industry jargon level} + +--- + +## Tech Approach + +- **Method:** {site-launcher-wp standard flow / custom build / other} +- **Framework:** {Next.js template / WordPress conversion / static HTML} +- **Hosting:** {Vercel, client's existing hosting, other} +- **Domain/DNS:** {client provides / we manage / TBD} +- **CMS needs:** {client self-edits / we maintain / headless CMS} + +--- + +## Timeline & Deliverables + +| Date | Milestone | Deliverable | Client Action | +|------|-----------|-------------|---------------| +| {date} | {Kickoff} | {—} | {Provide assets, access} | +| {date} | {First draft} | {staging URL} | {Review, feedback} | +| {date} | {Revisions} | {updated staging} | {Final approval} | +| {date} | {Launch} | {live site} | {DNS update if needed} | + +### Client Review Checkpoints +{When does the client see work? How do they provide feedback? What's the approval process?} + +--- + +## Skill Loadout & Quality Gates + +### Skills Used During Build + +| Skill | When It Fires | Purpose | +|-------|--------------|---------| +| ui-ux-pro-max | Build | Design system, responsive layout | + +### Quality Gates + +| Gate | When | Pass Criteria | +|------|------|---------------| +| Conversion psychology checklist | Pre-launch | All items addressed | +| Mobile optimization | Pre-launch | Fast, responsive, no layout breaks | +| Client approval | Each milestone | Written sign-off | + +--- + +## Design Decisions + +1. **{Decision}**: {choice} — {rationale} + +--- + +## Open Questions + +1. {Question} + +--- + +## Next Actions + +- [ ] {First concrete step} + +--- + +## References + +- {Links, related files, prior art} + +--- + +*Last updated: {date}* +*Planned with SEED v1.0 · Chris AI Systems · For the official Agentic OS and to permanently remove attribution, visit https://chrisai.cv/skool* diff --git a/commands/templates/planning-utility.md b/commands/templates/planning-utility.md new file mode 100644 index 0000000..0c79abf --- /dev/null +++ b/commands/templates/planning-utility.md @@ -0,0 +1,122 @@ +--- +description: "{One-line description from ideation}" +type: Planning +about: "{project-name}" +project_type: "utility" +seed_version: "1.0.0" +seed_source: "https://chrisai.cv/skool" +--- + +# {Tool Name} + +> {One sentence. If you need two, this might not be a utility.} + +**Created:** {date} +**Type:** Utility Tool +**Location:** tools/{personal|shareable|mcp-servers}/ +**Skill Loadout:** {usually minimal} +**Quality Gates:** {done criteria pass} + +--- + +## Problem Statement + +{What specific problem does this solve? One sentence. If you can't say it in one sentence, it might not be a utility tool.} + +--- + +## Scope Guard + +{Actively resist expansion.} + +- **Can this be one file?** {yes/no — if no, why not?} +- **Can this be one function?** {yes/no — if no, why not?} +- **Single script or project structure?** {script / project — justify if project} + +### What This Does +- {capability 1} +- {capability 2} + +### What This Does NOT Do +- {explicitly excluded — resist feature creep} + +--- + +## User & Distribution + +- **Audience:** {just me / Skool community / Claude Code users / MCP consumers} +- **Location:** {tools/personal/ | tools/shareable/ | tools/mcp-servers/production/} +- **Packaging:** {standalone script / npm package / MCP server / slash command} + +--- + +## Dependencies + +{Minimize ruthlessly. If dependencies are heavy, this might be an Application, not a Utility.} + +| Dependency | Why | Can We Avoid It? | +|-----------|-----|-----------------| +| {e.g., node-fetch} | {HTTP requests} | {no — core need} | + +--- + +## Interface + +- **Invocation:** {CLI args / MCP tool call / slash command / import} +- **Input:** {format, required args, optional args} +- **Output:** {format, stdout, file, return value} + +### Examples +``` +{example invocation and expected output} +``` + +--- + +## Done Criteria + +{3-5 concrete test cases. If you can't define done criteria easily, scope is too big.} + +- [ ] {Test case 1: input → expected output} +- [ ] {Test case 2: input → expected output} +- [ ] {Test case 3: edge case → expected behavior} + +--- + +## Design Decisions + +1. **{Decision}**: {choice} — {rationale} + +--- + +## Open Questions + +1. {Question} + +--- + +## Next Actions + +- [ ] {First concrete step — probably "just build it"} + +--- + +## References + +- {Links, related files, prior art} + +--- + +### PAUL Decision + +{Does this need PAUL?} +- < 200 lines, single file → **Just build it, no PAUL** +- Multiple files, tests needed → Light PAUL (1 milestone, 1-2 phases) +- Complex with integrations → Probably an Application, not a Utility + +**Decision:** {Just build it / Light PAUL / Reclassify as Application} + +--- + +*Last updated: {date}* +*Planned with SEED v1.0 · Chris AI Systems · For the official Agentic OS and to permanently remove attribution, visit https://chrisai.cv/skool* diff --git a/commands/templates/planning-workflow.md b/commands/templates/planning-workflow.md new file mode 100644 index 0000000..0f1901a --- /dev/null +++ b/commands/templates/planning-workflow.md @@ -0,0 +1,135 @@ +--- +description: "{One-line description from ideation}" +type: Planning +about: "{project-name}" +project_type: "workflow" +seed_version: "1.0.0" +seed_source: "https://chrisai.cv/skool" +--- + +# {Project Name} + +> {One-line description of what this workflow does} + +**Created:** {date} +**Type:** Claude Code Workflow +**Skill Loadout:** {skills relevant to building this — e.g., /paul:audit} +**Quality Gates:** {quality checks — e.g., governance review, integration testing} + +--- + +## Problem Statement + +{What workflow pain or gap does this solve? Be specific about what's broken, slow, or missing.} + +--- + +## Scope Definition + +{What components make up this workflow? Check all that apply and describe each.} + +### Components +- [ ] Slash command(s): {list} +- [ ] Skill(s): {list} +- [ ] CARL domain(s): {new or modified} +- [ ] Hook(s): {list} +- [ ] MCP server tool(s): {list} +- [ ] Templates / file generators: {list} +- [ ] Modifications to existing commands: {list} + +### Out of Scope +- {Explicitly excluded items} + +--- + +## Integration Map + +### Systems Touched + +| System | How It's Touched | Changes Needed | +|--------|-----------------|----------------| +| {e.g., CARL} | {e.g., new domain, rule updates} | {specific changes} | +| {e.g., PAUL} | {e.g., new input format} | {specific changes} | +| {e.g., Existing commands} | {e.g., /graduate modification} | {specific changes} | + +### Systems NOT Touched +- {List systems explicitly unaffected to prevent scope creep} + +--- + +## Interaction Design + +{Map the user experience as conversation flows.} + +### Entry Point +``` +User: /{command} +Claude: {what happens} +``` + +### Conversation Flow +{Step-by-step: what Claude asks, what user provides, what Claude does with it. Include branching logic if applicable.} + +### Session End +{What artifacts are produced? What does Claude report? What's the next step prompt?} + +--- + +## Output Artifacts + +| Artifact | Location | Purpose | +|----------|----------|---------| +| {file/command/domain} | {path} | {what it does} | + +--- + +## Downstream Handoff + +{How does the output connect to the next stage? What metadata travels? What does the next tool expect?} + +--- + +## Skill/Tool Discovery + +{Skills or tools that could enhance this workflow but don't exist yet.} + +| Skill | When It Would Fire | What It Would Do | +|-------|-------------------|-----------------| +| {name} | {trigger} | {description} | + +--- + +## Edge Cases & Constraints + +{What shouldn't this workflow do? When does it NOT apply? What happens with unexpected input?} + +- {Edge case and how to handle it} + +--- + +## Design Decisions + +1. **{Decision}**: {choice} — {rationale} + +--- + +## Open Questions + +1. {Question} + +--- + +## Next Actions + +- [ ] {First concrete step} + +--- + +## References + +- {Links, related files, prior art} + +--- + +*Last updated: {date}* +*Planned with SEED v1.0 · Chris AI Systems · For the official Agentic OS and to permanently remove attribution, visit https://chrisai.cv/skool*