القائمة
결정 위험이 높거나 실행 범위가 크고, 신규 spec·도메인, 모호한 요구, 기존 시스템 제약, 추상화 판단을 검토할 때 사용한다.
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/SWARVY/Cadence --skill cadence-planيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
AI 행동 통제 룰. AI 가 가지는 특유의 경향(sycophancy, 즉시 편집, 자동 push, 장황한 주석, 경로 혼동, 무거운 해석 선점 등)을 의도적으로 통제한다. 사람-사람 협업에는 무관하며 AI 도구 사용 시점에만 의미가 있다. 프로젝트와 무관 (technology-agnostic).
AI와 coding, debugging, review, planning, collaboration 작업을 시작하며 승인 범위, 사용자 결정, 외부 상태 변경에 따라 진행 경계를 정해야 할 때 사용한다.
개인 회고 작성·관리 skill. 작업 완료 / PR merge·머지 직후 / 실패 / mid-PR 학습 / 룰 위반 발견 시 트리거. 회고 가치와 처리 상태를 닫고 recurring 패턴의 룰화 승급을 검토해야 할 때 사용한다.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | cadence-plan |
| description | 결정 위험이 높거나 실행 범위가 크고, 신규 spec·도메인, 모호한 요구, 기존 시스템 제약, 추상화 판단을 검토할 때 사용한다. |
플랜 단계 결함 패턴 사전 차단용 4개 mandatory 정확도 체크. 회고에서 반복적으로 발견된 플랜 단계 실패 모드를 룰화한다.
4개 체크는 mandatory다. 4번의 사용자 게이트는 mandatory가 아니다.
다음 중 1+ 조건 충족 시 mandatory:
압축 대상: 결정 위험이 낮고 실행 범위도 작은 명백한 수정은 체크를 내부적으로 축약하고 결과만 보고한다.
제외 대상: 1줄 fix, 봇 follow-up, props 미세 조정, 명백한 typo.
4개 영역은 정확도를 위한 내부 체크다. 각 영역의 종료는 사용자 게이트 사유가 아니다. 사용자에게 보이는 게이트는 using-cadence가 소유한다.
Context ─┐
Options ─┼─ 내부 정확도 체크 ─→ 승인 범위 안이면 계획·편집·검증 지속
Risk/OoS ┤
Verify ──┘
└─ 새 사용자 선택이 생길 때만 보고 후 정지
다음 경우에만 체크 결과를 decision gate로 올린다.
단순히 context → options → risk → verification으로 phase가 바뀐다는 이유로 멈추지 않는다. 계획 전용 요청은 계획 산출물에서 끝나고, 구현 요청은 합의된 승인 범위 안에서 로컬 편집과 검증까지 이어간다.
결정 위험은 낮지만 실행 범위가 크면 사용자 게이트 대신 다음 경로를 사용한다.
표본 기준이나 예외 처리에 새 사용자 선택이 있을 때만 보고 후 정지한다.
플랜 작성 전 다음 4가지를 모두 확인한다.
docs/retrospectives/INDEX.md 가 있으면 카테고리 매칭으로 관련 회고 발굴Explore subagent 에 위임 ("관련 회고를 찾아 takeaway 를 정리해줘")기존 코드/문서/디자인/계약이 있는 영역을 수정할 때는, 사용자 요청의 문자 그대로를 바로 구현하지 않고 먼저 같은 시스템 안의 가장 가까운 선례와 대조한다.
순서:
발동 신호:
예시:
이 게이트는 기존 시스템을 무조건 정답으로 보라는 뜻이 아니다. 기존 시스템은 기준점이고, 사용자 명시가 그 기준을 의도적으로 바꾸는 요청일 수도 있다.
대표 통점: "기존 X 컴포넌트 재사용 가능?" 을 사용자 확인 지점에 두면 grep 으로 못 찾는 자체 모듈을 한 답변으로 발견 (분산 호출 패턴은 name 검색만으로 안 잡힘).
기존 X 재사용 가능? 확인 지점을 포함 — 사용자 지식이 grep 보다 빠를 때 많음. 단, 특정 다지선다 도구로 묶지 말고 자유 응답을 열어둔다.AST 검색 / 의존 그래프 분석 / 외부 contract 변경 감지 같은 도구별 자동화 (예:
ast-grep,knip,openapi-diff등) 는 별도 stack-특화 skill repo 또는 프로젝트 hook 에서 다룬다. cadence 본 repo 는 수동 검색 절차 만 정의.
done ≠ 구현 완성)스펙시트 status: done 은 그 PR 시점에 닫혔다 는 뜻이지 모든 분기/매핑이 코드에 반영됐다 는 보장이 아니다. 다분기 매핑(N라벨 표 등)은 stub(예: 단일 필드만 반환)으로 닫히기 쉽다.
done 스펙 영역을 건드릴 때 spec 본문 ↔ 실제 구현 함수를 대조한다. 스펙의 라벨/분기 표가 실제 코드에 다 있는지 해당 함수를 직접 읽는다.done 스펙에 닫혀 있는데 실제 formatter 는 raw status 만 반환하는 stub → 특정 상태에서 이전 라벨이 그대로 노출.단일 안 갇힘은 회고에서 반복 발견되는 실패 모드 (premature abstraction, stale spec 가정, 단일 결정 단정 톤). 다음을 강제한다.
실질적 대안 없음으로 닫는다.플랜 작성 후 자문한다. 결정 위험이 있는 작업은 답을 플랜에 적고, 낮은 위험 작업은 내부 확인으로 충분하다.
"반대 가정이 사실이라면? 이 결정이 틀렸을 가능성은?"
예시:
사용자에게 선택을 요청해야 할 때는 비교 산출물이 실제로 선택 가능한 상태인지 먼저 확인한다.
대표 증거:
사용자가 결과를 확인할 수 없는 placeholder, 0x0 렌더링, 사실상 같은 선택지로 decision gate를 열지 않는다. 이는 새 승인을 추가하는 절차가 아니라 기존 게이트의 입력 품질 조건이다.
머지 직전 발견되는 위험은 회수 비용이 크다. 계획 또는 spec 산출물이 있는 작업은 다음 3개를 명시한다. 낮은 위험의 기계적 작업은 최종 보고에 한 줄로 압축할 수 있다.
Eugene Yan 의 저렴 → 비싼 사다리 패턴 차용. 단일 layer 가 아니라 비용 효율적 escalation. 실패/disagree 시만 상위 layer 진입.
검증 layer를 고르기 전에 review unit을 정한다. plan task는 구현 순서와 인계를 위한 단위이며 자동으로 독립 리뷰 단위가 되지 않는다.
Review slice는 같은 위험·불변식·검증 증거로 함께 승인하거나 거부할 수 있는 변경 묶음이다. 다음 조건을 확인한다.
| 변경 성격 | 기본 증거 | semantic review |
|---|---|---|
| 문구·경로·format·기계적 이동 | 정적 검사, diff 표본, 관련 test | 기본 생략 |
| 같은 불변식을 공유하는 구조·통합 변경 | 관련 test, typecheck/build, 경계 검색 | slice 완료 후 targeted 1회 후보 |
| 공개 계약·보안·데이터·migration | 계약 증거, 실패 경로, rollback 조건 | 위험 경계마다 targeted 1회 |
| 여러 slice가 누적된 큰 변경 | 전체 회귀, 실제 runtime, 교차 경계 확인 | 누적 위험이 있을 때 whole-change 1회 |
reviewer 호출 수를 plan task, phase, commit 수에 맞추지 않는다. 하위 workflow가 task마다 review를 요구해도 사용자가 그 topology를 명시적으로 요청하지 않았다면 이 preflight 결과로 조정한다. 리뷰 단위와 위험 경계 회고
| Layer | 비용 | 자동/조건부 | 도구 예시 |
|---|---|---|---|
| L1. 결정론 (mechanical) | 토큰 0 | 자동 (post-edit hook 권장) | tsc / oxlint / oxfmt / ruff / build |
| L2. cheap semantic | 저토큰, 1회 | 조건부 후보 (완료 보고 전 검토) | 1차 보조 AI review (스펙 정합) — feedback_crosscheck 의 주 도구 → 보조 도구 1 |
| L3. consensus | 중토큰, 조건부 | L2 disagree / 의심 시만 | 다른 모델 family 또는 PR review bot — 다중 리뷰 경로 합의 |
| L4. 수동 inspection | 사람 시간 | L3 도 미해결 시 / 핵심 결정 | 사용자 직접 판단, 독립 리뷰의 플랜 텍스트 비판 |
agent 수와 검토 횟수 자체는 신뢰도의 증거가 아니다. 기본 경로는 주 작업 경로 1개와, 필요할 때의 독립 semantic 검토 1개다.
여기서 게이트는 다음 검증 layer로 진입하는 내부 조건이다. 새 사용자 선택이 없으면 사용자 turn을 요구하지 않는다.
| 결정 위험 | 실행 범위 | 적용 layer |
|---|---|---|
| 낮음 | 작음 | L1 |
| 낮음 | 큼 | dry-run / 표본 검토 + L1 |
| 높음 | 작음 | L1 + 필요 시 targeted L2 |
| 높음 | 큼 | L1 + L2 + 조건부 L3 + 핵심 결정의 L4 |
이 사다리는 단일 모델 편향 회피 (feedback_crosscheck) 와 결합해 비용 효율적 다각도 검증 을 보장.
플랜의 옵션 탐색 단계에 흔한 단축 경로 ("단언으로 풀자 / disable 로 막자 / types.ts 만들자 / 컴포넌트 분리하자") 가 나오면 자동 재검토 게이트 작동.
이런 코딩 판단 원칙 은 언어 / 프레임워크별 예시가 다르므로 cadence 본 repo 가 아닌 별도 stack-특화 skill repo 에서 다룬다 (예: frontend-skills / python-skills / go-skills 등). 본 repo 는 cross-stack 범용 만 담당.
해당 skill 이 설치되어 있으면 플랜 단계에서 동시 적용. 미설치 시 본 단축 경로 게이트만 약해질 뿐 다른 단계 작동에는 영향 없음.
스펙시트는 탐색 → 결정 → 문서화 의 세 단계를 거친다. cadence-plan 은 결정권과 게이트를 담당하고, 외부 helper skill 은 필요한 순간에만 보조 렌즈로 로드한다. helper 가 설치되어 있지 않으면 아래 체크리스트를 본 skill 안에서 직접 수행한다.
| 렌즈 | 로드 시점 | 역할 | 금지 |
|---|---|---|---|
Brainstorming Lens (brainstorming, superpowers 계열 등) | 요구가 모호하거나 첫 문제 정의 단계 | 가능한 해석 2-3개, 가장 작은 첫 PR 단위, 확인 질문 후보, 반대 가정 도출 | 바로 스펙시트 확정 / 구현 진입 |
Writing Lens (writing-skills, clarify 등) | 결정된 내용을 스펙시트로 정리할 때 | 구현 가능한 명세로 재구성, facts / assumptions / TBD 분리, 읽기 쉬운 섹션화 | 아직 결정 안 된 가정을 매끈한 문장으로 확정처럼 포장 |
Hardening Lens (harden, audit, stack 특화 skill 등) | ready 전 또는 위험 큰 UI/API 흐름 | 실패 UI, edge case, 접근성, i18n, responsive, contract gap 체크 | 본 PR 범위를 몰래 확장 |
## TBD, ## 위험 / 폐기 조건, ## Out of scope 에 남긴다.4개 정확도 체크가 문서 산출물로 필요하면 스펙시트 (specsheet) 형식으로 결정화한다. 프로젝트별 구체 어휘는 *프로젝트 안 _template.md*가 담당하고, 본 skill은 메타-구조만 정의한다.
| 플랜 단 | 산출물 위치 (스펙시트 섹션) |
|---|---|
| 1단. 컨텍스트 수집 | ## 개요, ## 동작 / 변경 목록, ## 관련 회고 link |
| 2단. 옵션 + Contrarian | ## 동작 상세, ## 엣지 케이스 |
| 3단. 위험 / 폐기 / Out of scope | ## TBD, ## 후속 작업 (별도 작업), ## 위험 |
| 4단. 외부 검증 | ## 검증 결과 (보조 도구 의견 요약), ## 구현 체크리스트 확정 |
---
title: <한 줄 제목>
status: draft | ready | in-progress | done | revised
created: YYYY-MM-DD
updated: YYYY-MM-DD
related-retrospectives: [<link>, ...]
---
## 개요
<목표 1-2 문장 — 왜 이 작업을 하는가>
## 동작 / 변경 목록
- [ ] <동작 1>
- [ ] <동작 2>
## 동작 상세
### <동작 1>
- 사용자 흐름 / 입력 → 출력 / 에러 처리
## 공통 사항
- 진입 조건 / 이탈 동작 / 상태 흐름
## 엣지 케이스
- <Contrarian 질문 결과>
## TBD
- <해소 안 된 결정 — 모두 해소되면 status: ready>
## 위험 / 폐기 조건
- 위험: <≥ 1>
- 폐기 조건: <어떻게 알아챌까>
## Out of scope
- <본 작업에서 다루지 않을 항목>
## 구현 체크리스트
- [ ] <100% 시 status: done>
## 후속 작업 (별도 PR)
- [ ] <- PR #N>
## 관련 회고
- [<link to retrospective>]
프로젝트가 디렉토리 lifecycle 을 운용하면 본 skill 은 그 컨벤션 따름:
| status | 위치 (예시) |
|---|---|
| draft / ready | backlog/ |
| in-progress | in-progress/ |
| done / revised | done/ |
위는 예시 — 각 프로젝트는 자기 lifecycle 따름.
| 결정 위험 / 실행 범위 | 스펙시트 |
|---|---|
| 낮음 / 작음 | 생략 가능. 최종 보고에 개요 + 변경 목록 |
| 낮음 / 큼 | dry-run 기준과 검증 목록을 얇게 기록 |
| 높음 / 작음 | 결정과 위험을 플랜 요약으로 기록 |
| 높음 / 큼 | 스펙시트 권장. 새 도메인 / 공개 계약 / migration은 mandatory |
작업 완료 후 학습할 점 이 있으면 cadence-retrospective 트리거. 스펙시트의 ## 관련 회고 섹션이 역방향 link — 회고가 어떤 스펙시트에서 나왔는지 추적 가능.
본 skill 은 프로세스 만 정의. 룰 내용은 cwd 에서 동적 스캔:
docs/ai-rules/, root config, 또는 동등 위치docs/specsheets/done/ 등회고 / 스펙시트 구조가 정착된 프로젝트는 그 자산을 동적 활용. 회고가 없는 프로젝트는 git log + 기존 PR 로 대체.
본 skill 작동 중 AI 응답에는 사용자 결정과 결과에 필요한 신호만 나타난다.
미작동 시 → USAGE.md § 5 진단표 참조.
docs/retrospectives/INDEX.md — 회고 스캔 entry point (있는 경우)