Free SKILL.md scraped from GitHub. Clone the repo or copy the file directly into your Claude Code skills directory.
npx versuz@latest install codingthefuturewithai-claude-code-primitives-plugins-teamcraft-skills-refresh-project-rulesgit clone https://github.com/codingthefuturewithai/claude-code-primitives.gitcp claude-code-primitives/SKILL.MD ~/.claude/skills/codingthefuturewithai-claude-code-primitives-plugins-teamcraft-skills-refresh-project-rules/SKILL.md--- name: teamcraft:refresh-project-rules description: Re-evaluate what Claude needs to be told about this project as the codebase evolves. Some gotchas become obvious from the code (remove them). New gotchas emerge. Decisions change. Use when the user says 'refresh the rules', 'update Claude's context', 'are the rules still accurate', 'clean up claude rules', or after significant codebase changes. argument-hint: "(no arguments)" disable-model-invocation: false user-invocable: true allowed-tools: - Read - Write - Edit - Glob - Grep - Bash - AskUserQuestion --- ## Goal Re-evaluate `.claude/rules/` and `CLAUDE.md` to ensure they still contain exactly what Claude needs — no more, no less. As the codebase evolves, some constraints become obvious from the code (and should be removed from rules), new constraints emerge (and should be added), and existing decisions may have changed. ## What to Evaluate **1. Read the current rules.** Read every file in `.claude/rules/` and `CLAUDE.md`. Understand what each rule claims. **2. Check each rule against reality.** For every rule, constraint, or decision documented: - **Is it still true?** The codebase may have changed. A tech decision may have been reversed. Check the code. - **Is it still non-obvious?** The test from init-project applies: could Claude figure this out by reading the codebase? If yes, the rule is noise — recommend removing it. Example: "We use Vitest" is obvious from `package.json`. "We require integration tests for all DB-touching code because of a Q1 incident" is NOT obvious from the code. - **Is it still relevant?** A constraint about a deprecated module that's since been removed is dead weight. **3. Check for missing rules.** Read `/docs/decisions/` if it exists. Are there decisions with constraints that should be in `.claude/rules/` but aren't? Look for recent additions to the codebase that introduce non-obvious patterns — things a new Claude session might get wrong. **4. Check the project manifest.** Is `.teamcraft/project.md` still accurate? Project name, repo identity. ## Present Findings Show the developer a clear diff of what you'd change: - **Remove:** rules that are now obvious from the codebase or no longer relevant (explain why) - **Update:** rules where the content is outdated (show old vs. proposed new) - **Add:** new rules for non-obvious constraints you discovered (explain what Claude would get wrong without them) - **Keep:** rules that are still necessary and accurate (briefly confirm) The developer approves each change individually. Never auto-update — this is the developer's configuration. ## Apply Changes For each change the developer approves, make the edit. Commit the updated files. ## Constraints - This skill is about `.claude/rules/` and `CLAUDE.md` — not about `/docs/` or `.teamcraft/work/`. Those are managed by their own skills. - Removing a rule doesn't mean the decision changed — it means the code now makes the decision obvious. The decision itself may still be documented in `/docs/decisions/`. - Keep `.claude/rules/` small. Every line is loaded every session. If it's growing, that's a signal to evaluate whether each rule truly needs to be always-loaded.