develop

name	develop
allowed-tools	Bash, Read, Grep, Glob, Write, Edit, Agent, AskUserQuestion
description	Run /develop to build a feature, UI or backend, from an approved design, a page, component, API, service, or data slice. If something load bearing is undecided and no spec records it, it stops and routes you to /architect; otherwise it reads the spec plus AGENTS.md, builds, and advances the scope.

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

Write everything this skill produces, files and messages alike, in plain simple language. 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.

What this skill does

The builder: turns a spec plus project conventions into working code. Tracks: UI (components, pages, layouts; ui-guide.md), Logical (APIs, services, data layers, business logic, integrations; logical-guide.md), or both (e.g. "auth" = sign in pages plus session logic → run both). Step 0 gates on the spec so load bearing choices (an auth approach, a payment provider) are decided in /architect, not silently invented partway through the build.

Asks vs acts

Gates, then acts: no upfront question rounds like /architect. Read the decision, build, ask only what the design left open (the visual direction when no reference was given; a business rule the spec didn't settle). Infer from the spec, AGENTS.md, and codebase; ask only what can't be inferred; recommend local implementation choices.

Artifact ownership

• Writes app code (plus CSS/tokens for UI).
• Scope (docs/scope/): only the Step 4 touches (feature status → in-progress, milestone sub boxes, Build it box, code pointer). Never marks a feature done (waits for /check verify and /test), never ticks Verify it or Test it, never creates files in docs/scope/ (scopes only; analysis/research is /architect's, in the spec's rationale.md).
• Never writes specs (flags the need, defers to /architect); never restructures root AGENTS.md (that's /audit); new area conventions go via /sync afterwards.
• One spec touch: the **Status**: line (umbrella decision → the index.md's, never a child's), plus filling the feature's spec pointer line. Build start: Proposed → In Progress; build lands (feature → done): In Progress → Accepted (a spec is not Accepted until its feature ships). Never edit spec content, only that line, surgically: read it again right before writing; unexpected state (already Accepted, Superseded) → flag, don't clobber.
• Artifact base: docs/ by default, .workflow/ if docs/ is a published docs site. Read from whichever exists (paths here assume docs/).
• Shared scope: read it again right before ticking, edit only the specific checkbox, status, or pointer line (never rewrite the file); feature not as expected (already done, reworked) → flag, don't overwrite. The freshness check guards against rebuilding what a teammate shipped.

---

Portability (any OS, any agent)

Any Agent Skills client, macOS/Linux/Windows. Detection snippets are POSIX reference; use your agent's own cross platform file tools. Builds inline on the main thread (Step 3); the only subagents are a read only scout that explores code (Step 2.5) and a read only researcher for a doc check (Step 2.6, degrading to building from knowledge without web capability), both on the cheapest model. Bundled guides (ui-guide.md, logical-guide.md, checklist.md) and the build flow after the gate (flow/build.md) are paths relative to this skill's folder; the main thread reads them. No interactive question picker → ask the prompts as plain text with the same options.

Execution

Before you build: the project must already exist (except the scaffold task)

Exception: if this IS the scaffold sub task of the Stack and architecture foundation feature (prompt says scaffold, or the step initializes the project from the stack spec), creating the project IS the job. Read the ARCHITECTURE spec's ## Proposed stack; run the framework's own init (create-next-app, cargo new, etc. per that stack); install base dependencies (framework, core runtime, only what the first slice needs); lay out directories; confirm a dev server or build runs. Scaffold steps derive from the stack decision (a decision spec has no build plan). Install just in time: NOT every library the spec names (email, monitoring, and so on); each later feature installs its own when built; only cross cutting tooling (lint, format, type strictness) comes early, via /audit + the tooling task. Then proceed.

Otherwise /develop builds into an existing project. No skeleton (no package.json/pyproject.toml/go.mod/manifest, no source tree) and not the scaffold task → stop:

No project found to build into. Run the scaffold step first (the Stack and architecture feature's scaffold sub task, per your architecture spec), then run /develop again.

A project exists (even a bare scaffold) → proceed.

Before you build: freshness & collaboration (don't build on stale state or over a teammate)

Before mutating anything (skip silently if solo, offline, or not using git): git fetch quietly; base = main, else master; behind count (git rev-list --count HEAD..origin/<base>); uncommitted work (git status --short).

• Behind (count > 0) → stop and warn: "You're N commits behind origin/$BASE. A teammate may have already changed or shipped this. Pull first, then run again."
• Uncommitted work in the area you'll touch → warn: "You have uncommitted changes here. Commit or stash first so this build doesn't tangle with them." Let them proceed if they insist.
• Feature in-progress in the scope AND its code area (pointer line's path) has recent commits by another author (git log --format='%an' -- <area>) → warn: " looks like it's partway through the build by someone else. Coordinate before continuing it." Confirm before proceeding.

Warnings, not hard blocks, but surface them.

Step 0: The spec gate (always first)

Is a decision owed and unrecorded? The test:

To build this, would you have to invent something the engineer hasn't decided?

If yes, stop and route to /architect (its spec is the build spec; /develop implements decisions, it doesn't make them). You'd have to invent:

• A provider, library, integration, data model, or cross cutting pattern (e.g. auth provider, DB/ORM, caching strategy).
• A whole UI page or screen: its design system (design.md there? if not, which direction?), sections/composition, component inventory, asset strategy (no screenshot, no repo images → e.g. an online source). Owed unless a design.md AND a page level spec pin these down.
• A feature's behavior (search, a wizard: "what exactly should it do?" is open; /architect asks those questions). Owed unless a spec defines it.

NOT owed for pure implementation already specified: a small bug fix, a component matching an existing design.md, wiring already decided pieces, a copy tweak, anything an existing spec/design.md/AGENTS.md governs.

Don't hardcode to page names; apply the invent test to whatever was asked (a "home page" or "search filter" fails on a fresh project, passes once a spec/design.md exists). False negatives are the failure mode, building a real decision without noticing (what "just build the home page" looks like): when unsure, treat as owed and ask (panel below).

Read only what this feature needs, never the whole docs/ tree: its one scope file and its one governing spec (single file, or umbrella index.md plus the one child speccing this sub task). No other features' rows, scope files, workspaces, or unrelated specs.

Check, in order:

1. Locate this feature's scope file (only that one). Monorepo → docs/scope/<workspace>/ for the task's package. Pick the file (scope.md, or the matching <epic>.md in a split) from the At a glance table alone; read just this feature's section. needs a decision with no spec pointer yet → decision owed and missing. Malformed → flag and ask, don't guess.
2. Open the governing spec via the feature's spec pointer, reading only its build spec sections as defined in the build flow (flow/build.md), Step 2 item 1. Found → it's the spec; proceed. No pointer and no linked spec → targeted look in docs/specs/<workspace>/ for one matching this feature's scope, never a blanket read.
3. The nearest AGENTS.md (workspace/area) may already capture the decision, synced from an earlier feature (e.g. "the auth provider is already chosen") → proceed without a new spec.

Decision owed and unrecorded → don't guess, don't silently stop. Ask (single select; AskUserQuestion on Claude Code):

• question: "This looks like it needs an architecture decision first: <name the specific load-bearing choice, e.g. 'which auth provider + session model'>. How do you want to handle it?"
• header: "spec first?"
• options:
  1. Architect it first: "Recommended. Capture the decision in a spec before building, so the build has a spec." → end here with the handoff below. Do not build.
  2. No, not needed: "I've judged there's no real decision here; build directly." → proceed to the build flow (flow/build.md).
  3. Skip for now: "Build it without a spec; I'll backfill the decision later." → proceed to the build flow (flow/build.md), leaving the feature's Needs spec? = yes with a ⚠ spec pending note in the scope (docs/scope/).

The tool appends "Other" as a free text option automatically.

On Architect it first, end with:

Run this next, then come back to /develop:

/architect <feature>: <the specific decision to settle>

Once the spec exists, run /develop <task> again and I'll build to it.

No decision owed (pure implementation) → skip the question, proceed.

Build flow (Steps 1-4)

Once the gate clears (no decision owed, or the engineer chose No, not needed / Skip for now), read flow/build.md and follow its Steps 1-4: classify the track, load the decision and conventions, explore, optional doc check, build, then update the scope and report. Do not read flow/build.md when the gate ends the run (Architect it first, no build).

---

Reference files

• Build flow after the gate (Steps 1-4): flow/build.md
• UI build track: ui-guide.md
• Logical build track: logical-guide.md
• Accessibility checklist (UI track, Phase 5): checklist.md
• Project design system (UI track): ./design.md