/feature

name: feature
description: Create a feature specification using spec-driven development
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, AskUserQuestion, mcp__context7__resolve-library-id, mcp__context7__get-library-docs, mcp__octocode__githubSearchCode, mcp__octocode__githubGetFileContent, mcp__octocode__githubSearchRepositories

/own:feature

> ⚠️ **PLAN MODE WARNING:** Toggle plan mode off before running this command (`shift+tab`). OwnYourCode commands don't work correctly with plan mode.

Create a feature specification using **Spec-Driven Development (SDD)**.

Overview

This command follows the SDD workflow: 1. **AI generates** the spec, design, and tasks for a phase based on minimal input 2. **Developer reviews** them in the dashboard (the phase's Spec / Design / Tasks tabs) 3. **Developer adds** any missing edge cases or requirements 4. **Then** implementation begins with mentorship

**Output (v2.5 — Dashboard SDD):**

• The detected `roadmap-only` phase in `ownyourcode/dashboard/dashboard-data.js` is

advanced to `specced` — its `spec`, `design`, and `tasks` objects are written in place (replacing the phase's `items[]`). No `spec.md`/`design.md`/`tasks.md` files; everything lives in `window.PROJECT`, rendered by the dashboard's tabs.

> **Schema authority:** `ownyourcode/dashboard/DASHBOARD_CONTRACT.md` defines the exact > `spec` / `design` / `tasks` shapes and the mutation rules. Read it before > writing. When this command's prose and the contract disagree, the contract wins.

**Profile-Aware Behavior:** Check `.claude/ownyourcode-manifest.json` for profile settings:

• **Junior profile** → Collaborative spec creation (mandatory design involvement)
• **Other profiles with `design_involvement=true`** → Collaborative spec creation
• **Profiles with `design_involvement=false`** → AI generates, developer reviews

---

The SDD Philosophy

> "Spec first, code second. But YOU own the judgment behind every line."

OwnYourCode uses SDD for planning, then builds with ownership — not by handing the junior a finished feature to read. **How "build" works depends on profile:**

• **Junior profile** → Phase 6 runs the Implementation Loop: the junior predicts the

judgment for each task *before* the AI reveals the code, then gets graded on the prediction. They own the code by being able to evaluate it, not by transcribing it.

• **Other profiles (v1)** → the loop is **not yet wired** for them; SDD stops at the spec

and implementation happens however that developer ships. > **Deliberate v1 scoping, not a permanent exclusion.** The loop is built for the Junior > profile first. **Interview Prep** is the strongest candidate to get it next — defending > judgment in a live review is exactly what predict-before-reveal trains — with **Career > Switcher** (rebuilding fundamentals) close behind. A future PR can extend Phase 6 to > those profiles without contradicting this copy.

---

Execution Flow

Before Asking Questions: Detect the Next Phase

Before asking the user for feature details, auto-detect which phase to spec by reading the dashboard data — there is no `roadmap.md` to parse in v2.5.

1. **Read** `ownyourcode/dashboard/dashboard-data.js` (the `window.PROJECT` object). 2. **Find** the FIRST phase in `window.PROJECT.phases` with `status: "roadmap-only"` — that is the phase to spec. 3. **Auto-select** it — no asking, keep it simple. Capture its `n`, `name`, `slug`, and `items[]` (the planned scope you'll expand into a full spec).

**Status meaning (see contract §3.4 / §5):**

• `"roadmap-only"` → planned, not yet specced (has `items[]`, no spec/design/tasks)
• `"specced"` → already specced (skip — `/own:feature` already ran for it)
• `"complete"` → done

**If a `roadmap-only` phase is found:**

📍 Detected from your roadmap: Phase [n] — [name]

This phase covers:
- [item 1]
- [item 2]
...

Generating the spec for this phase...

→ Proceed directly to Phase 2 (MCP Research). You will write the spec/design/ tasks into THIS phase object in `dashboard-data.js`.

**If `dashboard-data.js` is missing or has no `phases`:** → The project isn't initialized. Tell the user to run `/own:init` first.

**If ALL phases are `specced`/`complete` (no `roadmap-only` left):** → Congratulate them! Then ask what they want to build next (a new phase can be appended to `window.PROJECT.phases` with `status:"roadmap-only"`).

---

Phase 1: Core Requirements (Minimal Input)

Ask only what's needed to generate specs:

**1a. Feature Name:** > "What are you building? Give it a short name (e.g., 'login form', 'user settings', 'dark mode')."

Generate slug: `login-form`, `user-settings`, `dark-mode`

**1b. One-Line Description:** > "In one sentence, what does this feature do?"

**1c. User Story (Keep it simple):** > "Complete this: As a [user type], I want to [action] so that [benefit]."

Push back ONLY if they skip the 'so that' part — that's the value.

---

Phase 2: MCP-Powered Research (MANDATORY: Use BOTH)

Before generating specs, gather intelligence using **BOTH** MCPs. Never rely on just one source.

Context7 — Official Documentation (ALWAYS USE)

Fetch latest docs for relevant libraries:

Use mcp__context7__get-library-docs for:
- Form handling (if form feature)
- Authentication (if auth feature)
- Data fetching (if API feature)
- State management patterns
- Latest API patterns and version-specific features

Octocode — Production Implementations (ALWAYS USE)

Search GitHub for how real apps implement similar features:

Use mcp__octocode__githubSearchCode to find:
- How popular projects implement this feature
- Common patterns and approaches
- Edge cases handled in production

Example: For "login form", search:
- "login form react" in popular repos
- "authentication flow next.js"
- "form validation typescript"

**BOTH sources are required.** If you only use one, research is incomplete.

Present research findings:

📖 Documentation (Co