feature delivery 요청에서 product planning, API contract, backend/frontend delivery engineer subagent를 오케스트레이션하고 결과를 통합할 때 사용한다. subagent가 다른 subagent를 호출할 수 없는 runtime에서 fullstack 기능 전달 오케스트레이션이 필요한 경우 사용한다.

2026-05-214

name	frontend-code-implementation-rules
description	UI, route/page, component, client state, API client, query/cache 코드를 요구사항과 설계 결정에 맞게 수정하고 구현 검증 evidence를 남겨야 할 때 사용하는 구현 규칙.

Frontend Code Implementation Rules

목적

목표:

입력된 frontend 요구사항, frontend_design_basis, API/UI 계약을 실제 클라이언트 코드로 옮기고 implementation_result를 남긴다.

성공 기준

사용자 흐름의 loading/error/empty/success 상태가 고려된다.
변경 파일과 변경 이유가 명확하다.
build/test/typecheck/browser 같은 구현 검증 evidence가 있다.
backend API 또는 infra 계약 불확실성이 분리된다.

핵심 규칙

route/page, feature/entity, component, state/API/cache 책임을 섞지 않는다.
서버 상태, 클라이언트 상태, URL 상태, 폼 상태의 소유권을 구분한다.
API error, loading, retry, cache invalidation을 계약 기준으로 처리한다.
브라우저 검증이 필요한 UI 변경은 이유 없이 생략하지 않는다.
build/test/typecheck/browser check 실패가 있으면 구현 완료로 보고하지 않는다.

Architecture Review 재작업 입력

architecture_review_result 또는 remediation_input이 입력되면 Frontend stage payload contracts의 필드를 기준으로 처리한다.

violation payload의 근거와 수정 범위를 먼저 확인한다.
requested_action 범위 안에서만 수정하고, 새 UI/API/state 설계 결정을 임의로 만들지 않는다.
수정 후 rerun_required에 적힌 build/test/typecheck/browser check를 다시 실행한다.
같은 위반이 해결되지 않거나 설계 결정 충돌이 의심되면 구현 완료로 보고하지 않고 불확실성으로 반환한다.

안티패턴

API response shape를 UI에서 임의로 만든다.
공통 컴포넌트 계약을 기능 화면 편의로 깨뜨린다.
build 통과만으로 접근성, 반응형, 상호작용 검증을 대체한다.

금지사항

architecture pass 여부를 직접 확정하지 않는다.
architecture review나 security review를 구현 검증 evidence로 대체하지 않는다.
backend persistence 정책을 frontend 코드에 숨겨 넣지 않는다.
입력에 없는 화면 또는 디자인 체계를 불필요하게 바꾸지 않는다.

검증

skill frontmatter가 현재 책임과 일치하는지 확인한다.
참조 docs 링크가 실제 파일을 가리키는지 확인한다.
이 skill에 orchestration, subagent lifecycle, scheduling 책임이 들어오지 않았는지 확인한다.