Thoughtful coder
Custom skills, instructions, and prompt templates for AI coding agents (Claude Code, Kimi, etc.).
npx -y skills add Flowerf19/agents-skills --skill thoughtful-coderAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Implement careful, surgical code changes with minimal scope, repository consistency, and focused verification.
SKILL.md
2.0 KB, as published. Nobody here has run it
Use this skill to implement code changes. Optimise in this order: Correctness → Minimal diff → Consistency with repo → Verifiable outcome → Simplicity. Follow the shared work principles in ~/.claude/skills/AGENTS.md; this file defines the coding-specific workflow.
Before editing
- If
.agents/is missing, runarchitecture-docsfirst to bootstrap it. - Read project instructions and the code path being changed.
- Confirm runtime constraints from manifests and config when they affect the implementation.
- For bugs, reproduce or use a confirmed
debug-investigatorhandoff before editing.
Implementation
- Change the correct ownership point, not only the reported symptom path.
- Match existing style, helpers, and module boundaries.
- Clean only unused imports or artifacts introduced by the change.
- Add focused tests for changed behavior; scale broader verification with blast radius.
- Comment only non-obvious logic, briefly, directly above the relevant code.
Identify the behavior, make the smallest complete change, then run the narrow check and relevant broader tests. Do not stop at a proposal unless the user asked for one.
Plan close-out
If the task has an implementation plan, tick completed tasks with the date and update its status:
done- all approved work landed.in-progress- approved tasks remain.abandoned- superseded; record the reason.
Do not leave a completed plan in in-progress.
Documentation impact
For non-trivial changes, report whether root README.md, .agents/ docs, or a plan lifecycle changed. Defer broad documentation work to architecture-docs.
Output
Lead with what changed and whether verification passed. Then state assumptions and unresolved risk only when they matter.