Checkpoint: Four Questions for Any Claude Code Capability

Claude Code now has a recognizable shape: a repository-aware work surface, layered extensions and policies, staged workflows, and several ways to add review or external tools. This checkpoint connects those ideas into one operating test. When a new Claude Code capability appears, the reader should be able to ask what it enables, who owns its authority, when feedback arrives, and what evidence or boundary limits it.

One operating model for capability and control

Start with what the capability enables. A feature-development command enables a sequence of discovery, exploration, questions, design, implementation, review, and summary. A specialized agent enables a focused way of looking at a codebase. A Hookify rule enables a warning or block at a named event. An MCP server enables access to an external service. A security-guidance layer enables pattern detection or model-based review. These are different outputs even when they are all described casually as “adding intelligence” to Claude Code.

The second question is who owns the authority. A workflow plugin can be installed and chosen by a team. A project-local rule belongs to the repository’s working environment. A built-in mod participates closer to the engine and may protect managed policy. An organization-controlled setting can restrict what local users and plugins are allowed to add. A model endpoint or gateway may control another part of the data and identity path. The same capability can therefore have a different risk profile when it moves from a local rule to a shared plugin or a managed component, because the owner, update process, and ability to override it have changed.

The third question is when feedback arrives. A pre-tool block can prevent a matched operation. A post-tool warning can inform a decision after the operation has run. A stop hook can review the work at the end of a turn and ask Claude to continue. A pull-request review can arrive after a change has been prepared for collaboration. These controls may all produce text in the same terminal, but timing changes what they can prevent, what state they can inspect, and how expensive a correction becomes.

The fourth question is what evidence the capability can see. A project rule may inspect a command string, a file path, or new text. A codebase explorer may read selected files and trace an implementation. A diff reviewer sees changed content and perhaps related files. A managed setting may know which tool is being invoked but not whether the user’s underlying intent is legitimate. A gateway may control provider access without seeing every local action. Presence is not coverage. A control can be configured correctly and still be irrelevant to an action outside its event, path, or input scope.

flowchart TD A["A Claude Code capability"] --> B["What does it enable?"] B --> C["Who owns authority?"] C --> D["When does feedback arrive?"] D --> E["What can it see?"] E --> F["What remains unresolved?"]

The fifth box is not an extra feature; it is the discipline that keeps the four questions honest. Every control leaves something unresolved. A warning leaves the final decision to a person or the agent. A block covers only its match and event. A review can miss a vulnerability or flag a safe pattern. A managed policy can narrow choices without understanding every consequence of the allowed action. An external service can be approved while still creating data-handling and credential obligations. The unresolved remainder is where residual risk lives.

This model is more useful than asking whether a capability is “safe” in the abstract. It produces a conditional statement.