Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/cloudposse/atmos/component-developmentnpx skills add cloudposse/atmos --skill component-developmentgit clone --depth 1 https://github.com/cloudposse/atmosWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00044 | $0.01550 |
| Opus 5 | $0.00022 | $0.00775 |
| Sonnet 5 | $0.00009 | $0.00310 |
| Haiku 4.5 | $0.00004 | $0.00155 |
Grade A, and why
component-development scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 161 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Component Development
Use this skill when adding or changing an Atmos native component type or shared component behavior.
Start With The Existing Contract
Inspect comparable component types before designing:
rg -n "ComponentType|SectionName|components\\..*base_path" pkg/config pkg/schema
rg -n "component.Register|ComponentProvider|Execute\\(" pkg/component cmd internal
rg -n "process.*ComponentsIndexed|ExecuteGraph|dependencies.components" internal pkg
For stack-surface decisions, compare Terraform, Helmfile, Packer, and Ansible. Reuse shared sections when they already exist:
metadatavarsenvsettingshooksauthdependenciesgeneratesourceprovision
Do not invent nested settings for component-owned inputs. If an instance is components.<type>.<name>, component-specific inputs belong directly under that instance, e.g. components.kubernetes.argocd.paths, not settings.kubernetes.paths.
Required Wiring
For a new component type, update all applicable surfaces in one PR:
- Constants:
pkg/config/const.go - CLI/default config structs:
pkg/schema/schema.go - Defaults:
pkg/config/default.go - Config path resolution:
pkg/config/config.go,pkg/utils/component_path_utils.go - Component registry provider:
pkg/component/<type>/ - Command package:
cmd/<type>/ - Root side-effect imports:
cmd/root.go - Source provisioning base path support:
pkg/provisioner/source/ - Hooks/events if lifecycle hooks are supported:
pkg/hooks/ - Affected detection:
internal/exec/describe_affected_* - DAG/bulk execution if
--allor--affectedis supported - Embedded CLI usage examples:
cmd/markdown/atmos_<command>*_usage.md - Runtime stack schemas:
pkg/datafetcher/schema/atmos/manifest/1.0.jsonandpkg/datafetcher/schema/stacks/stack-config/1.0.json - LSP hints if stack authoring changes:
pkg/lsp/server/ - Docs: command docs, stack component docs,
atmos.yamlconfig docs - Examples under
examples/for user-visible component types
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 161 lines · 44 tokens per session scan A 52eade3a397f
component-development is a skill published in the GitHub repository cloudposse/atmos (1,365 stars, last pushed today), licensed Apache-2.0. It adds 44 tokens to every session and 1,550 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
x-cmd-advise
Skill "x-cmd-advise" from x-cmd/x-cmd, covering x-cmd advise writing guide, core principles, field quick reference, subcommands at root level and writing priority.
claw-admin
Claw system administration: service management, IM connections, logs, cron, and workspace diagnostics. Use when the user asks to manage claw services, connect/disconnect IM platforms, view logs, or perform system-wide operations.
x-nets
Enhanced netstat module with cached data and structured output. View network connections, routing tables, and interface statistics in interactive or TSV/CSV formats. Dependency: This is an x-cmd module. Install x-cmd first (see x-cmd skill for installation options). see x-cmd skill for installation.
x-arp
Display ARP cache table with MAC vendor lookup and suspicious entry detection. Supports CSV, TSV, and TUI output. Dependency: This is an x-cmd module. Install x-cmd first (see x-cmd skill for installation options). see x-cmd skill for installation.
x-mankier
Search and browse man pages from ManKier.com. Command line interface for ManKier man page repository. Dependency: This is an x-cmd module. Install x-cmd first (see x-cmd skill for installation options). see x-cmd skill for installation.
x-osv
CLI for Google OSV database. Query vulnerabilities for packages, scan local projects for vulnerable dependencies. Dependency: This is an x-cmd module. Install x-cmd first (see x-cmd skill). Required Tool: Install osv-scanner for project scanning (see https://github.com/google/osv-scanner).