New skill: issue_prioritization_workflow, prioritize issues with a coding agent and GitHub Projects or GitLab
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- github, gitlab
- Ambito
- devtools
Direzione di ricerca
Read the first comment for the full process summarized by the issue, then inspect the existing bug_triage_workflow skill to understand the project’s skill conventions. Define how the skill handles the listed open questions about GitHub Projects, GitLab, objectives, scoring, and queue size; done means a SKILL.md for issue_prioritization_workflow that proposes priorities and a ranked Ready queue for approval before updating a board.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Goal
Create a new skill, with its instructions in SKILL.md, that lets a coding agent prioritize the open issues of a repository and keep that priority order in the project board of the issue tracker.
- The coding agent estimates the impact, the urgency, and the effort of each open issue, and finds the dependencies and the blockers between issues.
- The coding agent proposes a priority level (P0, P1, P2, P3) and an explicitly ranked Ready queue, and explains each choice in one or two sentences.
- The developer approves the proposed priorities and the proposed ranking before the coding agent changes any issue or any project board.
- The coding agent writes the approved priorities and the approved ranking to GitHub Projects, or to the equivalent feature in GitLab.
- The developer can run the skill again whenever the objectives change, or once a week, to keep the priority order current.
The full process is summarized in the first comment of this issue.
Proposed name
issue_prioritization_workflow
Proposed description
Prioritize the open issues of a repository and keep a ranked Ready queue in GitHub Projects or in the equivalent feature in GitLab. Use when the developer asks which issue to work on next, asks to assign priorities, or asks to update the project board. Propose every priority and every ranking first, and change issues or project boards only after the developer approves.
Open questions
- Which GitLab feature is the equivalent of GitHub Projects: issue boards with scoped labels (for example
priority::1), the issue weight field for the effort, or epics? Do these features need a paid GitLab tier? - Where does the skill store the priority level and the effort in a personal GitHub repository: in custom fields of GitHub Projects, or in labels? Does the native Priority field and the native Effort field of GitHub issues apply only to organization repositories?
- How does the skill store the explicit ranking of the Ready queue: the item order of a GitHub Projects view, a number field, or a pinned issue that lists the queue?
- Does the skill use the
ghcommand line and theglabcommand line, or a Model Context Protocol server for GitHub and for GitLab? - How does the skill learn the current objectives of the project: from the developer in the conversation, from a file in the repository, or from a milestone?
- Does the skill keep the formula
Score = (Impact × Urgency) / Effort, or only use the three estimates as input for the judgment of the coding agent? - How does this skill relate to the existing
bug_triage_workflowskill: does the new skill replace it, call it, or stay separate and cover all issue types? - What is the maximum size of the Ready queue: ten issues, as the source suggests, or a number that the developer chooses?
Source
- Lingua principale
- Nessun dato sulla lingua
- Stelle
- 1
- Fork
- 0
- Merge medio
- 10m
- PR unite (30g)
- 11
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di jeromeetienne/coding_agent_plugin
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
jeromeetienne/coding_agent_plugin#29 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 64/100
jeromeetienne/coding_agent_plugin#7 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 Mezza giornata Idoneità per principianti 68/100
jeromeetienne/coding_agent_plugin#26 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
jeromeetienne/coding_agent_plugin#25 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
jeromeetienne/coding_agent_plugin#19 · 3 commenti ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di jeromeetienne/coding_agent_plugin
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 1 giorno
-
bug documentation
Difficoltà 2/5 1-3 ore Idoneità per principianti 83/100
cqframework/vscode-cql#198 ·
-
bug documentation good first issue help wanted testing
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
Show evidence time and supersede warnings in the memory inspectorForse già presa @Sinchanak-212 l’ha presa oggi. Apertaarea: ux good first issue priority: medium
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
rohit746/pdf-view.nvim#109 ·
I maintainer di solito rispondono entro 1 giorno