@cofoundr/init 1.5.0

package/content/templates/phases/phase-template/spec.md

@@ -0,0 +1,90 @@
+---
+description: >
+  Technical spec for Phase [N]. Source of truth for the AI during build.
+  Every section must be concrete enough that an AI coding agent can build
+  from it without guessing. Generated by /cofoundr:next during planning.
+---
+
+# Phase [N] — Technical Spec
+
+## TL;DR
+<!-- ≤60 words. The technical summary: what data moves, what surfaces are built, what integrations are touched. -->
+
+---
+
+## Data model
+
+<!-- New tables, column additions to existing tables, and RLS policies. Use plain SQL CREATE TABLE. Every table must have id, created_at, updated_at, and owner-scoping columns. Every table must have RLS policies listed in pseudocode. Reference tech.md for the project-wide conventions rather than restating them. -->
+
+```sql
+-- New table example
+create table [name] (
+  id uuid primary key default gen_random_uuid(),
+  account_id uuid not null references accounts(id) on delete cascade,
+  created_at timestamptz not null default now(),
+  updated_at timestamptz not null default now()
+);
+
+-- RLS
+alter table [name] enable row level security;
+-- policy: owners can select/update their own rows
+-- policy: service role can insert
+```
+
+## API endpoints
+
+<!-- One row per endpoint. Include method, path, auth requirement, request shape, success response, error cases. If Launch Kit, reference enhanceRouteHandler and authActionClient patterns from tech.md rather than restating them. -->
+
+### POST /api/[path]
+
+- **Auth:** [user | service-role | public]
+- **Request:** `{ field: type, ... }`
+- **Success:** `200 { ... }`
+- **Errors:** `401 unauthorized`, `403 forbidden`, `422 validation`, `5xx server`
+
+---
+
+## External integrations
+
+<!-- Third-party services this phase calls. For each: the service, the exact endpoint or SDK method, auth mechanism, rate limits or cost envelope, and how failure is handled. -->
+
+- **Service:** ...
+  - Endpoints used: ...
+  - Auth: ...
+  - Rate limits: ...
+  - Failure mode: ...
+
+## Server-side logic
+
+<!-- Server actions, background jobs, cron schedules, webhook handlers. For each, name the trigger, the inputs, the outputs, and the side effects. -->
+
+- ...
+
+## Client-side surfaces
+
+<!-- New routes, new components, state changes. For each route: path, loaders, protected-vs-public. Reference ui-spec.md for visual detail; this file covers data flow and state shape. -->
+
+- **Route:** `/[path]` — purpose, auth, data loaded
+
+## Security
+
+<!-- New attack surface introduced by this phase and how it's handled. Never-class items from rules.md that apply. Specific things like: token encryption, CSRF, magic-byte validation, RLS coverage, rate limiting. -->
+
+- ...
+
+## Feature flags and rollout
+
+<!-- Which parts ship behind a flag and why. If nothing is flagged, say so and justify. -->
+
+- ...
+
+## Observability
+
+<!-- What we log, what we alert on, what we want to see in a dashboard. Keep it scoped to this phase's surface. -->
+
+- Log: ...
+- Alert: ...
+
+---
+
+<!-- When spec.md is complete, ui-spec.md starts. This file should be concrete enough that the AI can build it without re-asking design questions. -->

package/content/templates/phases/phase-template/tests.md

