dynamic-workflow

Files (1)

• SKILL.md

SKILL.md (first lines)

# dynamic-workflow

현재 요청에 맞는 **작업 분해 → 서브에이전트 실행 → 독립 검증 → 종합/반복** 워크플로우를 동적으로 설계하고 수행한다.

Pi에서는 **메인 에이전트가 오케스트레이터**가 되어 `subagent` 실행, `todo_write`, 기존 스킬을 조합한다.

## 핵심 목표

- 긴 작업을 한 컨텍스트에서 끝까지 밀어붙이다 생기는 **agentic laziness**를 막는다.
- 결과물을 만든 에이전트와 검증하는 에이전트를 분리해 **self-preferential bias**를 줄인다.
- 원래 목표, 금지사항, 성공 기준을 워크플로우 명세로 고정해 **goal drift**를 줄인다.
- 병렬화가 유리한 작업은 fan-out하고, 충돌 위험이 있는 구현은 순차 gate를 둔다.

## 언제 사용하나

사용자가 명시적으로 워크플로우/서브에이전트 분해를 요청하면 사용한다.

명시 요청이 없어도 아래 중 2개 이상이면 사용을 검토한다.

- 3개 이상의 독립 조사/수정/검증 단위가 있다.
- 구현자와 검증자를 분리해야 신뢰도가 오른다.
- 여러 관점의 판단이 필요하다: 보안, UX, 데이터, 아키텍처, 성능 등.
- 실패 조건이 불명확해서 `loop until done`이 필요하다.
- 많은 파일, 많은 항목, 긴 로그, 과거 세션/이슈/슬랙/문서 등 대량 컨텍스트가 있다.
- 단일 컨텍스트로 진행하면 중간 결과가 오염되거나 잊힐 가능성이 크다.

사용하지 않는 경우:

- 단순 1파일 수정, 짧은 질의응답, 즉시 검증 가능한 작은 작업.
- 사용자가 빠른 직접 처리를 원하고 추가 비용/시간을 원하지 않는 경우.
- 병렬 worker가 같은 파일을 동시에 고칠 가능성이 높고 격리 수단이 없는 경우.

## Workflow

### 1. Scope lock

먼저 다음을 5~10줄로 고정한다. 모호하면 `ask_user_question`으로 한 번에 묻는다.

```markdown
## Workflow Scope
- Objective:
- Non-goals / do-not-do:
- Source of truth:
- Success criteria: 반증 가능한 술어로 (무엇을 실행·확인하면 done인지)
- Constraints: 시간/토큰/권한/커밋/배포/외부 전송
- Stop condition:
```

Success criteria를 체크 가능한 술어로 쓸 수 없으면 장기 실행을 시작하지 않는다. "잘 동작하게"는 술어가 아니다.

복잡한 구현/아키텍처 변경이면 `design-first`를 먼저 사용한다. 이미 구조화된 계획이 있으면 Scope lock을 약식으로 채우고 바로 worker→verifier→reviewer 체인으로 실행한다.

### 2. Pattern 선택

작업 성격에 따라 아래 패턴을 하나 이상 조합한다.

| Pattern                  | 언제 쓰나                                 | Pi 실행 방식                                                      |
| ------------------------ | ------------------------------------- | ------------------------------------------------------------- |
| classify-and-act         | 작업 종류/위험도/모델 선택이 먼저 필요                | `worker` 또는 `challenger`에게 분류 요청                             |
| fan-out-and-synthesize   | 많은 파일/항목/문서/소스를 독립 처리                 | `subagent batch --isolated` 또는 `--main` 후 메인에서 종합             |
| worker→verifier→reviewer | 구현 태스크 품질 게이트                         | `subagent chain` (worker→verifier→reviewer)                   |
| adversarial verification | 사실/코드/설계 검증 신뢰도 향상                    | `verifier` + `reviewer` + `challenger` 병렬, `stress-interview` |
| generate-and-filter      | 아이디어/해결책 다수 생성 후 선별                   | 여러 `worker` → `reviewer` 필터                         |
| tournament               | 설계/이름/접근법 비교 판단                       | N개 후보 생성 → pairwise judge/reviewer                            |
| loop until done          | 원인 불명 버그, flaky test, 반복 triage       | stop condition + max cycles를 정하고 반복                           |
| quarantine triage        | Slack/리뷰/공개 입력 등 untrusted content 처리 | 읽기 전용 agent와 실행 agent를 분리                                     |

