Menú
Jira/Figma/사진 근거를 바탕으로 작업을 만들거나 시작할 때, Jira 작성, Jira 확인, 스펙 작성, 구현, 개선, 검증 순서를 강제하는 공통 프론트엔드 작업 게이트입니다.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | jira-design-implementation-workflow |
| description | Jira/Figma/사진 근거를 바탕으로 작업을 만들거나 시작할 때, Jira 작성, Jira 확인, 스펙 작성, 구현, 개선, 검증 순서를 강제하는 공통 프론트엔드 작업 게이트입니다. |
Jira, Figma, 사진, 스크린샷을 근거로 프론트엔드 작업을 작성하거나 시작할 때 사용하는 선행 워크플로입니다.
이 skill은 실제 구현을 담당하지 않습니다. 구현 전에 필요한 근거 확인과 순서 게이트를 고정하고, 이후 작업 유형에 맞는 기존 workflow로 넘깁니다.
다음 요청이 있으면 먼저 이 skill을 사용합니다.
단순 오탈자, 문구만 바꾸는 변경, 이미 확인된 작은 문서 수정에는 강제하지 않습니다.
먼저 다음 근거를 확인합니다.
Jira issue type, parent 참조, 하위 작업 분해, 본문 템플릿은 docs/workflows/jira-issue-authoring.md와 templates/jira-issue-template.md를 기준으로 결정합니다.
근거가 부족하고 repo나 Jira에서 확인할 수 없으면 Jira를 작성하기 전에 질문합니다.
구현 전에 다음을 짧게 정리합니다.
Jira와 Figma/사진이 다르면 구현 전에 차이를 보고하고, 어떤 기준으로 진행할지 확인합니다.
변경 범위별 Jira key:
| 변경 범위 | Jira project key |
|---|---|
| root, docs, CI, repo workflow | DCMFE-* |
| client web | DCMCL-* |
| design-system web | DCMDS-* |
| design-system package | DCMDS-* |
디자인시스템 package와 design-system web은 같은 DCMDS-* project를 사용하고, 필요한 경우 Jira Component 또는 label로 surface를 구분합니다.
Jira 확인 후 실제 구현 workflow를 선택합니다.
| 작업 유형 | 다음 skill | 절차 |
|---|---|---|
| 디자인시스템 컴포넌트 | design-system-component-workflow | recipes/add-design-system-component.md |
| 페이지 또는 라우트 | page-feature-workflow | recipes/add-page.md |
| 앱 shared 컴포넌트 | app-shared-component-workflow | recipes/add-app-shared-component.md |
| 앱 로컬 컴포넌트 | refactor-evaluator 또는 가까운 컴포넌트 절차 | recipes/add-component.md |
| API 조회 또는 변경 요청 | api-integration-workflow | recipes/add-api-query.md |
| 폼, 검증, submit 흐름 | form-flow-workflow | recipes/add-form.md |
| Turbo generator 추가/수정 | turbo-generator-workflow | docs/workflows/turbo-generators.md |
| 검증 또는 PR 전 확인 | frontend-quality-verification | docs/workflows/local-development.md |
docs/workflows/spec-writing.md 기준으로 스펙 필요 여부를 확인합니다.
스펙이 필요한 경우:
스펙에는 최소한 목적, 사용 위치, public API 또는 입력, 상태, 동작, 검증/에러, 스타일 제약, 접근성, 검증 방법을 적습니다.
구현 직후 바로 마무리하지 않고 다음을 확인합니다.
docs/code-quality/frontend-fundamentals.md, 개별 기준 문서, 필요 시 docs/code-quality/frontend-logic-composition.md로 가독성, 예측 가능성, 응집도, 결합도, 로직 구성을 점검했는가비자명한 프론트엔드 구현, shared/public API 변경, PR 전 품질 점검에는 frontend-fundamentals-review를 추가로 적용합니다.
최종 요약에는 다음을 남깁니다.
작업 착수 시:
## Jira/Figma 작업 게이트
- Jira:
- 디자인 근거:
- 작업 유형:
- 필요한 스펙:
- 다음 워크플로:
- 확인 필요:
작업 완료 시:
## 완료 요약
- Jira:
- 변경:
- 검증:
- 남은 리스크:
endpoint 문서를 기준으로 API helper, TanStack Query hook, 타입, 에러/cache 동작을 구현할 때 사용합니다.
apps/client, apps/market-owner, apps/design-system-web, 선택적 apps/admin 내부의 앱 전용 shared 컴포넌트를 생성, 스펙 작성, export, 검증할 때 사용합니다.
GitHub 브라우저 PR 리뷰에서 visible diff, review comment, check status, local verification 여부를 분리해 기록할 때 사용합니다.
packages/design-system 공통 컴포넌트를 Figma/이미지/상태 요구사항 기반으로 생성, 구현, story/spec/export 검증할 때 사용합니다.
필드 검증, submit, mutation, error, disabled/loading/success 상태가 있는 프론트엔드 폼 흐름을 구현할 때 사용합니다.
프론트엔드 구현 또는 리뷰 중 Toss Frontend Fundamentals의 응집도 기준으로 함께 수정되는 component, hook, type, fixture, spec, form 흐름 배치를 점검할 때 사용합니다.