@@ -0,0 +1,65 @@
+---
+description: >
+  Test plan for Phase [N]. Happy path, edge cases, errors, security, and
+  performance budgets. Written before code so the AI has an explicit target.
+  Generated by /cofoundr:next during planning.
+---
+
+# Phase [N] — Tests
+
+## TL;DR
+<!-- ≤60 words. The one end-to-end flow a founder will click through to decide this phase is done, plus the highest-risk edge case we're covering. -->
+
+---
+
+## Happy path
+
+<!-- Step-by-step walkthrough of the primary success flow. Numbered steps, each with the action and the observable outcome. A founder should be able to follow this in the browser and tick each step. -->
+
+1. Action: ... → Observable: ...
+2. Action: ... → Observable: ...
+3. Action: ... → Observable: ...
+
+## Edge cases
+
+<!-- Unusual but realistic situations the user might encounter. Each edge case names the scenario and the expected behavior. -->
+
+- **Scenario:** ... → **Expected:** ...
+- **Scenario:** ... → **Expected:** ...
+
+## Error cases
+
+<!-- What the user sees when things fail. Cover at minimum: network failure, third-party API failure, validation failure, auth failure. Error messages should match copy in ui-spec.md. -->
+
+- **Network fails:** ...
+- **Third-party fails:** ...
+- **Validation fails:** ...
+- **Unauthorized:** ...
+
+## Security
+
+<!-- Tests that prove the security posture in spec.md holds. RLS prevents cross-account reads, auth gates endpoints, validation rejects malformed input, secrets never appear in client responses or logs. -->
+
+- [ ] RLS: user A cannot see user B's rows.
+- [ ] Auth: unauthenticated request to protected endpoint returns 401.
+- [ ] Validation: malformed request returns 422 with a readable error.
+- [ ] Secrets: grep the built bundle for known secret names — none appear.
+
+## Performance budget
+
+<!-- Latency and resource targets for the primary flows in this phase. Cite a measurement method (e.g. Chrome DevTools, Vercel analytics). -->
+
+- Primary flow [name]: budget [N]ms p95
+- Load: budget [N]ms TTFB on landing
+
+## Manual checklist
+
+<!-- The condensed founder-visible tick list. Extracted from happy path + error cases. Built to be run top-to-bottom in a browser without reading anything else in this folder. -->
+
+- [ ] ...
+- [ ] ...
+- [ ] ...
+
+---
+
+<!-- When tests.md is complete, the phase can be marked buildable. During build, the <verify> lines in tasks reference this file's checklists. -->

package/content/templates/phases/phase-template/ui-spec.md

@@ -0,0 +1,75 @@
+---
+description: >
+  UI spec for Phase [N]. Screens, states, copy, and brand tokens. Written
+  before any component is built. Reads brand.md for tokens and product.md
+  for voice. Generated by /cofoundr:next during planning.
+---
+
+# Phase [N] — UI Spec
+
+## TL;DR
+<!-- ≤60 words. Which screens this phase ships and the one UX principle that guides every decision inside them. -->
+
+---
+
+## Screens
+
+<!-- One subsection per screen. List route, purpose, entry points, exit points, primary action. -->
+
+### Screen: [Name] — `/[route]`
+
+- **Purpose:** ...
+- **Entry points:** ...
+- **Exit points:** ...
+- **Primary action:** ...
+
+#### States
+
+<!-- Every screen has at minimum: loading, empty, ready, error. List any additional states specific to this screen. For each state, describe what the user sees. -->
+
+- **Loading:** ...
+- **Empty:** ...
+- **Ready:** ...
+- **Error:** ...
+
+#### Copy
+
+<!-- Exact strings the user will read. Headings, body copy, button labels, empty-state copy, error messages. These should match the voice defined in brand.md. -->
+
+- Heading: "..."
+- Body: "..."
+- Primary button: "..."
+- Empty state: "..."
+- Error: "..."
+
+#### Components used
+
+<!-- List the components this screen composes. If Launch Kit, reference the kit's shadcn/ui components by name. If custom, note that a new component is needed. -->
+
+- ...
+
+---
+
+## Brand token usage
+
+<!-- Explicit references to brand.md tokens used on these screens. No hardcoded colors, fonts, or spacing. If brand.md doesn't exist yet, flag that /cofoundr:next brand is required before this phase can be fully spec'd. -->
+
+- **Accent color:** `brand.accent` — used on [elements]
+- **Heading type:** `brand.type.heading` — used on [elements]
+- **Spacing scale:** `brand.spacing` — used throughout
+
+## Responsive behavior
+
+<!-- Minimum breakpoints to support. Which parts collapse or reflow. Mobile-first if no reason to do otherwise. -->
+
+- ...
+
+## Accessibility
+
+<!-- Keyboard navigation path, focus order, screen-reader landmarks, color-contrast notes, any aria-* requirements for interactive states. -->
+
+- ...
+
+---
+
+<!-- When ui-spec.md is complete, research.md is next. The AI should be able to build every screen from this file without asking design questions during the build. -->

package/content/templates/phases.md

