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 commands/techequitycloud/rad-modules/add-modulegit clone --depth 1 https://github.com/techequitycloud/rad-modulesWhat 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.00000 | $0.01219 |
| Opus 5 | $0.00000 | $0.00609 |
| Sonnet 5 | $0.00000 | $0.00244 |
| Haiku 4.5 | $0.00000 | $0.00122 |
Grade A, and why
add-module 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 — 104 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Guided walkthrough for adding a new rad-modules module: $ARGUMENTS
$ARGUMENTS may name the new module and/or its shape (e.g. "Anthos_GKE based on Bank_GKE", "a new attached-cluster module for OKE"). If anything essential is unclear (module name, which existing module to copy, target cloud), ask before scaffolding.
Follow the "Checklist When Adding a New Module" in
.agent/skills/module-conventions/SKILL.md. Work through the phases below, pausing where a
human decision is genuinely needed.
PHASE 1 — CHOOSE THE TEMPLATE
Pick the closest existing module to copy (no symlinks — every file is a standalone copy):
- Attached cluster (registers a non-GKE cluster in a Fleet via Helm) → copy AKS_GKE or EKS_GKE (Pattern A, direct provider).
- Native GKE + add-ons (mesh, app deploy) → copy Istio_GKE or Bank_GKE (Pattern B, impersonated provider).
- Multi-cluster → copy MC_Bank_GKE (static kubernetes provider aliases cluster1–cluster4).
- Migration / non-cluster → copy Container_Migration or Migration_Center.
State which template you chose and why. Copy it to modules/<New_Name>/ with a
PascalCase_WithUnderscores name.
PHASE 2 — PROVIDER AUTH
Decide Pattern A vs Pattern B (see module-conventions SKILL.md) and DELETE the unused file:
- Pattern A: keep a single
provider.tf; removeprovider-auth.tf+versions.tfsplit. - Pattern B: keep
versions.tf+provider-auth.tf; removeprovider.tf. If the module usesgoogle-beta, it MUST be Pattern B.
PHASE 3 — VARIABLES
In variables.tf:
a) Keep the ten standard variables intact with their exact names/types/defaults:
module_description, module_dependency, module_services, credit_cost,
require_credit_purchases, enable_purge, public_access, deployment_id,
resource_creator_identity, trusted_users. Copy trusted_users' validation blocks verbatim.
b) Keep enable_services at group 0, order 109.
c) Update module_description / module_dependency / module_services / credit_cost defaults
to match the new module's scope.
d) Add module-specific variables in their own # SECTION N: block. Every variable
description MUST end with a {{UIMeta group=N order=NNN }} tag. Add updatesafe to
variables that can change in place; omit it for replace-forcing ones (cluster names,
CIDRs). Set sensitive = true on any credential variable and give it NO hardcoded default.
This is the part where your design judgement matters most — the variable surface defines the module's UI and contract. Propose the SECTION layout and the module-specific variables, and confirm with the user before writing the full file if the scope is non-trivial.
PHASE 4 — main.tf SCAFFOLD
Ensure main.tf has: the locals (random_id, project, project_services), random_id.default,
data.google_project.existing_project, and google_project_service.enabled_services with
for_each = toset(local.project_services) and BOTH disable_dependent_services = false and
disable_on_destroy = false. Update default_apis to exactly the APIs this module needs.
PHASE 5 — RESOURCES & POST-PROVISIONING
Implement the feature .tf files (network.tf, gke.tf, .tf). For anything not
expressible as a resource (CLI installs, manifest applies, waiting for an IP), use
null_resource + local-exec following the SKILL rules: triggers capture every destroy-time
variable; create provisioner uses set -eo pipefail; destroy provisioner uses set +e and
--ignore-not-found. Put Kubernetes YAML under manifests/ (raw) or templates/ (templated).
Ensure every new .tf begins with the Apache 2.0 license header (copy from a neighbour).
PHASE 6 — OUTPUTS
outputs.tf exports at least deployment_id and project_id, plus any user-facing endpoint
(e.g. ingress gateway IP) with a short description.
PHASE 7 — DOCS
a) Write README.md with the standard tables (Overview, Usage, Requirements, Providers,
Resources, Inputs, Outputs) reflecting the final variables.tf/outputs.tf.
b) Write the lab guide at docs/labs/<New_Name>.md (Overview & Architecture → Lab Setup →
Exercises → Cleanup → Reference). Do NOT create a LAB_GUIDE.md inside the module.
c) Set module_documentation default in variables.tf to that lab guide's GitHub URL.
d) Add the module to the "Module Families" table in CLAUDE.md. Leave README.md alone — it is
the upstream OpenTofu project README and carries no module list.
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 · 104 lines · 0 tokens per session scan A a8b65683f589
add-module is a command published in the GitHub repository techequitycloud/rad-modules (2 stars, last pushed 8d ago), licensed MPL-2.0. It costs nothing until one of its globs matches a file; then it loads 1,219 tokens. 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-31.
Other commands, from other repositories
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
converge
Assess the current codebase against the feature's spec, plan, and tasks, then append any remaining unbuilt work as new tasks to tasks.md so implement can complete it.
implement
Execute the implementation plan by processing and executing all tasks defined in tasks.md.