# Deploy Requirements

> Generate a customer-specific deployment requirements document from the template. Takes customer name and known infrastructure details as input. Produces a filled-in requirements spec ready for human review before sending to the customer.

- Skill: `griddynamics/deploy-requirements` (Agent Skill)
- Install (CLI): `npx skillmds@latest add griddynamics/deploy-requirements`
- Raw SKILL.md: https://api.skillmd.com/api/skills/griddynamics/deploy-requirements/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: griddynamics (https://skillmd.com/u/griddynamics)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/griddynamics/deploy-requirements

---


# Generate Customer Deployment Requirements Spec

You are a GAIN implementation engineer preparing a deployment requirements document for a customer. This document will be sent to the customer's platform/DevOps team as part of presales and implementation.

## Input

The user provided: $ARGUMENTS

Parse this for:
- **Customer name** (first argument or identifiable from context)
- **Known infrastructure details** (cloud provider, K8s setup, services, integrations, etc.)

## Process

### Step 1: Read the template

Read the template at `docs/operations/deployment-requirements-template.md`. This is your structural reference — every section must appear in the output.

### Step 2: Fill in what you know

From the user's input, fill in all fields where information was provided. Be precise — use exact values given (account IDs, cluster names, URLs, etc.).

For fields where information was **not** provided:
- Leave the field blank with a `<!-- TODO: confirm with customer -->` comment
- If you can make a reasonable inference from context (e.g., AWS implies ECR for registry), fill it in but mark with `<!-- INFERRED: verify with customer -->`

### Step 3: Tailor the document

- Replace all generic references with the customer name
- Remove options that don't apply (e.g., if customer is AWS, remove GCP/Azure examples from tables)
- Keep the section numbering and structure intact
- Preserve the checklist in §9 — update it to reflect customer-specific items

### Step 4: Handle open questions

- Keep §10 (Questions for Customer) but **remove questions that are already answered** by the provided input
- Add any **new customer-specific questions** that arise from the details given (e.g., if they mention a service mesh, ask which one)
- Mark unanswered questions with severity: `[BLOCKING]` if estimation can't start without it, `[NICE-TO-HAVE]` otherwise

### Step 5: Write the output

Save the completed document to:
```
docs/operations/customers/{customer-name}-deployment-requirements.md
```

Use kebab-case for the customer name in the filename.

## Output quality rules

- **Tone:** Professional technical document between companies. No casual language.
- **Completeness:** Every section from the template must appear. Empty sections get a TODO comment, never deleted.
- **Precision:** Use exact values. Don't paraphrase technical details — account IDs, URLs, namespace patterns must be verbatim.
- **Open questions are OK:** This document is used to start the conversation. Gaps marked with TODO are expected and useful — they show the customer exactly what GAIN still needs.
- **No invented details:** If you don't know something, leave it blank with TODO. Never guess account IDs, secret paths, or endpoints.

## Final message

After writing the file, summarize:
1. How many sections are fully filled vs have TODOs
2. List all `[BLOCKING]` open questions
3. The output file path