agentleFS
yamcodesyamcodes/arkenv/skills/groom-issue/SKILL.md

groom-issue

Skill147 starsChanged 23 days agoMITView on GitHub

Groom a poorly written issue by grilling the user to clarify requirements, updating the issue on GitHub via the gh cli, and utilizing the triage skill to apply the correct label and add an agent brief if necessary. Use when the user wants to groom, flesh out, or clarify a poorly written issue.

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this skill whenever the user says /groom-issue <number> or asks to "groom", "clarify", "flesh out", or "improve" a poorly written issue.

    line 14
  2. Distinctive:

    Before asking any questions, you MUST examine the current state of the issue and the surrounding codebase.

    line 20
  3. Very specific:

    If the issue is vague, poorly written, or lacks concrete acceptance criteria, conduct a rigorous interview session with the user (following …

    line 31
  4. Distinctive:

    Update Issue on GitHub: Use the GitHub CLI to update the issue body (and title if appropriate):

    line 45
  5. Distinctive:

    Apply Triage Labels: Use the GitHub CLI to apply the correct canonical labels to the issue:

    line 55
  6. Very specific:

    Post Agent Brief (If Applicable): If the issue is transitioned to ready-for-agent or ready-for-human, generate a durable, behavioral agent …

    line 60

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Groom issue

This skill takes a poorly written, ambiguous, or incomplete issue, conducts an interactive grilling session with the user to clarify requirements, updates the issue on GitHub using the GitHub CLI (gh), and utilizes the existing /triage skill workflow to apply the correct canonical labels and post an authoritative agent brief.

Trigger

Use this skill whenever the user says /groom-issue <number> or asks to "groom", "clarify", "flesh out", or "improve" a poorly written issue.

Workflow

1. Context gathering & initial assessment

Before asking any questions, you MUST examine the current state of the issue and the surrounding codebase.

  1. Retrieve Issue Details: Fetch the issue context, including title, body, comments, and labels using the GitHub CLI:
    gh issue view <issue-number> --json title,body,labels,comments
  2. Analyze Requirements: Evaluate the issue description and existing comments. Identify gaps, ambiguities, missing edge cases, unclear desired behavior, or lacking acceptance criteria.
  3. Explore Codebase: Explore the repository to understand the domain model and existing implementations relevant to the issue. Refer to the project's domain glossary (docs/CONTEXT.md), ADRs (docs/adr/), and prior rejections (.out-of-scope/*.md).

2. Grilling / requirement clarification (if needed)

If the issue is vague, poorly written, or lacks concrete acceptance criteria, conduct a rigorous interview session with the user (following the principles of /grill-with-docs):

  1. Ask One Question at a Time: Interview the user relentlessly about every aspect of the issue until reaching a shared understanding.
  2. Wait for Feedback: Present your recommended answer/approach for each question and wait for the user's confirmation before proceeding to the next question.
  3. Probe Specifics: Challenge fuzzy language, establish clear boundaries between domain concepts, and explore concrete edge cases and error conditions.

3. Fleshing out the issue on GitHub

Once the requirements are fully clarified and agreed upon:

  1. Synthesize Refined Specification: Format the clarified requirements into a clean, comprehensive issue body. Ensure it includes:
    • A clear problem statement
    • Detailed desired behavior
    • Concrete, testable acceptance criteria
  2. Update Issue on GitHub: Use the GitHub CLI to update the issue body (and title if appropriate):
    gh issue edit <issue-number> --body "<refined-issue-body>"

4. Triage & agent brief

At the end of the grooming process, you MUST utilize the existing /triage skill workflow (refer to skills/triage/SKILL.md and skills/triage/AGENT-BRIEF.md) to properly classify and prepare the issue:

  1. Determine Triage Roles: Identify the correct category role (bug or enhancement) and state role (ready-for-agent, ready-for-human, needs-info, wontfix, etc.) based on the triage skill guidelines.
  2. Apply Triage Labels: Use the GitHub CLI to apply the correct canonical labels to the issue:
    gh issue edit <issue-number> --add-label "<category-role>,<state-role>"
    (Note: Remove any conflicting or outdated triage state labels if necessary).
  3. Post Agent Brief (If Applicable): If the issue is transitioned to ready-for-agent or ready-for-human, generate a durable, behavioral agent brief following the principles and template in skills/triage/AGENT-BRIEF.md. Post it as a comment on the issue:
    gh issue comment <issue-number> --body "<agent-brief-content>"
    (If transitioned to needs-info or wontfix, follow the corresponding comment or closing procedures defined in the triage skill).

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.