What does this skill do, and when should you use it?
neat-freak is a knowledge-governance skill that performs 'knowledge closeout' after development: it aligns README/docs, CLAUDE.md/AGENTS.md rule files, agent memory, and workspace residue with what the code and runtime actually do, so the next session or person starts from one current answer. It offers a lightweight path for small projects and a full path for projects with release workflows and remote collaboration. It is read-only by default, never deletes anything without explicit user confirmation, and produces a structured handoff report. Trigger with '/neat', '洁癖', or any clear intent like 'sync docs and memory'.
Reads the project root and all Markdown files (skipping dependency and build dirs), runs scripts/audit-inventory.sh for read-only inventory (or manual equivalent if Bash unavailable). Cross-checks documentation and rule files against code and runtime truth, fixing outdated or conflicting commands, ports, dependencies, and feature descriptions. Audits rule files (CLAUDE.md/AGENTS.md) for dead references, conflicting hierarchy rules, and missing required files. Identifies session residue (PLAN.md, debug scripts, xxx_old copies) as deletion candidates and waits for user confirmation. Finally produces a two-phase report marking each fact surface's status (verified-current, changed-and-verified, pending, etc.) and listing unresolved contradictions.
- Solo developer: Just finished a feature iteration and README is outdated — run /neat to sync docs to code reality.
- Team collaboration: Preparing a handoff to a teammate, run neat-freak to ensure CLAUDE.md API list matches actual routes, avoiding misinformation.
- Release closeout: Before a release, use the full path to verify local, remote, and production states, then clean merged branches and temp files.
- Auditing rule enforcement: Suspect project rules aren't being followed, use it to check for missing required files and broken command references.
- Onboarding to a new project: A newcomer uses the lightweight path to generate a minimal AGENTS.md/CLAUDE.md to quickly regain context.
How do you install this skill?
- The skill involves file writes and deletions; ensure explicit user consent and confirmation before any destructive actions.
- Relies on external tools like git and rg and platform rules; ensure they are available and configured properly in the target environment.
- Static review only; actual performance needs runtime validation.
- Shell / CLI
- Local filesystem
Gitrg
In an Agent Skills-compatible tool (Claude Code, Codex), simply say: 'Install this skill: https://github.com/KKKKhazix/khazix-skills/tree/main/neat-freak'. The agent clones it into the right place. For tools without Skill support, download the full neat-freak/SKILL.md and use it as a project rules file or paste it into the conversation.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/KKKKhazix/khazix-skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/neat-freak" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- sync docs and memory
- clean up after development
After installation, trigger it in a session by typing '/neat' or '洁癖', or by stating a closeout intent like 'sync docs and memory' or 'clean up after development'. It runs automatically and outputs a report: files changed/created, deletion candidates awaiting confirmation, and lingering contradictions. Note: machine-generated memory (e.g., from Codex) is read-only by default; deletions happen only after you explicitly confirm the report.
What are this skill's strengths and limitations?
- Automatically aligns docs, rules, memory, and code, reducing knowledge rot.
- Two paths (lightweight/full) suit both small and complex projects.
- Read-only by default; deletions always require user confirmation, ensuring safety.
- Built-in final self-check ensures every fact surface has an explicit status.
- Depends on shell and rg; without Bash it falls back to manual checks, reducing efficiency.
- Machine-generated memory (e.g., Codex) cannot be edited directly; must use official control surfaces.
- No public test suite yet; real-world effectiveness depends on the use case.
- Trigger conditions are strict; pure coding tasks or data/weekly-report tidying won't trigger it.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| neat-freak — Knowledge & Governance Closeout this page | 63 · Recommended | ★ 21k | 10d ago | MIT |
| Engram Architecture Guardrails | 50 · Use with care | ★ 7.1k | 4d ago | MIT |
| BlockWatch | 67 · Recommended | ★ 29 | 3d ago | MIT |
| Claude Reflect Self-Learning Memory | 57 · Use with care | ★ 1.8k | 8d ago | MIT |
| NeMo-RL Session Memory ✓ NVIDIA · Official | 51 · Use with care | ★ 3.5k | 3d ago | Apache-2.0 |
How did FollowSkills review this skill?
The skill mandates writes only under user authorization and existing rules, destructive actions require reporting and explicit confirmation, deletions are only proposed as candidates. It respects permissions and confirmation. However, permission details depend on external agent and platform rules, and implementation is unverified, hence deduction to 18.
Provides clear execution process including light and full paths, with self-check. Depends on git and rg but offers alternatives. Includes evals but not executed. No actual testing, thus cap at 10.
Clear scenarios and triggers, with positive and negative examples, suitable for Chinese users. Primarily local files, no overseas services. May not cover all environment variations and untested, thus 12.
Well-structured docs with version, category, reference links, evals and LICENSE. Limited maintenance responsibility and update path, no changelog, thus 11.
Aims to reconcile docs, rules and memory; methods and self-check seem plausible. But static review cannot confirm actual task completion efficiency, evals not executed, hence cap at 7.
Provides evals and self-check but not executed, no third-party execution evidence. Hence cap at 5.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →