핵심 루프

DWP는 계획을 목표에서 완료된, 검토 가능한 작업으로 옮기는 작은 연산 집합을 정의합니다. create → execute → refine → resume → status, 그리고 결과를 확인하는 적합성 검증으로서의 verify입니다. 이들이 함께 에이전트가 계획의 수명 내내 따르는 루프를 이룹니다. 에이전트는 한 번에 하나의 작업을 실행하며, 다음으로 넘어가기 전에 각 단계를 검증합니다.

이 루프는 스펙 주도 개발의 운영적 형태입니다. 계획은 에이전트가 맞춰 실행하는 스펙이고, 각 작업은 명시적인 인수 기준을 담으며, 검증 단계는 완료 주장을 완료의 증거로 바꾸는 게이트입니다. 계획과 그 진행 로그가 리포지토리 안에 존재하므로, 루프는 세션과 에이전트를 넘어 재개 가능합니다.

연산들

이 방법론 스킬은 개발자의 의도를 9개의 특화된 서브 스킬로 위임합니다: 6개의 핵심 실행 연산, 2개의 수명 주기 도우미, 그리고 작성 엔진입니다:

• create — 목표로부터 새 계획을 생성합니다. 에이전트는 목표를 분석하고 순차적 작업으로 분해한 뒤 계획 파일을 작성합니다. 안내형 모드에서는 에이전트가 Lite 계획 — README.md에 포함되는 간결하고 직접 실행 가능한 제안 — 을 직접 구체화하며, 개발자는 이를 유지하거나, 작업 파일 기반의 Full 계획으로 승격하거나, 수정하거나, 중단할 수 있습니다. 신뢰 모드에서는 선택된 표현 형식(Lite 또는 Full)을 검토 단계 없이 직접 구체화합니다. 요구사항 분석과 계획 품질 점검은 두 모드 모두에서 실행됩니다.
• execute — 계획을 작업 단위로 순차 실행합니다. 에이전트는 각 작업 후 진행 로그를 갱신하고, 검증 게이트를 실행하며, 커밋합니다. 신뢰 모드에서는 작업 간에 묻지 않고 무인 실행을 지속합니다.
• refine — 기존 계획을 수정합니다(작업 추가, 편집, 분할, 재배열 또는 Lite 계획을 Full 계획으로 승격). 완료된 검증 증거를 엄격히 보존하며, 확인되지 않은 기준 완화를 금지합니다.
• resume — 중단된 계획을 이어 갑니다. 에이전트는 추가 전용 저널과 작업 파일을 읽어 상태를 재구성한 뒤, 완료되지 않은 첫 작업부터 작업을 반복하지 않고 계속합니다.
• status — 실행하지 않고 진행 상황을 보고합니다(엄격한 읽기 전용). 에이전트는 완료, 진행 중, 대기 작업을 요약하며 아무것도 바꾸지 않습니다.
• verify — 아무것도 바꾸지 않고 적합성을 확인합니다(엄격한 읽기 전용). 에이전트는 리포지토리가 AI-first 표준을 충족하는지, 그리고 계획 작업이 명시적인 인수 기준과 검증 게이트를 갖추고 있는지 보고합니다.
• onboard — 대상 리포지토리를 조사하여 정형화된 복사-붙여넣기가 아닌 추론을 바탕으로 리포지토리에 맞춤화된 AGENTS.md, 표준 docs/ 계층, 모듈 문서 및 호환성 심볼릭 링크를 갖춘 .agents/ 키트를 구축합니다.
• upgrade — 업스트림 릴리스를 확인하고, 다운로드 전 개발자의 명시적 동의를 요청하며, 고정된 안정 태그를 설치하고, 기존 .dwp/ 계획을 건드리지 않은 채 로컬 적응 사항을 조율합니다.
• author — 실제 반복 워크플로에 맞춰 리포지토리 로컬 스킬, 에이전트 또는 슬래시 명령을 생성 및 진화시키고 .agents/docs/ 카탈로그의 정합성을 유지합니다.

.dwp/ 출력 디렉터리

모든 DWP 산출물은 리포지토리 루트의 gitignore된 .dwp/ 디렉터리 아래에 존재합니다. 작업 공간을 버전 관리 밖에 두면 계획의 작업 상태가 프로젝트 이력을 오염시키는 일이 결코 없습니다. 리포지토리 수준의 애드온 설정은 .dwp/config.json(dwp-config/v1)에 기록되며, 계획은 평면 번호 디렉터리에 위치합니다:

.dwp/
├── config.json
└── plans/
    └── PLAN_001_<slug>/
        ├── manifest.json
        ├── contract.json
        ├── journal.ndjson
        ├── state.json
        ├── README.md
        ├── PROGRESS.md
        ├── 1.task_<slug>.md
        ├── 2.task_<slug>.md
        └── analysis_results/

열 절로 이루어진 작업 구조

작업 파일

1. 01 제목
2. 02 컨텍스트
3. 03 시작 전 필독
4. 04 목표
5. 05 영향 표면
6. 06 작업 지침
7. 07 수락 기준
8. 08 산출물
9. 09 검증
10. 10 실행 체크리스트 및 완료 로그

모든 작업 파일은 설치된 스킬에서 정의한 순서에 따라 위에 렌더링된 열 개의 규범적 섹션으로 구성됩니다.

1. 목표(Goal) — 작업이 무엇을 달성하는지 서술하는 한 단락.
2. 컨텍스트(Context) — 배경, 링크, 그리고 이 작업이 존재하는 이유.
3. 변경 표면(Touched Surface) — 작업이 바꾸는 것과 검증되어야 할 것 사이의 계약.
4. 단계(Steps) — 수행할 순서대로 정리된 구체적 행동.
5. 인수 기준(Acceptance criteria) — 완료를 정의하는 조건의 체크리스트.
6. 검증(Validation) — 작업을 확인하기 위해 실행할 명령이나 테스트.
7. 파일(Files) — 생성 또는 수정될 것으로 예상되는 경로.
8. 의존성(Dependencies) — 다른 작업이나 외부 선행 조건.
9. 리스크(Risks) — 무엇이 잘못될 수 있는지와 완화책.
10. 완료 & 로그(Completion & Log) — 상태 표시와 함께 시간순 기록.

검증, 완료, 재개

검증은 사후 고려가 아니라 작업의 일부입니다. 각 작업은 완료를 증명하는 명령이나 테스트를 명시하고, 에이전트는 완료를 표시하기 전에 그것들을 실행합니다. 테스트는 여기서 일급입니다 — 새로운 기능을 추가하거나 동작을 변경하는 작업은 그 동작에 대한 자동화된 테스트를 추가하거나 갱신하고, 단지 빌드가 성공함을 확인하는 것이 아니라 리포지토리의 전체 코드 품질 검사(테스트와 함께 lint 및 타입 검사)를 실행해야 합니다. 기존 테스트는 건너뛰는 대신 의도된 동작으로 갱신되어 통과 상태를 유지해야 합니다. 보안도 같은 방식으로 일급입니다 — 인증, 입력 처리, 비밀, 네트워크 표면, 또는 의존성에 닿는 어떤 작업이든 그 변경의 보안 기대치를 인수 기준에 담고 모든 커밋을 비밀이 없는 상태로 유지하며, 모든 계획은 Final Review로 마무리됩니다 — 전체 변경 집합에 대한 보안 점검, 최종 상태에 대한 전체 검증, 그리고 스킬 결정에 대한 조정입니다. 완료는 완료 & 로그 절에 명시적 상태 표시([ ] 시작 안 함, [~] 진행 중, [x] 완료, [!] 차단됨)로 기록됩니다. 재개는 이 표시와 진행 로그에 의존합니다 — 에이전트는 계획이 정확히 어디서 멈췄는지 재구성하고, 끝난 작업을 다시 하지 않으며 완료되지 않은 첫 작업부터 계속할 수 있습니다.

v6와 v7: 같은 방법론, 더 엄격한 구조

현재 DWP 표준은 7.0.0이며 7.x 스킬 라인이 이를 구현합니다. 이 팩은 모든 새 계획에 기본적으로 v7을 사용하며, 명시적으로 v6을 요청하면 여전히 v6 계획이 생성됩니다. 기존 v1, v2, v5, v6 계획은 기록된 세대를 유지하며 조용히 마이그레이션되지 않습니다. v5 계획을 v6으로 옮기려면 명시적 마이그레이션 요청이 필요합니다.

v6는 같은 계획 → 작업 → 검증 게이트 → 완료 방법론, 슬래시 명령, .dwp/plans/ 위치를 유지합니다. 계약, 저널, 작업별 컨텍스트 매니페스트, 스케줄러를 추가하고 빈 허용 목록을 거부해 엔지니어링 구조를 더 엄격하게 만듭니다. v7은 그 기록 계층을 유지하면서 선택적 parallel_safe 작업 표시, 다른 에이전트에 넘긴 경계가 정해진 작업을 위한 delegation 저널 이벤트, .dwp/config.json 애드온 레지스트리를 추가합니다. 위임 애드온이 활성화되어 있지 않으면 모든 계획은 여전히 현재 세션에서 순차적으로 실행됩니다. 아키텍처 결정은 GO입니다. 에이전트 결과의 경험적 비열등성은 측정되지 않았습니다.