scope

# OpenAI Codex adapter. This file supplies the interface metadata Codex shows in
# its agent picker. The skill's actual instructions live in ../SKILL.md, which the
# Agent Skills client installs alongside this file and loads when the skill runs.
interface:
  display_name: "Scope"
  short_description: "Plan and reconcile feature scopes"
  default_prompt: "Run the scope skill: read its SKILL.md, then plan the next feature slices for this product, or reconcile the scope with what has shipped."

# Build Approach: Facade (the UI first prototype engineer)

Adopt this role for decomposition. You are a product prototyper whose instinct is: **make it look and feel real first, on fake data, then wire the real system behind it.** A clickable, believable interface gets feedback and validates the experience before any backend exists. This is prototype grade on purpose, say so plainly.

## How you think
- The scariest risk is building the wrong experience. You retire that by making the whole thing clickable and testable before investing in real data.
- "Done" for phase 1 means every key screen renders and navigates on placeholder data, convincingly, even though nothing persists.
- You deliberately fake the backend early. This buys speed and feedback; the cost is that it is not production complete until wired.

## How you slice the scope
- First phase = **all the key screens**, built and navigable on mock/placeholder data (no real database, auth stubbed). Breadth of interface first.
- Later phases **wire real data and logic screen by screen**, replacing mocks with the real backend behind an interface that already exists and has been reviewed.
- A slice is "another screen made real," working backward from a UI that is already complete.

## What is real vs deferred
- **Real (built) in phase 1**: the full set of screens, navigation, layout, states, on hardcoded/mock data.
- **Faked in phase 1, wired later**: authentication, the database, persistence, every real read and write. Clearly labeled as stubs.

## Sequencing
Foundations (enough to render UI: design system, component library, routing) → all screens on mock data (the clickable prototype) → wire the backend per screen (auth, then the primary write, then the reads, then the rest). Explicitly flag the prototype to production transition as its own work.

## Grade
Prototype first, wired later. State openly that phase 1 is not production complete; it is a validated shell.

## Worked example: async standup app
1. Foundations (UI only): design system, component library, routing, mock data fixtures.
2. **Phase 1 (clickable prototype):** every screen on mock data and navigable, sign in, team dashboard, submit standup form, team feed, history, settings. Looks real, persists nothing.
3. Phase 2: wire in real authentication behind the existing sign in screen.
4. Phase 3: build the real data model and make the submit form persist.
5. Phase 4: make the feed and history read real data.
6. Phase 5: wire reminders, roles, the rest.

Contrast: unlike Tracer Bullet (one thin but fully real thread) and Skateboard (one small but fully real product), your first deliverable is broad but not real, the interface exists everywhere and the backend nowhere, wired in afterward.

# Build Approach: Journey (the one complete experience engineer)

Adopt this role for decomposition. You are a senior engineer whose instinct is: **deliver one complete user journey, fully, before starting the next.** The experience and the funnel are the product. You build one path deep, all its steps, states, and polish, then move to the next path, rather than a thin thread across everything.

## How you think
- The scariest risk is a shallow, half polished experience across the board. You retire that by finishing one journey to a real, polished standard before opening another.
- "Done" for a phase means one whole user path works end to end including its edge, empty, error, and confirmation states, not just its happy path.
- You go depth first per journey, not breadth first thin.

## How you slice the scope
- Each phase = **one complete user journey**, built fully: every step of that path, all its states, the polish a real user would expect.
- The next phase starts only when the current journey is genuinely complete. Other journeys do not exist yet, on purpose.
- A slice is "one whole experience finished," not "one layer connected" or "one screen wired."

## What is real vs deferred
- **Real and complete in phase 1**: every step and state of the chosen primary journey.
- **Deferred entirely**: all other journeys (they are whole later phases), not thinned versions sprinkled in early.

## Sequencing
Foundations → the primary journey built completely → the next journey built completely → and so on. Pick the journey order by user and business value (usually the core recurring action first).

## Grade
Production, one path deep at a time. Each shipped phase is a fully finished experience.

## Worked example: async standup app
1. Foundations: stack + scaffold, the data model the first journey needs, design system.
2. **Phase 1 (the daily submit journey, complete):** land / get reminded → open today's standup → fill it on the active template → submit → confirmation → edit before cutoff → see it in the feed. All states: already submitted, missed yesterday, empty template, network error. Fully polished before anything else.
3. Phase 2 (the team setup journey, complete): create a team → invite members → accept invite → set the template → manage roles, all steps and states.
4. Phase 3 (the review and insights journey, complete): browse history → filter by person/date → view trends → export.

Contrast: unlike Tracer Bullet, you do not build a thin version of the whole loop first and thicken; you finish the entire submission journey (edges and polish included) before the team setup journey exists at all.

# Build Approach: Skateboard (the smallest usable product engineer)

Adopt this role for decomposition. You are a senior product engineer whose instinct is: **ship the smallest complete product a real person would actually use, then grow it.** Not a thin thread to prove the stack, a genuinely usable whole you would release. Each release is a better version of the same usable product (skateboard → bike → car), never a half built chassis.

## How you think
- The scariest risk is building something nobody wants. You retire that by putting a usable product in real hands fast.
- "Done" for release 1 means a real user gets real value start to finish, even if the scope is tiny.
- You will cut **structure**, not just breadth, to reach usable sooner. If teams or roles are not needed to be useful on day one, they wait.

## How you slice the scope
- First deliverable = the **thinnest usable whole**: the least you can build that a real user would choose to use and you would actually ship.
- Each later release **grows the usable surface** (adds a capability that makes the same product more useful), always leaving a shippable product at every step.
- A slice is measured by "is the product more useful now," not "is another layer connected."

## What is real vs deferred
- **Real in release 1**: only what is required to be usefully complete for one real use.
- **Deferred**: anything the product can be genuinely useful without yet, including structural pieces (teams, roles, multi tenant niceties) if they are not day one essential.

## Sequencing
Foundations → smallest usable product → grow it release by release, each release shippable. Ordering is driven by "what makes it more useful next," not by proving integration.

## Grade
Production, minimal but genuinely usable and shippable at every release.

## Worked example: async standup app
1. Foundations: stack + scaffold, the minimal data model the first usable version needs, design system.
2. **Release 1 (smallest usable whole):** a person signs in and posts their daily standup to one shared board, and sees everyone's posts for today. No separate teams, no roles, no templates editor, no reminders. A tiny standup tool a small group could actually use tomorrow.
3. Release 2: teams, so more than one group can use it.
4. Release 3: custom questions / templates.
5. Release 4: reminders and scheduling.
6. Release 5: history and insights.

Contrast: unlike Tracer Bullet, you do not keep the full real structure (teams, memberships) just to prove it connects; you cut structure to reach "usable now," and add teams only when one shared board stops being enough.

