filing-issues
Skill131 starsChanged 8 days agoApache-2.0View on GitHub
Investigates a bug or small feature and drafts a GitHub issue with root cause, cross-cutting checklist, and plan, without implementing it. Use when something is identified but will not be fixed now; significant or uncertain changes use writing-rfcs instead.
In this repository12 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adding-chart-marksSkill
- adding-child-componentsSkill
- adding-propsSkill
- chart-featuresSkill
- comparing-time-periodsSkill
- fixing-bugsSkill
- implementing-milestonesSkill
- s2-design-tokensSkill
- summarizing-bugsSkill
- writing-rfcsSkill
- writing-s2-docs-pagesSkill
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 8 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
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
- Very specific: line 8
Use when a bug or small feature has been identified but won't be done immediately.
- Very specific: line 12
Read planning/README.md first, particularly "Issues" and "Cross-cutting concerns."
- Distinctive: line 14
Don't implement the fix as part of this skill.
- Distinctive: line 23
Search existing issues before investigating, so you don't file a duplicate:
- Distinctive: line 29
If a matching issue exists, update or comment on it instead of filing a new one.
- Distinctive: line 33
If the environment provides a semantic code-search or navigation tool (e.g.
- Distinctive: line 37
Read the encoding/logic for the affected behavior
- Distinctive: line 46
Check whether the component exists in both the S1 and S2 packages, and whether each actually has the bug.
- Distinctive: line 94
Check every cross-cutting item against the code.
- Distinctive: line 95
Keep the root cause to a tight paragraph per defect.
≈ “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.
Files
File an Issue
Use when a bug or small feature has been identified but won't be done immediately.
Investigates it and drafts a GitHub issue. Significant or uncertain changes need an RFC
instead; use writing-rfcs.
Read planning/README.md first, particularly "Issues" and "Cross-cutting concerns."
Don't implement the fix as part of this skill. The goal is a clear, actionable issue.
Step 1 — Clarify scope
Confirm the symptom or request, the affected component, and what correct behavior looks like. Ask if any of these are unclear.
Search existing issues before investigating, so you don't file a duplicate:
gh issue list --repo adobe/react-spectrum-charts --state all --search "<keywords>"If a matching issue exists, update or comment on it instead of filing a new one.
Step 2 — Investigate
If the environment provides a semantic code-search or navigation tool (e.g. an MCP-based code index), prefer it over manual grep/read for locating symbols and tracing call paths. Otherwise, spawn an Explore subagent to:
- Find the relevant source files for the reported area
- Read the encoding/logic for the affected behavior
- Compare against similar working code (e.g. line mark vs. line points, or the S2 sibling file if one exists). This comparison often reveals the fix direction.
- Note exact file paths and line numbers where the divergence is, or where the behavior is missing
For bugs, reproduce on current main when you can (a story, a test, or a browser check). If
the root cause can't be confirmed, say so plainly and give the leading hypothesis.
Check whether the component exists in both the S1 and S2 packages, and whether each actually has the bug. Don't assume both do; verify.
Step 3 — Draft the issue
Title: a short statement of the problem, prefixed with S2 if it's S2-only (e.g. "S2 Line:
dotted line gap too tight").
Body:
## Summary
One or two sentences.
## Symptom
<!-- Feature requests: "## Motivation" instead. -->
What the user sees.
**Expected:** ...
**Actual:** ...
## Root cause
<!-- Feature requests: "## Proposed behavior" instead. -->
Technical explanation with `file:line` references. Say if it's unconfirmed.
## Cross-cutting concerns
- [ ] Hover animation
- [ ] Controlled highlight
- [ ] Legend interaction
- [ ] Tooltip or popover
- [ ] New signal or scale
- [ ] S1/S2 parity
Notes for any that are checked.
## Implementation plan
- `path/to/file.ts` — what changes and why
## Open questions
- ...Check every cross-cutting item against the code; don't leave one unchecked without looking. Keep the root cause to a tight paragraph per defect. If the investigation found a separate defect, draft a separate issue and link them.
Labels: bug or enhancement, rsc:<Component> for each affected component, and s2
if it affects S2.
Step 4 — Confirm and create
Show the user the title, labels, and body. Create the issue only after they approve:
gh issue create --repo adobe/react-spectrum-charts --title "..." --label bug --label s2 \
--label rsc:Line --body-file <file>Report the issue URL.
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
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.