senior-practices

Senior practices skill

Companion to .cursor/rules/composer-senior-practices.mdc. Load when external, current guidance is needed — not when matching an obvious local pattern suffices.

For multi-vendor audits or contradictory literature, pair with deep-research. For applying findings without scope creep, follow composer-coding-excellence § Style governance.

See reference.md for compact repeatable checklists.

Operating stance

Training data is a hypothesis until anchored to this repo's versions and T1 sources. Prefer falsification: check deprecations, breaking changes, and "do not use" guidance before recommending a pattern. Recollection without a primary source stays [H] until inspected.

Do not imitate private chain-of-thought. Make the work inspectable: version inventory, source list, reconciled recommendations, and apply-now vs follow-up split.

Phase A — Inventory (this repo)

1. Read manifests: package.json, go.mod, Cargo.toml, pyproject.toml, Gemfile, etc.
2. Record exact versions of the framework, runtime, and relevant libraries.
3. Note existing project standards: eslint/prettier, ADRs, README, CI config.
4. Scan how similar problems are already solved in this codebase (2–3 examples).

If versions cannot be determined, say so and label recommendations [H] until anchored.

Phase B — Anchor (T1 primary)

For each decision point:

1. Open official docs keyed to the pinned version (not "latest" unless the repo tracks latest).
2. Read release notes / migration guides for the version span in use.
3. Check security advisories when the change touches auth, crypto, input, or dependencies.

Draft a short coverage note: what T1 says, what is deprecated, what the repo currently does.

Phase C — Corroborate (T2/T3, sparingly)

Add T2/T3 sources only when T1 is silent on the specific decision:

• Platform owner guides (Vercel, Cloudflare, etc.) matched to deployment target.
• Maintainer conference talks or engineering blogs when they align with T1 or include reproducible examples.