---
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

1. 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.
2. 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"`.
3. 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:

1. Is the user responding to Riley? -> `convoreply`
2. Is the user asking for Terraform? -> `tfgenerate` (if `[TERRAFORM_READY: true]`)
3. Is the user asking to deploy? -> `tfdeploy`
4. Is the user asking for status? -> `convostatus`, `tfstatus`, or `tflogs`
5. 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:

1. **Call `convoawait`** with the same `session_id` — this polls for the completed response
2. **NEVER call `convoreply` again with the same message** — this sends a duplicate and confuses the conversation
3. 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:

1. Call `tfstatus` for a quick pass/fail check (safe inline)
2. Launch a background subagent to poll `tflogs` with `last_event_id` pagination
3. 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

- **Discord:** https://insideout.luthersystems.com/discord
- **Tech call:** https://insideout.luthersystems.com/tech-call
- **Email:** contact@luthersystems.com