@@ -0,0 +1,234 @@
+# Build Phases
+
+<!-- HOW-TO: This is your build roadmap. Phases are grouped into milestones — each milestone is a shippable product increment. Within each phase, tasks are scoped to ≤45 minutes. The AI works through these in order. Every task has a verify block so you know when it's actually done — not "I think it's done" but "here's the observable proof." -->
+
+## TL;DR
+
+<!-- HOW-TO: ≤60 words. Name the milestones, the phases within each, and the core user flow that Milestone 1 delivers. -->
+
+*Two milestones. Milestone 1 (MVP): Phase 0 sets up the repo, auth, and database; Phase 1 delivers the core loop — connect Slack, trigger a morning pull, see a prioritized daily list. Milestone 2 (Growth): Phase 2 adds the second integration. Each task is ≤45 minutes with a verify checkpoint.*
+
+## Milestone Summary
+
+<!-- HOW-TO: One row per milestone. The Success Condition is what the founder can see or measure in their browser when the milestone is complete — not a technical definition of done. -->
+
+| Milestone | Phases | Goal | Success Condition |
+|-----------|--------|------|-------------------|
+| *Milestone 1 — MVP* | *Phase 0, Phase 1* | *Working product with the core loop* | *A real user can connect Slack, receive a morning pull, and interact with their task list* |
+| *Milestone 2 — Growth* | *Phase 2* | *Second integration live* | *User can connect Trello or Linear and see tasks from both sources in one list* |
+
+---
+
+## Milestone 1 — MVP
+
+**Goal:** *Working product that delivers the core user value end-to-end.*
+**Success condition:** *A real user can connect Slack, receive a morning pull, and interact with their task list on the production URL.*
+
+---
+
+## Phase 0 — Project Setup + Auth
+
+<!-- HOW-TO: This phase is MANDATORY. Every project starts here. Do not skip to features. The number one AI-build failure mode is jumping straight to feature code without a committed, authenticated, deployable skeleton. -->
+
+**Goal:** *Deployable skeleton with auth, database schema, and CI — zero features, fully working.*
+
+### Task 0.1 — Initialize repository
+
+**Files:** `.gitignore`, `package.json`, `.env.example`, `tsconfig.json`
+
+- [ ] Create Next.js 15 App Router project with TypeScript strict mode
+- [ ] Add `.env*` and `*.local` to `.gitignore`
+- [ ] Create `.env.example` with placeholder keys (no real values)
+- [ ] Commit initial state
+
+<verify>Git repo exists with initial commit. `npx next build` succeeds. `.env` is gitignored. `.env.example` lists every required variable.</verify>
+
+### Task 0.2 — Set up Supabase + schema
+
+**Files:** `supabase/migrations/001_initial.sql`, `src/lib/supabase.ts`
+
+- [ ] Create Supabase project and link to local dev
+- [ ] Run the CREATE TABLE statements from `tech.md`
+- [ ] Verify RLS policies are active on all tables
+- [ ] Create Supabase client utilities (browser + server)
+- [ ] Commit
+
+<verify>Running `supabase db reset` succeeds. All tables exist with RLS enabled. `SELECT * FROM profiles` returns empty (not an error).</verify>
+
+### Task 0.3 — Set up authentication
+
+**Files:** `src/app/login/page.tsx`, `src/app/auth/callback/route.ts`, `src/middleware.ts`
+
+- [ ] Implement Supabase Auth with email/password login
+- [ ] Add auth middleware to protect all routes except `/login`
+- [ ] Create login page with form and error handling
+- [ ] Create auth callback route for email confirmation
+- [ ] Commit
+
+<verify>User can sign up, receive confirmation email, confirm, and log in. Visiting `/` while logged out redirects to `/login`. Visiting `/login` while logged in redirects to `/`.</verify>
+
+### Task 0.4 — Deploy skeleton to Vercel
+
+**Files:** `vercel.json` (if needed)
+
+- [ ] Connect repo to Vercel
+- [ ] Add environment variables to Vercel dashboard
+- [ ] Deploy and verify auth works on production URL
+- [ ] Commit any deployment-related config changes
+
+<verify>Production URL loads login page. Sign-up and login work on the deployed URL, not just localhost.</verify>
+
+**Phase 0 success criteria:**
+- *Git repo with 4+ commits*
+- *Auth flow works end-to-end on production URL*
+- *Database schema matches `tech.md` with RLS active*
+- *No secrets in git history*
+
+**⛔ HALT — stop and ask the human if:**
+- 3 consecutive tasks in this phase fail (something is wrong with the environment, not your code)
+- Supabase project creation fails or RLS policies won't enable
+- The tech stack in `tech.md` conflicts with the founder's hosting environment
+
+---
+
+## Phase 1 — One End-to-End Happy Path
+
+<!-- HOW-TO: This phase is MANDATORY. Pick the single most important user flow from your P0 features and build it end-to-end. "End-to-end" means: the user can do the thing, see the result, and come back tomorrow and see it persisted. Resist the urge to build two half-features instead of one complete one. -->
+
+**Goal:** *A user can connect Slack, trigger a pull, and see a prioritized daily task list — the core product loop, fully working.*
+
+### Boundary Map
+
+<!-- HOW-TO: List what this phase creates and what it depends on from prior phases. This prevents the next phase from accidentally rebuilding something this phase already built. Phase 0 doesn't need a boundary map because it has no prior phases to consume from. -->
+
+| Produces | Consumes |
+|----------|----------|
+| *Slack OAuth flow (`/api/integrations/slack/`)* | *Auth system (Phase 0)* |
+| *Pull engine + Inngest function (`/api/pull/`)* | *Database schema + RLS (Phase 0)* |
+| *TaskList, TaskItem components* | *Supabase client utilities (Phase 0)* |
+| *`tasks` table populated with real data* | *User profiles table (Phase 0)* |
+
+### Task 1.1 — Slack OAuth flow
+
+**Files:** `src/app/api/integrations/slack/connect/route.ts`, `src/app/api/integrations/slack/callback/route.ts`, `src/app/settings/page.tsx`
+
+- [ ] Implement Slack OAuth initiation (server route)
+- [ ] Handle OAuth callback and store tokens in `integrations` table
+- [ ] Show connection status on settings page
+- [ ] Add disconnect functionality
+- [ ] Commit
+
+<verify>User clicks "Connect Slack" → completes Slack OAuth → sees green checkmark with workspace name. User clicks "Disconnect" → checkmark disappears. Refreshing the page preserves the connection state.</verify>
+
+### Task 1.2 — Morning pull engine
+
+**Files:** `src/app/api/pull/route.ts`, `src/lib/integrations/slack.ts`, `src/lib/inngest/functions.ts`
+
+- [ ] Create Slack message fetcher (channels the user is in, last 24 hours)
+- [ ] Map Slack messages to task records in `tasks` table
+- [ ] Create Inngest scheduled function that runs at user's configured pull time
+- [ ] Add manual "Pull now" button for testing
+- [ ] Commit
+
+<verify>User clicks "Pull now" → tasks appear within 60 seconds. Tasks have source, title, and link back to Slack. Running pull twice on the same day doesn't create duplicates.</verify>
+
+### Task 1.3 — Daily focus view
+
+**Files:** `src/app/page.tsx`, `src/components/TaskList.tsx`, `src/components/TaskItem.tsx`
+
+- [ ] Display today's pulled tasks grouped by source
+- [ ] Implement drag-to-reorder with optimistic UI updates
+- [ ] Add "focus" toggle (max 3 items) — focus items pin to top
+- [ ] Add "complete" toggle — completed items show strikethrough and move to bottom
+- [ ] Commit
+
+<verify>User sees today's tasks. Dragging reorders them. Marking 3 as focus pins them to top. Marking one as complete shows strikethrough. Refreshing the page preserves all changes.</verify>
+
+### Task 1.4 — Polish and edge cases
+
+**Files:** *various*
+
+- [ ] Empty state when no integrations connected (prompt to connect)
+- [ ] Empty state when no tasks pulled (show "all clear" message)
+- [ ] Loading states for pull and reorder actions
+- [ ] Error handling for failed pulls (show retry option)
+- [ ] Commit
+
+<verify>Disconnecting all integrations shows empty state with connect prompt. A fresh account with no pulls shows a clean onboarding message. Slow network shows loading indicators, not blank screens.</verify>
+
+**Phase 1 success criteria:**
+- *Complete Slack → Pull → View → Reorder → Focus → Complete flow works*
+- *Data persists across sessions*
+- *Edge cases handled (empty states, errors, loading)*
+- *Works on production URL*
+
+**⛔ HALT — stop and ask the human if:**
+- 3 consecutive task failures in this phase
+- Auth or database from Phase 0 is broken or missing
+- OAuth credentials (Slack app) haven't been created yet — you can't fake this
+- The founder hasn't answered which Slack channels to pull from
+- A task would take more than 2 hours — break it into subtasks first
+
+---
+
+## Milestone 2 — Growth
+
+**Goal:** *Expand the product's value by adding a second task source.*
+**Success condition:** *User can connect both Slack and Trello/Linear and see a unified task list from both.*
+
+---
+
+## Phase 2 — Second Integration
+
+<!-- HOW-TO: Replace the placeholder below with the next priority from your PRD. Keep the same structure: goal, 3-4 tasks, verify blocks, success criteria. -->
+
+**Goal:** *User can connect Trello or Linear as a second source, and morning pulls aggregate tasks from both Slack and the project board.*
+
+### Boundary Map
+
+| Produces | Consumes |
+|----------|----------|
+| *Generalized OAuth flow (`/api/integrations/[provider]/`)* | *Slack OAuth pattern (Phase 1)* |
+| *Trello/Linear fetcher (`/lib/integrations/`)* | *Pull engine (Phase 1)* |
+| *Multi-source badge UI* | *TaskList component (Phase 1)* |
+
+### Task 2.1 — Trello/Linear OAuth flow
+
+**Files:** `src/app/api/integrations/[provider]/connect/route.ts`, `src/app/api/integrations/[provider]/callback/route.ts`
+
+- [ ] *Generalize OAuth flow to support multiple providers*
+- [ ] *Implement Trello OAuth (or Linear, based on user preference)*
+- [ ] *Show both integrations on settings page*
+- [ ] Commit
+
+<verify>*User can connect both Slack and Trello/Linear. Settings page shows status of each. Disconnecting one doesn't affect the other.*</verify>
+
+### Task 2.2 — Multi-source pull
+
+**Files:** `src/lib/integrations/trello.ts` or `src/lib/integrations/linear.ts`, `src/app/api/pull/route.ts`
+
+- [ ] *Add fetcher for second integration*
+- [ ] *Update pull engine to aggregate from all connected sources*
+- [ ] *Tasks from different sources display with source badges*
+- [ ] Commit
+
+<verify>*Morning pull returns tasks from both Slack and Trello/Linear. Each task shows its source. Duplicate detection works across sources.*</verify>
+
+**Phase 2 success criteria:**
+- *Both integrations connect and pull independently*
+- *Daily view shows tasks from all sources in one unified list*
+- *Phase 1 functionality unchanged*
+
+**⛔ HALT — stop and ask the human if:**
+- 3 consecutive task failures in this phase
+- Phase 1 pull engine or OAuth flow is broken
+- The founder hasn't decided between Trello and Linear
+- API rate limits from the second integration block development
+
+---
+
+## Convention: Decimal Phases
+
+<!-- HOW-TO: If you need to insert urgent work between phases, use decimal numbering (e.g., Phase 1.1) instead of renumbering everything. Renumbering phases breaks references in commit messages, AI conversation history, and your own notes. Decimal phases keep the original numbering stable. -->
+
+*Example: If a critical auth bug surfaces after Phase 1, create "Phase 1.1 — Auth Token Refresh Fix" rather than renumbering Phase 2 to Phase 3. The original phase numbers are permanent anchors.*

