Agile delivery

TypeMCP uses GitHub Issues, milestones, labels, pull requests, and a reviewer-owned label policy to keep small, verifiable work visible.

Sprint cadence

Label taxonomy

Apply at most one label from each status, priority, size, and review group.

GroupLabelsPurpose
Typetype:feature, type:bug, type:docs, type:test, type:tooling, type:chore, type:releaseNature of the work
Areaarea:core, area:http, area:ci, area:docs, area:community, area:securityAffected package surface or community operation
Prioritypriority:critical, priority:high, priority:medium, priority:lowSprint ordering
Statusstatus:needs-triage, status:needs-info, status:ready, status:in-progress, status:blockedDelivery state
Cross-cuttingdependencies, breaking-change, good first issue, help wantedDependency, compatibility, and contributor discovery signals
Sizesize:XS, size:S, size:M, size:L, size:XLPlanning estimate
Reviewreview:approved, review:changes-requested, review:commentedAutomated reviewer outcome

Pull request label policy

PR이 opened, reopened, ready-for-review, 또는 synchronize 상태가 되면 Request AI pull-request review workflow가 reviewer를 자동 요청합니다. workflow는 pull_request_targetGitHub PR metadata API 호출에만 사용하며, PR branch를 checkout하거나 실행하지 않습니다. Draft PR과 이미 요청된 reviewer는 건너뜁니다. AI account (sjungwon03-ai)가 author이면 sjungwon03에게, 그 외에는 sjungwon03-ai에게 review를 요청하므로 self-review 요청을 만들지 않습니다.

sjungwon03-ai는 현재 head commit을 검토한 뒤에만 적절한 review:* label을 부여합니다.

두 workflow 모두 pull_request_targetGitHub metadata API 호출에만 사용합니다. PR branch를 checkout하거나 PR code를 실행해서는 안 됩니다.

GitHub does not offer a label-only collaborator permission. This policy is therefore an automatic enforcement mechanism, not a way to remove the label UI from a collaborator with broader write or triage privileges. If stricter access control is needed, restrict collaborator roles in GitHub in addition to keeping this workflow active.

Minimal ceremony

  1. Triage a new issue: add type, area, priority, status, and size labels.
  2. Put ready issues in the current sprint milestone.
  3. Create one branch and PR per issue.
  4. Let CI and the automated reviewer determine merge readiness.
  5. Use the reviewer-owned review:* label as the PR's current review state.