Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/fotoetienne/gru/github-issuesnpx skills add fotoetienne/gru --skill github-issuesgit clone --depth 1 https://github.com/fotoetienne/gruWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00062 | $0.01497 |
| Opus 5 | $0.00031 | $0.00749 |
| Sonnet 5 | $0.00012 | $0.00299 |
| Haiku 4.5 | $0.00006 | $0.00150 |
Grade A, and why
github-issues scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 175 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are an expert at managing GitHub issues for the Gru project. Follow these conventions exactly.
Creating Issues
Use gh issue create with a heredoc body:
gh issue create --title "Clear, specific title" --body "$(cat <<'EOF'
## Description
What this issue addresses.
## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2
**Blocked by:** #X, #Y
EOF
)"
- Keep titles concise and actionable
- Include acceptance criteria when possible
- Add
**Blocked by:** #X, #Yin the body if the issue has dependencies (see Dependencies below) - Add labels with
--label "gru:todo"or other appropriate labels
Dependencies (CRITICAL)
Gru uses a two-layer dependency system. Always set dependencies both ways:
Layer 1: Body text (ALWAYS do this — works everywhere including GHES)
Include **Blocked by:** #X, #Y in the issue body. This must be:
- On a single line (only the first line after the marker is parsed)
- Using
#prefix for issue numbers (bare numbers are ignored) - Same-repo only (cross-repo references like
owner/repo#123are skipped)
When editing an existing issue to add blockers, prepend the line to the body:
# Get current body, prepend blocked-by line
CURRENT_BODY=$(gh issue view 123 --json body --jq .body)
gh issue edit 123 --body "**Blocked by:** #10, #20
$CURRENT_BODY"
Layer 2: Native GitHub Dependencies REST API (always attempt after body text)
The native API requires the blocker's internal id (not the issue number):
# 1. Get the internal id of the blocking issue
BLOCKER_ID=$(gh api /repos/OWNER/REPO/issues/BLOCKER_NUMBER --jq .id)
# 2. Set the dependency: BLOCKED_ISSUE is blocked by BLOCKER
gh api /repos/OWNER/REPO/issues/BLOCKED_NUMBER/dependencies/blocked_by \
-f issue_id="$BLOCKER_ID"
Error handling for native API
After each gh api POST, check the exit status:
- 404 / "Not Found": GHES without native dependency support — log a warning and continue. Body-text
**Blocked by:**is the universal fallback. - Other errors (422, 500, etc.): Surface the error to the user so dependency setting doesn't silently fail.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 175 lines · 62 tokens per session scan A 2f95108eef47
github-issues is a skill published in the GitHub repository fotoetienne/gru (11 stars, last pushed 25d ago), licensed Apache-2.0. It adds 62 tokens to every session and 1,497 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
github-image-upload
Upload local images and other files (PDF, zip, log, …) to GitHub and embed them in a pull request description, an issue, or a comment — producing canonical github.com/user-attachments URLs (private-repo uploads stay private). Use when asked to "attach a screenshot to the PR", "add an image to the PR description", "put…
wfdash
Serve wayfinder maps held in GitHub Issues as a local browser dashboard — one map drawn as a dependency DAG, plus an overview of every map across every repo. Use when the user asks what to work on next, wants to see a map's shape or frontier, wants to read a resolved ticket's decision, or types /wfdash. Also use for…
workingon
Record the work done in this Claude Code session in the configured ticketing tool (Jira, Linear, GitHub Issues, Trello or Vikunja), creating the ticket, adding a short progress comment, linking an existing one or closing it. Use it when the [workingon] hook reports unrecorded work, when the user types /workingon, and…
release
Automate project release workflow with version management, CHANGELOG updates, and git operations.
daf-issue-topo-sort
Dependency and conflict-aware issue ordering with topological sort.
daf-jira-mcp
Using MCP JIRA tools with DevAIFlow validation logic and field intelligence.