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.
Best use case
update-issues-in-repo is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
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.
Teams using update-issues-in-repo 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/update-issues-in-repo/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How update-issues-in-repo Compares
| Feature / Agent | update-issues-in-repo | 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 a tracked file in current_tasks/. Use after running identify-* commands to create a local record of current 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
# Updating Issues in Repository This skill provides guidelines for converting issue files (created by the identify-* commands) into tracked issue files stored directly in the repository. ## Overview Issue files are markdown files located in `_tasks/<category>/` directories within a library (these are gitignored). This command converts them into tracked files at `current_tasks/<category>.md` within the same library, which are committed to the repository. ## Process Follow these steps to convert an issue file into a tracked repository file: ### 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 Category and Output Path The category is determined by the folder name under `_tasks/` where the issue file was created. The output file should be: - Input: `libs/<library>/_tasks/inconsistencies/<date>.md` - Output: `libs/<library>/current_tasks/inconsistencies.md` Create the `current_tasks/` directory in the library if it doesn't exist. ### 3. Load the Existing Issues File (if any) If `current_tasks/<category>.md` already exists, read its contents to identify existing issues that may need updating or merging. ### 4. Parse Issues from Both Files Issues in the markdown files follow this format: ```markdown ## <number>. <Short description> Description: <detailed description> Recommendation: <recommendation> Decision: <Accept|Reject|Pending> ``` Parse all issues from: 1. The new issue file (from `_tasks/<category>/`) 2. The existing `current_tasks/<category>.md` file (if it exists) ### 5. Merge Issues For each issue in the new file: 1. Check if a similar issue exists in the current file by comparing titles and descriptions 2. If a matching issue exists, update it with any new information from the new file 3. If no matching issue exists, add it as a new issue For issues that exist in the current file but not in the new file: - Keep them (they may still be valid, just not re-identified this time) ### 6. Sort and Number Issues Sort all issues by importance (same criteria as the identify-* commands use): - Impact (higher = more important) - Certainty (higher = more important) - Effort to fix (lower = more important) Renumber all issues starting from 1. ### 7. Write the Output File Write the merged, sorted issues to `current_tasks/<category>.md` with the format: ```markdown # Current <Category> Issues Last updated: <current date/time> ## 1. <Short description> Description: <detailed description> Recommendation: <recommendation> Decision: Accept ## 2. <Short description> ... ``` ### 8. Commit the Changes Commit the updated file with a descriptive message: ```bash git add libs/<library>/current_tasks/<category>.md git commit -m "Update current <category> issues for <library>" ``` ### 9. Fetch and Merge Main Before pushing, ensure you have the latest changes from main: ```bash git fetch origin main git merge origin/main --no-edit ``` If there are merge conflicts in the `current_tasks/` file, resolve them by keeping the most comprehensive version of each issue. ### 10. Push Directly to Main Since this only contains documentation updates (the current issues list), push directly to main: ```bash git push origin HEAD:main ``` ## Important Notes - The `current_tasks/` directory should NOT be gitignored (unlike `_tasks/`) - This provides a quick reference of current known issues without needing GitHub - The file is meant to be a living document that gets updated as issues are identified and resolved - When issues are fixed, they can be removed from the file manually or by running this command again with an updated source file - The "Decision" field can be set to "Accept" (will be fixed), "Reject" (not a real issue), or "Pending" (needs discussion)
Related Skills
identify-style-issues
Identify divergences from the style guide in the $1 library
create-github-issues-from-file
Convert a file containing identified issues into GitHub issues. Use after running identify-* commands to create corresponding GitHub issues.
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
minds-dev-iterate
Set up and iterate on the minds app stack (desktop client, workspace server, mngr, forever-claude-template) with a running Docker agent
message-agent
Send a message to another mngr agent. Use when you need to communicate with a peer agent.