# Spec First Development

> Use when the user asks for actual frontend development or frontend changes based on approved planning, IA, design, or prototype screens, especially for requests like `프론트 개발해줘`, `이 화면 구현해줘`, `UI 수정해줘`, or `프로토타입 참고해서 실제 화면 만들어줘`. Update planning docs first when requirements changed, then design docs, then implement frontend code, verify locally, and keep backend work out of scope unless the user explicitly asks for a separate backend task.

- Skill: `kim-dh2417/spec-first-development` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kim-dh2417/spec-first-development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kim-dh2417/spec-first-development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: kim-dh2417 (https://skillmd.com/u/kim-dh2417)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kim-dh2417/spec-first-development

---


# Spec First Development

## Overview

Use this skill when the user wants real frontend implementation work, not just placeholder prototype coverage.

The core rule is:

`기획 -> 디자인 -> 개발 -> 검증`

Do not jump straight to code when the change affects frontend requirements, screen behavior, information structure, interaction flow, or UI rules.

## Required Order

Always apply changes in this order when relevant:

1. planning
2. design
3. frontend development
4. verification
5. optional README refresh
6. optional git actions under `ask-before-push` rules

## Planning Update

First update the planning document when the request changes frontend-facing behavior:

- feature scope
- business rules
- status definitions
- interaction rules
- frontend validation logic
- navigation or role exposure
- data interpretation rules
- upload or form rules

## Design Update

After planning, update design documents to match the new behavior.

At minimum check and update:

- screen design docs
- IA or route structure docs
- wireframes or prototype notes when they define frontend behavior
- prototype screen references when the user wants the actual frontend to follow them

## Development Update

Only after planning and design are updated, change the frontend implementation.

Typical code targets:

- `src/pages`
- `src/components`
- `src/layouts`
- `src/data`
- `src/lib`
- `src/routes` or route config files

Use existing prototype screens as a reference input when available, but convert them into real frontend pages, flows, and reusable components.

Backend scope is excluded by default:

- do not add API/server/database work under this skill unless the user explicitly asks for backend implementation
- if backend is required, treat that as a separate task or a separate backend-oriented skill

## Verification

After frontend implementation:

1. make the app runnable locally
2. check the changed flow in the browser when feasible
3. run verification commands

Default verification:

- `npm run build`
- `npm run lint`

Use `npm run dev` when UI review is needed or when the user wants to confirm the change in the browser.

Use Playwright when browser confirmation is useful and available.

## Local-Only Rule

If the user says not to commit or not to push:

- do not commit
- do not push
- keep the modified files locally
- make sure the app is viewable in the browser
- restart the dev server if needed
- tell the user the local URL

Treat phrases like these as local-only instructions:

- `커밋 하지마`
- `푸시 하지마`
- `커밋 푸시는 하지말고 보여줘`
- `로컬에서만 보자`

## README Refresh

Update `README.md` when the change materially affects:

- project status
- feature set
- route structure
- setup instructions
- implemented frontend scope

Do not update README for tiny internal refactors unless they change user-facing understanding.

## Response Pattern

When doing a feature change, describe progress in this order:

1. what changed in planning docs
2. what changed in design docs
3. what changed in frontend code
4. what was verified
5. whether commit/push is pending or intentionally skipped

## Scope Notes

- Do not update the planning docs only partially when the request clearly changes frontend behavior or user flow.
- Do not update only code when the request affects screen structure, navigation, or interaction workflow.
- Exclude `업무일지` from the required update chain.
- If the user asks only for simulation or explanation, describe the process without editing files.
- Git actions should still follow the `ask-before-push` skill.
- This skill is for actual frontend development, not just prototype placeholder creation.