Keeps project documentation like variables.tf and README.md in sync automatically.

Install

mkdir -p .claude/skills/sync-docs && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/3004" && unzip -o skill.zip -d .claude/skills/sync-docs && rm skill.zip

Installs to .claude/skills/sync-docs

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Use when documentation needs updating - ensures variables.tf, llms.md, kube.tf.example, and README are in sync
110 chars✓ has a “when” trigger
Intermediate

Key capabilities

  • Sync variables.tf with documentation
  • Identify undocumented configuration variables
  • Update kube.tf.example configurations
  • Verify consistency across project files

How it works

It extracts variables from the source of truth (variables.tf) and compares them against reference documents (llms.md, README.md) to identify and fill gaps.

Inputs & outputs

You give it
Project configuration files
You get back
Synchronized documentation and examples

When to use sync-docs

  • Sync terraform variables with README files
  • Update documentation after feature changes
  • Identify undocumented configuration variables

About this skill

Sync Documentation

Overview

Ensure documentation is synchronized across all key files when variables or features change.

Usage

/sync-docs

Documentation Files

FilePurposePriority
variables.tfSource of truth for all variablesPRIMARY
docs/llms.mdComprehensive variable referenceHIGH
kube.tf.exampleWorking example configurationHIGH
README.mdProject overview and quick startMEDIUM
MIGRATION.mdOperator-facing upgrade contract and v2 -> v3 variable mapHIGH for major upgrades
docs/v2-to-v3-migration.mdStepwise migration playbookHIGH for major upgrades
docs/selinux.mdSELinux policy provenance and AVC workflowHIGH for SELinux changes
docs/v3-release-evidence.mdLive proof and release evidenceHIGH for release claims
docs/terraform.mdAuto-generated terraform docsAUTO
docs/index.mdCurated documentation map and routing hubHIGH
docs/support-matrix.mdDetailed capability and maturity contractHIGH
docs/operations.mdDay-2 access, scaling, and cluster operationsMEDIUM
docs/upgrades.mdModule, Kubernetes, and transactional OS upgradesHIGH
docs/troubleshooting.mdIncident diagnosis and recovery proceduresHIGH
docs/recipes.md / docs/recipes/*Advanced configuration recipe index and focused guidesMEDIUM
docs/v3-topology-recommendations.mdTopology chooser and release-shaping guidanceMEDIUM
examples/*/README.mdFeature-specific operator examplesMEDIUM
tests/README.mdTest gate expectations and live-test notesMEDIUM
.claude/skills/*/SKILL.mdAgent/operator workflowsMEDIUM

Workflow

digraph sync_flow {
    rankdir=TB;
    node [shape=box];

    extract [label="1. Extract from variables.tf"];
    compare [label="2. Compare with docs/llms.md"];
    gaps [label="3. Identify gaps"];
    update_llms [label="4. Update docs/llms.md"];
    update_example [label="5. Update kube.tf.example"];
    update_readme [label="6. Update README if needed"];
    verify [label="7. Verify consistency"];

    extract -> compare;
    compare -> gaps;
    gaps -> update_llms;
    update_llms -> update_example;
    update_example -> update_readme;
    update_readme -> verify;
}

Step 1: Extract Variables from Source

Use exact extraction before semantic review:

# List all variables from variables.tf
rg -o '^variable "[^"]+"' variables.tf | cut -d'"' -f2 | sort -u

# Get variable details
sed -n '/^variable "<name>"/,/^}/p' variables.tf

Step 2: Find Undocumented Variables

# Compare source variable names with code-formatted names in docs/llms.md
comm -23 \
  <(rg -o '^variable "[^"]+"' variables.tf | cut -d'"' -f2 | sort -u) \
  <(rg -o '`[a-zA-Z_][a-zA-Z0-9_]*`' docs/llms.md | tr -d '`' | sort -u)

Step 3: Generate Documentation

docs/llms.md Format

**Variable Name**

```tf
variable_name = "default_value"
  • variable_name (Type, Optional/Required):
    • Default: default_value
    • Purpose: Clear explanation of what this does
    • Usage: When and how to use it
    • Considerations: Important notes, limitations, impacts
    • Example: Practical usage example if helpful

### kube.tf.example Format

```tf
  # Description of what this controls
  # Additional context if needed
  # variable_name = "default_value"

Step 4: Update docs/llms.md

For each undocumented variable:

  1. Read variable definition from variables.tf
  2. Understand its usage in locals.tf and other files
  3. Write comprehensive documentation following the format above
  4. Place in appropriate section of docs/llms.md

Section Organization in docs/llms.md

SectionVariables
Cluster Basicscluster_name, hcloud_token, ssh_*
Networknetwork_, subnet_
Control Planecontrol_plane_*
Agentsagent_, autoscaler_
Load Balancerlb_, traefik_, nginx_*
CNIcni_, cilium_, calico_*
Node Transportnode_transport_mode, tailscale_*
Storagelonghorn_*
Securityfirewall_, audit_
AdvancedAdditional/misc options

Step 5: Update kube.tf.example

Ensure new variables appear in the example with:

  • Clear comment explaining purpose
  • Commented out with default value
  • Grouped with related variables
# Inspect source variables that do not appear in kube.tf.example
comm -23 \
  <(rg -o '^variable "[^"]+"' variables.tf | cut -d'"' -f2 | sort -u) \
  <(rg -o '[a-zA-Z_][a-zA-Z0-9_]*[[:space:]]*=' kube.tf.example | sed 's/[[:space:]]*=//' | sort -u)

Step 6: Update README if Needed

Update README.md if:

  • New major feature added
  • New CNI or ingress option
  • Significant capability change

README is the visual project entry point, four-step Quick Start, and documentation router. Keep the running-cluster image in the opening block and keep README at or below the contract limit enforced by scripts/tests/test_generated_site_contract.sh. Put debugging, upgrade, day-2 operations, long support notes, and advanced recipes in their focused guides; add or update the route in docs/index.md instead of growing README.

When moving README content, keep repository-relative links valid from the new directory depth and regenerate site-docs/index.md with python3 scripts/sync_docs_site.py. The generator rewrites extracted README links for the site-docs/ directory; verify them with the generated-site contract test.

Features section should match actual capabilities.

For Tailscale changes, keep these surfaces in sync:

  • docs/support-matrix.md support levels and docs/recipes/networking-and-scale.md Tailscale recipe
  • kube.tf.example Tailscale node-transport comments
  • docs/llms.md support levels and variable notes
  • docs/v3-topology-recommendations.md
  • examples/tailscale-node-transport/README.md
  • examples/external-overlay-tailscale/README.md
  • examples/external-overlay-cloudflare-access/README.md when access-boundary wording changes
  • .claude/skills/kh-assistant/SKILL.md
  • .claude/skills/migrate-v2-to-v3/SKILL.md

For Cloudflare Zero Trust wording, keep the boundary consistent:

  • Cloudflare Access/Tunnel is a documented external operator/app access pattern.
  • kube-hetzner does not add Cloudflare provider inputs or manage Cloudflare resources.
  • Cloudflare Mesh/WARP is not supported kube-hetzner node transport in v3.
  • Tailscale remains the supported managed node transport for secure multinetwork scale.

For Cilium Gateway API changes, keep these surfaces in sync:

  • variables.tf validation for cilium_gateway_api_enabled
  • locals.tf Cilium values and Gateway API CRD version mapping
  • README.md
  • kube.tf.example
  • docs/llms.md
  • docs/v3-topology-recommendations.md
  • examples/cilium-gateway-api/README.md
  • .claude/skills/kh-assistant/SKILL.md
  • .claude/skills/test-changes/SKILL.md

For embedded registry mirror changes, keep these surfaces in sync:

  • variables.tf validation for embedded_registry_mirror
  • locals.tf effective generated registries YAML merge behavior
  • host/control-plane/agent/autoscaler config rendering
  • README.md
  • kube.tf.example
  • docs/llms.md
  • docs/v3-topology-recommendations.md
  • .claude/skills/kh-assistant/SKILL.md
  • .claude/skills/test-changes/SKILL.md

For v2 -> v3 migration or production-upgrade safety changes, keep these surfaces in sync:

  • MIGRATION.md, especially "Production in-place upgrades: safety model"
  • docs/v2-to-v3-migration.md
  • CHANGELOG.md upgrade notes
  • docs/v3-release-evidence.md live proof
  • .claude/skills/migrate-v2-to-v3/SKILL.md
  • .claude/skills/upgrade-cluster/SKILL.md
  • .claude/skills/kh-assistant/SKILL.md

The no-destroy gate must include the full protected hcloud set: hcloud_server, hcloud_network, hcloud_network_subnet, hcloud_load_balancer, hcloud_volume, hcloud_primary_ip, hcloud_placement_group, and hcloud_firewall.

For SELinux changes, keep these surfaces in sync:

  • docs/selinux.md
  • templates/kube-hetzner-selinux.te
  • templates/k8s-custom-policies.te
  • variables.tf enable_selinux and per-pool selinux
  • .claude/skills/debug-node/SKILL.md
  • .claude/skills/kh-assistant/SKILL.md

Do not make generic "disable SELinux" recommendations. The operator path is AVC evidence, udica-first workload policy, upstream module policy only with reproducible denials, and per-pool selinux = false as the last resort.

For release presentation changes, verify README's compact current-release link points at the latest release tag and that CHANGELOG.md contains the release content.

Step 7: Verify Consistency

Run the exact comparisons above, terraform-docs, the generated-site contract, and the relevant validators from /test-changes. Then inspect defaults and descriptions for each changed variable directly in all three surfaces.

Verification Checklist

  • All variables.tf variables documented in docs/llms.md
  • All major variables appear in kube.tf.example
  • README features match actual capabilities
  • No typos in variable names across files
  • Default values consistent across docs
  • Major-upgrade safety wording matches MIGRATION.md
  • SELinux workload-denial wording points to docs/selinux.md
  • README current-release URL is current for the release train

Common Sync Issues

Variable renamed

  1. Update in variables.tf
  2. Search and replace in docs/llms.md
  3. Search and replace in kube.tf.example
  4. Add to CHANGELOG.md (breaking change!)

Variable removed

  1. Remove from variables.tf
  2. Remove from docs/llms.md
  3. Remove from kube.tf.example
  4. Add to CHANGELOG.md (breaking change!)

Default changed

  1. Update in variables.tf
  2. Update in docs/llms.md
  3. Update in kube.tf.example
  4. Consider if this is a breaking change

Quick Commands

# Regene

---

*Content truncated.*

When not to use it

  • When the project does not use Terraform
  • When documentation is not maintained in the specified files

Prerequisites

Gemini model access for file analysis

Limitations

  • Requires Gemini for large file analysis
  • Manual review is needed for complex variable descriptions

How it compares

It automates the synchronization of documentation and examples with code changes, preventing configuration drift.

Compared to similar skills

sync-docs side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
sync-docs (this skill)16moReviewIntermediate
bazel-build-optimization142moNo flagsAdvanced
postmortem-writing172moNo flagsBeginner
aws-solution-architect203moReviewAdvanced

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

bazel-build-optimization

wshobson

Optimize Bazel builds for large-scale monorepos. Use when configuring Bazel, implementing remote execution, or optimizing build performance for enterprise codebases.

14116

postmortem-writing

wshobson

Write effective blameless postmortems with root cause analysis, timelines, and action items. Use when conducting incident reviews, writing postmortem documents, or improving incident response processes.

1799

aws-solution-architect

alirezarezvani

Design AWS architectures for startups using serverless patterns and IaC templates. Use when asked to design serverless architecture, create CloudFormation templates, optimize AWS costs, set up CI/CD pipelines, or migrate to AWS. Covers Lambda, API Gateway, DynamoDB, ECS, Aurora, and cost optimization.

2047

terraform-module-library

wshobson

Build reusable Terraform modules for AWS, Azure, and GCP infrastructure following infrastructure-as-code best practices. Use when creating infrastructure modules, standardizing cloud provisioning, or implementing reusable IaC components.

759

azure-deployment-preflight

github

Performs comprehensive preflight validation of Bicep deployments to Azure, including template syntax validation, what-if analysis, and permission checks. Use this skill before any deployment to Azure to preview changes, identify potential issues, and ensure the deployment will succeed. Activate when users mention deploying to Azure, validating Bicep files, checking deployment permissions, previewing infrastructure changes, running what-if, or preparing for azd provision.

746

terraform-azurerm-set-diff-analyzer

github

Analyze Terraform plan JSON output for AzureRM Provider to distinguish between false-positive diffs (order-only changes in Set-type attributes) and actual resource changes. Use when reviewing terraform plan output for Azure resources like Application Gateway, Load Balancer, Firewall, Front Door, NSG, and other resources with Set-type attributes that cause spurious diffs due to internal ordering changes.

534

Search skills

Search the agent skills registry