create-github-issues-from-file
Convert a file containing identified issues into GitHub issues. Use after running identify-* commands to create corresponding GitHub issues.
Best use case
create-github-issues-from-file is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Convert a file containing identified issues into GitHub issues. Use after running identify-* commands to create corresponding GitHub issues.
Teams using create-github-issues-from-file should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/create-github-issues-from-file/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How create-github-issues-from-file Compares
| Feature / Agent | create-github-issues-from-file | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Convert a file containing identified issues into GitHub issues. Use after running identify-* commands to create corresponding GitHub issues.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Creating GitHub Issues from Issue Files
This skill provides guidelines for converting issue files (created by the identify-* commands) into GitHub issues.
## Overview
Issue files are markdown files located in `_tasks/<category>/` directories within a library. Each file contains a list of identified issues (inconsistencies, style issues, outdated docstrings, etc.) that should be tracked as GitHub issues.
## Process
Follow these steps to convert an issue file into GitHub issues:
### 1. Find the Newly Created Issue File
Look for recently created markdown files in the library's `_tasks/` directory. The file will be in a subdirectory that indicates the issue category:
- `_tasks/inconsistencies/` - Code inconsistencies
- `_tasks/docs/` - Documentation and code disagreements
- `_tasks/style/` - Style guide violations
- `_tasks/docstrings/` - Outdated docstrings
### 2. Determine the Label
The label for GitHub issues should be based on the folder name under `_tasks/` where the issue file was created. For example:
- If the file is in `_tasks/docstrings/`, the label should be `docstrings`
- If the file is in `_tasks/inconsistencies/`, the label should be `inconsistencies`
- If the file is in `_tasks/style/`, the label should be `style`
- If the file is in `_tasks/docs/`, the label should be `docs`
### 3. Load All Open GitHub Issues with This Label
Query GitHub for all open issues with this label using:
```bash
gh issue list --label "<label>" --state open --json number,title,body,state --limit 1000
```
This returns all open issues with the specified label so you can avoid creating duplicates.
### 4. Create New GitHub Issues
For each issue in the file that does not already exist in GitHub:
1. Parse the issue from the markdown file (each issue is typically a numbered section like `## 1. <title>`)
2. Check if a similar issue already exists by comparing titles and descriptions
3. If no matching issue exists, create a new one:
```bash
gh issue create --title "<Short description>" --body "<Full issue content>" --label "<label>" --label "autoclaude"
```
**Important:** Always include the `autoclaude` label when creating new issues. This label identifies issues that were automatically created by Claude and helps with downstream processing (e.g., converting triaged issues to FIXMEs).
The body should include all data from the issue file, including:
- The full description of the issue
- File names and line numbers where applicable
- The recommendation for how to fix it
- etc.
### 5. Update Existing Issues
For any issues that already exist in GitHub but have new data or details in the file:
```bash
gh issue edit <issue_number> --title "<Updated description>" --body "<Updated body content>"
```
Only update if there is meaningful new information to add.
### 6. Refresh the Issue List
After creating and updating issues, query GitHub again to get a consolidated view:
```bash
gh issue list --label "<label>" --state open --json number,title,body,createdAt --limit 1000
```
### 7. Rank Issues by Importance
Review all open issues with this label and create your own ranking from most important to least important. Consider:
- Impact (how important it is to fix the issue, how confusing the current state is, etc.). Higher impact = more important
- Certainty (how likely this issue is to actually be a problem). Higher certainty = more important
- Effort required to fix. Lower effort = more important
Make an explicit ranked list of issue numbers in order from the most important to the least important by writing the issue numbers to a file (ranked_issue_list.txt) in order from most important to least important, one per line.
### 8. Prune Excess Issues
If there are more than 50 open issues with this label, delete the least important ones until only 50 remain:
```bash
tail -n +51 ranked_issue_list.txt | xargs -I {} gh issue delete {} --yes
```
### 9. Update Timestamps for Sorting
In reverse order (from least important to most important), update each open issue by adding and then removing the "updated" label. This will cause them to sort properly when viewing by "recently updated".
This can be done by running the following commands:
```bash
head -n 50 ranked_issue_list.txt > reversed_issue_list.txt
tac reversed_issue_list.txt | xargs -I {} gh issue --add-label updated
tac reversed_issue_list.txt | xargs -I {} gh issue --remove-label updated
```
## Notes
- The issue file formats vary slightly between different identify-* commands, but all follow a similar pattern with numbered sections
- Always check for duplicates before creating new issues
- Use your judgment when determining if an existing issue should be updated vs. left as-is
- The 50-issue limit per label helps keep the issue backlog manageableRelated Skills
update-issues-in-repo
Convert a file containing identified issues into a tracked file in current_tasks/. Use after running identify-* commands to create a local record of current issues.
identify-style-issues
Identify divergences from the style guide in the $1 library
create-task-from-json
Create a prompt from a short task description in a JSON file
create-fixmes
Create FIXME's in the codebase for each of the issues in the given input file.
convert-github-issues-to-fixmes
Convert triaged autoclaude GitHub issues into FIXMEs in the codebase. Use when you want to process issues that have been triaged by authorized users.
writing-specs
Write high quality specifications or design docs for a program. Use any time you are asked to write, improve, or update specs / design docs (e.g., files in a `specs/` folder).
writing-ratchet-tests
Write ratchet tests to prevent accumulation of code anti-patterns. Use when asked to create a "ratchet test" for tracking and preventing specific code patterns (e.g., TODO comments, inline imports, broad exception handling).
writing-docs
Write high quality, user-facing documentation. Use any time you need to write, improve, or update a significant amount of user-facing documentation (e.g., files in a "docs/" folder or README file).
wait-for-agent
Wait for another agent to enter WAITING state, then execute follow-up instructions
triage-backlog
Interactively triage the user's local engineering backlog file into GitHub issues. Use when the user wants to process their raw thought notes / ticket backlog into proper GitHub issues.
think-of-something-to-fix
Come up with good ideas about what to fix. Use when you have to fix something, but you're not sure what.
sync-tutorial-to-e2e-tests
Match tutorial script blocks to e2e pytest functions and add missing tests