package/content/templates/prd.md

@@ -0,0 +1,89 @@
+# Product Requirements Document
+
+<!-- HOW-TO: This is the contract between you and your AI builder. If a feature isn't here, it doesn't get built. If the acceptance criteria are vague, you'll get vague output. -->
+
+## TL;DR
+
+<!-- HOW-TO: ≤60 words. Summarize the features that ship in v1 and explicitly state what's deferred. -->
+
+*TaskPilot v1 ships three things: OAuth connection to Slack + one project board, a morning pull that creates a prioritized task list, and a drag-to-reorder daily focus view. Email integration, AI prioritization, and mobile apps are deferred to v2.*
+
+## P0 — Must Ship
+
+<!-- HOW-TO: These are launch-blocking. If any P0 is incomplete, you don't ship. Each feature needs a name, a one-line description, and acceptance criteria written as observable behaviors — what the user sees or experiences. -->
+
+### Connect Integrations
+
+*User connects Slack and one project board (Trello or Linear) via OAuth.*
+
+**Acceptance criteria:**
+- *User clicks "Connect Slack" and completes OAuth flow without leaving the app*
+- *User sees a green checkmark and workspace name after successful connection*
+- *User can disconnect and reconnect without losing previously pulled tasks*
+- *If OAuth fails, user sees a specific error message (not a generic "something went wrong")*
+
+### Morning Pull
+
+*App pulls pending items from connected tools at the user's configured time each day.*
+
+**Acceptance criteria:**
+- *User sets a pull time (e.g., 7:00 AM) and timezone in settings*
+- *At the configured time, the app fetches unresolved items from all connected tools*
+- *User sees a notification (browser or email) that their daily list is ready*
+- *Pull completes within 60 seconds for up to 200 items*
+
+### Daily Focus View
+
+*User sees a single prioritized list and marks their top 3 tasks for the day.*
+
+**Acceptance criteria:**
+- *User sees all pulled items grouped by source (Slack, Trello/Linear)*
+- *User drags items to reorder the list*
+- *User marks up to 3 items as "today's focus" — these pin to the top*
+- *Non-focus items collapse into an "everything else" section*
+- *Completed items show a strikethrough and move to the bottom*
+
+## P1 — Should Ship
+
+<!-- HOW-TO: Important but not launch-blocking. Build these immediately after P0 is stable. -->
+
+### Email Digest
+
+*User receives a daily email summary of their focus items and yesterday's completions.*
+
+**Acceptance criteria:**
+- *Email arrives within 5 minutes of the morning pull*
+- *Email shows today's focus items and yesterday's completion rate*
+- *User can reply "done" to any item to mark it complete from email*
+
+### Snooze Items
+
+*User can snooze non-urgent items to a future date.*
+
+**Acceptance criteria:**
+- *User clicks "snooze" and picks a date from a date picker*
+- *Snoozed items disappear from the daily list until the chosen date*
+- *User sees a count of snoozed items in the sidebar*
+
+## P2 — Nice to Have
+
+<!-- HOW-TO: Tracked but not committed. These might become P0 in v2. -->
+
+### AI Priority Suggestions
+
+*App suggests a priority order based on deadlines, mentions, and item age.*
+
+**Acceptance criteria:**
+- *User sees a "suggested order" button on the daily focus view*
+- *Clicking it reorders items with an explanation tooltip ("due tomorrow", "mentioned 3x")*
+- *User can accept, modify, or dismiss the suggestion*
+
+## Clarifications Log
+
+<!-- HOW-TO: Track every decision made during build. When the AI or you make an ambiguous call, log it here. This becomes your institutional memory. -->
+
+| Question | Answer | Decision | Date |
+|----------|--------|----------|------|
+| *Should Slack DMs be pulled or only channel messages?* | *Channels only in v1* | *DMs add privacy complexity — defer to v2* | *2025-01-15* |
+| *What happens if OAuth token expires mid-pull?* | *Retry once, then notify user to reconnect* | *Silent retry + notification is better UX than failing silently* | *2025-01-16* |
+| *Max items per daily list?* | *200 items hard cap* | *Performance degrades above 200; show "oldest items hidden" warning* | *2025-01-17* |

