AGENT SKILL

dev

Implement a feature. Supports resuming interrupted work and team mode (--team flag). Reads spec/feature/[name]/spec.md and design.md, generates PLAN.md inside the feature directory, waits for user confirmation, then implements and verifies the feature.

License 许可
MIT
最近更新
2026-03-27
Stars
★ 3
Forks
1

01 前言 Front Matter

name
dev
context
fork
description
Implement a feature. Supports resuming interrupted work and team mode (--team flag). Reads spec/feature/[name]/spec.md and design.md, generates PLAN.md inside the feature directory, waits for user confirmation, then implements and verifies the feature.
argument-hint
[feature name] [--team]

02 资源文件 2

03 SKILL.md 正文

Prerequisite check

Before parsing arguments, verify /init has been run:

  • Check if spec/PROJECT.md exists
  • If NOT exists → output: "Project not initialized. Run /init first to analyze your codebase and set up the spec directory." → STOP

Argument Parsing

Parse $ARGUMENTS before anything else:

  1. If $ARGUMENTS contains --team:
    • Remove --team from arguments → remaining text = feature name (trimmed)
    • Set MODE = team
  2. Otherwise:
    • Feature name = $ARGUMENTS as-is
    • Set MODE = solo

Resume Protocol

Before starting, read spec/STATE.md and find the target feature's phase under ## Features.

Feature name resolution:

  • If feature name (after parsing) is provided, use it.
  • If feature name is empty, look for features with non-idle phases in spec/STATE.md.
    • If exactly one non-idle feature exists, use it.
    • If multiple non-idle features exist, list them and ask the user which to continue.
    • If all features are idle, ask the user which feature to work on.

Auto-generated spec check

After resolving the feature name:

  • Read the first 10 lines of spec/feature/[feature-name]/spec.md
  • If the file contains > DRAFT:
    • Output: "Warning: The spec for "[feature-name]" was auto-generated by /init and is marked as DRAFT. Run /spec [feature-name] to review and finalize before developing. Proceed anyway? (yes/no)"
    • If "no" → STOP
  • If the file contains > REFORGED:
    • Output: "Warning: The spec for "[feature-name]" was auto-generated by /reforge. Review with /spec [feature-name] if refinement needed. Proceed anyway? (yes/no)"
    • If "no" → STOP
  • If spec.md doesn't exist → skip (planner handles this)

Mode detection on resume:

When resuming (phase is not idle), MODE is determined by the existing PLAN.md:

  • If spec/feature/[name]/PLAN.md contains ## Team Composition → MODE = team
  • Otherwise → MODE = solo

The --team flag is only needed for fresh starts. Resume auto-detects from PLAN.md.

Approval gate contract

Planning must not transition to execution without explicit user approval.

Accepted approval replies:

  • approve
  • approved
  • yes
  • proceed

Rules:

  • If response is not an accepted approval reply, keep PLAN.md as Status: pending.
  • Do not spawn lead-engineer while status is pending.
  • If user requests changes, route back to planner and keep phase planning.

Model selection

The planner writes a ## Model Assignment section in the feature's PLAN.md with the recommended model for each agent. When spawning agents, read PLAN.md and use the assigned model:

  • planner: always sonnet (no PLAN.md exists yet at this point)
  • lead-engineer: read lead-engineer: from PLAN.md ## Model Assignment
  • verifier: always haiku (fixed — see spec/rules/_model-routing.md)

If ## Model Assignment is missing for lead-engineer, default to sonnet.

