---
name: figure-it-out
description: "더 좁은 것이 맞지 않을 때 감사 가능한 플레이북을 설계하세요: 대규모 마이그레이션, 야심 찬 다중 부분 변경, 또는 인간이 떠난 후 검토하는 작업. 작업에 맞게 엄격성을 조정하고, 가설 루프를 실행하고, 결정을 로깅합니다. /figure-it-out 또는 'figure it out'에 사용하세요."
disable-model-invocation: true
---

# Figure it out

작업이 어떤 플레이북과도 일치하지 않을 때 하나를 설계하세요. 코드 이전의 제공물은 워크플로우 자체입니다: 작업에 맞게 엄격성을 조정하고, 과학적 방법을 실행하고, 인간이 떠난 후 감사할 수 있는 결정 추적을 남기는 단계 시퀀스.

## 시작

**poteto-mode** 스킬의 Principles 섹션을 읽는 것이 첫 번째 항목인 투두리스트를 여세요. 그런 다음 아래 단계를 투두로 추가하세요.

## 단계 A: 프레임

먼저 기반을 다지고, 그 다음 커밋하세요. 다음을 진술할 수 있을 때까지 실행을 시작하지 마세요:

- 반증 가능한 술어로서의 완료 정의 (**prove-it-works** 원칙 스킬).
- 정량화된 범위: 대략적인 단위와 노력, 그리고 기반 다지기가 표면화한 차단 요소.
- 높게 편향된 엄격성 수준. 단방향 도어와 높은 폭발 반경은 더 많이 받습니다. 가역적인 저위험 단계는 덜 받습니다. 엄격성은 게이트와 아티팩트이지 "더 열심히 노력"이 아닙니다.

긴 실행에 커밋하기 전에 프레이밍과 트레이드오프를 제시하세요. 가역적 작업은 진행됩니다 (**never-block-on-the-human** 원칙 스킬), 그러나 여러 시간의 실행은 하나의 체크포인트를 받습니다.

## 단계 B: 워크플로우 설계

원자적이고 독립적으로 착륙 가능한 단위로 분해하세요. 가장 위험한 미지수를 먼저 시퀀싱하세요. 기능 이전에 스캐폴드와 검증이 옵니다 (**foundational-thinking** 원칙 스킬).

- 작업 전에 검증 하니스를 빌드하세요. 변경 전 상태에서 캡처된 베이스라인으로, 검사가 "이전 값 대 새 값"으로 읽히도록.
- 단방향 도어 설계 결정의 경우 **architect** 스킬을 실행하세요 (그것은 **arena**를 실행합니다). 형태가 이미 구체적인 기계적 작업은 건너뛰세요. 정착된 설계에 대한 두 번째 arena는 과도한 엔지니어링입니다 (**laziness-protocol** 원칙 스킬).
- 무엇을 팬 아웃할지 결정하세요. 솔기에서만 병렬화하고 각 워커에게 자체 워크트리 또는 브랜치를 제공하세요 (**separate-before-serializing-shared-state** 원칙 스킬). 과도하게 팬하지 마세요. **poteto-mode** 스킬의 Subagents 섹션에 따라 작업에 대한 각 서브에이전트의 추론 수준과 빠른 또는 표준 속도를 선택하세요.
- 설계된 단계 목록을 작성하세요. 그 목록이 인간이 검토하는 것입니다.

그런 다음 설계를 실행하세요. 단계 C와 단계 D 항목 사이의 구체적인 항목으로 투두리스트에 단계를 추가하세요. 단계 C 루프 규율 하에 각각을 실행하고, 각 단계가 착륙할 때 행으로 단계 D 로그를 엮습니다. 끝까지 전체 추적을 저장하는 대신.

## 단계 C: 루프 실행

각 단위는 실험입니다. 가설을 진술하고, 가장 작은 변경을 하고, 실제 아티팩트에 대한 술어에 대해 측정하고, 진전했다면 유지하고, 하지 않았다면 되돌립니다. **sequence-verifiable-units** 원칙 스킬을 적용하여 끝에 검사를 배치하는 대신 다음 단계를 시작하기 전에 각 단위를 검증하세요.

- 자체 보고가 아니라 아티팩트를 검사하여 검증하세요. 무언가가 너무 쉽게 통과하면 시스템보다 관찰 방법을 의심하세요.
- 위임된 작업을 판정자와 쌍으로 묶으세요. 워커가 게이트를 게임하면 재설정하고 계약을 강화하세요. 게이트 자체가 잘못되었다면 게이트를 우회하는 대신 자체 변경으로 게이트를 수정하세요.
- 평결은 VERIFIED, NOT VERIFIED 또는 INCONCLUSIVE입니다. Inconclusive은 통과가 아닙니다. 부정적인 것을 숨기지 마세요.

## 단계 D: 감사 추적 유지

**show-me-your-work** 스킬을 통해 실행을 로깅하세요. figure-it-out의 작업은 일반적으로 리뷰어가 PR에서 읽을 수 있도록 추적을 커밋할 만큼 충분히 야심 찹니다. 추적 플러스 diff가 인간이 돌아와서 작업을 신뢰할 수 있게 하는 것입니다.

## 단계 E: 검증 및 반환

하니스뿐만 아니라 실제 제품에 대한 단계 A 술어에 대해 전체를 확인하세요. 게이트, 린트 규칙, 검사 또는 스크립트로 반복되는 수정을 인코딩하세요 (**encode-lessons-in-structure** 원칙 스킬).

**Reply:** 설계한 플레이북, 엄격성 수준과 이유, 결정 추적 경로, 술어에 대해 검증된 것, 그리고 여전히 열려 있는 것.