package/content/templates/product.md

@@ -0,0 +1,73 @@
+# Product Brief
+
+<!-- HOW-TO: This is the single document your AI assistant, your co-founder, and your first investor will read to understand what you're building. Keep it tight — this file should take under 3 minutes to read. Every section maps to a specific planning question so nothing gets missed. -->
+
+## TL;DR
+
+<!-- HOW-TO: Write exactly one paragraph, 60 words max. This combats the "curse of knowledge" — founders who live inside their idea forget that nobody else has context. If you can't summarize it in 60 words, you don't understand it well enough yet. -->
+
+*TaskPilot is a lightweight daily planner for solo founders who lose hours to context-switching between Slack, email, and project boards. It pulls pending items from connected tools into a single prioritized list each morning, so founders start every day knowing exactly what to work on first.*
+
+## The Problem
+
+<!-- HOW-TO: Keyed to Interrogation Q1 — "What problem does the user face today, and how are they currently solving it (badly)?" Be specific. "People are overwhelmed" is not a problem statement. "Solo founders spend 40 minutes every morning triaging notifications across 4+ tools before they start real work" is. Name the problem, quantify the pain, and describe the broken workaround they're using today. -->
+
+*Solo founders spend 40+ minutes every morning triaging notifications across Slack, email, Trello, and GitHub before starting real work. Most end up working on whatever feels urgent rather than what actually moves the business forward.*
+
+*The current workaround is a daily manual copy-paste into a Notes doc — tedious and abandoned within two weeks. Some founders try "Slack-free mornings," but that just moves the triage to the afternoon and delays time-sensitive items.*
+
+*The cost: 3+ hours per week lost to triage, plus the invisible cost of starting every day on someone else's agenda instead of your own roadmap.*
+
+## The User
+
+<!-- HOW-TO: One sentence. Name the role, not a demographic. "25-34 year old male in San Francisco" is a demographic. "Solo founder running a pre-seed startup with no project manager" is a role. Roles tell you what the user needs; demographics tell you what ads to buy. -->
+
+*A solo founder or solo technical co-founder running a pre-seed startup with no dedicated project manager.*
+
+**Secondary user:** *An early employee (first 1-3 hires) who inherits the founder's multi-tool chaos but has even less context about which tasks matter most.*
+
+<!-- HOW-TO: If you have a secondary user, name them. But be clear about who comes first — build for the primary user, validate with the secondary. -->
+
+## The Solution
+
+<!-- HOW-TO: One paragraph describing what the product does — not how it works technically. Write it as if you're explaining to the user, not to an engineer. Avoid implementation details like "uses webhooks" or "stores in Postgres." Those belong in tech.md. -->
+
+*TaskPilot connects to Slack, email, and one project board (Trello or Linear). Each morning at a time the user sets, it pulls all pending items, groups them by project, and presents a single prioritized list. The user drags to reorder, marks the top 3 as "today's focus," and gets a clean view with everything else hidden until tomorrow.*
+
+*The core loop takes under 2 minutes: open TaskPilot, review the auto-generated list, drag your priorities to the top, and start building. No setup, no configuration beyond connecting your tools.*
+
+## The Analogue
+
+<!-- HOW-TO: Name one existing product people will compare this to, and what's different. The "X for Y" frame gives people an instant mental model. If you skipped this during the planning conversation, add it now — it's too useful to leave blank. The comparison doesn't have to be flattering — it just needs to be instantly understood. -->
+
+*"Superhuman for daily planning" — Superhuman made email fast; TaskPilot makes your whole morning triage fast by pulling from every tool, not just email.*
+
+*Key difference: Superhuman is a replacement for Gmail. TaskPilot sits on top of your existing tools and doesn't replace any of them.*
+
+<!-- HOW-TO: The analogue isn't a competitive analysis. It's a communication shortcut. You'll do competitive analysis later. Right now you need something people can repeat to each other in one sentence. -->
+
+## Why Now
+
+<!-- HOW-TO: Founders almost never volunteer this. The planning conversation forces it because investors and builders both need it. What changed recently — a market shift, a technology unlock, a regulation, a cultural moment — that makes this idea viable now when it wasn't two years ago? -->
+
+*Three things changed:*
+
+1. *Slack, Linear, and Trello all now offer stable OAuth + webhook APIs that didn't exist or were unreliable before 2024.*
+2. *AI prioritization models (small LLMs) are cheap enough to run per-user at <$0.01/day.*
+3. *The solo-founder movement has grown 3x since 2020, creating a large enough niche to sustain a focused tool.*
+
+*Two years ago you'd have needed a team of 3 just to maintain the integrations. Today a solo dev with AI tooling can build and maintain this.*
+
+## What This Is NOT
+
+<!-- HOW-TO: Non-goals prevent scope creep. List 3 things users might expect that you explicitly won't build in v1. These are decisions, not limitations — own them. Non-goals are some of the most important sentences in this document because they prevent the most common failure mode in AI-assisted building: the AI "helpfully" adding features you didn't ask for. -->
+
+1. *Not a project management tool — no boards, no sprints, no team features. If you need Jira, use Jira.*
+2. *Not a calendar app — it doesn't schedule your day, it prioritizes your tasks. It tells you WHAT to work on, not WHEN.*
+3. *Not an automation platform — it won't auto-reply to Slack messages or close tickets. It's read-only from your connected tools.*
+
+<!-- HOW-TO: If the AI suggests building any of the above, point it back to this section. Non-goals are not "not yet" — they are "not this product." If one of your non-goals turns out to be the real product, that's a pivot — rewrite this entire document from scratch. -->
+
+---
+
+<!-- HOW-TO: This file is complete when a stranger can read it in 3 minutes and accurately describe your product to someone else. If they can't, the file is too vague or too long. Read it aloud to someone unfamiliar with your idea — their confused face is your editing guide. -->