aligned-delivery

Files (29)

• plugin.json · .claude-plugin/
• .gitignore
• CHANGELOG.md
• LICENSE
• README.ko.md
• README.md
• SKILL.md
• health_check_template.md · assets/
• monthly_productivity_review_template.md · assets/
• retro_kpt_template.md · assets/
• sprint_report_template.md · assets/
• demo.gif
• demo.tape
• evals.json · evals/
• sprints.csv · evals/
• coaching-questions.md · references/
• manifesto.md · references/
• operating-loops.md · references/
• operating-rules.md · references/
• principles.md · references/
• flow_metrics.py · scripts/
• forecast_montecarlo.py · scripts/
• health_check_analyze.py · scripts/
• sample_flow.csv · scripts/
• sample_health_check.csv · scripts/
• sample_throughput.csv · scripts/
• sample_workload.csv · scripts/
• sprint_predictability.py · scripts/
• workload_fragmentation.py · scripts/

SKILL.md (first lines)

# Aligned Delivery (얼라인드 딜리버리)

A project-management operating method that treats belief as the load-bearing layer under
performance. It is grounded in **N2C (Neo²-Confucianism / Dynamic Resonance Ontology)** —
the philosophy lives *inside* this skill as its foundation; the full ontology is a separate
`life-reading` skill. Here we use only the parts that map cleanly to running a team.

> **KO.** 신념을 성과 아래 하중을 견디는 층(load-bearing layer)으로 다루는 프로젝트 관리
> 운영 방법론입니다. **N2C(네오² 유학 / 동적 공명 존재론)** 에 뿌리를 두며, 철학은 이 스킬의
> *토대*로서 내부에 존재합니다. 전체 존재론은 별도의 `life-reading` 스킬에 있고, 여기서는 팀 운영에
> 깔끔하게 매핑되는 부분만 사용합니다.

## What this skill is (이 스킬은 무엇인가)

Three sentences hold the whole method:

1. **Read 리·기·도.** Read any team on three layers — its latent structure (리), its live
   operating state (기), and its measurable footprint (도) — before judging it, and never
   from metrics alone.
2. **Move 응축 → 해산 → 창발 → 무위.** Run the real cycle beneath sprints: condense and
   diagnose a problem, dissolve fixed plans, let a new pattern emerge, then stabilize it
   with minimal force.
