@friedbotstudio/create-baseline 0.1.0

package/obj/template/.claude/skills/technical-tutorials/references/audience-context-README.md

@@ -0,0 +1,53 @@
+# developer-audience-context
+
+**Foundation skill** — All other skills reference this first.
+
+## What It Does
+
+Creates and maintains `.claude/skills/developer-audience-context.md` — a single document capturing everything about your target developers. Define your audience once, and every other skill automatically has context.
+
+## When to Use
+
+- Starting any developer marketing project
+- Before running other skills (automatically referenced)
+- When you say "developer persona," "target developers," "ICP," or "who are our developers"
+
+## Quick Start
+
+```
+/developer-audience-context
+
+Create our developer audience context. We're building an open source
+API testing library for Node.js/TypeScript developers.
+```
+
+The skill will either:
+1. Auto-draft from your codebase (README, docs, landing pages)
+2. Walk through 10 sections conversationally
+
+## Files
+
+| File | Description |
+|------|-------------|
+| `SKILL.md` | Full skill instructions |
+| `references/template.md` | Blank template to fill out |
+| `references/example-apitest.md` | Filled example for a fictional dev tool |
+
+## The 10 Sections
+
+1. **Product Overview** — Name, one-liner, category, tech, pricing
+2. **Developer Persona** — Role, seniority, company size, tech stack
+3. **Where They Hang Out** — Reddit, Discord, Twitter, podcasts, conferences
+4. **Problems & Pain Points** — Functional, emotional, trigger moments
+5. **Current Alternatives** — Competitors, DIY, do nothing
+6. **Key Differentiators** — Technical, DX, ecosystem, philosophy
+7. **Verbatim Developer Language** — Exact quotes, not polished copy
+8. **Technical Trust Signals** — GitHub stars, downloads, notable users
+9. **Conversion Actions** — Awareness → Activation → Conversion
+10. **Voice & Tone** — How you sound when talking to developers
+
+## Related Skills
+
+Skills that reference this context:
+
+- `technical-tutorials`

package/obj/template/.claude/skills/technical-tutorials/references/audience-context.md