### 3. Workflow spec 작성

서브에이전트를 띄우기 전에 실행 계획을 명확히 작성하고 `todo_write`에 반영한다.

```markdown
## Adaptive Workflow Plan
- Pattern(s):
- Work units:
  1. [unit] owner agent / mode(main|isolated) / expected output / validation
- Parallel groups:
- Sequential gates:
- Conflict risks:
- Verification gates:
- Max cycles / budget:
- Human approval gates:
```

규칙:

- 한 번에 정확히 하나의 `todo_write` 항목만 `in_progress`로 둔다.
- 독립 fan-out 결과는 반드시 synthesis barrier에서 합친다.
- 구현 결과는 구현자가 아닌 `verifier`/`reviewer`가 검증한다.
- 같은 파일을 고치는 worker를 병렬 실행하지 않는다.
- 긴 프롬프트/컨텍스트는 임시 markdown 파일로 쓰고 subagent에게 경로를 전달한다.
- 장기 실행·다수 사이클·사용자가 자리를 비우는 워크플로우는 `show-me-your-work` 스킬의 `decisions.tsv` 결정 로그를 유지하고, 최종 보고를 Attention 섹션으로 마무리한다.

### 4. Subagent 실행 지침

먼저 현재 세션에서 `subagent help`를 확인하지 않았거나 인터페이스가 불명확하면 확인한다.

- 독립 작업: `subagent batch [--main|--isolated] --agent <agent> --task "..." ...`
- 의존 작업: `subagent chain [--main|--isolated] --agent <agent> --task "..." --agent <agent> --task "..."`
- 단일 위임: `subagent run <agent> [--main|--isolated] -- <task>`

모드 선택:

- `--main`: 같은 repo의 최신 변경/컨텍스트를 공유해야 하는 구현·검증.
- `--isolated`: 독립 조사, 아이디어 생성, 반론, 오염 방지 검증.

주의:

- `--` 뒤로 넘기는 task 본문에 apostrophe(`'s`, `won't` 등)가 들어가면 CLI가 "Unclosed quote"로 거절한다. apostrophe를 제거하거나, task를 `.tmp/*.md`에 적고 `subagent run <agent> -- read PATH and follow the instructions there` 패턴으로 우회한다.
- 실행 직후 바로 `status/detail`로 폴링하지 않는다. 자동 완료/실패 follow-up을 기다린다.
- 읽기 전용 역할(challenger, reviewer, verifier)에는 파일 산출물을 요구하지 않는다. write/셸 도구가 없어 조용히 불이행될 수 있다. 결과는 응답 본문으로 받고, 보존이 필요하면 메인 에이전트가 파일로 저장한다.
- `continue`는 최신 메인 컨텍스트를 자동 동기화하지 않으므로, 이어서 필요한 변경사항/결론을 프롬프트에 명시한다.
- 외부 전송, 삭제, 배포, 대량 변경, 비용 큰 작업은 사용자 승인 gate를 둔다.

#### Failed write-capable run recovery

실패하거나 중단된 write-capable subagent를 retry, continue, 재할당하기 전에 실패 로그와 그 실행이 실제로 사용한 workspace를 확인한다. `--main`이면 공유 worktree를, `--isolated`이면 해당 isolated worktree를 직접 확인하며 호출자의 깨끗한 worktree를 대리 증거로 사용하지 않는다.

Git workspace라면 `HEAD`, worker commit 유무, `git status --short`, staged/unstaged diff, 관련 untracked output을 기록한다. 관찰된 결과를 `complete | partial | unknown`으로 분류하고, 다음 프롬프트에 그 상태와 이어서 사용할 worktree 또는 revision을 명시한다. 실패가 write를 원자적으로 rollback했다고 가정하지 않는다.

From Jonghakseo/my-pi, MIT.

More from Jonghakseo/my-pi