AI 소프트웨어 프로젝트 관리하기
모호한 AI 지원 전달 작업을 한 명의 인간 운영자를 위한 통제된 실행 시스템으로 전환하세요. 프레임을 도출하고, 스토리 분할에 대한 의식적인 승인을 받고, 지속 가능한 파일의 소형 라우팅된 작업 대기열을 통해 실행하고, 증거로 검증하며, 모든 성공 기준이 종단 간 확인을 통과한 후에만 종료하세요.
지속 가능한 프로젝트 상태를 공급업체 중립적으로 유지하세요. Codex, Claude Code 또는 다른 호환 에이전트 간 전환 시 pm/ 파일을 변환할 필요가 없어야 합니다.
빠른 시작
- 작업 공간을 검사합니다.
pm/이 존재하면pm/STATE.md를 읽고, 그 다음pm/TASKS.md를 읽습니다. 시스템을 재생성하는 대신 간격을 복구하세요. - 프로젝트 시스템이 없으면 CP1을 실행합니다: 도출 질문을 하고 프레임을
pm/PLAN.md에 초안으로 작성합니다. - references/file-templates.md에서 4개의 표준 파일을 생성합니다.
- CP2 분할, CP3 대기열, 실행 루프, 그리고 CP4 최종 승인을 통해 작업을 진행합니다.
운영자 체크포인트 프로토콜
운영자와 협력하여 분할을 공동 생성합니다. 각 승인을 pm/PLAN.md 또는 pm/TASKS.md에 날짜와 함께 기록합니다.
- CP1 — 프레임. 목표, 성공 기준, 최종 점검, 범위, 제약 조건 및 구조적 가정을 도출하고 승인을 받습니다.
- CP2 — 분할. 스토리를 운영자의 언어로 제시합니다. 각 스토리에 승인 기준을 부여하고, 그것이 어떤 성공 기준에 기여하는지 추적합니다. 미결 구조적 결정을 운영자와 해결합니다.
- CP3 — 대기열. 실행 시작 전에 라우팅 계층이 포함된 순서가 있는 작업 대기열을 제시합니다.
- CP4 — 최종 승인. 모든 CP1 최종 점검을 종단 간 다시 실행하고, 증거를 연결하며, 승인 보고서를 제시하고, 서명을 받습니다. 완료된 작업만으로 프로젝트가 끝난 것은 아닙니다.
다음 상시 규칙을 사용하세요:
- 승인된 프레임 내의 작은 간격은
pm/DECISIONS.md에 기록된 가정으로 채웁니다. - 구조적 변경(범위, 스토리, 성공 기준 또는 승인 기준)은 관련 체크포인트로 되돌리고 트레이드오프를 기록합니다.
- CP1에서 질문: 어떤 결과가 존재해야 하며, 누구를 위한 것인가? 운영자가 개인적으로 어떻게 검증할 것인가? 범위를 벗어난 것은 무엇인가? 어떤 제약 조건이 고정되어 있는가? 이미 존재하는 것은 무엇인가? 가장 위험하거나 불명확한 것은 무엇인가? 운영자가 원하는 검토 수준은 어느 정도인가?
- 복구 모드에서는 작업 공간에서 암시된 프레임과 분할을 재구성하고, 확인을 위해 제시한 다음 대기열을 재구축합니다.
표준 프로젝트 파일
pm/ 아래에 4개의 파일을 유지합니다:
pm/PLAN.md— 목표, 성공 기준, 범위, 스토리, 추적 가능성, 승인pm/TASKS.md— 순서가 있는 작업 대기열, 안정적인 ID, 라우팅, 검증, 증거pm/STATE.md— 현재 상태, 핸드오프 노트, 세션 로그pm/DECISIONS.md— 결정, 가정, 위험, 이슈, 변경 로그
기본적으로 추가 제어 파일을 생성하지 마세요. 일치하는 분기가 활성화된 경우에만 pm/CONSTRAINTS.md, pm/RELEASE.md 또는 pm/RESEARCH.md를 추가하세요.
제품별 진입 파일(예: AGENTS.md 또는 CLAUDE.md)을 짧고 탐색적으로 유지하세요: pm/STATE.md를 가리킨 다음 pm/TASKS.md를 가리키고, pm/PLAN.md는 승인된 범위로 표시합니다. 세션 로컬 계획 도구의 지속 가능한 정보를 pm/TASKS.md 및 pm/STATE.md에 미러링합니다.
역량별 작업 라우팅
각 작업이 대기열에 들어갈 때 공급업체 중립적인 Route: 계층을 할당합니다:
| 계층 | 용도 |
|---|---|
heavy | 계획, 분해, 아키텍처, 모호한 디버깅, 교차 변경 리팩터링, 위험 검토, 최종 승인 |
standard | 경계가 있는 구현, 테스트, 중간 복잡도 변경 |
light | 저장소 검색, 요약, 기계적인 편집, 문서, 포매팅, 로그 분류 |
각 작업을 안정적으로 완료할 수 있는 가장 저렴한 계층으로 라우팅합니다:
- 기본 스레드를 지시할 수 있을 만큼 충분한 능력으로 유지: 프레임 브리핑, 작업 라우팅, 증거 판단, 서명.
- 동일한 작업에서 두 번 실패하거나 낮은 신뢰도 결과가 나오면 한 계층 에스컬레이션하고 에스컬레이션을 기록합니다.
- 검토자 계층은 최소한 작성자 계층 이상이어야 합니다. 위험하거나 교차 변경 사항은 새로운 컨텍스트의
heavy검토를 받으세요.light작업자가 자체 승인하도록 절대 허용하지 마세요. - 모델 이름을
pm/에 넣지 마세요. 제품 별칭과 가격은 변하지만 역량 계층은 유용하게 남습니다. - Codex, Claude Code 또는 다른 에이전트용 작업자를 구성하기 전에 references/agent-routing.md을 읽으세요.
먼저 컨텍스트 구축
- 실제 목표, 사용자, 승인 기준, 종속성 및 릴리스 기대치를 추출합니다.
- 날짜, 예산, 승인, 공급업체 일정 또는 출시 기간은 명시적인 경우에만 일급 입력으로 취급합니다.
- 새 아티팩트를 만들기 전에 기존
pm/파일, 작업 브리핑, 백로그, 설계, ADR, 테스트 전략, 런북, 위험 로그 및 에이전트 명령 파일을 찾습니다. - 복구 작업에서는 목표 명확성, 범위, 종속성, 승인 품질, 위험 위생, 컨텍스트 가독성, 권한 및 릴리스 준비 상태를 평가합니다.
가장 작은 제어 모드 선택
- 기본값은
solo-operator: 한 명의 운영자가 AI 에이전트를 조종합니다. - 실제 고정 날짜, 규정 준수 게이트, 승인, 공급업체 종속성, 할당량 또는 출시 기간이 있는 경우
external-constraint를 추가합니다. - 발견, 사용자 학습 또는 UX 반복이 지배적인 경우
feedback-heavy를 추가합니다. - 출시에 전환, 롤백, 모니터링 또는 운영 노트가 필요한 경우
release-safety를 추가합니다.
실행 단위 크기 조정
- 사용자 가시적 가치와 승인을 위해 스토리를 사용하세요. 작업을 그룹화하려면 마일스톤만 사용하세요. 작업을 통해 실행합니다.
- 각 작업이 하나의 집중된 에이전트 실행과 하나의 빠른 운영자 검토에 맞도록 만드세요: 하나의 하위 시스템, 인터페이스, 문서 또는 테스트 표면, 그리고 하나의 검토 가능한 diff.
- 모든 작업에 안정적인 ID, 스토리 참조, 라우팅 계층, 범위, 종속성, 완료 조건, 정확한 검증, 증거 필드 및 명시적인 중지 지점을 부여하세요.
- 작업이 관련 없는 영역 또는 여러 독립적인 검증에 걸쳐 있을 때는 실행 전에 분할하세요. 기록을 유지하세요: 하위 작업은 새 ID를 받고, 대체된 작업은
superseded가 됩니다. - 작업 완료 후 동일한 실행에서 증거를 채우고
pm/STATE.md를 업데이트하세요.
추적 가능성 유지
- 모든 성공 기준을 최소 하나의 스토리에 매핑하고, 모든 스토리를 최소 하나의 작업에 매핑하세요.
- 모든 작업과 승인 기준이 증거로 검증된 경우에만 스토리를 완료된 것으로 표시하세요.
- CP4가 모든 성공 기준을 종단 간 재검증한 후에만 프로젝트를 완료된 것으로 표시하세요.
품질 우선 루프 실행
- 구현 전에 가장 작은 신뢰할 수 있는 증거를 정의하세요: 실패 재현, 자동화된 테스트, 예상 출력, 스크린샷 비교, 계약 점검 또는 정확한 수동 절차.
탐색 -> 계획 -> 구현 -> 검증 -> 검토 -> 문서화를 사용하세요.- 결론만이 아니라 명령, 결과, 스크린샷, 메트릭 및 검토 노트를 기록하세요.
- 위험한 작업에 대한 변경 예산을 명시하세요: 허용된 파일, 안정적인 인터페이스, 데이터 안전, 롤백 및 에스컬레이션 트리거.
- 반복적이거나 자동화된 변경은 확장 전에 좁은 대표 샘플에서 시험하세요.
- 동일한 실패가 두 번 발생하면 중단하고 환경, 문서, 규칙 또는 검증기를 개선한 후 깨끗한 컨텍스트로 다시 시작하세요.
- 반복되는 에이전트 실패를 시스템 피드백으로 취급하세요. 현재 답변뿐만 아니라 프로세스를 개선하세요.
안전하게 위임
- 자율성에 준비된, 경계가 있는 작업만 위임하세요. 목표, 분해, 종합 및 서명은 기본 스레드에 유지하세요.
- 각 작업자에게 서면 브리핑을 제공하세요: 작업 ID, 목표, 범위, 제약 조건, 검증 명령, 예상 증거, 중지 지점, 에스컬레이션 트리거 및 라우팅 계층.
- 매우 작고, 밀접하게 결합되거나, 상호작용이 많은 작업은 위임 오버헤드가 이점을 초과할 때 기본 스레드에 유지하세요.
- 필수 테스트, 경로 제한, 포매팅 또는 비밀 스캔과 같은 무예외 규칙에는 결정론적 검증기를 선호하세요.
- 최소 권한, 신뢰 경계, 비밀 처리 규칙 및 위험한 작업에 대한 명시적인 운영자 승인을 시행하세요.
참조
pm/을 생성하거나 복구할 때 references/file-templates.md를 읽으세요.- 간결한 종단 간 예제를 보려면 references/worked-example.md를 읽으세요.
- 프로젝트를 감사하거나 복구할 때 references/project-rulebook.md를 읽으세요.
- 실제 외부 제약 조건이나 프로덕션 릴리스 위험이 있는 경우에만 references/external-constraints.md를 읽으세요.
- 지속 가능한 메모리, 컨텍스트, 위임, 평가 및 가드레일에 대한 더 깊은 지침을 보려면 references/ai-agent-practices.md를 읽으세요.
- 계층을 제품의 현재 기능에 매핑할 때 references/agent-routing.md를 읽으세요.
- 출처 또는 변동성 있는 공급업체 지침이 중요할 때 references/source-anchors.md를 읽으세요.
- 가장 작은 관련 참조만 로드하세요.
출력 표준
- 구체적이고 결정 준비가 된 아티팩트를 명령형 형태로 작성하세요.
- 체크포인트 상태를 먼저 보고하고, 텍스트 상태 앞에 작업 ID를 보고하세요.
- 작업 형식:
작업 ID,작업,스토리,경로,범위,종속성,완료 조건,검증 방법,증거,중지 후,상태. - 작업당 하나의 검토 가능한 diff를 선호하세요.
- 모델 이름을 지속 가능한 프로젝트 파일에 넣지 마세요.
- 프로젝트가 진정으로 필요하지 않는 한 날짜 계획, 예산, 승인 워크플로, 정기적인 의식 또는 단계 게이트를 추가하지 마세요.
- 사용하기 전에 현재 모델, 벤치마크, 가격 또는 공급업체 워크플로 주장을 기본 소스에서 확인하세요.