agentleFS
rade-nugrohorade-nugroho/Agentic-Enteprises-Skill/solutions-architect/SKILL.md

solutions-architect

Skill9 starsChanged 6 months agoMITView on GitHub

Guides customer-facing and internal technical solution design—discovery and requirements, integration and reference architecture, security/compliance fit, sizing and cost framing, RFP/RFI responses, PoC scoping, build-vs-buy, and handoff to delivery. Use when scoping a customer or partner solution, designing integration architecture for a deal, drafting RFP/RFI technical responses, planning a proof-of-concept, framing security and compliance fit, or preparing solution decks for stakeholders—not for org-wide landing zones and Well-Architected programs (cloud-architect, enterprise-cloud-architect), internal product ADRs and C4 (senior-system-architecture), production Terraform/IaC (infrastructure-engineer), hands-on cloud resource config (cloud-engineer), live PoC execution and competitive demos (sales-engineer), business strategy without technical design (business-consultant), contract redlines (commercial-counsel), or deep FinOps/GL (finops-analyst, compute-accounting-manager).

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run technical discovery — stakeholders, systems, constraints, success criteria

    line 21

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Solutions Architect

When to Use

  • Run technical discovery — stakeholders, systems, constraints, success criteria
  • Translate needs into requirements — functional, integration, NFRs, assumptions
  • Design integration architecture — APIs, events, identity, data flows, boundaries
  • Produce reference architectures — logical, deployment, and integration views for review
  • Assess security and compliance fit — controls mapping, gaps, mitigations (not legal advice)
  • Frame sizing and cost — order-of-magnitude capacity, licensing, cloud spend drivers
  • Scope PoC/Pilot — goals, in/out of scope, success metrics, exit criteria
  • Draft RFP/RFI technical responses — requirements traceability, solution narrative
  • Recommend build vs buy — options, trade-offs, TCO drivers, risks
  • Prepare handoff to delivery — backlog, dependencies, open decisions, acceptance criteria

When NOT to Use

  • Org landing zones, CCoE, enterprise EA programs → enterprise-cloud-architect
  • Single-product internal ADRs, C4, engineering standards → senior-system-architecture
  • Well-Architected cloud platform design (non-deal) → cloud-architect
  • Production Terraform modules, CI/CD, K8s build → infrastructure-engineer, devops
  • Configure RDS, IAM errors, autoscaling tuning → cloud-engineer
  • Build and demo the PoC in customer environment → sales-engineer
  • Issue trees, operating model, steerCo without technical design → business-consultant
  • MSA/SaaS redlines and legal risk → commercial-counsel
  • SOC 2 evidence packs and control narratives → compliance-engineer
  • Implement cloud guardrails and CSPM → cloud-security-engineer
  • Multi-year NPV/EA economics deep dive → cloud-economist
  • Program RAID, milestones, steering cadence → technical-program-manager

Related skills

NeedSkill
Cloud platform and migration architecturecloud-architect
Enterprise cloud governance at scaleenterprise-cloud-architect
Internal system ADRs and architecture reviewsenior-system-architecture
IaC modules and delivery implementationinfrastructure-engineer
Cloud service configuration and opscloud-engineer
Pre-sales PoC execution and battlecardssales-engineer
Business case and strategy (non-technical)business-consultant
Cloud security controls and architecture reviewcloud-security-engineer
TCO/NPV and economic option modelingcloud-economist
Multi-team delivery and launch readinesstechnical-program-manager
FinOps dashboards and rightsizingfinops-analyst

Core Workflows

1. Scope and engagement framing

Role boundaries, inputs, outputs, stakeholders.

See references/solutions_architect_scope.md.

2. Discovery and requirements

Interviews, current state, requirements pack, assumptions.

See references/discovery_and_requirements.md.

3. Integration and reference architecture

Context, integration patterns, reference diagrams, interfaces.

See references/integration_and_reference_architecture.md.

4. Security and compliance fit

Threat framing, control mapping, gaps, customer questionnaires.

See references/security_compliance_fit.md.

5. Sizing, cost, and options

Capacity, cost drivers, build-vs-buy, option comparison.

See references/sizing_cost_and_options.md.

6. RFP, PoC, and handoff

RFP structure, PoC charter, delivery handoff package.

See references/rfp_poc_and_handoff.md.

Outputs

  • Discovery summary — context, constraints, open questions
  • Requirements pack — must/should/could, NFRs, traceability matrix
  • Solution architecture — context, integration, deployment views
  • Security/compliance fit memo — mappings, gaps, mitigations
  • Sizing and cost estimate — assumptions, ranges, sensitivities
  • Option comparison — build vs buy vs partner, recommendation
  • PoC charter — scope, timeline, success criteria, risks
  • RFP response sections — compliant narrative with requirement IDs
  • Handoff package — backlog seed, dependencies, decisions log

Principles

  • Discovery before design — validate problem, constraints, and buyers
  • Explicit assumptions — every estimate and diagram states what you assumed
  • Fit for purpose — right-size architecture for phase (PoC vs production)
  • Traceability — requirements IDs flow through design, RFP, and backlog
  • Reversible decisions — call one-way doors; defer until evidence from PoC
  • Handoff-ready — delivery teams get scope, risks, and acceptance criteria

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.