Borrowing it
Nothing to install: this file belongs to r3bl-org/r3bl-open-core. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/r3bl-org/r3bl-open-core/main/.agents/skills/fix-issue/SKILL.mdgit clone --depth 1 https://github.com/r3bl-org/r3bl-open-coreWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/r3bl-org/r3bl-open-core/fix-issue)<a href="https://agentmods.dev/skills/r3bl-org/r3bl-open-core/fix-issue"><img src="https://agentmods.dev/badge/skills/r3bl-org/r3bl-open-core/fix-issue/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/r3bl-org/r3bl-open-core/fix-issue"><img src="https://agentmods.dev/badge/skills/r3bl-org/r3bl-open-core/fix-issue.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Memory Poisoning · line 51 Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.Fix: Protect agent memory and state from modification by untrusted content. Use read-only memory for critical instructions and validate all state changes.
What 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.1 | $0.00021 | $0.00904 |
| Opus 5 | $0.00010 | $0.00452 |
| Sonnet 5 | $0.00004 | $0.00181 |
| Haiku 4.5 | $0.00002 | $0.00090 |
Grade A, and why
fix-issue 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 9d 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 — 105 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Issue Fix Workflow: Deep Exploration and Design
This skill codifies the "slow and steady" approach to solving non-trivial issues or adding features. It enforces exploring the problem space, considering alternative designs, and formalizing the design before writing any implementation code.
When to Use
Use this skill whenever you are:
- Creating a new task file for a non-trivial issue or feature.
- Asked by the user to "explore first", "design first", or "write a design doc".
- Working on complex or architectural changes that span multiple components.
The Design-First Workflow
The workflow consists of four distinct steps:
┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐ ┌───────────────────┐
│ 1. Deep Research │ ───► │ 2. Design Doc │ ───► │ 3. User Review │ ───► │ 4. Implementation │
│ (No Code Written) │ │ (Task MD File) │ │ & Approval │ │ (Iterative Step) │
└───────────────────┘ └───────────────────┘ └───────────────────┘ └───────────────────┘
Step 1: Deep Research (No Code Written)
Before proposing any changes or writing a task file, gather context on the problem space:
- Read the issue description (e.g., via
gh issue view <id>). - Search the codebase to locate all relevant files, traits, types, and usages.
- Understand the control flow, thread boundaries, and lifecycle constraints.
- Do NOT write or modify any code during this step.
Step 2: Design Doc (Task File Creation)
Create the task file under task/issue-<id>-fix.md or task/<name>.md.
Create a new git branch for this task, push it, and open a Draft PR using gh pr create --draft --fill to track the work.
Instead of a simple todo list, format this task file as a Design Document with the following sections:
1. Overview
- Clear statement of the goal.
- Context and reference to GitHub issues or PRs.
2. Problem Space & Constraints
- Detailed analysis of the current code.
- Specific limitations of the existing design.
- Architectural and safety constraints (e.g., thread safety, locks, lifetimes, platform compatibility).
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.
- 9d ago First seen · 105 lines · 21 tokens per session scan A dbf0b00deea8
fix-issue is a skill published in the GitHub repository r3bl-org/r3bl-open-core (483 stars, last pushed 2d ago), licensed Apache-2.0. It adds 21 tokens to every session and 904 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
cw-land
Use when turning verified Codewhale work into commits, branches, or a merge: choosing direct-main vs. worktree vs. integration branch, preserving contributor credit, and honoring the gate artifact before merging.
cw-slice
Use before writing code for any Codewhale feature, upgrade, or refactor: find the existing owner of the behavior, bound the change to one reviewable slice, and fix the evidence bar before you start.
cw-dogfood
Use when a Codewhale change needs proving in the real product, or when asked to build/install/dogfood the local binaries: stamped release build, atomic install, fresh-shell verification, and the manual QA that gates cannot cover.
cw-gates
Use before claiming any Codewhale change is done, green, or ready to land: the focused-to-broad verification ladder, the budget checks CI enforces, and the rules for what counts as a passing test.
best-of-n
Generate a small set of independent candidate solutions in worktrees, judge them against one explicit rubric, and apply the winner only after PASS verification.
contributor-onboarding
Help a new contributor get productive on this checkout - inspect sync state against main, build, run the repository's exact verification gate, and produce a local what's-new digest. Never fetches, pulls, or modifies a dirty tree on its own. Explicit-only.