Help us improve
Share bugs, ideas, or general feedback.
From nullstone-skills
Use when creating or editing Nullstone IaC YAML files under `.nullstone/` — adding or wiring apps, datastores, networks, domains, subdomains, ingresses, clusters, cluster-namespaces; setting `vars`, `environment`, `connections`, or `capabilities`; configuring `events`. Triggers on file paths `.nullstone/config.yml`, `.nullstone/{env}.yml`, `.nullstone/previews.yml`, and anything under `.nullstone/stacks/{stack}/`.
npx claudepluginhub nullstone-io/agent-skills --plugin nullstone-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/nullstone-skills:nullstone-config-filesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Produces schema-valid Nullstone IaC YAML with a consistent style, using the Nullstone MCP to resolve modules before emitting blocks.
references/docs/app-capabilities.mdreferences/docs/apps.mdreferences/docs/blocks.mdreferences/docs/cluster-namespaces.mdreferences/docs/clusters.mdreferences/docs/datastores.mdreferences/docs/event-targets.mdreferences/docs/events.mdreferences/docs/ingresses.mdreferences/docs/multi-stack.mdreferences/docs/networks.mdreferences/docs/overview.mdreferences/docs/subdomains.mdreferences/examples/global-config.ymlreferences/examples/global-previews.ymlreferences/examples/stack-scoped-config.ymlreferences/schema/config.0.1.jsonscripts/refresh-docs.mdMeasures whether skills, rules, and agent definitions are actually followed by auto-generating test scenarios at 3 strictness levels and reporting compliance rates with full tool call timelines.
Share bugs, ideas, or general feedback.
Produces schema-valid Nullstone IaC YAML with a consistent style, using the Nullstone MCP to resolve modules before emitting blocks.
.nullstone/ (single-stack or multi-stack)..nullstone/ directory from scratch.nullstone up, nullstone launch) — those are runtime, not config..nullstone/.Two layouts. Stack-scoped wins exclusively — if any stack-scoped file exists for a stack, global files are ignored for that stack.
Global (applies to any stack hooked up via GitOps):
.nullstone/config.yml — base.nullstone/<env>.yml — overlay for a specific env.nullstone/previews.yml — overlay for all preview envsStack-scoped (directory name must match the stack name):
.nullstone/stacks/<stack>/config.yml — base.nullstone/stacks/<stack>/<env>.yml — overlay.nullstone/stacks/<stack>/previews.yml — overlay for previewsOverlay semantics:
module is optional in overlays — include it only when changing the module.vars / connections in overlays replace the matching fields from the base.environment in overlays appends to (does not replace) the base set.When adding a new block, follow these steps in order:
Resolve the module. Use the nullstone MCP:
modules_find to discover candidates when the user describes what they want ("postgres", "static site", "fargate cluster").modules_describe on the chosen module to read its category, expected vars, connections, and capabilities.Place the block under the correct top-level key based on the module category:
| Module category | Top-level key |
|---|---|
app | apps |
datastore | datastores |
network | networks |
domain | domains |
subdomain | subdomains |
ingress | ingresses |
cluster | clusters |
cluster-namespace | cluster_namespaces |
| other / generic | blocks |
Emit the block using the style rules below.
Sanity-check against references/schema/config.0.1.json before finishing.
If modules_find / modules_describe are unavailable, ask the user to confirm the module source and category rather than guessing — placing a block under the wrong top-level key silently breaks Nullstone.
Apply these to every block you write. Deviate only on explicit user request.
module
module_version
connections
vars
environment # apps only
capabilities # apps only
events
domains
subdomains
ingresses
apps
datastores
cluster_namespaces
clusters
networks
blocks
Rationale: events is orthogonal and always sits at the top. The rest is a dependency order — consumers appear above providers so a reader sees the "what" before the "how". Within each top-level map, order member keys alphabetically unless a natural grouping is clearer.
module_versionOmit unless the user explicitly asks to pin a version.
Use the map form — the key is the capability's name:
capabilities:
postgres:
module: nullstone/aws-postgres-access
connections:
postgres: db
For colliding capabilities on the same app (e.g. two postgres accesses), add a namespace to prefix the injected env vars — see references/docs/app-capabilities.md. Only drop to the array form (- name: ...) on explicit user request.
Default to string, shortest form. Omit <stack>. / <env>. segments that match the file's own scope.
| Situation | Form |
|---|---|
| Same stack, same env | block-name |
| Same stack, different env | env-name.block-name |
| Different stack, different env | stack-name.env-name.block-name |
Global infra in global stack/global env | global.global.block-name |
Only use the object form ({ block_name, env_name, stack_name }) if the user explicitly asks for it.
version: "0.1" as a quoted string, always present at the top."{{ NULLSTONE_ENV }}.acme.com".postgres_version: "16") stay quoted.When writing an overlay (<env>.yml / previews.yml):
module unless changing it.environment entries are additive — use the overlay only for vars you want to add or change for that env.The authoritative schema is bundled at references/schema/config.<version>.json. Select by the YAML's version: key. Today only 0.1 exists. When a new version ships, drop config.0.2.json alongside and select based on the document's version: — the skill does not need to fork.
For editor / schemastore integration details, see references/docs/overview.md.
Read these to calibrate style before emitting output: