An AI coding agent can run your build perfectly and still follow yesterday's architecture. It can also spend half an hour pursuing a plausible fix when a second perspective would have exposed the wrong assumption. These are different problems. Claude Code now has useful tools for both.
The interesting trend is the shift from writing a better individual prompt to maintaining the environment around the agent: its instructions, model configuration, feedback and evidence. For a software company, that environment deserves the same care as a build pipeline.
This article examines /advisor and prompt-audit, explains where each fits, and ends with a practical cheat sheet for everyday Claude Code work. The commands were checked against official documentation; we did not run a live Claude model benchmark.
Research checked on October 23, 2026. Claude Code installed locally: 2.1.309. Experimental behavior and provider support can change.
Why this matters for software engineering
Homann Software's engineering philosophy emphasizes clear responsibilities, explicit dependencies and traceable decisions. That makes agent configuration a practical architecture concern: who decides, which context reaches that decision, and what evidence makes the result acceptable?
Three developments make this a timely topic. Anthropic added an instruction audit to the everyday diagnostic workflow in Claude Code 2.1.283. The 2.1.300 release extended advisor support to Claude Platform on AWS and made explicit selection the prerequisite for running an advisor. And Anthropic's current cost and intelligence guidance recommends testing a single model's effort settings before introducing a second model.
Our editorial conclusion: the strongest topic here is maintaining and measuring the coding-agent workflow. A command list is useful for discovery. An accepted change, with a known cost and preserved constraints, is useful for a business.
Figure 1. Our proposed engineering model. These responsibilities remain separate even when one product exposes all three.
/advisor: a second perspective at a decision point
According to the advisor documentation, the experimental feature lets the main model request guidance from another model. It receives the full conversation, including tool calls and results, and runs server-side. Claude chooses when to consult it; enabling it does not force a consultation on every task. Advisor calls add model usage.
Our preferred starting configuration for demanding engineering work is Opus 5.5 as the default main model, with Fable as the advisor. Opus handles implementation and tool use; Fable provides an additional perspective at difficult decision points. This is our recommended setup for this workflow, not a measured claim that it is the best combination for every task or budget. Anthropic lists Fable as an accepted advisor for Opus 5.5 in its pairing table.
Set the main model and advisor inside Claude Code, where your account supports both:
/model claude-opus-5-5
/advisor fable
The explicit Opus model ID pins the intended version rather than following a moving alias. In an interactive session, /model saves the model selection as the default; /advisor saves the advisor selection. Anthropic's model configuration reference explains model IDs and aliases. The fable alias follows the Fable version configured for your provider; record the resolved model when comparing runs.
To launch a session with this pairing from your operating-system shell, use:
claude --model claude-opus-5-5 --advisor fable
Launch flags apply to that session. Fable requires account access and, on some plans, a one-time consent to usage-credit billing. If Claude Code requests that consent, follow the documented /model fable flow, then reselect Opus 5.5 and set /advisor fable. See Anthropic's Fable advisor requirements. To inspect available advisor choices, use /advisor; to disable consultations, use /advisor off.
The advisor reference also explains that the advisor's own transcript reads are not cached between consultations. We therefore avoid treating “advisor enabled” as proof of either a completed review or a cost reduction.
Consider a retry bug in a payment integration. The executor has changed three timeout values, but the failing test concerns duplicate effects after a reconnect. An advisor could challenge the framing: is this really a timeout problem, or an idempotency problem? That is an illustrative use case, not a measured result from this article.
The team still needs a failing regression test and a review of the resulting change. Agreement between two model calls is additional advice, not proof of correctness. Correlated mistakes remain possible when both calls share the same misleading conversation.
Provider caveat: the advisor reference retrieved for this article still excludes Claude Platform on AWS, while the newer 2.1.300 release notes explicitly add it. These official sources disagree. Verify the installed version, provider and available picker entries before planning a rollout; this article does not promise identical support across providers.
Figure 2. Conceptual UML sequence, not an internal implementation trace. The executor continues working after advice; the acceptance decision follows executable evidence and review.
prompt-audit: maintain instructions that still match the project
The everyday entry point introduced in 2.1.283 is:
/doctor prompt-audit
/checkup prompt-audit is an alias. For application prompts and tool descriptions, Anthropic also documents /claude-api prompt-audit in its command reference.
The official audit method asks for scope and target-model assumptions, findings with locations and confidence, and a proposed diff. It prioritizes evidence over shortening: project knowledge and working constraints should survive. A clean audit is allowed to produce no changes.
This is a model-assisted review. Treat its output as a proposal to assess against repository facts and behavior. A phrase that resembles an old prompting habit is insufficient evidence that deleting it will improve your project.
Here is a deliberately fictional example. The repository has moved from Maven to Gradle and now runs Java 27. Its instruction file still says:
This project uses Java 21.
Build with ./mvnw verify.
CRITICAL: verify every answer twice before responding.
Never log access tokens or customer payloads.
A reasonable proposed replacement, after checking the real build configuration, is:
This project uses Java 27.
Build and test with ./gradlew check.
For a code change, report the checks run and any unresolved failures.
Never log access tokens or customer payloads.
The important repairs are the stale runtime and build command. The new verification sentence names an observable deliverable. The confidentiality constraint remains. None of these lines is a recommendation to change an arbitrary Java project; they illustrate how an audit should connect a finding to facts.
Keep domain rules, deployment boundaries, architectural dependencies and failure-specific regression checks. Improve an unclear rule before assuming it is unnecessary. Anthropic's memory documentation also distinguishes textual instructions from enforced configuration. For critical boundaries, use appropriate permissions, sandboxing, service authorization and CI controls rather than depending on prose alone.
What the published savings actually mean
In its cost-optimization article, Anthropic describes a customer-support experiment with six deliberately introduced prompting anti-patterns. It reports about 18% lower cost from a model migration, then another 9% reduction and roughly two percentage points of accuracy from prompt-audit.
Those are vendor-reported results on that experiment. They do not establish a 9% saving on software repositories, and we did not reproduce them. A build-command repair may be enormously valuable without changing token spend. A shorter instruction file may save tokens while making a critical workflow less reliable.
For advisor use, ask a different question: does selective consultation beat both the executor alone and the stronger model alone? The current platform guidance warns that advisor gains on its coding benchmark lie near run-to-run noise. The extra model is a hypothesis to test.
A practical rollout with BPMN
Start with a small, representative task set: a routine change, an unfamiliar module, a recurring failure and a domain-sensitive edge case. Define acceptance before seeing the outputs. Record the repository commit, exact models, effort, instruction version and tool permissions for each trial.
Evaluate one change at a time:
- Establish the current configuration as the baseline.
- Run an instruction audit and review the proposed diff.
- Evaluate accepted instruction changes with the advisor off.
- Evaluate advisor use separately against that cleaned baseline.
- Compare with the stronger model running alone, including lower effort settings.
Use isolated clean workspaces for each run so an earlier solution does not leak into the next trial. Repeat tasks to expose variability, vary run order, and keep a held-out set for the final decision. Count failed attempts and maintainer rework, not only successful completions. Record consultation counts; zero calls means the trial did not exercise the advisor.
Figure 3. Proposed, non-executable BPMN 2.0 rollout. Review authorizes a candidate edit; evaluation determines whether to adopt it. Editable BPMN XML and a PlantUML sequence source are included in the package.
The decision should preserve task-level outcomes. Two configurations can accept the same number of changes while failing on different tasks. Losing the one security-sensitive regression cannot be concealed by gaining a trivial formatting task.
Cheat sheet: twelve useful Claude Code commands
Enter these at the Claude Code prompt, not in your operating-system shell. The functions below follow Anthropic's command reference; the situations in the last column are our practical suggestions. Availability depends on version, account and environment. Start with /help in your own session.
| Command | What it does | A useful moment |
|---|---|---|
/help |
Lists available commands. | A command from an online tip is missing. |
/plan |
Enters plan mode. | Clarify the approach before a broad refactor. |
/diff |
Displays working-tree changes. | Inspect the patch before accepting it. |
/code-review |
Reviews changes for correctness. | Get another review perspective; assess its findings. |
/context |
Shows context usage. | Investigate a crowded session. |
/compact |
Summarizes the conversation to free context. | Continue a long task with a shorter history. |
/clear |
Starts an empty conversation. | Begin unrelated work without the old discussion. |
/memory |
Manages instructions and auto memory. | Check persistent project guidance. |
/usage |
Shows cost, limits and activity. | Check consumption during a long session. |
/permissions |
Manages tool permission rules. | Inspect access before sensitive work. |
/mcp |
Manages MCP connections and authentication. | Diagnose an unavailable integration. |
/btw <question> |
Asks a side question outside the main conversation. | Resolve a tangent without expanding the main thread. |
For example, ask /btw What does idempotency mean in this integration? while investigating a retry bug. Use /context before deciding whether the current session needs compaction. After implementation, inspect /diff, request /code-review, and judge the findings against the code and project checks.
Treat /compact and /clear as different choices: one continues with a summary, the other starts a fresh conversation. Neither is a request to remove the repository's persistent instruction files. Likewise, /diff shows changes; it does not validate them. A model review complements executable checks and maintainer judgment.
For prompt maintenance, return to /doctor prompt-audit. For our preferred model setup, use /model claude-opus-5-5 and /advisor fable; use /advisor off to compare with Opus alone. Those commands solve the particular problems discussed above; the cheat sheet helps manage the surrounding work.
What to do on Monday morning
Pick one repository where repeated agent mistakes are costing engineering time. Check its instruction files against the build, architecture and actual failure history. Run prompt-audit and review its evidence. Then trial an advisor on the difficult decisions that remain.
The outcome to seek is concrete: an accepted patch, fewer repeated mistakes, understandable total effort, and constraints that still hold. /advisor and prompt-audit become valuable when they help produce that outcome. Their presence in a command menu is only the starting point.
For the broader purchasing question, see our companion article on Claude, ChatGPT, Claude Code and Codex. This article focuses on improving one coding workflow after the tool has been chosen.