codingthefuturewithai/teamcraft-auto:refresh-project-rules

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.

Before promoting a constraint out of a decisions file, check that file's Teamcraft certification (see ../references/doc-provenance.md). If the decisions doc you're sourcing from is UNVERIFIED, say so when you propose the promotion — a constraint pulled from uncertified, possibly-inherited content shouldn't land in the always-loaded layer on uninformed approval. Don't block; surface it so the developer approves with eyes open. (This skill never stamps anything — it only reads the stamp to inform what it promotes.)

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.

When You're Done

Confirm what changed in .claude/rules/ / CLAUDE.md and why. Then point the developer to the natural next step: /check-project-context to confirm Claude now reads the project correctly with the refreshed rules, or straight back to the work — /pick-next-issue or /build-issue <id>.

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.