Develop Feature Builder

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

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; 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). Marks a feature done only at the Prototype workflow tier (build plus its own self check; the engineer opted out of separate verification); an Assumed spec does not block this, it stays flagged as owing ratification. At Alpha/Beta/GA it leaves the feature in-progress for /check verify and /test to close, and 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 spec content or deliberates a decision (flags the need, defers to /architect); never restructures root AGENTS.md (that's /audit); new area conventions go via /sync afterwards. One narrow exception: on Build now, record it as an assumed spec (Step 0), /develop may create a spec, but only in Status: Assumed, and only the assumption record fields (owed decision, assumption built on, authorized by, code area, requirements seeds). It never writes rationale and never advances an Assumed spec past that state; /architect owns clearing it. This is the only spec /develop creates.
• One spec touch on an existing spec: 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. Never move a spec out of Assumed (that is ratification, /architect's job): an Assumed spec stays Assumed through the build even while the feature is in-progress, so it can never reach Accepted until /architect ratifies it. The feature itself can still be marked done (the engineer's call); the Assumed spec stays flagged as owing ratification, it does not block done.
• 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.

---

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 project initializer for the stack the spec names; install base dependencies (framework, core runtime, only what the first slice needs); lay out directories; confirm a dev server or build runs. Keep the repo the initializer creates (never discard it when relocating the project); if it made none and git integration is on, git init. 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: "<feature> 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.

Git integration: if the nearest AGENTS.md ## Git says integration: on, read flow/git.md and follow it (branch before building, commit as milestones land); absent or off → do no active git.