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.