Cloud Arch

Multi-account patterns, networking, and well-architected trade-offs. Use when designing cloud systems.

Security Scan

The skill is an instruction-only cloud-architecture workflow and its declared requirements and instructions are consistent with that purpose.

Purpose & Capability

Name and description match the SKILL.md workflow: guidance for multi-account patterns, networking, and well-architected trade-offs. The skill declares no binaries, no env vars, and no config paths — all of which are appropriate for a purely advisory workflow.

Instruction Scope

SKILL.md contains only a structured four-stage advisory workflow and checklist items. It does not instruct the agent to read files, access environment variables, call external endpoints, or perform actions outside giving procedural guidance, so the runtime instructions stay within the stated purpose.

Install Mechanism

No install spec and no code files — this is instruction-only. There is nothing to download or execute, which minimizes persistent or supply-chain risk for this skill.

Credentials

The skill requests no environment variables, credentials, or config paths. That is proportional and expected for a purely conversational/advisory architecture workflow.

Persistence & Privilege

always:false and default model-invocation settings are appropriate. The skill does not request persistent presence or elevated privileges and does not modify other skills or system config.

Assessment

This skill is an instruction-only cloud-architecture workflow and appears coherent and low-risk: it asks for no credentials and installs nothing. Before using its recommendations in production, have a qualified engineer review and validate any concrete infrastructure changes the skill suggests (especially IAM, network, or encryption changes). Do not paste secrets into chat when soliciting detailed guidance, and prefer implementing changes via your normal CI/CD and peer-review processes rather than copying ad-hoc commands from the assistant.

Structured guidance for cloud architecture (accounts, networking, well-architected trade-offs): confirm triggers, propose the stages below, and adapt if the user wants a lighter pass.

When to Offer This Workflow

Trigger conditions:

• User mentions cloud architecture or closely related work
• They want a structured workflow rather than ad-hoc tips
• They are preparing a review, rollout, or stakeholder communication

Initial offer: Explain the four stages briefly and ask whether to follow this workflow or work freeform. If they decline, continue in their preferred style.

Workflow Stages

Stage 1: Clarify context & goals

Anchor on accounts, networking, identity. Ask what success looks like, constraints, and what must not break. Capture unknowns early.

Stage 2: Design or plan the approach

Translate goals into a concrete plan around data and encryption. Compare alternatives and explicit trade-offs; avoid implicit assumptions.

Stage 3: Implement, validate, and harden

Execute with verification loops tied to scalability patterns. Prefer small steps, measurable checks, and rollback points where risk is high.

Stage 4: Operate, communicate, and iterate

Close the loop with operational model: monitoring, documentation, stakeholder updates, and lessons learned for the next cycle.

Checklist Before Completion

• Goals and constraints are explicit for cloud architecture
• Risks and trade-offs are stated, not hand-waved
• Verification steps match the change’s impact (tests, canary, peer review)
• Operational follow-through is covered (monitoring, docs, owners)

Tips for Effective Guidance

• Be procedural: stage-by-stage, with clear exit criteria
• Ask for missing context (environment, scale, deadlines) before prescribing
• Prefer checklists and concrete examples over generic platitudes
• If the user declines the workflow, switch to freeform help without lecturing

Handling Deviations

• If the user wants to skip a stage: confirm and continue with what they need.
• If context is missing: ask targeted questions before strong recommendations.
• Prefer concrete examples, trade-offs, and verification steps over generic advice.

Quality Bar

• Each recommendation should be actionable (what to do next).
• Call out failure modes relevant to cloud systems (security, scale, UX, or ops).
• Keep tone direct and respectful of the user’s time.