# Build Approach: Tracer Bullet (the integration proving engineer)

Adopt this role for decomposition. You are a senior engineer whose instinct is: **prove the whole pipe works before building any part of it fully.** A working thread through every layer beats any single layer built out. You are validating that the architecture connects, end to end, as early as possible.

## How you think
- The scariest risk is that the layers do not connect (auth, DB, API, UI, deploy). You retire that risk first with one real, working path.
- "Done" for the first slice means a real user action travels DB → logic → interface → UI and back, for real, just narrow.
- You keep the real structure (real auth, real schema, real UI), you only cut breadth. Nothing is faked or stubbed.

## How you slice the scope
- First slice = the **thinnest real thread** through the core user loop that touches every layer and works. This IS the walking skeleton; do not plan a separate throwaway skeleton, merge them.
- Every later slice **thickens one segment** of that working thread, still end to end. Never build one layer fully across all features before the loop runs once.
- A slice is not "a whole capability built"; it is "one more strand added to a thread that already runs."

## What is real vs deferred
- **Real from slice 1**: authentication, the database and its migration, the core write and read path, a usable UI for exactly that path.
- **Deferred (added as later strands)**: breadth like invitations, editable templates, reminders, history, search, admin, insights.

## Sequencing
Foundations (stack, data model, design system) → the one core loop slice (= skeleton, merged) → thicken segments one at a time, each shipped end to end. Most slices lean on the foundation specs, so few need their own.

## Grade
Production, minimal. Everything built is real and shippable, just narrow in scope.

## Worked example: async standup app
1. Foundations: stack + scaffold, core data model (orgs, teams, memberships, templates, entries), design system.
2. **Slice 1 (core loop, = skeleton):** sign in (real auth) → create a team → submit today's standup on a default template → see it in the team feed. Real DB, real auth, real UI. No invites, no custom templates, no reminders, no history yet.
3. Slice 2: invite teammates to a team.
4. Slice 3: editable custom templates.
5. Slice 4: reminders / scheduling.
6. Slice 5: standup history and per person view.
7. Slice 6: insights.

Contrast: unlike Journey, you do not finish the whole submission experience before touching teams; you run a thin version of the *entire* loop first, then thicken every segment.

# Scope Mode: add

## Add (enroll one ad hoc feature, lightweight)

Inferred when a scope exists and the argument names a single feature: `/scope <a feature>` enrolls one coarse row without planning again, for a feature invented partway through. No `add` subcommand to type.

1. Read the scope again and dedup: present at any status → extend that row, don't duplicate.
2. Ask only what's needed (a short panel if intent/tier is ambiguous, else infer): intent, workflow tier (only if it differs from the project default, else inherit), placement (`Order` / `Phasing`).
3. Offer the per feature Approach: top option `(recommended) inherit the project default`, plus the named approaches (Tracer Bullet · Skateboard · Facade (prototype grade) · Journey); tag beside the heading only if it differs from the header default.
4. Set `Needs spec?` with the invent test: would building it require a decision the engineer has not made? Yes for a provider/library choice, a data model, a cross cutting pattern, the design system, a whole page/screen with no spec yet, or behavior that is not trivial (search, filtering, recommendations). No only for pure implementation an existing `design.md`/spec/convention covers. Unsure → yes; `GA`/`Beta` tier → almost always yes. Yes means its next step is `/architect <feature>`.
5. Append: an At a glance row (next free `#`, status `planned`) + a feature section under its phase with intent, a `Done when:` line, its one entry checkbox (no build task breakdown, derived from the spec later). Epic split: add to the right epic file, bump that epic's rollup in `index.md`.
6. Report briefly (mode: add): the row, tier (inherited or overridden), approach (inherited or overridden), Needs spec, next command.

# Scope Plan Route: brownfield

Brownfield: read root `AGENTS.md` (and any existing scope) to plan the next slice on top:
1. Enroll already built features for context, from `AGENTS.md` (nested area docs map to existing areas) + a light code scan, each with a `Code area` pointer. Large repo: offload the scan to a read only subagent (on Claude Code the `scout` subagent type, which is read only and pins a fast, low cost model; else set the model explicitly to a fast, low cost tier, not inherited; `Read`/`Grep`/`Glob`) returning a compact map, don't read the tree inline. Assess completeness honestly from the code, don't stamp everything done: complete and shipped → `existing` (distinct from `done`); partially built → `in-progress` (so `/develop` can resume). Never mark a half built feature `existing`.
2. Plan the next slice as `planned` rows; don't plan `existing` features again. No root `AGENTS.md`: note in the report that `/audit` should run first for real context.

Run again (scope exists): read the union, don't duplicate or fragment:
- Read the whole scope (single file, or `index.md` + every epic file); all features at any status (`planned`, `in-progress`, `done`, `existing`, `dropped`) are the dedup baseline.
- Never add back a feature present at any status; request overlaps an existing `planned` row → extend it (sharpen intent/seeds).
- Reconcile drift: shipped work or specs no row covers get enrolled (completed as `existing`/`done`, unfinished as `in-progress`); note as "drift enrolled".
- Report: counts already there / new / drift, files written. Full reconcile after shipping → prefer replan mode.

# Scope Plan Route: greenfield

Greenfield: decompose the whole MVP from scratch, foundations first. Apply the foundations first sequencing below at Step 4 of `plan.md`, after the build approach is chosen in Step 3.

## Foundations first sequencing (a principle every build approach obeys)

No approach starts a feature slice before the ground it stands on exists (working skeleton before features). Lead with these explicit foundation features (never buried sub tasks), default order below (cheaper foundation precedes what depends on it). Stack decided + project scaffolded before `/audit` runs: `/audit` seeds root `AGENTS.md` conventions + tooling from the real project.

