Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

implementation: let implement-dispatch run a spec'd item list without a PLAN.md

Đang mở
  • Có gì không ổn?
#6,412 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
32/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
markdown, shell
Lĩnh vực
ai-infra-agents, cli, developer-experience, tooling

Hướng nghiên cứu

Start from the existing /implementation:implement-dispatch skill and SKILL.md (item 11 on quoting PLAN.md ## Design, phases, and implementation:phase-verifier). Trace how briefs, phases, and verifiers currently require an approved PLAN.md. Design an item-list mode (e.g. --items <report path>) that groups file:line items into disjoint workers, injects a shared PR-lifecycle block, uses per-item acceptance checks instead of phase-verifier, and defines a denied-edit return shape. Related: #5764. Done when dispatch can run from a scoped audit/report without writing PLAN.md.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

needs-human needs-triage

Problem

/implementation:implement-dispatch assumes an approved PLAN.md: briefs quote its ## Design section (SKILL.md item 11), phases come from it, and each phase boundary runs implementation:phase-verifier. In the 2026-10-04 CI-performance session the work arrived instead as audit or report output that was already scoped to file:line with acceptance evidence:

  • a version-consumer audit listing 10 required changes with file:line targets;
  • a selection-gap plan (F1-F9) with file:line targets and expected gap counts;
  • verifier findings to fold back into open PRs.

Writing a PLAN.md for that would only restate the report. So the session bypassed the skill and hand-dispatched general agents, each told to spawn its own fresh-context verifier and carry its own PR through ready → CI → review threads → merge. That worked, but every brief re-typed the same lifecycle rules, and three recurring gaps had no skill support:

  1. File-ownership fencing across parallel workers. Two workers started in overlapping areas. The coordinator had to reassign ownership by hand mid-flight and relay one worker's half-built script to another.
  2. PR lifecycle per worker. Each worker needed: draft, verifier, ready, an empty commit when a draft-era ci-status failure lingers, review threads resolved with resolveReviewThread as a separate call, merge-queue --match-head-commit, version-conflict resolver, re-queue once on a known flake. All of it was re-specified in every brief.
  3. Classifier denials in a worker. A worker cannot see the owner's in-session approval, so an approved edit was denied in the worker and had to be escalated and applied in the main session. The skill has no "escalate the exact edit to the coordinator" return shape.

Ask

Add a context-specific entry point that keeps the dispatch discipline but drops the plan-document requirement when the input is already scoped. For example implement-dispatch --items <report path> or an "item-list mode":

  • Input: a list of items, each with file:line targets and an acceptance check, from an audit, review or report file.
  • Group items into workers by disjoint file sets, and record ownership so a second worker is refused an owned path.
  • One fresh-context verifier per resulting PR, with criteria taken from each item's acceptance check. This replaces phase-verifier, which needs a plan.
  • A shared PR-lifecycle block (the steps in 2) injected into every brief, instead of hand-copied.
  • A standard return shape for "denied edit, here is the exact diff" so the coordinator can apply it where the approval is visible.

Related: #5764 (dispatch independent plan phases in parallel by default).

Evidence

Session dba79e68-af19-4ecc-a0ce-69d8b1dbefbb (transcript under ~/.claude/projects/C--Users-KyleSexton/). Resulting PRs include #6343-#6346, #6359, #6369, #6370 and the phase-3 PRs for #6006.

Ngôn ngữ chính
Shell
Star
22
Fork
2
Merge trung bình
5 giờ 11 phút
Pull request đã merge (30 ngày)
838

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của melodic-software/claude-code-plugins

Tất cả issue của melodic-software/claude-code-plugins

Issue tương tự

Thêm issue về Shell/Bash

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.