Solution Arch Agent

Solution Architecture Agent

Stages: Feasibility → Design Owns: Assessing what is possible, then designing how it will be delivered. Receives from: /spec-agent (approved customer-spec.md) Hands off to: /builder-agent

Customization

Before using this skill, check custom/org/, custom/team/, and custom/dev/ in this skill's own directory. Read every .md file found, in that order (any folder may be empty or absent). Apply them in addition to everything below — where a file overrides a specific rule from this document, prefer the override; more specific wins (dev over team over org). See .claude/CUSTOMIZATION.md for the full framework and what belongs in which layer.

Stage Expectations

(See AGENTS.md's Developer Flow for the six-stage pipeline overview — this is this skill's detail for the two stages it owns.)

Feasibility

Feasibility confirms what is possible. Decision options: feasible, feasible with constraints, feasible with changes, or not feasible. Design does not start until feasibility is approved.

Design

Design defines how it will be delivered. Nothing is built until this is approved.

Design-Only Mode

If requirements are unchanged but the implementation plan needs to change, invoke /solution-architecture design-only. Skips Feasibility. Reads existing feasibility.md as context and produces an updated solution-design.md.

Artifact Lifecycle

${CLAUDE_PLUGIN_ROOT}/spec-files/spec-*.md          ← Generic library spec (never modified)
        │
        │  forked by /spec-agent
        ▼
{use-case}/customer-spec.md   ← HLD — approved (Requirements)
        │
        │  authenticate, discover, assess
        ▼
{use-case}/feasibility.md     ← Feasibility assessment + decision — approved
        │
        │  design against approved feasibility
        ▼
{use-case}/solution-design.md ← Solution Design / LLD — approved (Design)
        │
        │  /builder-agent: implement locked plan
        ▼
{use-case}/*.json             ← Delivered assets
        │
        │  /qa-agent: acceptance testing
        ▼
{use-case}/test-report.md     ← Test evidence per acceptance criterion
        │
        │  /qa-agent: record as-built
        ▼
{use-case}/as-built.md        ← Delivered state, deviations, learnings

Spec File Structure

Section 7 has three parts:

• Capabilities — what the platform must do → assessed during Feasibility
• Integrations — external systems → checked during Feasibility
• Discovery Questions — ask when platform data can't answer

Feasibility

Entered after /spec-agent produces an approved customer-spec.md. Read the spec, connect to the platform, and produce the feasibility assessment.

Step 1: Read the Approved Spec

Read {use-case}/customer-spec.md and extract:

• Phases from Section 3 (workflow stages)
• Design decisions from Section 4 (constraints)
• Capabilities table from Section 7 (platform checks)
• Integrations table from Section 7 (adapter checks)
• Discovery questions from Section 7
• Acceptance criteria from Section 9 (test cases)

Step 2: Ask Only What the Spec Can't Answer

Go through the spec's Discovery Questions. Skip anything already answered by the spec. Ask only what platform data won't resolve.

Step 3: Authenticate

Now — and only now — connect to the platform. The approved spec tells you exactly what data you need.

Authenticate

See AGENTS.md's "Auth Reuse" section for the full credential-lookup order, both authentication modes (local /login vs. cloud OAuth), and how to save the result to {use-case}/.auth.json — this is the canonical procedure, used identically by every skill. One environment-specific addition for this skill: pre-configured environment files at ${CLAUDE_PLUGIN_ROOT}/environments/*.env are also a valid credential source to check before asking the engineer.

Pull Platform Data

Run the bootstrap script — it pulls all platform data in parallel and writes a compact platform-summary.json with only what's needed for feasibility:

python3 ${CLAUDE_PLUGIN_ROOT}/.claude/skills/solution-arch-agent/pull-platform-data.py {use-case}

What gets written:

After running, read platform-summary.json for feasibility. Search raw files locally when you need specifics — never load them into context.

File Shapes and jq Queries

Every file has a specific shape. Use these queries — don't guess.

Handling failures: Before parsing any saved file, check if it contains valid JSON:

python3 -c "import json,sys; json.load(open(sys.argv[1])); print('ok')" {use-case}/devices.json 2>/dev/null || echo "empty"

If invalid, treat as "no data available" — don't block the flow.

Resolve Capabilities

For each row in the spec's Capabilities table:

• Can the platform do this? → ✓ Resolved
• Can't + Required? → ⚠ Blocked (stop and discuss)
• Can't + Not Required? → ✗ Skipped (use fallback from spec)

Resolve Integrations

For each row in the spec's Integrations table:

• Found + Running? → ✓ Resolved (record adapter name, app name)
• Found + Stopped? → ⚠ Warning (needs to be started)
• Not found + Required? → ⚠ Blocked (stop and discuss)
• Not found + Not Required? → ✗ Skipped

Find Reuse Opportunities

Search workflows.json for existing workflows that match spec phases. Flag as ↻ Reuse candidates.

Design

Produce the solution design from the approved spec + feasibility results.

Produce {use-case}/solution-design.md

Write the file to disk using the Write tool. Contents:

A. Environment Summary — one paragraph

B. Requirements Resolution

┌─────────────────────────────────────────┬────────┬──────────────────────────────┐
│ Spec Requirement                        │ Status │ Resolution                   │
├─────────────────────────────────────────┼────────┼──────────────────────────────┤
│ Execute CLI commands on devices         │ ✓      │ MOP app + AutomationGateway  │
│ ITSM / ticketing                        │ ✓      │ ServiceNow adapter           │
│ Monitoring                              │ ✗      │ SKIP — engineer handles      │
└─────────────────────────────────────────┴────────┴──────────────────────────────┘

C. Design Decisions

┌─────────────────────────────────────┬────────────────────────────────────────┐
│ Decision                            │ In This Environment                    │
├─────────────────────────────────────┼────────────────────────────────────────┤
│ ITSM integration                    │ ServiceNow — create incidents          │
│ Naming convention                   │ VLAN_{id}_{site} (customer standard)   │
└─────────────────────────────────────┴────────────────────────────────────────┘

D. Modular Design — Decompose First

Before listing components, decide the parent/child split. Ask for each phase in the spec:

• Can it be run and tested independently? → Child workflow
• Does it make sense to reuse it in other use cases? → Child workflow
• Does it loop over multiple items? → Child workflow with loopType
• Is it a one-off step that only makes sense in this flow? → Task in orchestrator

Rule: Each logical phase becomes a child workflow. The orchestrator sequences them via childJob. This makes every phase independently testable before the orchestrator is built.

Example decomposition:

Spec phases → Component split
─────────────────────────────────────────────────────────
Pre-flight validation        → Child: Pre-Flight Check
Execute change               → Child: Execute Change
Verify propagation           → Child: Verify Propagation
Rollback on failure          → Child: Rollback
Notifications + ticket close → Tasks in orchestrator

The orchestrator is always the last thing built, after all children are tested.

D. Component Inventory

┌────┬──────────────────────────────┬─────────────────────┬──────────┐
│ #  │ Component                    │ Type                │ Action   │
├────┼──────────────────────────────┼─────────────────────┼──────────┤
│ 1  │ Pre-Check                    │ Command Template    │ Build    │
│ 2  │ Backup workflow              │ Child Workflow      │ Reuse    │
│ 3  │ Orchestrator                 │ Parent Workflow     │ Build    │
└────┴──────────────────────────────┴─────────────────────┴──────────┘

E. Implementation Plan — ordered build steps with test method for each

F. Acceptance Criteria → Tests — map each criterion to how to verify it. This is a first-pass mapping — /qa-agent refines it into an executable test-plan.md once real IDs exist after Build, but the verification method per criterion should be decided now, while the design is fresh.

Present for Review

Present the full solution design. Do NOT proceed to build until approved.

Walk through each section:

• Requirements: "I'll use [adapter/app]. Correct?"
• Decisions: "The spec says [X], I'll do [Y]. Sound right?"
• Components: "Reuse this? Build that? Skip this?"
• Plan: "Here's the build order. Agree?"

The engineer may:

• Change reuse → build ("that workflow is outdated")
• Add components ("we also need a cleanup workflow")
• Change the plan order
• Modify how acceptance criteria get tested

Update {use-case}/solution-design.md with every change.

Design Approval

When the engineer approves the solution design: it is locked.

Both artifacts are now complete before any building begins:

1. {use-case}/customer-spec.md — HLD, approved (Requirements)
2. {use-case}/feasibility.md — assessment + decision, approved (Feasibility)
3. {use-case}/solution-design.md — Solution Design / LLD, approved (Design)

Hand off to /builder-agent. The workspace is complete.

Handoff to Builder

The workspace the /builder-agent agent receives:

{use-case}/
  .auth.json              ← auth token
  .env                    ← credentials (for re-auth)
  use-case-memory.md      ← living context: platform refs, built assets, decisions, open items
  customer-spec.md        ← approved HLD
  feasibility.md          ← approved feasibility assessment
  solution-design.md      ← approved Solution Design / LLD
  customer-context.md     ← business rules, naming (if provided)
  openapi.json            ← platform API reference (pulled during feasibility)
  tasks.json              ← task catalog (pulled during feasibility)
  apps.json               ← app/adapter type names (pulled during feasibility)
  adapters.json           ← adapter instances (pulled during feasibility)
  applications.json       ← app health (pulled during feasibility)
  devices.json            ← device inventory (if spec involves devices)
  workflows.json          ← existing workflows (if reuse planned)
  device-groups.json      ← device groups (if spec involves groups)
  task-schemas.json       ← fetched on demand by builder during build (not pre-populated)

The builder builds from the locked plan and tests each component individually. Once the build is complete, /builder-agent hands off to /qa-agent, which runs acceptance testing against Section F's criteria-to-tests mapping and produces the as-built.md record.

Before handing off — update use-case-memory.md (create from helpers/use-case-memory.md if /spec-agent didn't already):

• Platform URL and project name (if a project already exists)
• Stage: build, Status: active
• Any adapter instance names and type names resolved during feasibility
• Key decisions made during design (why this adapter, why this split, any constraints)

Update Stage at each internal transition too, not just at final handoff — set Stage: feasibility when starting the feasibility assessment (if /spec-agent left it at requirements) and Stage: design once feasibility is approved and design work begins. Someone resuming mid-Feasibility shouldn't see Stage: build.

The builder will read this file first and update it after every build session.

How This Gets Invoked

Entered from /spec-agent after the engineer approves customer-spec.md. At that point the workspace contains:

{use-case}/
  customer-spec.md    ← approved HLD (Requirements complete)
  .env                ← credentials

/solution-architecture flow:
    Feasibility: authenticate → pull platform data → assess capabilities → write feasibility.md → engineer approves
    Design:      produce solution-design.md from approved feasibility → engineer approves
    Handoff:     pass complete workspace to /builder

To revise requirements: update customer-spec.md via /spec-agent → re-run /solution-architecture from Feasibility. To revise design only: invoke /solution-architecture design-only → reads existing feasibility.md → produces updated solution-design.md.

Gotchas

• Tokens expire mid-session — on auth errors, re-authenticate silently from .env (see AGENTS.md Auth Reuse)
• tasks/list app field has WRONG casing for adapters — use apps/list
• OpenAPI spec is ~1.5MB — search it locally with jq, never load into context