teamcraft:refresh-project-rules

What this skill does

## 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 `/plan-and-implement-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.