Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#6,412 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
32/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
markdown, shell
Área
ai-infra-agents, cli, developer-experience, tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Shell
Estrellas
22
Forks
2
Merge medio
5 h 11 min
PR fusionados (30 d)
838

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de melodic-software/claude-code-plugins

Todos los issues de melodic-software/claude-code-plugins

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.