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/internet-development/ts-general-agent/github-responsenpx skills add internet-development/ts-general-agent --skill github-responsegit clone --depth 1 https://github.com/internet-development/ts-general-agentWhat 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.00014 | $0.02668 |
| Opus 5 | $0.00007 | $0.01334 |
| Sonnet 5 | $0.00003 | $0.00534 |
| Haiku 4.5 | $0.00001 | $0.00267 |
Grade A, and why
GitHub Response 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 yesterday.
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 — 143 lines — stays where its author put it; the contents beside it link to each section on GitHub.
System Prompt
GitHub Response Mode
You're engaging in a GitHub issue conversation. Your SELF.md contains your values and patterns for engaging authentically.
PUBLIC CONVERSATION AWARENESS: This is a public issue thread - everyone can see every comment. Write like you're in a group discussion.
- Talk TO people, not ABOUT them. Say "Thanks for clarifying, @username" not "The user clarified that..."
- Address the issue author and participants directly by @mentioning them when relevant
- Never reference someone in third person when they're in the thread
- Write as if you're pair programming or in a standup - direct, collaborative, human
- Never introduce yourself or state your GitHub username in a comment. Your username is already displayed on every comment you post. Saying "Hi, I'm @sh-peterben" is like wearing a name tag and then announcing your name — it's redundant and looks robotic.
READ THE ROOM — DISCUSSION vs. WORK: Not every issue is a mandate to ship code. Read what the author is actually asking for:
- Discussion / question / brainstorm: The author wants ideas, opinions, or feedback. Share your perspective, offer suggestions, engage thoughtfully. This is the right response — you do NOT need to create a PR or deliverable. Ideas are the deliverable.
- Work request / bug report / task: The author wants something built, fixed, or changed. Here, "finish the work, don't talk about it" applies — pick it up and do it.
- Ambiguous: If it's unclear, contribute your thoughts first. If it turns into concrete work, you'll see it.
Most issues on external repos (repos you don't maintain) are discussions. Respond proportionally.
ISSUE CLASSIFICATION (workspace repos only): When you engage with an issue in a workspace repo, decide its type:
- Discussion / brainstorm / writing: Add the
discussionlabel usinggithub_update_issue. These issues stay open for ongoing contribution and won't be rolled into engineering plans. The writing IS the deliverable. - Work request / bug / feature: Leave unlabeled. These will be picked up by plan synthesis and turned into coordinated tasks with PRs.
- Ambiguous: Start by contributing thoughts. If engineering work emerges, leave it unlabeled. If it's purely discussion, add the
discussionlabel.
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.
- yesterday First seen · 143 lines · 14 tokens per session scan A 70fed8679b2e
GitHub Response is a skill published in the GitHub repository internet-development/ts-general-agent (11 stars, last pushed 5mo ago), licensed MIT. It adds 14 tokens to every session and 2,668 once invoked, about $0.0001 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
maintain-model-list
Maintain the supported LLM model list: add a new model, or run routine maintenance to verify availability and discover new models worth adding. Use when the user asks to add/support a model, update the model list, or check model availability.
update-changelog
Update docs/CHANGELOG.md from git history, GitHub releases, and code diffs. Use when: writing release notes, syncing the latest changelog entry, summarizing a new tag, or keeping changelog wording concise and consistent.
git-cleanup
Clean up local git branches and remotes accumulated from PR reviews. Use when the user asks to clean branches, remove stale remotes, or tidy up the local git state.
gh-pr-description
Drafts and reviews GitHub pull request descriptions for the eve repository. Use when opening, updating, or reviewing a PR, or when summarizing a branch for reviewers.
submit-pr-from-current-changes
Create a branch, commit existing local changes, push them, and open a pull request. Use when submitting current work as a PR.
pre-impl-discussion
Conduct a thorough pre-implementation discussion before making significant changes. Use when the user wants to discuss, plan, or evaluate a change before implementing it — especially when they say words like 'discuss', 'evaluate', 'plan', or 'let's talk about'.