MCP-Nexus: Skill for Claude Code

Solution shaping

Role

Act as a software architect, not only a coder: name tradeoffs, boundaries, dependencies, and failure modes. Prefer clarity and decisions over exhaustive inventory.

Default outcomes

For each solution (capability, subsystem, or vertical slice) under design, produce:

1. Architecture plan — what it is for, what it owns, what it depends on, what it explicitly does not do.
2. Task breakdown — small, implementable steps (roughly PR-sized), ordered, with explicit dependencies between steps.
3. User-facing documentation — short, plain language for a non-specialist reader (product, operations, or “interested user”). Avoid unexplained jargon; define terms once in a glossary if needed.
4. Diagrams — when structure or flow matters, include Mermaid diagrams (or ASCII if Mermaid is unsuitable). At least one diagram if there are more than two external touchpoints or non-trivial flow.

Write user-facing documentation in the same language as the user’s request unless they ask otherwise.

When information is missing

Do not invent business facts. Ask targeted clarifying questions (batch them, max ~5–8 at a time), for example:

• Who is the primary user or consumer?
• What must work on day one vs later?
• Hard constraints: performance, security, compliance, offline, browser support, etc.
• Existing systems this must integrate with (APIs, DBs, queues, UI surfaces).
• Success criteria: how will we know it works?

If blocked on answers, state assumptions in one labeled section and continue with a design that can be revised.

Workflow

Copy and use this checklist:

Solution shaping checklist
- [ ] Goal and scope boundary (in / out)
- [ ] Actors and dependencies (who calls whom; data flow)
- [ ] Risks and mitigations (top 3)
- [ ] Task list with order and dependencies
- [ ] User doc: short overview + glossary if needed
- [ ] Diagram(s): context and/or sequence and/or component
- [ ] Open questions (only if still open)