Naksha v6 adds a dashboard for Claude Code design reviews
Naksha Studio has published version 6.0.0 of its Claude Code plugin for interface design. Released on October 18, the update adds an optional local dashboard and changes how the plugin reviews design findings, checks interface files and estimates command costs.
This is an independently maintained third party project, not an Anthropic release. ByteForward inspected release metadata and tagged source files but has not installed or tested the plugin.
The version comparison shows a new dashboard and cost tools alongside an expanded existing linter. Taste memory and design variants were already available in version 5.3.0, released earlier that day.
Design findings get another check
The revised design review command asks the reviewing agent to record evidence and mark each finding as needing validation. A separate verifier is then asked to challenge each finding without seeing the original recommendation or the reviewer’s reasoning.
Findings can be confirmed, rejected or left unresolved. The command also records which review dimensions were checked and why others were skipped. That gives readers more context than a verdict alone.
The separation has a limit. If separate agents are unavailable, the command falls back to another pass in the same conversation and must disclose that weaker arrangement. Even with separate agents, the result remains a model assessment. The included schema checks validate the structure of findings, not whether the design judgment is correct.
A local view of the work
Naksha Live groups design role activity, findings and costs into a dashboard. It stays off until setup. The server implementation binds to the local computer and requires a token for its API, rather than exposing an ordinary public dashboard.
Those details describe the dashboard connection. They do not establish that the assistant’s model inference runs offline or that the broader workflow has no provider usage costs.
Lint checks and spending figures have limits
The new design detection command wraps deterministic lint checks with an assistant explanation. The linter itself makes no model calls, but the surrounding explanation can still use the assistant. Its contrast checks cover color pairs declared together in a CSS block. Inherited styles and actual rendered combinations require a browser based check.
Some rules flag stylistic patterns rather than accessibility failures. Teams should read the reported evidence before treating every warning as a defect or claiming that a clean report proves accessibility compliance.
The cost documentation is similarly explicit about scope. Figures come from surviving local Claude Code transcripts and represent estimates at API list prices. They are not invoices, and subscription users should not interpret them as charges against their plan.
Unknown models can remain unpriced, which can understate totals. Command attribution is best effort. The optional budgets provide warnings and approval prompts rather than a hard spending block. A missing transcript or an unpriced model can therefore change what the dashboard appears to show.
What to check before relying on it
For a first evaluation, choose a small interface with a known problem and compare the plugin’s evidence with what the browser renders. Check which findings remain unresolved and whether the recorded costs include the models you actually used.
ByteForward’s coverage of visual review inside Claude Code explores a complementary approach, keeping screenshots and recordings close to the coding conversation.
Illustrative website design photograph. Photo by cottonbro studio on Pexels, used under the Pexels License. The photograph does not depict Naksha Studio.
