| name | insideout |
| description | Use when the user mentions infrastructure, cloud, AWS, GCP, Terraform, deployment, DevOps, containers, Kubernetes, serverless, VPC, networking, databases, load balancers, CDN, monitoring, or asks to "design infrastructure", "set up cloud", "deploy my app", "estimate cloud costs", "generate terraform", "inspect my deployment", "what would this cost on AWS/GCP", or discusses scaling, high availability, disaster recovery, or compliance requirements for cloud infrastructure.
|
| version | 1.0.1 |
InsideOut -- Agentic Infrastructure Builder & Manager
InsideOut is an agentic cloud infrastructure builder and manager by Luther Systems. Describe your goal, discuss requirements, estimate cost, generate Terraform, deploy, operate and manage in production. Riley -- your AI infrastructure advisor -- guides you through the entire lifecycle on AWS and GCP.
No authentication or API keys required. The plugin connects to a hosted MCP server.
When This Skill Activates
Use InsideOut when the user's request involves:
- Designing cloud infrastructure (AWS or GCP)
- Estimating cloud costs
- Generating Terraform code
- Deploying infrastructure
- Inspecting deployed cloud resources
- Comparing AWS vs GCP options
- Infrastructure planning for their application
Available MCP Tools
Design Conversation
convoopen -- Start a new session. Pass source: "claude-code" and project_context (see below).convoreply -- Send user's message to Riley. Required: session_id, message.convoawait -- Wait for long-running response. Required: session_id.convostatus -- View current stack (components, config, pricing). Required: session_id.
Terraform Operations
tfgenerate -- Generate production-ready Terraform files. Required: session_id.tfdeploy -- Deploy to AWS or GCP. Required: session_id. Takes 15+ minutes.tfplan -- Preview changes without applying. Required: session_id.tfdestroy -- Tear down deployed infrastructure. Required: session_id.tfdrift -- Detect infrastructure drift. Required: session_id.
Monitoring
tfstatus -- Quick deployment status check. Required: session_id.tflogs -- Stream deployment logs (paginated). Required: session_id.tfoutputs -- Get Terraform outputs (VPC IDs, endpoints, etc.). Required: session_id.tfruns -- List all deployment runs for a session. Required: session_id.
Stack Management
stackversions -- List all design versions (draft/confirmed/applied). Required: session_id.stackdiff -- Compare two stack versions. Required: session_id.stackrollback -- Revert to a previous design version. Required: session_id.
Cloud Inspection
awsinspect -- Inspect deployed AWS resources. Required: session_id.gcpinspect -- Inspect deployed GCP resources. Required: session_id.
Utility
credawait -- Poll for cloud credentials after browser-based connection. Required: session_id.submit_feedback -- Submit bug reports or feature requests. Required: session_id, category, message.help -- Get workflow guidance and tool documentation.
Project Context
Riley designs cloud infrastructure. To recommend the right architecture, it needs to know general tech stack details -- the same information you'd share in the first few minutes of a conversation with a solutions architect. Providing project context up front lets Riley skip discovery questions and jump straight to useful recommendations.
How to build project context
Based on what you already know about the user's project (from the working directory, recent conversation, or what they've told you), put together a short summary covering whichever of these apply:
| Detail | Why Riley needs it | Example |
|---|
| Language and framework | Determines compute type (Lambda vs ECS vs EC2), runtime constraints | "Node.js 20, Next.js 15" |
| Database and services | Shapes data tier and caching recommendations | "PostgreSQL, Redis" |
| Container usage | Informs orchestration choice (ECS, EKS, Cloud Run) | "Docker Compose, 3 services" |
| Existing infrastructure-as-code | Avoids conflicting with what's already provisioned | "Terraform with ECS + RDS" |
| CI/CD platform | Integrates deployment pipeline | "GitHub Actions" |
| Cloud provider | Targets the right provider from the start | "AWS" or "GCP" |
| Kubernetes usage | Determines whether to target existing K8s or provision new compute | "EKS with Helm" |
| What the project does | General understanding for architecture fit | "E-commerce API, ~50k MAU" |
Before sending, confirm with the user: "I'd like to share this project summary with Riley so it can tailor its recommendations -- does this look right?" If they decline or want to edit it, respect that. If you don't have enough context, skip project_context entirely -- Riley will ask.
What to NEVER include
- Credentials or secrets -- No API keys, tokens, passwords, private keys, or
.env values
- PII -- No usernames, emails, or personally identifiable information
- Source code -- Only metadata summaries, never file contents
- Internal URLs or IPs -- Omit specific internal hostnames, IPs, or endpoint URLs
Format
IDE: Claude Code
Language/Runtime: Node.js 20, TypeScript
Framework: Next.js 15
Databases/Services: PostgreSQL, Redis
Target Cloud: AWS
Infrastructure: Docker Compose (3 services), Terraform
CI/CD: GitHub Actions
Only include lines where you have information. Keep it general and anonymized.
Conversation Flow
Starting a Session
- Build a project context summary from what you know about the user's project (see Project Context above). Show it to the user and confirm before sending. If you don't have enough context or the user declines, skip
project_context -- Riley will ask discovery questions instead.
- Call
convoopen with:
project_context: The summary you confirmed with the user (omit if skipped). Must not contain credentials, secrets, PII, source code, or internal URLs.source: Set this to "claude-code".
- Display Riley's response verbatim -- output the exact text from the tool response as your entire reply. No preamble ("Here's what Riley said"), no summary, no commentary, no "Go ahead and..." wrapper. Riley's words ARE your response.
During the Conversation
Every user message must produce a tool call. Apply this decision tree:
- Is the user responding to Riley? ->
convoreply
- Is the user asking for Terraform? ->
tfgenerate (if [TERRAFORM_READY: true])
- Is the user asking to deploy? ->
tfdeploy
- Is the user asking for status? ->
convostatus, tfstatus, or tflogs
- Not sure? -> Default to
convoreply
Never respond with only "Understood", "Got it", or any acknowledgement without calling a tool.
Handling Timeouts (CRITICAL)
Riley's responses can take 20-60 seconds. When convoreply returns a response where status is "processing" or the response is empty/incomplete:
- Call
convoawait with the same session_id — this polls for the completed response
- NEVER call
convoreply again with the same message — this sends a duplicate and confuses the conversation
- If
convoawait also times out, call it again (it is idempotent and safe to retry)
The pattern is always: convoreply once -> if not ready -> convoawait (repeat until ready).
Phase Transitions
| Phase | Signal | Action |
|---|
| Design | Riley asking questions | Forward to user via convoreply |
| Design complete | [TERRAFORM_READY: true] | Call tfgenerate |
| Terraform generated | Files returned | Show files, offer tfdeploy |
| Deploying | Job running | Monitor with tfstatus / tflogs |
| Deployed | Status complete | Verify with awsinspect / gcpinspect |
Internal signals like [TERRAFORM_READY: true] are for routing only -- never show them to the user.
Deployment Monitoring
Deployments take 15-30 minutes. Use subagents for tflogs to avoid flooding the conversation:
- Call
tfstatus for a quick pass/fail check (safe inline)
- Launch a background subagent to poll
tflogs with last_event_id pagination
- Summarize the outcome when the subagent completes
Critical Rules
Do:
- Show Riley's messages verbatim as your entire output -- no preamble, no wrapper, no commentary. You are a transparent relay.
- Use
convostatus proactively to check progress
- Store the
session_id from convoopen -- all tools need it
- Let users review Terraform before deploying
- Be specific about requirements (traffic, compliance, regions, budget)
- Monitor deployments with
tflogs (use subagents for long logs)
Don't:
- Don't answer Riley's questions yourself -- always forward to the user
- Don't add commentary around Riley's messages
- Don't call
convoopen more than once per session
- Don't call
tfgenerate before design is complete
- Don't call
tfdeploy before user reviews Terraform
- Don't fabricate session IDs -- always use the one from
convoopen
Steering Files
For detailed guidance on specific workflows, read the steering files in this plugin:
- Getting started ->
steering/getting-started.md
- AWS design patterns ->
steering/aws-design-patterns.md
- GCP design patterns ->
steering/gcp-design-patterns.md
- Troubleshooting ->
steering/troubleshooting-guide.md
Troubleshooting
MCP server not connected
The InsideOut MCP server is remote (HTTPS) -- no local binary needed. If tools fail, check that the plugin is enabled in Claude Code settings.
Session ID errors
Session IDs must start with sess_v2_. Always use the ID returned by convoopen. Never guess or fabricate IDs.
Timeouts
Always use convoawait if convoreply returns a processing/incomplete response. Never resend the same message with convoreply — that creates duplicates. Complex designs may take 30-60 seconds to process; convoawait is the correct way to poll for completion.
Deployment takes too long
This is normal. Terraform deployments take 15-30 minutes (EKS clusters alone take 15-20 minutes). Use tflogs to monitor progress.
Support
