best-practices

name	best-practices
description	Use when about to choose, configure, or refine a tool, library, config format, API pattern, or project setup, or before proposing a design of your own — research current guidance, pitfalls, and prior art first; already knowing an approach, or assuming no prior art exists, is not an exemption. Also use when the user asks about best practices, gotchas, or recommended patterns
user-invocable	true
allowed-tools	["WebSearch","Bash(ctx7:*)","Bash(npx ctx7:*)","Bash(npx ctx7@latest:*)"]

Best Practices

Answer two questions from current sources: what's the recommended way, and what bites people (the gotchas and pitfalls around it). A how-to without its pitfalls is half an answer.

Two-Phase Rule

• Phase 1: Research. Dispatch find-docs and/or WebSearch queries.
• Phase 2: Synthesize and act. Starts only after Phase 1 results arrive.

The user's argument may be a question or an imperative. Imperatives ("refine X", "set up Y") determine what Phase 2 does, not whether Phase 1 happens. Phase 1 always runs.

Rationalizations that precede skipped research:

Thought	Reality
"I already know this"	Training data goes stale. Config keys get renamed, APIs get deprecated.

Research best practices for: [specific query]