Phase-based routing:

  • existing → Feature already has code but no formal spec. Output:

    Feature "[feature-name]" was detected as existing code during /init.
    Before modifying, create a formal spec:
      /spec [feature-name] "brief description"
    After running /spec, the phase updates to idle and you can run /dev normally.
    

    STOP — do not spawn any agent.

  • idle (or no entry) → Fresh start. Spawn planner (sonnet) with HANDOFF:

    • TASK: Create [team?] implementation plan for feature "[feature-name]"
    • If MODE = team: add MODE: team and include Team Composition in DONE-WHEN
    • DONE-WHEN: PLAN.md approved, CONTEXT.md created, lead-engineer spawned
    • MUST-NOT: Start implementation before user confirms, create plan without reading spec.md and design.md
    • READS: spec/feature/[feature-name]/spec.md, design.md
  • planning → Planner was interrupted. Check spec/feature/[name]/PLAN.md:

    • If Status: approved: staleness check (compare spec.md mod time vs PLAN.md Created date). If stale, warn user. If proceeding, update phase to executing and spawn lead-engineer (same as executing below).
    • If Status: pending: spawn planner (sonnet) — TASK: present pending plan for approval. MUST-NOT rewrite from scratch. READS: PLAN.md only.
    • If PLAN.md missing: spawn planner same as idle above.
  • executing → Lead-engineer was interrupted. Read model from PLAN.md, spawn lead-engineer ({model}) with HANDOFF:

    • TASK: Resume implementing feature "[feature-name]" (skip completed tasks)
    • DONE-WHEN: all tasks [x], tsc passes, verifier L1-3
    • MUST-NOT: re-do [x] tasks, modify spec.md/design.md
    • READS: spec/feature/[feature-name]/PLAN.md, CONTEXT.md
  • verifying → Verifier was interrupted. Spawn lead-engineer ({model from PLAN.md}) — not verifier directly, because lead-engineer manages the auto-fix budget across sessions.

    • TASK: Resume verification for feature "[feature-name]" (re-run verifier)
    • DONE-WHEN: verifier L1-3 pass, L4 human-verify presented
    • MUST-NOT: re-implement completed tasks, modify spec.md/design.md
    • READS: spec/feature/[feature-name]/PLAN.md, CONTEXT.md
  • looping → Feature is in a /loop cycle. Do NOT start /dev flow. Report to the user:

    Feature "[feature-name]" is currently in looping phase (managed by /loop).
    - To continue the loop: run `/loop [feature-name]`
    - To restart from scratch: manually set the phase to idle in spec/STATE.md, then run `/dev [feature-name]`
    

    Stop here — do not spawn any agent.


Implement the following feature:

$ARGUMENTS

04 同仓库更多 Skills

ByeongminLee
ByeongminLee/nextjs-claude-code

zustand

Zustand state management guide. Use when working with store code (src/store/**), implementing actions, managing state, or creating slices. Triggers on Zustand store development, state management questions, or action implementation.

★ 3
ByeongminLee
ByeongminLee/nextjs-claude-code

web-vitals

暂无简介

★ 3
ByeongminLee
ByeongminLee/nextjs-claude-code

vercel-storage

Vercel storage expert guidance — Blob, Edge Config, and Marketplace storage (Neon Postgres, Upstash Redis). Use when choosing, configuring, or using data storage with Vercel applications.

后端与接口
★ 3
ByeongminLee
ByeongminLee/nextjs-claude-code

vercel-functions

Vercel Functions expert guidance — Serverless Functions, Edge Functions, Fluid Compute, streaming, Cron Jobs, and runtime configuration. Use when configuring, debugging, or optimizing server-side code running on Vercel.

开发工程师后端与接口
★ 3
ByeongminLee
ByeongminLee/nextjs-claude-code

ui-ux-pro-max

UI/UX design intelligence for web and mobile. Includes 50+ styles, 161 color palettes, 57 font pairings, 161 product types, 99 UX guidelines, and 25 chart types across 10 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native, Flutter, Tailwind, shadcn/ui, and HTML/CSS). Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, and check UI/UX code. Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, and mobile app. Elements: button, modal, navbar, sidebar, card, table, form, and chart. Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode, responsive, skeuomorphism, and flat design. Topics: color systems, accessibility, animation, layout, typography, font pairing, spacing, interaction states, shadow, and gradient. Integrations: shadcn/ui MCP for component search and examples.

设计师数据分析师前端开发视觉设计
★ 3
ByeongminLee
ByeongminLee/nextjs-claude-code

turborepo

Turborepo monorepo build system guidance. Triggers on: turbo.json, task pipelines, dependsOn, caching, remote cache, the "turbo" CLI, --filter, --affected, CI optimization, environment variables, internal packages, monorepo structure/best practices, and boundaries. Use when user: configures tasks/workflows/pipelines, creates packages, sets up monorepo, shares code between apps, runs changed/affected packages, debugs cache, or has apps/packages directories.

★ 3