요구사항 및 설계

제품 책임자가 intent.md를 승인하면, Claude는 이를 받아 요구사항 및 설계 명세서를 작성합니다. 이 과정은 브랜드, 보안, 컴플라이언스, UX에 대한 조직의 스킬에 따라 진행됩니다.

제품 책임자는 해당 명세서를 검토하지만 직접 작성하지는 않습니다. 이 프로세스의 목표는 엔지니어링 팀이 계획을 세울 수 있는 명세서를 만들고, 우려되는 부분을 표시하는 것입니다.

프런트엔드 작업이 가장 명확한 예시입니다. intent.md가 승인되면, 제품 책임자는 intent.md를 바탕으로 Claude Design에서 디자인 목업을 만들고, 목업을 반복 수정한 다음, 이를 Claude Code로 내보내 빌드합니다.

달라지는 점

시작하기

• 전제 조건: 브랜드, 보안, 컴플라이언스, UX 정책을 스킬로 작성한 intent.md 파일을 작성합니다.
• 인프라: Claude에 접근할 수 있는 제품 책임자. 엔지니어링 역량은 필요하지 않습니다.

실행 방법

1. 제품 책임자는 조직의 스킬을 사용할 수 있는 세션을 열고 intent.md를 첨부합니다.
2. 제품 책임자의 프롬프트는 intent를 가리키고, 제약 조건을 명시하며, 우려 사항을 표시하도록 요구합니다. 처음에는 수동으로 실행한 다음, 이를 조직 수준의 슬래시 명령으로 체계화합니다. 그런 다음 intent 홈에서 intent.md의 승인을 트리거로 삼아, 병합 시 실행되는 비대화형 작업이 조직의 스킬을 로드한 상태로 패스를 실행하고 spec.md를 풀 리퀘스트로 커밋하도록 합니다(배관 작업은 5단계: 배포의 CI/CD 플레이에서 다룹니다). 이 시점부터 제품 책임자의 첫 관여는 검토입니다.
3. 동일한 제품 책임자가 아이디어에 비추어 명세서를 검토합니다. 명세서가 제시된 문제를 해결하는지, 그리고 intent.md에서 제기된 미해결 질문들이 답변되었거나 이어지고 있는지 확인합니다.
4. 표시된 우려 사항을 먼저 처리합니다. 이는 분석가라면 상부에 보고했을 지점이기 때문입니다. 제품 책임자는 엔지니어링 팀이 명세서를 보기 전에 각 정책 담당자와 함께 각 사항을 해결합니다.
5. spec.md를 intent.md와 함께 커밋합니다. 이 파일 쌍은 무엇이 요청되었고 무엇이 결정되었는지를 기록합니다.
6. 제품 책임자는 명세서와 intent가 빌드 단계로 진행할지 여부를 결정하며, 조직이 더 높은 위험으로 분류하는 사항에 대해서는 기술 리드와 상의합니다. 이 판단은 항상 사람인 팀원이 내리며, 명세서를 승인하는 것이 3단계: 빌드의 계획 모드 플레이를 시작하는 계기가 됩니다.

실제 모습

프롬프트:

이 예시의 배경이 되는 intent.md는 고객이 포털에서 청구 상태를 확인할 수 있기를 원하는 보험사에서 나온 것입니다. 여기서 claims-api는 포털의 백엔드이고, claims-core는 청구 정보를 보유한 더 오래된 내부 시스템입니다. 위의 프롬프트는 이를 다음과 같은 spec.md로 변환합니다:

# Spec: claims status self-service
From: intent.md (J. Ortiz, claims operations). Status: ready for product owner review.
Skills applied: secure-api-review, brand-voice, portal-ux.

## Requirements
- R1. A signed-in customer sees status, next step and expected date for each open claim.
- R2. Status is one of four states: received, in review, approved, paid.
- R3. The response carries those three fields and nothing else.
- R4. What the customer sees is at most 60 seconds old.

## Design
- New endpoint GET /claims/{id}/status in claims-api, behind the gateway JWT.
- claims-api reads the claim from claims-core. The portal never calls claims-core.
- New StatusPanel on the portal claims page. It caches each answer for 60 seconds.

## How each constraint in the intent is met
| Constraint | Met by |
| :---- | :---- |
| No new PII in the portal session | R3. None of the three fields is tagged pii in the schema. |
| Existing authentication only | The gateway JWT. No new login, token or role. |

## Open questions from the intent
- Do third-party loss adjusters need access too? Not answered. Carried forward as concern 1.

## Areas of concern
1. Loss adjusters have no portal account. Giving them access breaks "existing
   authentication only", so they are left out of this spec. Owner: security.
2. The portal-ux skill says every status shows a date. The brand-voice skill says
   never to state a payment date as a commitment. I cannot satisfy both as written.
   Proposed label: "Estimated date". Owner: compliance.
3. claims-core allows 50 requests a second. The 60-second cache should keep the
   portal under that, but nobody has load tested it. Owner: claims-core team.

요구사항에는 번호가 매겨져 있어 계획과 검토에서 이를 인용할 수 있습니다. 우려 사항 2는 두 스킬을 서로 충돌시키는데, 이는 프롬프트가 Claude에게 표시하도록 지시한 종류의 충돌입니다.

거버넌스 고려사항

정책 충돌이 몇 주 후 검토 과정에서 발견되는 대신, 명세서가 작성되는 동안 현재 정책이 읽히고 적용됩니다. 조직의 스킬은 명세서에 대한 제약 조건으로 적용됩니다. 명세서, 이를 생성한 프롬프트, 그리고 적용된 스킬 버전은 모두 버전 관리 시스템에 기록됩니다. 제품 책임자는 명세서를 승인하고, 표시된 우려 사항을 지정된 정책 담당자에게 전달합니다.

측정 방법

• 선행 지표: 동일한 변경 사항에 대한 intent.md 커밋과 spec.md 커밋 사이의 경과 시간(두 Git 타임스탬프)을, 기존의 요구사항 및 설계 주기와 비교합니다.
• 후행 지표: 빌드 시작 후 발생하는 요구사항 재작업. 동일한 변경 사항에 대한 첫 번째 plan.md 커밋 이후 날짜가 찍힌 spec.md 커밋 수를 셉니다. Git 로그에서 바로 확인할 수 있습니다.