@@ -0,0 +1,246 @@
+# Developer Audience Context (reference for `technical-tutorials`)
+
+> **Note:** This file used to be a standalone skill (`developer-audience-context`). It was consolidated into `technical-tutorials` on 2026-04-28 because the only consumer was the tutorial author. Upstream YAML frontmatter and "this skill" framing removed; substance preserved verbatim. Apache 2.0 attribution: see `audience-context-README.md` in this directory for the original upstream README.
+
+This document defines the audience profile a tutorial author needs before writing. Maintain a project-level copy at `audience-context.md` (or wherever your project tracks developer-marketing context); reference it from every tutorial draft so the audience is defined once and reused.
+
+---
+
+## Before You Start
+
+Check if `.claude/skills/developer-audience-context.md` exists:
+
+- **If it exists**: Read it and offer to update specific sections
+- **If it doesn't exist**: Create the directory and file, then walk through each section
+
+---
+
+## Two Ways to Build Context
+
+### Option 1: Auto-Draft from Codebase (Recommended)
+
+Analyze existing materials to draft an initial version:
+
+1. **README.md** — Product description, features, getting started
+2. **Documentation** — `/docs`, API reference, tutorials
+3. **Landing pages** — `index.html`, marketing copy
+4. **package.json / pyproject.toml** — Dependencies reveal ecosystem
+5. **GitHub Issues** — Common questions, frustrations, use cases
+6. **Existing blog posts** — Technical content, tutorials
+
+After drafting, walk through each section to validate and fill gaps.
+
+### Option 2: Start from Scratch
+
+Ask questions section-by-section. Don't advance until the current section is complete.
+
+---
+
+## The 10 Sections to Capture
+
+### 1. Product Overview
+
+| Field | What to capture |
+|-------|-----------------|
+| Product name | Official name and any aliases |
+| One-liner | "We help [developers] do [X] without [Y]" |
+| Category | API, SDK, CLI, SaaS, open source library, infrastructure |
+| Core technology | Languages, frameworks, platforms supported |
+| Pricing model | Free/open source, freemium, usage-based, seat-based |
+
+### 2. Developer Persona
+
+Not "developers" generically — get specific:
+
+| Field | What to capture |
+|-------|-----------------|
+| Primary role | Backend, frontend, full-stack, DevOps, data, ML, mobile |
+| Seniority | Junior, mid, senior, staff, lead, architect |
+| Company size | Solo, startup, scale-up, enterprise |
+| Industry verticals | Fintech, healthtech, e-commerce, gaming, B2B SaaS |
+| Tech stack | Languages, frameworks, cloud providers they use |
+| Decision authority | Individual contributor, team lead, buyer, influencer |
+
+**Ask**: "Describe the developer who gets the most value from your product in one paragraph. What's their day-to-day like?"
+
+### 3. Where They Hang Out
+
+Developers research before they buy. Know where:
+
+| Channel | Specifics to capture |
+|---------|---------------------|
+| Communities | Specific subreddits, Discord servers, Slack groups |
+| Social | Twitter/X hashtags, LinkedIn groups |
+| Content | Blogs they read, newsletters they subscribe to, podcasts |
+| Events | Conferences, meetups, hackathons |
+| Code | GitHub topics, Stack Overflow tags |
+
+**Pro tip**: Use social listening tools to monitor conversations across Hacker News, Reddit, Stack Overflow, GitHub, and Twitter. See where discussions about your problem space happen organically.
+
+### 4. Problems & Pain Points
+
+Capture the actual problems, not your solution's features:
+
+| Level | What to capture |
+|-------|-----------------|
+| Functional | "I can't do X" / "X takes too long" / "X is error-prone" |
+| Emotional | Frustration, anxiety, embarrassment, fear |
+| Situational | When does the pain occur? What triggers the search? |
+
+**Ask**: "What's the #1 frustration that brings developers to you?"
+
+**Research**: Search Reddit, Hacker News, and Stack Overflow for complaints about your problem space. Capture verbatim quotes.
+
+### 5. Current Alternatives
+
+What are developers using today instead of you?
+
+| Alternative type | Examples |
+|-----------------|----------|
+| Direct competitors | Tools that solve the same problem |
+| DIY / build it yourself | Custom scripts, internal tools |
+| Indirect solutions | Workarounds, manual processes |
+| Do nothing | Live with the pain |
+
+For each alternative, capture:
+- Why developers choose it
+- What's frustrating about it
+- What would make them switch
+
+### 6. Key Differentiators
+
+What makes you different — in developer terms:
+
+| Differentiator type | Example |
+|--------------------|---------|
+| Technical | "10x faster," "No dependencies," "Type-safe" |
+| DX (Developer Experience) | "5-minute setup," "Great docs," "First-class CLI" |
+| Ecosystem | "Works with X," "Built for Y framework" |
+| Philosophy | "Open source," "Privacy-first," "Local-first" |
+
+**Warning**: Avoid marketing fluff. Developers see through "best-in-class" and "enterprise-grade." Use specific, provable claims.
+
+### 7. Verbatim Developer Language
+
+Capture exact phrases developers use — not polished marketing copy:
+
+| Category | Examples |
+|----------|----------|
+| Describing the problem | "This is such a pain," "I wish I could just..." |
+| Describing your product | How they explain it to others |
+| Objections | "But what about...", "I'm worried that..." |
+| Praise | Testimonials, tweets, GitHub comments |
+
+**Sources**: GitHub issues, Twitter mentions, Hacker News comments, support tickets, sales calls, community Slack/Discord.
+
+### 8. Technical Trust Signals
+
+What proof points matter to developers:
+
+| Signal type | Examples |
+|-------------|----------|
+| Adoption | GitHub stars, npm downloads, Docker pulls |
+| Quality | Test coverage, security audits, uptime SLA |
+| Community | Contributors, Discord members, forum activity |
+| Credibility | Backed by X, used by Y, created by Z |
+| Transparency | Open source, public roadmap, changelog |
+
+### 9. Conversion Actions
+
+What does success look like at each stage?
+
+| Stage | Primary action | Secondary actions |
+|-------|---------------|-------------------|
+| Awareness | Star repo, follow on Twitter | Read blog post, share content |
+| Consideration | Clone repo, read docs | Watch demo, join Discord |
+| Trial | Sign up, install SDK | Complete quickstart, make first API call |
+| Activation | Reach "Hello World" moment | Integrate into real project |
+| Conversion | Upgrade to paid | Add team members, expand usage |
+
+### 10. Voice & Tone
+
+How should you sound when talking to these developers?
+
+| Dimension | Spectrum |
+|-----------|----------|
+| Formality | Casual ← → Professional |
+| Technicality | Accessible ← → Deep technical |
+| Personality | Neutral ← → Opinionated |
+| Humor | Serious ← → Playful |
+
+**Examples**:
+- Stripe → Professional, precise, clean
+- Vercel → Modern, confident, developer-first
+- Supabase → Friendly, accessible, community-driven
+- Tailwind → Opinionated, direct, practical
+
+---
+
+## Output Format
+
+Save to `.claude/skills/developer-audience-context.md` with this structure:
+
+```markdown
+# Developer Audience Context
+
+Last updated: [DATE]
+
+## Product Overview
+[Section content]
+
+## Developer Persona
+[Section content]
+
+## Where They Hang Out
+[Section content]
+
+## Problems & Pain Points
+[Section content]
+
+## Current Alternatives
+[Section content]
+
+## Key Differentiators
+[Section content]
+
+## Verbatim Developer Language
+[Section content]
+
+## Technical Trust Signals
+[Section content]
+
+## Conversion Actions
+[Section content]
+
+## Voice & Tone
+[Section content]
+```
+
+---
+
+## Maintenance
+
+Update this document when:
+
+- You learn something new from user research
+- You find great verbatim quotes
+- Your positioning or differentiation changes
+- You expand to new developer segments
+
+---
+
+## Tools
+
+| Tool | Use case |
+|------|----------|
+| **GitHub Search** | Find how developers describe problems in issues |
+| **Twitter Advanced Search** | Find discussions about your space |
+| **Google Alerts** | Track mentions of competitors and problem keywords |
+
+---
+
+## Related Skills
+
+After establishing context, these skills will reference it:
+
+- `technical-tutorials` — Writing technical tutorials for developers

