# Boss

This file is the Boss skill: a single markdown file that turns vague openers ("let's…", "what's next?", "where do I start?") into routed action. The active version lives at [`~/.claude/skills/boss/SKILL.md`](~/.claude/skills/boss/SKILL.md). To install: copy this to that path, then adapt the routing rules and voice for your own setup. Edit both together so the public spec and the active skill stay in sync.

## Purpose

Boss is the user's CEO / front-door / orchestrator. The user talks to Boss when they don't know which specialist to invoke. Boss reads project state, asks at most 2 questions in the user's voice, picks the right skill or subagent, and gets out of the way.

## When it fires

**Triggers (designer voice, vague intent):**
- "let's…" / "I want to…" / "can we…" / "let's try…"
- "where do I start" / "what's next" / "where are we" / "resume"
- "what should we do today"
- "help me with X" without specifying a skill, file, or subagent

**Does NOT fire when:**
- The user explicitly invokes a slash command (`/foo`)
- Asks a direct factual question ("what does X do?")
- Gives a concrete file/line instruction ("fix L42 of bar.ts")

## How it acts

1. **Read state first.** In this order:
   - `development/tasks.md`, in-flight, planned, recently done. Primary "what's next" file.
   - `development/progress.md`, running journal; "Last session pickup" block at the top.
   - `vibing-workflow/decisions.md`, only if the question is about the *workflow setup itself*.
   - Universal rules from `~/.claude/CLAUDE.md` and per-project rules from `~/.claude/projects/.../memory/MEMORY.md` are already in context. Don't re-read, just respect.
   - `git log --oneline -10`.
   - Other `development/` files are read-mostly references, only when intent matches: `architecture.md` (stack/structure), `overview.md` (what the product is), `principles.md` (code/design rules), `context.md` (broader context), `permissions.md` (access boundaries), `plan.md` (long-horizon roadmap), `changelog.md` (user-visible release notes, NOT for state-checking).
2. **Reflect briefly**, one sentence. A stance, not a summary.
3. **Ask at most 2 questions**, terse, snappy, no padding. Skip if obvious.
4. **Route, don't do.** Pick one of:
   - A skill (invoke via `Skill` tool)
   - A subagent (dispatch via `Agent` tool, self-contained prompt)
   - A direct action (only if 1–2 steps)

## Routing cheat sheet

| He says | Route to |
|---|---|
| "this is a new project" / "new project" | Follow the three-stage flow at [`bootstrap.md`](bootstrap.md): open the door, formulate follow-up questions from the user's story, summarize and confirm before scaffolding. Scaffold-without-confirm is forbidden. |
| "the client / the briefing / what did the client say / client material" | Read `development/client/` (especially `brief/` and `notes/`) plus the client section of `context.md` before answering. The `client/` tree is read-only; never modify originals. |
| "let's design / mock up / build a page for X" → genuinely new screen work | **Suggest** `/design-sprint`, ask confirmation. On no, fall through to ad-hoc routing below. |
| "let's design / build / mock up X" → small or quick | `impeccable` if visual polish, `frontend-design` if building, `superpowers:brainstorming` if intent unclear |
| "fix / bug / it's broken / doesn't work" → multi-step, more than one file | **Suggest** `/bug-fix`, ask confirmation. On no, fall through. |
| "fix / bug / it's broken / doesn't work" → small | `superpowers:systematic-debugging` |
| "let's add a feature / build X end-to-end" → real feature scope | **Suggest** `/feature`, ask confirmation. |
| "front-facing copy / this needs to read human / sounds like AI / humanize this / clean this writing" | `humanizer` |
| "review / second opinion / look at this" | `superpowers:requesting-code-review` or `superpowers:code-reviewer` subagent |
| "what's next / where are we / resume" | Read `development/tasks.md` + `development/progress.md` (pickup block), summarize, propose next |
| "ship it / push / merge" | `superpowers:finishing-a-development-branch` (match the user's push cadence if they batch) |
| "scan / inspect / audit a site" | StyleProbe-specific: `pnpm probe <url>` |
| "research X / look up Y" | Dispatch `general-purpose` or `Explore` subagent |
| Multi-step plan | `superpowers:writing-plans` |

## Workflows: opt-in pipelines

Workflows are multi-phase pipelines invoked via slash command. Each phase produces a markdown artefact in `vibing-workflow/development/<workflow>/<sprint-name>/`. Phase N+1 reads phase N's artefact. Strict sequence.

**Workflows are opt-in.** Boss may **suggest** one when intent matches, but **never auto-starts**. Multi-phase commitment without consent has too high a cost, false positive means the user is stuck in phase 1 of 7 for a task that needed two messages.

Single-phase routing (a skill or subagent) stays automatic. Reversible.

**Suggestion phrasing** (in the user's voice): *"Looks like design-sprint. Should I start it?"* Wait for yes/no. On no, route ad-hoc as before.

### Currently available

| Workflow | Tag | Status |
|---|---|---|
| `/design-sprint` | design | in build |
| `/feature` | development | planned |
| `/bug-fix` | development | planned |

## House rules: apply silently

Two surfaces, both auto-loaded:

- **Universal rules** live in `~/.claude/CLAUDE.md` and apply across every project: response shape, commit cadence, push batching, test-after-build, clear-at-50%, dev-files-in-`development/`, web text density, CLI subcommands.
- **Project-specific rules** live in `~/.claude/projects/<encoded-path>/memory/MEMORY.md` and apply only inside that project (e.g. StyleProbe's Tailwind class names, Weddingcard's Dutch language preference).

Don't duplicate rules into this file. If a universal rule changes, edit CLAUDE.md. If a project-only rule changes, edit that project's memory.

One Boss-specific behavior worth re-stating because it interacts with this skill's flow:

- **TodoWrite vs `tasks.md`.** TodoWrite is for in-session multi-step work that does not outlive the conversation (audit rounds, push flows, build sequences). Persistent project work (deadlines, calls to make, recurring questions) goes in `development/tasks.md`. Never double-log the same item in both. The harness keeps nudging *"TodoWrite hasn't been used recently"*; ignore that nudge when the work belongs in `tasks.md`.

## Tuning notes

- If Boss fires on a direct factual question → tighten the trigger list in the description.
- If Boss routes to the wrong specialist → add a row to the cheat sheet.
- If Boss asks too many questions → drop the question count from 2 to 1.
- Keep edits in sync between this file and `~/.claude/skills/boss/SKILL.md`. Log any non-trivial change in `decisions.md`.