claude-code-extension-engineeringlisted

# Claude Code extension engineering ## Before you wire anything up: check the request is possible **An imperative is not a licence.** "Wire that up", "make it stop when X", "put the sandbox config in settings.json" all presuppose the mechanism can do what is being asked, and that presupposition is wrong often enough to check every time. The costly failures in this domain are not syntax errors, they are configurations that parse, load, and do nothing: - an event that reports but **cannot block**, wired to block - a key that is **inert in project scope**, written into the repo settings file - a path rule for a tool it is **never consulted for** - a matcher naming a tool that **does not exist** All four look correct in the file and all four fail silently, so nobody finds out until the thing they were guarding against happens. So before writing config: name the mechanism the request needs, open its reference, and confirm it can do the thing **at the scope being asked for**. If it cannot, say so and give the nearest thing that can, rather than delivering config that will never fire. Say which half is deliverable when only half is. ## Before answering: open a reference **If the question is diagnostic, capability, or scope shaped, open [INDEX.md](references/INDEX.md) and read the reference it names before you answer.** That covers every "can X block", "will this setting take effect here", "does this work on that provider or version", "it is installed but never fires", and "is