package/obj/template/.claude/skills/technical-tutorials/references/audience-example.md

@@ -0,0 +1,175 @@
+# Developer Audience Context
+
+Last updated: 2024-01-15
+
+---
+
+## Product Overview
+
+| Field | Value |
+|-------|-------|
+| **Product name** | Checkmate (fictional example) |
+| **One-liner** | We help backend developers write API tests without learning a new DSL |
+| **Category** | CLI + Open source library |
+| **Core technology** | TypeScript, works with any Node.js project |
+| **Pricing model** | Open source core, paid cloud dashboard for teams |
+
+---
+
+## Developer Persona
+
+| Field | Value |
+|-------|-------|
+| **Primary role** | Backend / Full-stack |
+| **Seniority** | Mid to Senior (2-8 years experience) |
+| **Company size** | Startup to Scale-up (10-500 employees) |
+| **Industry verticals** | B2B SaaS, Fintech, E-commerce |
+| **Tech stack** | Node.js, TypeScript, Express/Fastify, PostgreSQL, REST APIs |
+| **Decision authority** | Individual contributor who influences tooling decisions |
+
+**Day-in-the-life**:
+> Sarah is a senior backend engineer at a Series B fintech startup. She spends most of her day writing and reviewing API code. She knows they should have better test coverage but the existing test setup is brittle and slow. Every time she tries to add tests, she spends more time fighting the test framework than writing actual tests. She's evaluated Postman and other tools but doesn't want to maintain tests in a separate GUI. She wants tests that live in her codebase and run in CI.
+
+---
+
+## Where They Hang Out
+
+| Channel | Specific places |
+|---------|-----------------|
+| **Reddit** | r/node, r/typescript, r/webdev, r/ExperiencedDevs |
+| **Discord/Slack** | Reactiflux, TypeScript Community, various company Slacks |
+| **Twitter/X** | #typescript, #nodejs, follows @sindresorhus, @maaboroosh, @benloeb |
+| **Newsletters** | Node Weekly, JavaScript Weekly, bytes.dev |
+| **Podcasts** | Syntax.fm, JS Party, The Changelog |
+| **Blogs** | Dev.to, Kent C. Dodds, Testing JavaScript |
+| **Conferences** | NodeConf, TSConf, local JavaScript meetups |
+| **GitHub** | Topics: testing, api-testing, typescript |
+| **Stack Overflow** | Tags: node.js, typescript, api-testing, jest, vitest |
+
+---
+
+## Problems & Pain Points
+
+### Functional problems
+- Existing test setups are slow and flaky
+- Learning curve for testing frameworks is steep
+- Mocking APIs and databases is painful
+- Tests don't catch the bugs that actually matter
+- CI runs take forever because of integration tests
+
+### Emotional pain
+- Embarrassment when production bugs could have been caught by tests
+- Frustration with test maintenance overhead
+- Anxiety about shipping without confidence
+- Guilt about skipping tests due to time pressure
+
+### Trigger moments
+- Just shipped a bug that tests would have caught
+- New team member asks "where are the tests?"
+- CI is taking 20+ minutes
+- Tried to refactor code and broke everything
+
+**#1 frustration that brings developers to us**:
+> "I want to test my APIs but I don't want to spend a week learning a new framework and setting up fixtures. Just let me write tests that look like the code I'm already writing."
+
+---
+
+## Current Alternatives
+
+| Alternative | Why devs choose it | What's frustrating | Switching triggers |
+|-------------|-------------------|-------------------|-------------------|
+| **Jest + Supertest** | Already using Jest, Supertest is simple | Slow, verbose setup, bad TypeScript support | Speed issues, TypeScript errors |
+| **Postman/Insomnia** | Visual, easy to start | Tests live outside codebase, hard to version control | Need tests in CI, team scaling |
+| **Playwright/Cypress** | Powerful, good DX | Overkill for API testing, slow | Just need API tests, not E2E |
+| **Build it themselves** | Full control | Maintenance burden, reinventing the wheel | Team grows, need standards |
+| **Do nothing** | No time investment | Bugs in production, no confidence | Major incident, new compliance requirement |
+
+---
+
+## Key Differentiators
+
+| Type | Our claim | Proof |
+|------|-----------|-------|
+| **Technical** | 10x faster than Jest+Supertest | Benchmark: 500 tests in 2s vs 20s |
+| **DX** | Zero-config TypeScript support | Just `npm install`, no setup |
+| **Ecosystem** | Works with your existing test runner | Vitest, Jest, Node test runner |
+| **Philosophy** | Tests should look like your code | No DSL, just TypeScript |
+
+---
+
+## Verbatim Developer Language
+
+### How they describe the problem
+> "Testing APIs shouldn't be this hard"
+> "I just want to make a request and check the response"
+> "Why do I need 50 lines of setup for one test?"
+> "Our test suite takes 15 minutes to run"
+
+### How they describe our product
+> "It's like if fetch() was designed for testing"
+> "Finally, API tests that don't suck"
+> "The TypeScript support is *chef's kiss*"
+
+### Common objections
+> "What about when I need to mock the database?"
+> "Will this work with our existing Jest setup?"
+> "We're already invested in Postman"
+> "Is this maintained? I don't want to depend on an abandoned project"
+
+### Praise / testimonials
+> "Migrated 200 tests in an afternoon. CI went from 12 minutes to 90 seconds." — @devname on Twitter
+> "Best testing DX I've experienced in 10 years of backend work." — GitHub issue #142
+
+**Sources**: GitHub issues, Twitter mentions, Hacker News launch thread, support Discord
+
+---
+
+## Technical Trust Signals
+
+| Signal | Current value |
+|--------|---------------|
+| **GitHub stars** | 3,200 |
+| **npm downloads** | 45k/week |
+| **Contributors** | 28 |
+| **Community size** | Discord: 1,200 members |
+| **Notable users** | Vercel, Linear, Cal.com |
+| **Backed by** | YC W24 |
+
+---
+
+## Conversion Actions
+
+| Stage | Primary action | Secondary actions |
+|-------|---------------|-------------------|
+| **Awareness** | Star repo | Read blog post, follow on Twitter |
+| **Consideration** | Read docs/quickstart | Watch 5-min demo, join Discord |
+| **Trial** | `npm install checkmate` | Run first test |
+| **Activation** | Migrate 1 existing test | Add to CI |
+| **Conversion** | Sign up for cloud dashboard | Add team members |
+
+**"Hello World" moment**:
+> Developer runs their first test and sees it pass in <100ms. They think "wait, that's it?" Then they look at the TypeScript autocomplete and realize they get full type safety on their API responses.
+
+---
+
+## Voice & Tone
+
+| Dimension | Our position (1-5) |
+|-----------|-------------------|
+| Casual ← → Professional | 2 (casual but competent) |
+| Accessible ← → Deep technical | 4 (assume backend knowledge) |
+| Neutral ← → Opinionated | 4 (we have opinions about testing) |
+| Serious ← → Playful | 3 (occasional humor, not try-hard) |
+
+**Voice inspiration** (brands/people to emulate):
+- Tailwind (opinionated but practical)
+- Vitest (modern, fast, developer-first)
+- tRPC (TypeScript-native thinking)
+
+**Words we use**:
+- Fast, simple, TypeScript-native, zero-config, real tests
+- "Just works", "designed for", "built by developers"
+
+**Words we avoid**:
+- Enterprise-grade, best-in-class, revolutionary, game-changing
+- Anything that sounds like marketing fluff