3. **Lead by minimal interference toward alignment.** Optimize for *alignment* — stable
   under many valid interpretations — rather than for the single "right" answer, because
   alignment is what produces stable, sustainable delivery. The *goal* of that minimal
   interference is a team **"managed without being managed"** — a self-driving system rooted in
   each person's self-management, where management is *caring* rather than control and the leader
   earns the step-back through attraction and trust (principles.md #4).

> **KO.** 세 문장이 방법론 전체를 담습니다. (1) **리·기·도를 읽어라** — 어떤 팀이든 잠재
> 구조(리), 살아 움직이는 운영 상태(기), 측정 가능한 흔적(도)의 세 층위로 읽되, 절대 지표
> 하나만으로 판단하지 않는다. (2) **응축 → 해산 → 창발 → 무위로 움직여라** — 스프린트 밑에
> 흐르는 진짜 사이클을 돌려라: 문제를 응축·진단하고, 고정된 계획을 해산하고, 옛 구조가 설명
> 못 하던 새 패턴이 창발하게 두고, 최소한의 힘으로 무위로 안정화한다. (3) **최소 간섭으로
> 정렬을 향해 이끌어라** — 단 하나의 '정답'이 아니라 여러 타당한 해석 아래에서도 안정적인
> *정렬(alignment)* 을 최적화하라. 안정적이고 지속가능한 딜리버리를 만드는 것은 정렬이다. 이 최소
> 간섭의 *목표*는 **'관리하지 않아도 관리되는'** 팀 — 개인의 자기관리에 뿌리내린 자율주행 체계 — 이며,
> 여기서 관리는 통제가 아니라 *케어*이고 리더는 매력과 신뢰로 물러설 권리를 얻는다(principles.md #4).

The thesis the whole skill embodies: *belief is the load-bearing layer under performance;
alignment (not the single right answer) creates stability; and real productivity comes from
stability, not heroic speed.*
(이 스킬이 체현하는 한 줄 명제: *신념은 성과 아래의 하중층이고, 정렬(정답이 아닌)이 안정성을
만들며, 진짜 생산성은 영웅적 속도가 아니라 안정성에서 나온다.*)

## The 리·기·도 diagnostic lens (리·기·도 진단 렌즈)

Before recommending anything, locate the situation on all three layers. Judging from one
layer alone — especially metrics — is the most common operating mistake.

- **Li 리 — latent structure (잠재 구조).** The de-facto structure the team actually runs on —
  team/role topology, backlog shape, dependencies, recurring failure modes — not the org chart
  or the documented process. Ask: *what does this system tend toward?* It's emergent: it shifts
  as the team's practices change. Read it from org/backlog structure and repeated incidents.
- **Gi 기 — operating state (운영 상태).** The live operating state: workload, capacity, morale,
  tension, delivery pressure — the team's real-time signal. Read it through health checks and
  1:1s. Structure tells you the design; only the operating state tells you how it's running now.
- **Do 도 — footprint / trajectory (흔적/궤적).** The measurable footprint and trajectory:
  predictability, velocity, fragmentation — the telemetry the team actually emitted and where the
  trend points. Read it through sprint analytics. Metrics are the trace — not the whole system.

> **KO.** 무엇을 권하기 전에 상황을 세 층위 모두에 위치시켜라. 한 층위(특히 지표)만으로
> 판단하는 것이 가장 흔한 운영 실수다. **리** 는 팀이 실제로 굴러가는 구조 — 팀·역할 토폴로지,
> 백로그 구조, 의존성, 반복되는 실패 모드 — 이며 조직도나 문서화된 프로세스가 아니다.
> *이 시스템은 무엇을 향해 기우는가?* 팀의 실천이 바뀌면 함께 바뀐다. **기** 는 살아 있는
> 운영 상태(업무량, 캐파, 사기, 긴장, 딜리버리 압력) — 팀의 실시간 신호 — 로 헬스체크와 1:1로
> 읽는다. 구조는 설계를 말해주지만, 지금 실제로 어떻게 돌아가는지는 운영 상태만 말해준다.
> **도** 는 측정 가능한 흔적과 궤적(예측도, 벨로시티, 파편화) — 팀이 실제로 남긴 텔레메트리와
> 추세 방향 — 으로 스프린트 분석으로 읽는다. 지표는 시스템 전체가 아니라 흔적일 뿐이다.

A complete diagnosis names what you see on each layer, then reconciles them. When the
layers disagree (e.g. green metrics but a heavy operating state), trust the disagreement — it is the signal.
(완전한 진단은 각 층위에서 본 것을 명명한 뒤 서로 대조한다. 층위들이 어긋날 때 — 예: 지표는
초록인데 기가 무거울 때 — 그 어긋남을 신뢰하라. 그것이 곧 신호다.)

## When to use which capability (어떤 역량을 언제 쓰는가)

Route the request to one of three capabilities (요청을 세 역량 중 하나로 라우팅하라):

- **Coach / interview / assess a PM** → **Capability A** (PM 코칭·인터뷰·평가).
  Read `references/coaching-questions.md` and run the **staged coaching protocol** at its top —
  frame the mode, read 리·기·도, start with the **core-6 forcing questions**, then go deep one
  question at a time (STOP between). Answer in the philosophy's voice; tie every abstract point to
  one concrete, measurable move. (코칭 세션은 그 파일 상단의 단계형 프로토콜로 — 모드 확인 → 리·기·도
  → 코어 6문항 → 한 번에 한 문항씩 심화(사이에 STOP). 추상 원칙은 측정 가능한 한 수로 착지.)
- **Diagnose a team / read its health or sprint data** → **Capability B** (팀 진단·데이터 해석).
  Read `references/operating-loops.md`, then run the relevant script in `scripts/` on the
  user's data and interpret the output — leading indicators first, lagging second. For a
  whole-team monthly write-up, populate `assets/monthly_productivity_review_template.md`;
  for a per-sprint one, `assets/sprint_report_template.md`. (월간 전사 리포트는 월간 생산성
  리뷰 템플릿, 스프린트별은 스프린트 리포트 템플릿으로.)
- **Design cadence / retro / feedback loops / guardrails** → **Capability C** (운영 루프 설계).
  Read `references/operating-loops.md` and design the ceremonies around the
  응축→해산→창발→무위 cycle and 무위 (minimal-interference) leadership.

Many real requests touch two or three. Read 리·기·도 first; it tells you which capability
leads. (실제 요청은 둘셋을 함께 건드린다. 먼저 리·기·도를 읽어라 — 어느 역량이 주도할지를
그것이 알려준다.)

> **Step-change in tooling or process (e.g., adopting an AI coding assistant) → B then C.**
> A sudden velocity jump is lagging and the estimation unit may have broken — don't read it at
> face value. First verify with leading indicators and the **per-person distribution** (B):
> scope predictability, fragmentation, ops ratio, cost-per-output, and whether *everyone* rose
> or only some (coach anyone left behind). Then design the recovery as an operating loop (C):
> baseline reset → ~3-month capacity-finding push → health check → ±5–10% capacity → ~80% steady
> state. See operating rules #8–#9 and coaching Q48.
> (KO. 도구·프로세스 계단식 변화(예: AI 코딩 어시스턴트 도입) → B로 검증한 뒤 C로 설계. velocity
> 급등은 후행이고 추정 단위가 깨졌을 수 있으니 액면대로 읽지 마라. 먼저 선행지표와 **개인별
> 분포**(B)로 검증 — 예측도·파편화·운영비중·비용당 산출, 그리고 전원이 올랐는지 일부만인지(뒤처진
> 인력은 코칭). 그다음 회복을 운영 루프(C)로 설계 — 베이스라인 리셋 → ~3개월 캐파 탐색 →
> 헬스체크 → ±5~10% 캐파 → ~80% 정상상태. 운영 경험칙 #8–#9, 코칭 Q48 참고.)

> **Merging two teams → B then C.** Day 1, diagnose from each team's history *yourself* before
> engaging people; keep each team's own way until a joint method is agreed; converge on one simple
> shared unit (don't re-platform mid-merge); measure per-cohort leading indicators (incl.
> distribution match) and never judge by velocity (it drops first). See `operating-loops.md` §6
> and operating rule #7 (false-normal confidence). (두 팀 병합 → B 후 C. Day 1에 사람 만나기 전
> 각 팀 이력으로 *스스로* 진단; 합의 전까진 각자 방식 유지; 단순 공유 단위로 수렴; 코호트별
> 선행지표(분포 매칭 포함) 측정, velocity로 판단 금지. operating-loops §6, 규칙 #7 참고.)

From ahnbingbing/aligned-delivery, MIT.