1. **Standards preferences**: light preferences that can't be inferred (architecture style leanings, formatting taste). Keep light; may fold into the stack feature rather than its own row. Heavy convention + tooling capture is `/audit`, after scaffold. `Needs spec: no`.
2. **Stack and architecture**: ONE foundation feature, built like any other (a decision box, `Decide the stack (spec)`, then an execution box, `Scaffold from the decision: /develop …`), never two rows. `/architect` decides the stack (ARCHITECTURE spec: the one place tools/providers/frameworks are chosen; nothing tooling related runs before it); `/develop` then scaffolds from it (framework init, dependency install, directory layout, runnable dev server/build). `Needs spec: yes`, tier `Beta`+. The spec records only the decision; `/develop` derives scaffold steps at build time (writing them in both places is the double spec bug). Scaffold installs only the runnable skeleton the first slice needs (framework, language, core runtime), never every eventual library: deciding the full stack up front is correct (the spec's job), installing it all is not; each later feature installs its own dependencies when built (e.g. the billing SDK when billing is built). Exception: cross cutting tooling (lint, format, type strictness, `pre-commit`, CI) comes early via `/audit` + `/develop tooling`, since all later code must follow it.
3. **Coding standards & tooling**: two sub tasks: `/audit` (greenfield) captures conventions AND tooling choices into root `AGENTS.md` from the real scaffolded project, not guesses; then `/develop tooling` installs the chosen tooling (packages, config files, `pre-commit` hooks, CI) per what audit captured. `/audit` decides and records, never installs; `/develop` installs. `Needs spec: no`. After the stack and scaffold feature, never before.
4. **Data model**: explicit, never skipped (`Needs spec: yes`): core entities, relationships, persistence shape. Never fold into another feature or skip; a wrong data model is the most expensive thing to redo.
5. **Design system / UI foundation**: `/architect` → `design.md`, then base components (`Needs spec: yes`), if the product has meaningful UI; every page depends on it.
6. **Walking skeleton slice**: a thin vertical slice wired end to end (DB → API → UI) doing one trivial real thing (e.g. one record created and rendered), proving the stack is connected before feature work. Tier `Beta`; usually leans on the foundation specs, not its own. Under Tracer Bullet it merges with the first real slice (below).

Then the feature slices, ordered and phased per Step 3. Phasing column: `Foundation`, `Skeleton`, the slice/journey (e.g. `Slice 2`), or `Deferred`; Order column: integer build sequence across the whole scope.

Shape the slices exactly as the chosen approach's persona directs (`approaches/<name>.md`, already read in Step 3 of `plan.md`, whose role you have adopted). The approach changes WHAT the slices are, not just labels: every capability as its own fully built feature with `Slice 1 … Slice N` stapled on has NOT honored the approach. Follow the persona's decomposition rule, its first slice or deliverable, its real vs deferred split, and its sequencing, and let its worked example calibrate the shape.

Whatever the approach, most rows do NOT each need their own spec: the early slice rests on the foundational specs (data model, auth), and later slices usually extend a decided pattern. Still apply the invent test per row, but expect far fewer `Needs spec: yes` rows than a flat feature list; nearly every row needing one means you decomposed into full features, slice again.

# Scope Plan Route: monorepo

Monorepo (workspaces config: `pnpm-workspace.yaml`, `turbo.json`, `nx.json`, `lerna.json`, `workspaces` in root `package.json`; or multiple manifests under `apps/*` / `packages/*`): plan per workspace, never mix apps:
- Each workspace: `docs/scope/<workspace>/` (`scope.md`, or `index.md` + epics if large). Repo wide planning (monorepo tooling, cross cutting infra, e.g. a shared design system in `packages/ui`): `docs/scope/_root/`.
- Top level `docs/scope/index.md` maps the monorepo: one line per workspace (and `_root`) linking its scope with a status rollup (features done / total); create or update whenever a workspace scope is added or its rollup changes.
- `/scope web <idea>` plans the `web` app; bare `/scope` on a monorepo asks which workspace(s) (or "repo wide") as a panel. Read that workspace's nested `AGENTS.md` for its stack/conventions; apps differ, don't assume one.
- Each feature's `Code area` points into its workspace (`apps/web/...`). Foundations are per workspace, except genuinely shared ones (monorepo tooling, a shared UI package), which live in `_root` and the apps depend on. A greenfield workspace (no code yet) follows the foundations first sequencing in `modes/plan-greenfield.md`, applied per workspace; an already built workspace enrolls per `modes/plan-brownfield.md`.
- Feature spanning workspaces: plan in `_root` (tag intent by workspace) or split into coordinated per workspace features; never bury cross app work in one app's scope.

# Scope Mode: plan

### Step 1: Locate the scope; greenfield / brownfield / monorepo

Detect (skip `node_modules/` and `.git/`): source files (any `.ts`, `.tsx`, `.js`, `.py`, `.go`, `.rs`; presence ⇒ brownfield, none ⇒ greenfield); root `AGENTS.md`; existing scope under `docs/scope/` (`scope.md`, or `index.md` + epic files; monorepo: `docs/scope/<workspace>/`), noting the shape.

Read exactly one route file before continuing to Step 2:

- `modes/plan-monorepo.md` when workspace markers or multiple app/package manifests show a monorepo.
- `modes/plan-brownfield.md` when source files or a manifest show an existing codebase or an existing scope is being extended.
- `modes/plan-greenfield.md` when there is no source code and no manifest yet.

Do not read the other plan route files unless the classification changes. After the selected route has established the scope/workspace context, continue with Step 2 below.

### Step 2: Ask (generated question walk, as decision panels)

Do not follow a fixed script or a set number of rounds. Enumerate the planning dimensions THIS product needs (generate them from the idea and `AGENTS.md`), then ask them one after another as batched decision panels (up to 4 per panel), as many panels as it takes. Infer and skip anything already stated; ask everything else. Never cap the questions to save time, and never end while a load bearing dimension is unasked.

Cover at least these dimension groups (a checklist of what to reach, not an order to recite; add product specific dimensions freely):

- **Product & business**: MVP boundary (smallest version delivering the core value; most important); primary audience (only if unclear); monetization (free / subscription / one time / usage based / ads / none yet; shapes billing features); success metric (signups, activation, revenue; informs analytics features); hard constraints (deadline, budget, team size, compliance scope; shape phasing and weights).
- **Capabilities**: the cross cutting capabilities the product plausibly needs, by type (e.g. authentication, multi tenant orgs, payments/billing, email/notifications, file/media upload, search, realtime, admin panel, public API), as a multi select. Confirm in scope this slice vs deferred; each selected becomes one or more features. Name capabilities, never the implementing tool.
- **Cross cutting & go to market** (routinely forgotten, in the plan from day one): SEO (public/marketing pages, metadata, sitemap, structured data, social cards, SSR/SSG needs; skip for purely internal/auth walled apps); performance (Core Web Vitals targets, caching, expected load); analytics & tracking (product analytics, error monitoring, conversion events); accessibility (WCAG target); internationalization (languages/locales, RTL); legal/compliance (cookie consent, privacy/terms, GDPR/CCPA, age gating).

Each "yes" becomes its own feature or folds into a relevant feature's acceptance criteria seeds (e.g. "SEO metadata present" on each public page; cookie consent its own feature).

### Step 3: Choose the build approach (decision panel)

Decides how every feature is sliced and sequenced. No fixed procedure; reason about this product (goal, the product & business constraints from Step 2, production build vs throwaway), then present a panel of the named approaches, each stated by its guiding principle (not steps), recommending exactly one:

- **Tracer Bullet**: vertical slices; each feature built end to end through every layer, working.
- **Skateboard**: MVP first; ship the thinnest usable whole first, then grow it.
- **Facade**: UI first; a clickable shell on placeholder data, then wire the back. Prototype grade (fast to demo, not production complete).
- **Journey**: a complete user path end to end per phase.

Reason out the pick, never hardcode it or its mechanics: default for a proper production build is Tracer Bullet; shift only when the goal calls for it (fast validation of one core loop → Skateboard; the experience/funnel is the product → Journey; a quick clickable prototype → Facade, said plainly to be prototype grade). One line why in terms of this product. Never name a tool; the approach shapes how, not with what.

**Once the approach is chosen, read its persona file and adopt that engineer's role for decomposition** (`approaches/tracer-bullet.md`, `approaches/skateboard.md`, `approaches/facade.md`, or `approaches/journey.md`). Read only the chosen one. Each persona defines how that engineer slices, what the first slice or deliverable is, what is real vs deferred, and the sequencing, with a worked example. All slicing and sequencing in Step 4 and Step 5 follows that persona. A per feature override (Step 5) reads that feature's chosen persona and applies it to that feature only.

Record it (the propagation source) in the scope header: `Build approach: <name> (<one-line principle>)`. A project wide convention: `/audit` and `/sync` persist it into root `AGENTS.md`; `/architect`, `/develop`, `/check verify` read and honor it. It also sets each feature's Phase (its slice / journey), shown in the At a glance table and as section grouping.

Header value = project default; a single feature may override via the optional per feature Approach (Step 5), a tag beside its heading (e.g. `· Facade`). Precedence: own tag if set, else project default; tag only when it differs (no tag = inherit).

### Step 4: Foundations first sequencing (a principle every build approach obeys)

No approach starts a feature slice before the ground it stands on exists (working skeleton before features): lead with explicit foundation features (stack, tooling, data model, design system, walking skeleton), never buried sub tasks, cheaper foundation before what depends on it. Then the feature slices, ordered and phased per Step 3 (Phasing column: `Foundation`, `Skeleton`, the slice/journey e.g. `Slice 2`, or `Deferred`; Order column: integer build sequence across the whole scope).

- **Greenfield (and greenfield monorepo)**: apply the full foundations first sequencing in `modes/plan-greenfield.md` (the ordered foundation features, then how each build approach shapes the slices). That route file is your Step 4 detail.
- **Brownfield**: the foundations already exist; do not plan them again. Plan the next slice on top per `modes/plan-brownfield.md`, shaping it to the Step 3 approach; enroll already built features rather than laying foundations.

### Step 5: Decompose into coarse feature sections (you reason; don't ask)

From the answers, produce the feature list: foundations first (Step 4), then slices, then explicitly deferred nice to haves. Per feature:

- Keep features small: one page or one cohesive unit each (a listing, a product page, and a cart are three features, not one "storefront"); split anything spanning unrelated screens.
- **Intent (1 to 2 lines)**: what it is and why it matters.
- **Done when line (acceptance criteria seeds)**: one compact `Done when:` line of observable outcomes (e.g. "user can filter the list and the URL reflects it; empty and error states render"). Seeds, not a spec; `/architect` grows them into the spec's full requirements and acceptance criteria. Load bearing outcomes only.
- **Workflow tier** (only when it differs from the project default set in Step 5b): `Prototype` / `Alpha` / `Beta` / `GA`, from this feature's risk, scope, and compliance sensitivity. Most features inherit the project default; tag a feature (e.g. `· GA`) only when it warrants more or less rigor than the rest. Higher tier → more likely `Needs spec: yes`.
- **Approach (optional per feature override)**: defaults to inherit. Only when genuinely best built differently, run a Build approach panel for THAT feature: `(recommended) inherit the project default` on top, plus the named approaches (Tracer Bullet · Skateboard · Facade (prototype grade) · Journey) as overrides; same panel and no hardcoded tool conventions as Step 3, tag and precedence rules per Step 3.
- **Needs spec?**: the invent test: would building it require a decision the engineer hasn't made? Yes for a provider/library choice, a data model, a cross cutting pattern, the design system, a whole page/screen with no spec yet, or behavior that is not trivial (search, filtering, recommendations). No only for genuinely pure implementation an existing `design.md`/spec/convention covers. Unsure → yes; an unflagged decision is the expensive miss. `GA`/`Beta` tier → almost always yes.
- One decision per spec: multiple distinct decisions in one feature → one `Needs spec: yes` item each, never one lumped "strategy" spec. Several sharing one broad decision that then splits → an umbrella that dependents reference; never mark a dependent `no` when it carries its own decision.

No build task breakdown here. A not yet designed feature gets exactly one checkbox, its entry command: `/architect <feature>` when it `needs a decision`, else `/develop <feature>` (the coding standards and tooling foundation's first box is `/audit`, never `/develop`). Never enumerate UI / data model / API / test sub tasks; `/architect` fills the built ready shape on spec capture (see What this skill does; atomic tasks stay in the spec). The next step is then always the first unticked box, always a command or tracked milestone (no separate `Next:` line). See the lifecycle table in `scope-template.md`.

Analysis/inventory is not a scope row: cataloguing duplication, listing call sites, auditing current state is decision support research living with the spec (`/architect` puts it in the spec's `rationale.md`). Never plan a row or step that writes a `.md` into `docs/scope/`.

### Step 5b: Recommend the workflow depth (decision panel)

Now that the features exist, propose the project's default **workflow depth**: how many stages a feature normally runs after `/develop`. Reason from the product (throwaway prototype vs internal tool vs real product vs payments/auth/compliance/regulated/team work) and the mix of feature weights you just assigned, then present a panel with exactly one recommended.

Depth governs only the stages **after** `/develop` (verify, test, review, document). It does **not** turn off the `/architect` gate: at every depth, a feature that needs a load bearing decision still runs `/architect` first (or records an `Assumed` spec). Alpha does not mean "skip architect"; it means lean features are usually `Needs spec: no`, so you rarely reach it.

- **question**: "How much workflow do you want by default for this project? Each level sets the stages a feature normally runs after `/develop`; a risky feature can still be bumped up, and `/architect` still applies whenever a decision is owed."
- **header**: "Workflow"
- **options** (mark exactly one `(recommended)` by the product signals, one line why):
  - `Prototype`: "Just `/develop`. Nothing after it, you rely on `/develop`'s own build time self check (typecheck, and rendering the screen when it can) and your own eye. No `/check verify`, no test suite, no review. `/develop` can mark the feature `done` itself. Best for throwaway prototypes, experiments, and personal projects."
  - `Alpha`: "After `/develop`, `/check verify` on the real app. No separate test suite or second model review unless a feature needs it. Best for low risk features and internal tools you still want proven."
  - `Beta`: "After `/develop`, `/check verify` then `/test`. No fresh model review by default. Best for most real products."
  - `GA`: "After `/develop`, `/check verify`, `/test`, a fresh model `/check review`, then `/document`; and most features are treated as needing a spec. Best for high risk, payments, auth, compliance, regulated, or team projects."

The picker appends a free text Other automatically; in a plain text fallback offer the same four. Recommend by signal: throwaway prototype, experiment, or a personal one off → `Prototype`; a low risk product or internal tool you still want proven → `Alpha`; a normal production product → `Beta`; payments, auth, PII, compliance, regulated, or a team codebase → `GA`.

Each tier also sets what `done` means (see `scope-template.md`); a feature built on an `Assumed` spec can still be `done`; the `Assumed` spec stays flagged as owing ratification until `/architect` ratifies it.

Record the pick as the project default in the scope header `**Workflow:**` line (see `scope-template.md`). This default is what `/develop` reads (via the effective tier) to scale the next steps it recommends after a build.

### Step 6: Write the scope (single file or epic split)

List the scope location again immediately before writing (a teammate may have changed it), then write per `scope-template.md`:

- Small product → single file `docs/scope/scope.md` (monorepo: `docs/scope/<workspace>/scope.md`): At a glance table (including brownfield enrolled features) + phase grouped feature sections + legend.
- Large product → epic split per Artifact ownership (`docs/scope/index.md` + `docs/scope/<epic>.md`); promote only when `scope.md` has outgrown a comfortable scan, else stay single file.
- Run again (living update): edit in place, never a dated file: append new rows with the next free `#`, sharpen existing rows' intent/seeds, leave existing statuses untouched; set a now out of scope row to `dropped` (never delete). Brownfield: append enrolled `existing`/`in-progress` rows above the `planned` ones.

Citations are gated by Step 6b: ask that panel first (or confirm the chosen level) before adding any `(basis: …)` or `## References` content, and honor its level.

### Step 6b: References consent (one panel, covers sources AND links)

Ask ONE consent question governing both the `(basis: …)` citations and any reference links (one clear ask, not two). Panel; record the outcome as the References level:
- question: "Add a References section to the scope (where the recommendations come from, and optionally links)? The intent and reasoning stay either way. The links option runs a subagent that web searches and fetches pages to confirm official docs and standards, which costs some extra tokens."
- header: "References"
- options:
  - `No references, keep it clean (recommended)`
  - `Sources only (named project sources and practices, no web fetch)`
  - `Sources plus web verified links (fetches pages to confirm the links, costs some extra tokens)`

No references (or no answer): no `## References` section, no `(basis: …)` citations anywhere; the scope keeps its intent and reasoning and reads clean. Done.

Sources only (or the agent has no web tools): wherever the scope recommends something the engineer didn't dictate (phasing choice, order rationale, a suggested capability, a `Needs spec` flag, a tier call), append a short `(basis: …)`: a project source (`your AGENTS.md`, a spec, the existing stack) or a named practice (`vertical slices ship real value early`, `foundations before features`, `data model is the costliest thing to redo`); inline you have no web tools, so name the source or practice, never a URL. Add a `## References` section naming *Project sources* (verifiable) and *Practices & standards* (named); no Links group, no subagent. Done.

Sources plus web verified links: as Sources only, then verify the links with a read only web subagent (it only fetches; you do the writing), so links are confirmed, never fabricated:
- Spawn a read only `researcher` subagent (capability first). `model`: the cheapest tier; do not inherit the session model (Claude Code: the `researcher` type pins `haiku` and carries the web tools; a light model elsewhere) · `description: "Scope: verify reference links"`
- Tools: `Read`, `WebSearch`, `WebFetch` (no `Edit`; it does not write)
- `prompt`: the scope recommendations and the candidate sources. Job: confirm each load bearing `(basis: …)` is sound; where a canonical source is worth linking (an official doc, a named standard/practice), web search and fetch to confirm it exists and says what's claimed; return only the compact list of verified links (title + URL), or "none verified". Never invent a URL. Keep it lean.
- Then YOU (main thread) write the `## References` *Links* group from that verified list (web verified only, else "none verified"); the fetch happens once here, and nothing fetches these links again afterward. They are for a human to follow.
- No web tools or subagents: degrade to the Sources only behavior.

### Step 7: Report and hand off

Print the completion report using the `## /scope complete` block in `scope-template.md`, filled with this run's specifics. `/scope` does not run `/architect` or `/develop` for you; it hands you the ordered, coarse, weighted list to walk feature by feature (architect the `Needs spec: yes` ones, then build).

# Scope Mode: replan

## Replan (the living rhythm, run after a feature or phase ships)

The default cadence, not rare: run each time a feature or phase lands, keeping the scope matching reality and queueing the next slice. Reconciles in place, never spawns a new file; coarse and surgical (reconcile cells, append rows, don't rewrite the file).

1. Read the whole scope again (single file, or `index.md` + epics; the workspace's in a monorepo) and the code/specs for what just shipped.
2. Reconcile what shipped: mark completed features `done` (verify from code/spec, don't stamp); tick nothing unconfirmed; leave rows `/develop`/`/sync` already advanced. **A feature whose governing spec is `Assumed`** keeps its `assumed decision (spec NNNN)` note and is surfaced (below) as decision debt; the note does not block `done`, so reconcile its status from what actually shipped.
2a. Surface assumed decisions in the readout and report: for each feature with an `Assumed` spec, list it as "built, awaiting ratification (spec NNNN)" and point to `/architect <feature>`. The flag does not block `done`; it stays surfaced until ratified.
3. Enroll needs surfaced during the build: read shipped features' spec `## Consequences` and `## Follow-up` sections; a follow-up (e.g. "add rate limiting") not yet a scope row becomes a new `planned` row with intent, tier, `Needs spec?`; the scope grows from real build feedback.
4. Reprioritize / reorder: sequence `Order` again, adjust `Phasing` for work not yet built; foundations stay first; work dropped from scope → `dropped`. If the project's risk profile has clearly shifted (e.g. payments or auth were added), recommend the `**Workflow:**` default again via the plan Step 5b panel; otherwise leave it.
5. Queue the next slice: which feature(s) are next (lowest `Order` `planned` rows), each `Needs spec: yes` (→ `/architect` next) or `no` (→ `/develop`).
6. Report via the completion block (mode: replan): marked done, enrolled from spec follow-up items, reordered/dropped, next step.

Reference shapes for writing the scope and the completion report. Rules live in `SKILL.md`.

## What keeps it readable (the format rules)

- **Two parts:** a slim **At a glance** table for a quick scan, then **the plan** as clean feature sections grouped by phase. Build order is just the section order. There is no separate "build order" list to keep in sync.
- **Clean headings.** A heading is `### <N>. <Feature name>` plus a short status word and short tags **only when they carry real information** (`needs a decision`, a per feature approach override, a workflow tier override like `· GA`). Never a pipe delimited metadata row like `Title | P0 | inherit | …`.
- **Each fact appears once.** Intent, the definition of done, tasks, and pointers live in the section; the At a glance table is the quick index. Status is shown in the table and beside the heading, and nowhere else.
- **Only what is set.** No `n/a`, no `inherit`, no empty fields. A pointer line (`spec <n> · code in <path>`) appears **only once those exist**: the spec link added by `/architect` at capture, the code path by `/develop`.
- **A feature grows a defined shape.** It has a one or two line **intent**, a single **Done when:** line (the acceptance criteria seeds), and **checkbox steps**. A **not yet designed** feature has **one box** (its entry command: `/architect` when it `needs a decision`, else `/develop`, or `/audit` for standards & tooling). **When its spec is captured, `/architect` fills in the built ready shape:** `Design it` (ticked) → `Build it: /develop <feature>` with **2 to 5 milestone sub items rolled up from the spec** → `Verify it: /check verify <feature>` → `Test it: /test <feature>`. **The atomic build tasks stay in the spec's `## Build plan`, never here**. The scope carries only the milestone rollup. The next step is always the first unticked box.

## Single file scope

```markdown
# Scope: <Product name>

<One or two plain sentences: what the product is and who it serves.>

**Build approach:** <Tracer Bullet | Skateboard | Facade | Journey> (<one-line principle>).
**Workflow:** <Prototype | Alpha | Beta | GA> (<what runs after develop, e.g. Beta = check verify, then test>). The project default level of rigor. `/architect` is the recommended first stop for a feature with a real decision, but skippable when you already know the build. Any feature can carry its own tag (e.g. `· GA`) to do more or less.

_These are recommendations to keep your build orderly, not requirements. Skip anything that does not fit: if you already know how to build a feature, use `/develop` and skip `/architect`. You decide when a feature is `done`._

## At a glance

| # | Feature | Phase | Status |
|---|---------|-------|--------|
| 1 | Stack & architecture | Foundation | in-progress |
| 2 | Coding standards & tooling | Foundation | planned |
| 3 | Data model | Foundation | in-progress |
| 4 | Design system & UI foundation | Foundation | planned |
| 5 | Core standup loop | Slice 1 | planned |
| 6 | Daily reminders | Slice 2 | planned |
| … | … | … | … |

## Foundations

### 1. Stack & architecture · in-progress
Decide the stack and scaffold a runnable project so every later slice builds on real structure.
**Done when:** the stack is recorded in a spec and the empty scaffold boots locally and passes build.
- [x] Decide the stack (spec): `/architect stack & architecture`
- [x] Scaffold from the decision: `/develop stack & architecture`
- [ ] Smoke-check it runs: `/test`
Spec 0001 · code in `./`

### 2. Coding standards & tooling
Capture conventions, then install lint, format, and pre-commit enforcement from the real scaffolded project.
**Done when:** root `AGENTS.md` reflects the real stack, and lint/format/pre-commit run clean.
- [ ] Capture conventions + tooling choices: `/audit`
- [ ] Install the tooling: `/develop tooling`
- [ ] Check it runs clean: `/test`

### 3. Data model · in-progress
<!-- DESIGNED: /architect captured spec 0002 and filled in the shape below. The 2 to 5 boxes under
     "Build it" are a ROLLUP of the spec's ## Build plan: every table, column, and policy lives in
     the spec, NOT here. This is what a feature looks like right after its spec is captured. -->
Core entities every feature builds on: users, teams, memberships, standup entries, template.
**Done when:** entities and relationships support later slices (reminders, templates, history) without a breaking migration.
- [x] Design it (spec): `/architect data model`
- [ ] Build it: `/develop data model`
   - [ ] Schema + constraints: tables, keys, unique/check, cascades (AC-1..6)
   - [ ] Row-level security: per-table policies + helpers (AC-7..9)
   - [ ] Apply migration, confirm live, generate types (AC-1..9)
- [ ] Verify it: `/check verify data model`
- [ ] Test it: `/test data model`
Spec 0002 · code (filled by /develop)

### 4. Design system & UI foundation · needs a decision
Visual language, layout primitives, and base components so the flows feel cohesive and accessible.
**Done when:** `design.md` covers type/color/spacing/components, and base components handle focus and keyboard.
- [ ] Design it (spec): `/architect design system & UI foundation`

## Slice 1: Core standup loop

### 5. Core standup loop · needs a decision
Sign in, create a team, submit today's update on the default template, read the team feed. Nothing else yet. This slice is the walking skeleton.
**Done when:** a user can sign in, create a team, submit one standup a day, and see the team's updates for today.
- [ ] Design it (spec): `/architect core standup loop`

## Slice 2: Daily reminders

### 6. Daily reminders · needs a decision
Nudge members who have not submitted before a team cutoff, so daily standup becomes a habit.
**Done when:** unsubmitted members get a timezone-aware reminder before cutoff, and submitters are not nagged.
- [ ] Design it (spec): `/architect daily reminders`

## Deferred
Out of scope for the current build pass, kept so the plan stays honest.
- **Email invites**: invite teammates by email · needs a decision
- **Billing & plans**: free and paid tiers · needs a decision · GA
- **Chat integrations**: post standups to team chat · needs a decision
- **Product analytics**: measure signups and habit · needs a decision

## Legend

**The decision box.** Every feature carries exactly one, the sub-task whose label ends with `(spec)`. Its wording varies (`Design it (spec)` normally, `Decide the stack (spec)` on Stack & architecture), so skills locate it by that `(spec)` suffix, never by an exact label. Every other box is an execution box and `/architect` never ticks one.

**Feature lifecycle**: the scope updates as a feature moves; each row is what it shows and who sets it:

| State | Set by | The feature shows |
|---|---|---|
| `planned` · needs a decision | `/scope` | one box: `Design it (spec): /architect <feature>` |
| `in-progress` (designed) | **`/architect` at spec capture** | `Design it` ticked; spec linked; `Build it: /develop <feature>` + **2 to 5 milestones**; the tier's closing boxes (`Verify it` Alpha+, `Test it` Beta+, `Review it` + `Document it` GA); any surfaced follow-up enrolled |
| `in-progress` (building) | `/develop` | milestone sub-boxes tick one by one; code pointer filled |
| `in-progress` (verified) | `/check verify` | `Build it` + milestones ticked; `Verify it` ticked |
| `done` | **you, when you decide it is** (any skill sets it when you say so); `/sync` reconciles | boxes you ran ticked, skipped ones marked skipped; the tier's last stage (`Prototype` → after `/develop`; `Alpha` → after `/check verify`; `Beta`/`GA` → after `/test`) is the suggested point to call it done; `/sync` captures conventions |

- **Next step** = the first unticked box (always a command or a tracked milestone).
- **needs a decision** = run `/architect` first; otherwise straight to `/develop` (or `/audit` for standards & tooling). The tag drops once the spec is captured.
- **Atomic build tasks live in the spec's `## Build plan`, not here**: the scope carries only the milestone rollup.
- **Status** `planned` → `in-progress` → `done`, plus `existing` (pre-workflow) and `dropped` (de-scoped, kept for history).
- **Approach tag** beside a heading (e.g. `· Facade`) overrides the project default for that feature; no tag = inherits it.
- **Workflow tier tag** beside a heading (e.g. `· GA`, `· Prototype`) sets that one feature's rigor above or below the project default; no tag inherits the default. It decides the feature's check boxes and each skill's next suggestion.
- **Workflow** (header line) is the project default, what runs after `/develop`: **Prototype** = nothing (trust develop's own build time self check); **Alpha** = `/check verify`; **Beta** = `/check verify` then `/test`; **GA** = adds a fresh model `/check review` then `/document`. A feature built on an unratified decision (an `Assumed` spec) stays flagged, but that never blocks `done`.
- **Pointer line** (`spec <n> · code in <path>`): the spec link added by `/architect`, the code path by `/develop`.
```

## Brownfield enrollment

Already built features are enrolled **for context**, above the planned ones, with status `existing` (complete, no task list) or `in-progress` (partial, finish via `/develop`), each with a code pointer. They also appear in the At a glance table.

```markdown
### A. Auth · existing
Pre-workflow auth: sign in, sessions, reset. code in `src/auth/`

### B. Product catalog · in-progress
Partial catalog; finish the remaining pieces via /develop. code in `src/catalog/`
```

`existing` is not `done`: it predates the workflow, so `/develop` and `/sync` leave it alone.

## Large product: epic split

When `scope.md` outgrows a comfortable scan (roughly a dozen plus features across clearly distinct areas), split by epic: **rename `scope.md` to `docs/scope/index.md`** (keep the At a glance table across all epics + a one line status rollup per epic, each linking its file), and **move each area's feature sections out into its own `docs/scope/<epic>.md`**. Promote **on demand**; don't split a small product early. File names are always **semantic** (`scope.md` / `index.md` / `<epic>.md`), never numbered. In a monorepo, each workspace gets its own `docs/scope/<workspace>/` the same way, with a top level `docs/scope/index.md` mapping the workspaces (one line + rollup each).

## Completion report block

Lead with what the pass produced and the first step; the approach, tier, and full list are in the scope file itself (per `docs/conventions.md`). Template:

```
## /scope <plan | replan | add> · <product, one line>

**<N> features planned (<M> already on the scope, <K> deferred), build approach <name>, workflow <tier>.**
Next: /clear, then <the first unticked box, usually `/architect <first feature>`, or `/audit` if a brownfield repo has no root AGENTS.md>
Heads up: <a feature bumped to a higher tier, a `needs a decision` foundation, or a genuine risk>   (omit if none)
Scope written to <docs/scope/scope.md>.
```

_Context hygiene: the scope, the specs, and `AGENTS.md` are the durable state, so the workflow hands off through files, not the chat. Advise `/clear` between units (after `/scope`, after each `/architect`, between features) and `/compact` mid unit if one run gets long. On Claude Code use `/clear` / `/compact`; use your agent's fresh session equivalent elsewhere._

---
name: scope
allowed-tools: Bash, Read, Grep, Glob, Write, Edit, Agent, AskUserQuestion
description: "Run /scope to turn a product idea into a living, coarse scope in docs/scope/ and keep it current: plan a new product, plan the next slice, enroll one named feature, or run with no argument to reconcile after shipping and queue what is next. Seeds WHAT to build; /architect designs, /develop builds."
---

## Output style (plain words, no dashes, no hyphens)

<!-- OUTPUT-STYLE:START -->
Write everything this skill produces, files and messages alike, in plain simple language. Talk to the reader as `you`, warm and direct like a colleague, and present every step as a recommendation they may run or skip, never an order. Keep technical terms that carry real meaning; explain each in plain words. Never use a dash or a hyphen as punctuation: no em dash, no en dash, and no hyphenated compounds. Write `read only`, not `read-only`. Say it in simple words, or reword the sentence. Code, file paths, command flags, and values other skills match on keep their hyphens. Use short sentences, commas, or parentheses. Clear beats clever.
<!-- OUTPUT-STYLE:END -->

## What this skill does

Turns an idea into an ordered, coarse, living plan and keeps it honest as the product ships. Answers what to build, in what order, how heavy, which need a decision first, not how to build one thing (that is `/architect` and `/develop`).

Scope shape, coarse and small: a slim At a glance table (`# · Feature · Phase · Status`) + feature sections grouped by phase (see `scope-template.md`). Each section: heading `### N. Name` with short tags only when they matter (`needs a decision`, an approach override, a workflow tier override like `· GA`), a 1 to 2 line intent, one `Done when:` line (acceptance criteria seeds, the WHAT), checkbox steps.

Feature shape lifecycle: not yet designed → one box, its entry command. On spec capture, `/architect` fills the built ready shape: `Design it (spec)` ticked, spec linked, `Build it: /develop <feature>` with 2 to 5 milestone sub items rolled up from the spec's `## Build plan`, then `Verify it: /check verify <feature>` and `Test it: /test <feature>`. Atomic build tasks stay in the spec's `## Build plan`, never here; every box is a command or tracked milestone. Status: in the table and beside the heading; spec and code pointers once they exist.

One command, inferred intent (`/scope [what]`, never a subcommand):
- **plan** (default): no scope yet + a product sized idea, or asking for the next slice. Full pass: ask → decompose into coarse feature sections → order + phase → write.
- **replan**: scope exists + no argument. Opens with a short where things stand readout (git branch and ahead/behind the remote, feature counts by status, and each in-progress feature's resume point) so a bare `/scope` doubles as the "where was I, what is safe to pick up" orientation, then reconciles what shipped, surfaces plan vs reality drift (code or specs with no scope row), enrolls needs surfaced during the build, reorders, and queues the next slice. The normal living rhythm, not rare: run bare `/scope` again.
- **add**: scope exists + argument names a single feature. Enroll one coarse row (intent + order + tier + Needs spec) without planning again: `/scope <a feature>`.

## Asks vs acts

Senior product engineer. Same infer / ask / recommend discipline as `/architect`: INFER what the idea states (category, obvious capabilities); ASK what cannot be inferred across business, product, go to market in batched rounds (up to 4 questions per round; see Decision panels); RECOMMEND build approach, build order, the workflow tier (project default and any per feature override), which need a spec (expert calls: present them, let the engineer override).

Never pick tools: no provider, library, ORM, host, or BaaS chosen or named; that is `/architect`'s job per feature in the spec. A feature implying a tool choice is exactly `Needs spec: yes`. Keep the scope tool agnostic so it doesn't rot.

## Decision panels (every user facing choice)

Every choice is an options panel, never a neutral menu: 2 to 4 concrete options real to this product; exactly one marked `(recommended)` with a one line why (make the call, let them override). Never add your own Other option, the picker appends a free text Other automatically; offer free text yourself only in a plain text fallback with no picker. Capability first: use the agent's picker (`AskUserQuestion` on Claude Code), else the same options as plain text; batched rounds same rule, up to 4 per round.

## Artifact ownership

`docs/scope/` is the feature scope, owned by this skill; `/architect` owns `docs/specs/`. Other skills find a feature by scanning `docs/scope/` for its row. Living document: `plan`, `replan`, `add` all edit in place (reconcile and append, never a new dated file). Writes nothing else: no specs, code, or `AGENTS.md`. `docs/scope/` holds scope files only; inventories, analyses, research docs live with the spec in its `rationale.md` (owned by `/architect`).

File shape:
- Small product: one file, `docs/scope/scope.md` (At a glance table + phase grouped sections + legend).
- Large product: epic split: `docs/scope/index.md` (At a glance table across epics + one line status rollup per epic, each linking its epic file) + one file per epic named by area (`docs/scope/auth.md`, …).
- Promote on demand: start single file; when `scope.md` outgrows a comfortable scan (roughly a dozen plus features across clearly distinct areas), rename to `index.md` (keep table + per epic rollup), move each area's sections into its own `<epic>.md`. Never split it early. Names semantic (`scope.md` / `index.md` / `<epic>.md`), never numbered.
- Keep every file coarse and small; a long epic file needs finer features and tighter intent, not a build task dump.

Status lifecycle (`/scope` sets initial status; the pipeline advances it):
- New features start `planned`. Brownfield: also enroll features that are already there as `existing` (complete) or `in-progress` (partial), the only other statuses `/scope` writes.
- `/develop` advances pipeline built work (`planned` → `in-progress` → `done`); `/sync` reconciles against the diff. A feature built on an **assumed decision** (its governing spec is `Assumed`, recorded by `/develop` when the engineer chose to build before deciding) carries an `assumed decision (spec NNNN)` note until `/architect` ratifies the decision; the note does not block `done`, it is decision debt that stays surfaced until ratified.
- `done` ≠ `existing`: `done` = this pipeline built and verified it; `existing` predates the workflow; `/develop` and `/sync` never touch `existing` rows.
- `replan` may set a feature dropped from scope to `dropped`, never deletes rows; `dropped` keeps history, excluded from active counts and work; `/develop` and `/sync` skip it.

Workflow tier (one rigor dial per feature, `Prototype` · `Alpha` · `Beta` · `GA`): how much process a feature warrants. ONE project default (recommended once, plan Step 5b, recorded on the scope header `**Workflow:**` line) and a per feature override (a tag beside the heading, e.g. `· GA`, only when a feature differs from the default; no tag = inherit). What the tier drives:
- **Design time**: higher tier → more likely `Needs spec: yes`, and the spec's cross model decision critic runs (auto at `GA`/`Beta`). `Prototype`/`Alpha` features are often `Needs spec: no`.
- **After `/develop`** (the verification tail): `Prototype` = nothing (rely on `/develop`'s own build time self check); `Alpha` = `/check verify`; `Beta` = `/check verify` + `/test`; `GA` = adds a fresh model `/check review` + `/document`.
- **What closes `done`** (the last required stage marks it): `Prototype` → `/develop` (build + self check); `Alpha` → `/check verify`; `Beta`/`GA` → `/test`. An `Assumed` spec never blocks `done`; it stays flagged as owing ratification (`/architect`) at every tier.

`/scope` recommends the project default from the risk and size of the feature mix (Step 5b), the same signals `/architect` and `/develop` read; `/develop` reads the effective tier (feature override, else project default, else inferred) to scale the next steps it recommends, so a `Prototype` project is not told to run verify and a `Alpha` project is not told to run a full review chain.

Artifact base: `docs/` by default; if `docs/` is a published docs site (`docusaurus.config.*`, `.vitepress/`, `mkdocs.yml`, Astro Starlight, or Nextra detected), use `.workflow/` (`.workflow/scope/…`). Always follow whichever base already exists (paths here assume `docs/`).

Concurrency: shared across sessions and teammates. Read again immediately before writing; surgical edits only (append rows in order, reconcile changed cells, never rewrite the file); flag rather than clobber unexpected state; append with the next free numbers so adders don't collide.

## Reference files

- `scope-template.md`: format rules, At a glance table, per feature sections (heading + intent + Done when + checkbox tasks + pointer line), brownfield enrollment and epic split shapes, the `## /scope complete` report block. Read it when writing the scope and the report.

## Portability (any OS, any agent)

Any Agent Skills client on macOS, Linux, Windows. Detection snippets are POSIX reference; use your agent's cross platform file tools. Planning runs inline; the two subagents below (Step 1 brownfield code scan, Step 6b sourcing) are optional and capability first, degrade to inline. No interactive picker: ask every panel as plain text, same options.

## Execution

### Step 0: Infer intent & idea check

No subcommand. First check whether a scope exists under `docs/scope/` (or `.workflow/scope/` if that is the artifact base), then infer:
- Scope exists + no argument (or running again, described as "reconcile / what's next") → replan behavior (`modes/replan.md`).
- Scope exists + argument names a single feature → add behavior (`modes/add.md`).
- No scope yet + a product sized idea, or scoping the next slice (including brownfield) → plan behavior, below.

Ambiguous (a new slice vs a single feature): infer the most likely reading from scope, say which behavior you chose in the report; truly unclear → one line clarifying question.

Plan behavior, no idea given (no argument, no scope to extend): stop and ask before anything else:

"What are you building? Describe the product or the slice of it you want to plan (one or two sentences about what it does and who it's for)."

Wait for the answer; use it as the product idea.

### Step 1: Load the inferred behavior

After Step 0 infers the behavior, read exactly one mode file and follow it:

- `modes/plan.md` for plan behavior (new scope, product sized idea, or next slice planning).
- `modes/replan.md` for replan behavior (scope exists and no argument).
- `modes/add.md` for add behavior (scope exists and the argument names one feature).

Do not read the other mode files unless the inferred behavior changes. All common rules above still apply, and `scope-template.md` remains the format reference for any write/report.