identify-doc-code-disagreements
Identify places in the $1 library where the docs and code disagree
Best use case
identify-doc-code-disagreements is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Identify places in the $1 library where the docs and code disagree
Teams using identify-doc-code-disagreements 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/identify-doc-code-disagreements/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How identify-doc-code-disagreements Compares
| Feature / Agent | identify-doc-code-disagreements | 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?
Identify places in the $1 library where the docs and code disagree
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
Go gather all the context for the $1 library (per instructions in CLAUDE.md). Be sure to read non_issues.md as well. Once you've gathered that context, please do the below (and commit when you're finished). Your task is to identify disagreements between the implementation and the documentation in the $1 library. In particular, focus on logical, meaningful conflicts between what is said in any written documentation and what is actually implemented in the code. Do NOT worry about functionality that is still clearly in-progress, under construction, etc--if something simply has not yet been implemented, that's ok. At most, you can suggest that the code be better about raising a NotImplementedError in such cases. We want to focus on issues where something actually *is* implemented, but it's not implemented *how* the docs say it should be. Do NOT worry other disagreements between really long, claude-generated "spec" files and the code (those are usually just left-over construction artifacts). If anything, you can simply highlight places where there was a big detailed spec that should have been deleted. Do NOT worry other types of issues besides conflicts between the docs and code. Do NOT report issues that are already covered by an existing FIXME Do NOT report issues that are highlighted as non-issues in non_issues.md After reviewing all the code in the library, think carefully about the most important disagreements between the docs and code. Then put them, in order from most important to least important, into a markdown file in the library's "_tasks/docs/" folder (make one if you have to) Name the file "<date>.md` (where you should get "date" by calling this precise command: "date +%Y-%m-%d-%T | tr : -") For the format of the file, use the following: ```markdown # Doc and code disagreements in the $1 library (identified on <date>) ## 1. <Short description of disagreement> Description: <detailed description of the disagreement, including file names and line numbers where applicable> Recommendation: <your recommendation for how to fix the disagreement> Decision: Accept ## 2. <Short description of disagreement> Description: <detailed description of the disagreement, including file names and line numbers where applicable> Recommendation: <your recommendation for how to fix the disagreement> Decision: Accept ... ``` There's no need to commit when you're done (these files are gitignored). Just be sure to create the file in the right location with the right content.
Related Skills
identify-style-issues
Identify divergences from the style guide in the $1 library
identify-outdated-docstrings
Identify outdated docstrings in the $1 library
identify-inconsistencies
Identify inconsistencies in the $1 library
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
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.
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