agentleFS
Sign inStart free
alexchen5alexchen5/research-epic-manager/skills/issue-manager/SKILL.md

issue-manager

Skill0 starsChanged 2 months agoMITView on GitHub

Use this skill when a chat is asked to work on, execute, progress, resolve, or close an issue under EPICS_ROOT/. - "work on issue X", "execute this issue", "pick up issue", "close issue", "issue manager". Defines the issue-manager protocol: the parent chat working an issue is the issue manager - the only role allowed to change issue state, append issue comments, and dispatch sub-agents. Coding and reviewer sub-agents are isolated from issue concepts and interact only with the issue manager.

3 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions3 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 3

    1. KenosInc/sigrok-mcp-server★ 12same name
    2. icetomoyo/CodingSkills★ 4same name
    3. fworks-tech/agenthood★ 3same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository6 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Only the issue manager dispatches agents: No agent-to-agent communication exists in this protocol - every sub-agent's results return to its …

    line 41
  2. Very specific:

    Verify before believing: When a coder reports, the issue manager re-runs the key verification (tests/build/lint) itself.

    line 69
  3. Very specific:

    Every non-trivial state transition gets a comment only when there is narrative worth recording (decision, blocker, resolution) - see …

    line 97

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 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

Issue Manager

Protocol for working an issue in the EPICS_ROOT/ tracker. When a chat is asked to work on an issue, that chat is the issue manager for the duration of the work. This skill is normative for the parent chat; the mechanics of dispatching the sub-agents live in the issue-subagent-orchestration skill.

Roles

RoleWhat it isMay do
Issue managerThe parent chat working the issue (you)Read/write the issue (status, metadata, resolution), append comments via the add-comment skill, dispatch sub-agents, verify results, close the issue
Coding agentA dispatched sub-agent (fresh context)Edit project code/files and report results to the issue manager only
Reviewer agentA dispatched sub-agent (fresh context)Read code + requirements and report a verdict to the issue manager only

Hard rules

  1. Only the issue manager mutates issue state. Status, metadata, and resolution are written to ISSUE.md by the issue manager alone.
  2. Only the issue manager appends issue comments (via the add-comment skill). Coding/reviewer agents never write to the tracker.
  3. Only the issue manager dispatches agents. No agent-to-agent communication exists in this protocol - every sub-agent's results return to its dispatcher (the issue manager), which is how the harness works natively.
  4. Coding/reviewer agents have no idea about the concept of issues. Their briefs contain no paths under EPICS_ROOT/, no ISSUE.md content, no lifecycle vocabulary (open/blocked/resolved/closed/...), and no comment protocol. They receive a self-contained engineering task: files, requirements (the acceptance criteria rephrased as task requirements), done criteria, out-of-scope. If a sub-agent needs information that lives in the issue thread, the issue manager retrieves it and passes it in a follow-up brief - the sub-agent never reads the tracker itself.
  5. The manager orchestrates; agents implement. The issue manager does not write code itself, except when the user explicitly asks the manager to make a change directly.

Working an issue - standard flow

  1. Read the issue. cat EPICS_ROOT/<epic>/issues/<issue>/ISSUE.md and skim the thread in comments/. If the status is draft, author and promote it first (via add-issue --promote or the promote-issue.py wrapper).
  2. Claim it. Set Status: open in ISSUE.md Metadata if it is not already open (update the Updated date).
  3. Plan the dispatch. Decide how to split the work (single coder vs. parallel modules) - see issue-subagent-orchestration.
  4. Dispatch coding agent(s) with self-contained briefs (templates in issue-subagent-orchestration).
  5. Verify before believing. When a coder reports, the issue manager re-runs the key verification (tests/build/lint) itself. A coder's self-report is a claim, not evidence.
  6. Dispatch a reviewer with the changed files + the requirements.
  7. Act on the verdict.
    • APPROVE -> record the resolution in ISSUE.md (Resolution & PRs), set Status: resolved (or closed), and append one summary comment via add-comment if there is narrative worth recording.
    • REJECT -> send the findings back to the coder (send_message to the same sub-agent, or a fresh dispatch) and repeat. After 3 rejected rounds, stop and escalate: set Status: blocked with a comment explaining the loop.
  8. Blocked? Set Status: blocked and append a comment recording the blocker (what is missing, what unblocks it).

State machine

draft -> open -> resolved
         \
          blocked -> open -> closed
  • Status lives in ISSUE.md Metadata and is written only by the issue manager.
  • The ## Comments section of ISSUE.md is reserved - actual comments live as files in comments/ (one file per comment, via add-comment); never write ad-hoc notes into the ISSUE.md section.
  • Every non-trivial state transition gets a comment only when there is narrative worth recording (decision, blocker, resolution) - see add-comment/references/comments-best-practices.md. Status changes themselves are not commented.

What the issue manager never does

  • Lets a sub-agent touch EPICS_ROOT/ (no issue paths in briefs).
  • Marks an issue resolved on a coder's self-report without manager-side verification and a reviewer verdict.
  • Dispatches agents "to read the issue" - briefs are the contract.
  • Edits historical comments (append-only thread).

Related skills

  • issue-subagent-orchestration - the DSH-native dispatch mechanics (tools, brief templates, review loop, parallelism).
  • add-issue - creates issues; owns the draft -> open readiness gate.
  • add-comment - appends comments to the thread.
  • add-epic - creates the epic that scopes the issue.

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.

Check your setup, free