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

2026-05-214

name	backend-code-implementation-rules
description	백엔드 코드를 요구사항과 설계 결정에 맞게 수정하고 compile/test/typecheck 같은 구현 검증 evidence를 남겨야 할 때 사용하는 구현 규칙.

Backend Code Implementation Rules

목적

목표:

입력된 backend 요구사항과 backend_design_basis를 실제 코드 변경으로 옮기고 implementation_result를 남긴다.

성공 기준

변경 파일과 변경 이유가 명확하다.
Source of Truth와 backend_design_basis가 구현에 반영된다.
compile/test/typecheck 같은 구현 검증 evidence가 있다.
frontend 또는 infra로 넘길 계약 불확실성이 분리된다.

핵심 규칙

요구사항과 명시적 제외사항 밖으로 범위를 넓히지 않는다.
domain, application, storage, external, app 계층 책임을 섞지 않는다.
transaction, consistency, exception, security 정책을 docs 기준으로 보존한다.
compile/test/typecheck 실패가 있으면 구현 완료로 보고하지 않는다.

Architecture Review 재작업 입력

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

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

안티패턴

backend_design_basis의 결정과 다른 구조로 구현한다.
테스트를 맞추기 위해 domain policy를 우회한다.
frontend 표시 편의를 backend domain 책임으로 끌어온다.

금지사항

architecture pass 여부를 직접 확정하지 않는다.
architecture review나 security review를 구현 검증 evidence로 대체하지 않는다.
입력에 없는 파일을 불필요하게 수정하지 않는다.
secret, token, credential을 코드나 로그에 남기지 않는다.

검증

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