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/eveld/claude/linear-updatenpx skills add eveld/claude --skill linear-updategit clone --depth 1 https://github.com/eveld/claudeWhat 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.00027 | $0.01226 |
| Opus 5 | $0.00014 | $0.00613 |
| Sonnet 5 | $0.00005 | $0.00245 |
| Haiku 4.5 | $0.00003 | $0.00123 |
Grade A, and why
linear-update 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 3d 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 — 178 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Update Linear Issue
Update Linear issues with debugging findings, status changes, and investigation notes.
When to Use
- Adding debugging findings as comments
- Updating issue status after investigation
- Adding labels for categorization
- Changing priority based on severity
- Recording root cause analysis
Pre-flight Checks
Authentication
# Check linearis is available and authenticated
linearis --version 2>/dev/null || {
echo "linearis CLI not installed"
exit 1
}
linearis issues list --limit 1 >/dev/null 2>&1 || {
echo "Not authenticated to Linear"
exit 1
}
Common Commands
1. Add Comment
# Add single-line comment
linearis comments create ENG-1234 --body "Root cause identified: database connection pool exhausted"
# Add multi-line comment with heredoc
linearis comments create ENG-1234 --body "$(cat <<'EOF'
## Investigation Findings
**Root Cause**: Database connection pool exhausted
**Evidence**:
- GCP logs show "connection refused" errors starting at 10:30 UTC
- Kubernetes events show 1/3 pods in CrashLoopBackOff
- Pod describe shows max_connections reached
**Timeline**:
- 10:28 UTC: Traffic spike to 3x normal
- 10:30 UTC: First connection errors
- 10:32 UTC: Pod restarts begin
**Recommendation**: Increase database connection pool limit from 100 to 250
EOF
)"
2. Update Issue Status
# Change state to "In Progress"
linearis issues update ENG-1234 --state "In Progress"
# Change state to "Done"
linearis issues update ENG-1234 --state "Done"
# Common states: "Backlog", "Todo", "In Progress", "In Review", "Done", "Canceled"
3. Update Priority
# Set priority (1 = Urgent, 2 = High, 3 = Medium, 4 = Low)
linearis issues update ENG-1234 --priority 1
# Lower priority after resolution
linearis issues update ENG-1234 --priority 4
4. Add Labels
# Add labels (comma-separated)
linearis issues update ENG-1234 --labels "bug,production,database"
# Add labels (adding mode - default)
linearis issues update ENG-1234 --labels "investigating" --label-by adding
# Replace all labels (overwriting mode)
linearis issues update ENG-1234 --labels "resolved,production" --label-by overwriting
# Clear all labels
linearis issues update ENG-1234 --clear-labels
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.
- 3d ago First seen · 178 lines · 27 tokens per session scan A a97347740190
linear-update is a skill published in the GitHub repository eveld/claude (10 stars, last pushed 7mo ago), licensed MIT. It adds 27 tokens to every session and 1,226 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-31.
Other skills, from other repositories
code-indexing-pipeline
How Infigraph turns source into a graph — adding a language (tree-sitter vs ANTLR grammar-plugin), cross-file call resolution, SCIP compiler-grade enrichment, and file-watch/reindex triage. Use when adding language support, debugging unresolved calls or SCIP import, or triaging stale index/watcher issues.
analysis-subsystems
How Infigraph's multi-repo/group mode and taint analysis work internally — HTTP contract extraction heuristics, cross-service edge linking, combined-graph merge, remote mode, plus taint's line-based tracking and sanitizer heuristic. Use when working on crates/infigraph-core/src/multi/ or src/taint/, or investigating…
review-pr-against-issue
Review one or more PRs against the GitHub issue(s) they claim to fix, including fetching PR branches directly when gh can't reach github.com (e.g. gh is authenticated to an enterprise host instead). Use whenever asked "does this PR fix issue.
golden-rss
Use when testing the rss golden build.
omh-buzz
This is a Hermes-native buzz workflow skill.
redteam-api-detail-pack
Domain routing and boundary guidance for authorized API security testing, including BOLA/IDOR, authentication bypass, mass assignment, missing rate limits, and GraphQL issues. Use when a task belongs to the API testing domain and needs scope, evidence, pivot, or exit criteria.