package/obj/template/.claude/skills/technical-tutorials/references/audience-template.md

@@ -0,0 +1,152 @@
+# Developer Audience Context
+
+Last updated: [DATE]
+
+---
+
+## Product Overview
+
+| Field | Value |
+|-------|-------|
+| **Product name** | |
+| **One-liner** | We help [developers] do [X] without [Y] |
+| **Category** | API / SDK / CLI / SaaS / Open source library / Infrastructure |
+| **Core technology** | |
+| **Pricing model** | Free / Open source / Freemium / Usage-based / Seat-based |
+
+---
+
+## Developer Persona
+
+| Field | Value |
+|-------|-------|
+| **Primary role** | Backend / Frontend / Full-stack / DevOps / Data / ML / Mobile |
+| **Seniority** | Junior / Mid / Senior / Staff / Lead / Architect |
+| **Company size** | Solo / Startup / Scale-up / Enterprise |
+| **Industry verticals** | |
+| **Tech stack** | |
+| **Decision authority** | Individual contributor / Team lead / Buyer / Influencer |
+
+**Day-in-the-life**:
+> [Describe your ideal developer's typical day and challenges]
+
+---
+
+## Where They Hang Out
+
+| Channel | Specific places |
+|---------|-----------------|
+| **Reddit** | r/ |
+| **Discord/Slack** | |
+| **Twitter/X** | # hashtags, @accounts |
+| **Newsletters** | |
+| **Podcasts** | |
+| **Blogs** | |
+| **Conferences** | |
+| **GitHub** | Topics: |
+| **Stack Overflow** | Tags: |
+
+---
+
+## Problems & Pain Points
+
+### Functional problems
+- [ ]
+
+### Emotional pain
+- [ ]
+
+### Trigger moments
+- [ ]
+
+**#1 frustration that brings developers to us**:
+>
+
+---
+
+## Current Alternatives
+
+| Alternative | Why devs choose it | What's frustrating | Switching triggers |
+|-------------|-------------------|-------------------|-------------------|
+| | | | |
+| | | | |
+| Build it themselves | | | |
+| Do nothing | | | |
+
+---
+
+## Key Differentiators
+
+| Type | Our claim | Proof |
+|------|-----------|-------|
+| **Technical** | | |
+| **DX** | | |
+| **Ecosystem** | | |
+| **Philosophy** | | |
+
+---
+
+## Verbatim Developer Language
+
+### How they describe the problem
+>
+
+### How they describe our product
+>
+
+### Common objections
+>
+
+### Praise / testimonials
+>
+
+**Sources**: GitHub issues, Twitter, Hacker News, support tickets, sales calls
+
+---
+
+## Technical Trust Signals
+
+| Signal | Current value |
+|--------|---------------|
+| **GitHub stars** | |
+| **npm/PyPI downloads** | |
+| **Docker pulls** | |
+| **Contributors** | |
+| **Community size** | Discord: / Slack: |
+| **Notable users** | |
+| **Backed by** | |
+
+---
+
+## Conversion Actions
+
+| Stage | Primary action | Secondary actions |
+|-------|---------------|-------------------|
+| **Awareness** | | |
+| **Consideration** | | |
+| **Trial** | | |
+| **Activation** | | |
+| **Conversion** | | |
+
+**"Hello World" moment**:
+> [What's the moment developers feel they've succeeded?]
+
+---
+
+## Voice & Tone
+
+| Dimension | Our position (1-5) |
+|-----------|-------------------|
+| Casual ← → Professional | |
+| Accessible ← → Deep technical | |
+| Neutral ← → Opinionated | |
+| Serious ← → Playful | |
+
+**Voice inspiration** (brands/people to emulate):
+-
+
+**Words we use**:
+-
+
+**Words we avoid**:
+-

package/obj/template/.claude/skills/triage/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: triage
+owner: baseline
+description: Triage an incoming request — pick the workflow entry phase (intake / spec / tdd / chore) and record the workflow statefile that the Track Guard reads.
+argument-hint: "<request in plain English>"
+---
+
+Triage the user's request and set up `.claude/state/workflow.json` so downstream phase skills and the Track Guard hook know which track we're on.
+
+# Decision rules (per seed.md)
+
+- **New implementation / feature**: entry = `intake`. Full 11-phase pipeline.
+- **Bugfix**: entry = `spec` (Phase 4) OR `tdd` (Phase 6), depending on whether the bug needs a written spec. Ask if unclear; default to `spec` when the bug affects contract/behaviour and `tdd` when it's a localized misbehaviour with a known failing case.
+- **Quickfix** (typo across multiple files, multi-file config tweak, small bundled patch): entry = `tdd`. May also mark phases `intake`, `scout`, `research`, `spec`, `review` as exceptions.
+- **Chore** (no TDD-driven code change needed): entry = `chore`. Choose chore when the request has no failing-test-driven code change — documentation edits, governance count refreshes, vendored-skill content updates, configuration tweaks, formatting / typo fixes, dependency bumps where no project code changes, skill consolidation moves, file renames with no behaviour change. The classification rule is *"if there's no failing test that should exist for this work, it's a chore"*. Mark `intake` / `brd` / `scout` / `research` / `spec` / `review` / `tdd` as exceptions in `workflow.json`; **leave `simplify`, `security`, `integrate`, `document`, `archive` and `commit` in the phase list** — the chore skill itself decides which of those phases to actually run based on its conditional triggers (it does not silently skip them). If the request needs a failing test to drive correctness, route to `tdd` or higher instead.
+
+# Steps
+
+1. Restate the request back to the user in 1-2 sentences, and name the entry phase you've chosen and why.
+2. **Git-repo detection (mandatory).** Run `git rev-parse --is-inside-work-tree 2>/dev/null` at the project root. If the exit status is non-zero, the project is not a git repository: gate C / `commit` are inapplicable AND the swarm path is unavailable because worktree isolation (the swarm contract's physical safety mechanism) requires git (CLAUDE.md Article IV "Phase 6c and Phase 11 are git-conditional", Article VII). Append `"swarm-plan"`, `"approve-swarm"`, `"swarm-dispatch"`, `"grant-commit"`, and `"commit"` to the exceptions array you'll write in step 4. Tell the user: "Non-git project detected — `swarm-plan`, `approve-swarm`, `swarm-dispatch`, `grant-commit`, and `commit` auto-excepted. Phase 6 routes to solo `/tdd`. Workflow ends after `/archive`. Persistence outside git is your responsibility."
+3. If the user has not confirmed yet, ask: "Entry phase = <X>. Exceptions = <Y>. Proceed? (or tell me a different entry)"
+4. On confirmation, write `.claude/state/workflow.json`:
+   ```json
+   {
+     "request": "<the request>",
+     "entry_phase": "<intake|spec|tdd|chore>",
+     "exceptions": ["<phase>", ...],
+     "completed": [],
+     "created_at": <epoch>,
+     "updated_at": <epoch>
+   }
+   ```
+5. **Seed the workflow tasklist.** Use the `TaskCreate` tool to register one task per non-excepted phase plus each applicable consent gate. The tasks are the running checklist that `/harness` (or any direct phase invocation) reads to decide the next action; consent-gate tasks block the workflow until the user runs the corresponding command. **When `grant-commit` and `commit` are in exceptions (non-git project), do NOT seed those two tasks** — the workflow ends after `/archive`. Use these canonical templates:
+
+   **For `chore` track** (single phase + commit gate):
+   - `Run /chore for <slug>` — activeForm: "Running chore", metadata: `{"phase": "chore"}`
+   - `Wait for /grant-commit` — metadata: `{"phase": "grant-commit", "needs_user": true}`, addBlockedBy previous
+   - `Run /commit for <slug>` — activeForm: "Running commit", metadata: `{"phase": "commit"}`, addBlockedBy previous
+
+   **For `tdd`-entry quickfix track** (skip intake/scout/research/spec/review):
+   - `Run /tdd`, `Run /simplify`, `Run /security` (only if not in exceptions), `Run /integrate`, `Run /document`, `Run /archive`, `Wait for /grant-commit` (`needs_user`), `Run /commit` — each with `addBlockedBy` set to the previous task's id.
+
+   **For `spec`-entry track** (skip upstream): start from `Run /spec`, then `Wait for /approve-spec <path>` (`needs_user`), then continue per the full track.
+
+   **For `intake`-entry full track**: `Run /intake`, `Run /brd` (only if stakeholder-heavy), `Run /scout`, `Run /research`, `Run /spec`, `Wait for /approve-spec <path>` (`needs_user`), `Run /tdd` OR (`Run /swarm-plan`, `Wait for /approve-swarm <slug>` (`needs_user`), `Run /swarm-dispatch`), `Run /simplify`, `Run /security` (unless excepted), `Run /integrate`, `Run /document`, `Run /archive`, `Wait for /grant-commit` (`needs_user`), `Run /commit`. **On non-git projects the swarm branch SHALL NOT be seeded** — only `Run /tdd` goes in the list, regardless of expected component count. Swarm-vs-solo is a Phase-6 main-context decision (per CLAUDE.md Article V) only on git projects; non-git workflows resolve to solo at triage time because `swarm-plan`, `approve-swarm`, and `swarm-dispatch` are already in `exceptions`.
+
+   For every task: `subject` is imperative ("Run /scout for <slug>" / "Wait for /approve-spec <path>"); `description` names the phase + the slug; `metadata.phase` carries the phase name; consent-gate tasks set `metadata.needs_user: true`. Wire `addBlockedBy` so each task blocks until its predecessor completes — this surfaces the workflow's true dependency graph and prevents `/harness` from racing past a gate.
+
+6. Tell the user the next concrete step to run: e.g. `/intake`, `/spec`, `/tdd`, `/chore`, or `/harness` to autopilot.
+
+# Constraints
+
+- NEVER skip triage by guessing from filename or diff alone. The user's natural-language framing is the primary signal.
+- The Track Guard reads `entry_phase` and `exceptions`. If the user wants to skip an optional phase (e.g. `security`), add it to `exceptions` — do not silently re-order `workflow.phases` in project.json.
+- If a workflow.json already exists for an open request, ask whether to replace it (starts a fresh track) or add to `completed` (continuing the same track).