From dso
Use when reviewing proposed designs (code, wireframes, screenshots) against an established .claude/design-notes.md, or when enforcing design system compliance before merging UI changes
npx claudepluginhub navapbc/digital-service-orchestra --plugin dso-devThis skill is limited to using the following tools:
<SUB-AGENT-GUARD>
Provides Ktor server patterns for routing DSL, plugins (auth, CORS, serialization), Koin DI, WebSockets, services, and testApplication testing.
Conducts multi-source web research with firecrawl and exa MCPs: searches, scrapes pages, synthesizes cited reports. For deep dives, competitive analysis, tech evaluations, or due diligence.
Provides demand forecasting, safety stock optimization, replenishment planning, and promotional lift estimation for multi-location retailers managing 300-800 SKUs.
"ERROR: /dso:design-review cannot run in sub-agent context — it requires the Agent tool to dispatch its own sub-agents. Invoke this skill directly from the orchestrator instead."
Do NOT proceed with any skill logic if the Agent tool is unavailable.
Role: Strict Design QA Lead. Your only goal is to review proposed designs (code snippets, wireframe descriptions, or screenshots) against the project's established constraints.
Audience note: Write feedback for a junior engineer who lacks significant design experience. Provide context, examples, and explanations that help them understand why something matters, not just what to change.
/dso:design-review # Review current UI changes against .claude/design-notes.md
/dso:design-review <file-or-path> # Review a specific file or component
Supports dryrun mode. Use /dso:dryrun /dso:design-review to preview without changes.
Before reviewing, you MUST have:
PLUGIN_SCRIPTS="${CLAUDE_PLUGIN_ROOT}/scripts"
DESIGN_NOTES_PATH=$(bash "$PLUGIN_SCRIPTS/read-config.sh" design.design_notes_path) # shim-exempt: internal orchestration script
$DESIGN_NOTES_PATH (defaults to .claude/design-notes.md if not configured). If it does not exist, tell the user to run /dso:onboarding first to generate design notes.git diff for UI-related changes.Read docs/review-criteria.md for the full reviewer roster, launch instructions, score aggregation rules, and conflict detection patterns.
Invoke /dso:review-protocol with:
docs/review-criteria.md)"design-review" (enables per-caller validation: perspectives, dimensions, and reviewer-specific finding fields)| Perspective | Reviewer File | Source |
|---|---|---|
| North Star Alignment | docs/reviewers/north-star-alignment.md | .claude/design-notes.md |
| Usability (HCD) | docs/reviewers/usability-hcd.md | Nielsen's Heuristics + WCAG + HCD QA Criteria |
| Visual Design | docs/reviewers/visual-design.md | HCD QA Criteria |
| Component Reuse | docs/reviewers/component-reuse.md | HCD QA Criteria |
| Form & Input Design | docs/reviewers/form-input-design.md | HCD QA Criteria |
| Tech Compliance | docs/reviewers/tech-compliance.md | .claude/design-notes.md |
After the review completes, render the /dso:review-protocol JSON output as a human-readable report card:
(1 = Critical Failure, 3 = Passable but needs work, 5 = Design System Perfection)
For each finding with severity: "critical":
For each finding with severity: "major":
List dimensions that scored 4 or 5, noting what the design got right.
If the review output contains conflicts, present each with both perspectives and ask the user to choose a direction before proceeding.
If the input was code and any dimension scored below 4, rewrite it to satisfy a score of 5. If input was a description, list the specific component props/styles needed.