author-component

Authoring a missing component

When a design genuinely needs a capability and python ${CLAUDE_PLUGIN_ROOT}/engine/cli.py list shows no matching component, do not silently drop it or avoid it. Author a real, thorough component that follows the contract, then use it like any other. Only fall back to a documented "named upgrade path" (a note in decisions, not a node) if you genuinely cannot author it — e.g. no web access to verify the provider's resource schema.

This is the one sanctioned way to add a type that isn't already in components/.

0. Confirm it's actually missing and worth adding

• cli.py list and skim components/<provider>/ — make sure no existing component covers it (e.g. don't add "cache" if aws.elasticache.redis fits).
• A component must be a reusable building block, not a one-off. If it's truly bespoke, prefer composing existing components.

1. Research before writing (be thorough)

Working from a documentation URL? Use the research-component skill (skills/research-component/SKILL.md) for this step — it crawls the doc page, fans out subagents over the relevant subpages, and hands back a verified research brief. Return here with that brief for steps 2–5.

1. Read the contract end to end: components/CONTRACT.md. It is the source of truth for every field and convention below.
2. Mirror two existing components of the closest shape as templates — read all four files of each:
   • a compute one (aws/ecs-service or aws/lambda-function) if it runs code,
   • a store/managed one (aws/dynamodb-table, aws/s3-bucket) if it holds data,
   • a network one (aws/rds-postgres) if it lives in the VPC behind a security group,
   • an external/SaaS one (web/frontend, supabase/database) if it's not AWS IaC.
3. Look up the real Terraform resources on the Terraform Registry (registry.terraform.io → the provider → Resources): get the exact resource names, required arguments, and sane defaults. Prefer raw resource blocks; wrap a registry module only for genuinely complex things (VPC, EKS). Verify against the provider's own docs — never copy from third-party blog snippets.
4. Note cross-resource needs. Some components need a resource that lives on another node (e.g. CloudFront needs an S3 bucket policy that references the distribution ARN — "reverse injection"). The contract's provides/inbound injection covers a target referencing a source; if you need the opposite, emit the dependent resource from the component that owns it and reference across with a documented convention, or note the limitation in the component's SKILL.md.