bateau84/skills

terraform-provider-docs

Create, update, and review Terraform provider documentation for Terraform Registry using HashiCorp-recommended patterns, tfplugindocs templates, and schema descriptions.

ソースを見る

使い方

  1. インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
  2. 必要なツール、認証情報、対応環境を原文で確認します。
  3. 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/bateau84/skills --skill terraform-provider-docs

開始前の確認

  • 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
  • スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文

見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。

Terraform Provider Docs

Follow This Workflow

  1. Confirm scope and documentation targets.
  • Map code changes to the exact doc targets: provider index, resources, data sources, ephemeral resources, list resources, functions, or guides.
  • Decide whether content should come from schema descriptions, templates, or both.
  1. Write schema descriptions first.
  • Add precise user-facing descriptions to schema fields so generated docs stay aligned with behavior.
  • Keep wording specific to argument purpose, constraints, defaults, and computed behavior.
  1. Add or update template files in docs/.
  • Create only files that map to implemented provider objects.
  • Use HashiCorp-recommended template paths:
  • docs/index.md.tmpl
  • docs/data-sources/<name>.md.tmpl
  • docs/resources/<name>.md.tmpl
  • docs/ephemeral-resources/<name>.md.tmpl
  • docs/list-resources/<name>.md.tmpl
  • docs/functions/<name>.md.tmpl
  • docs/guides/<name>.md.tmpl
  • Keep templates focused on overview and examples; rely on generated sections for field-by-field details.
  1. Generate documentation with tfplugindocs.
  • Prefer repository defaults when configured:
bash
go generate ./...
  • Otherwise run the generator directly:
bash
go run github.com/hashicorp/terraform-plugin-docs/cmd/tfplugindocs generate --provider-name <provider_name>
  • Re-run generation after every schema or template edit.
  1. Validate the generated markdown.
  • Verify files in docs/ match the current provider implementation.
  • Verify examples are valid HCL and reflect current argument/attribute names.
  • Verify required/optional/computed semantics in docs match schema behavior.
  1. Apply Registry publication rules before release.
  • Use semantic version tags prefixed with v (for example v1.2.3).
  • Create release tags from the default branch.
  • Keep terraform-registry-manifest.json in the repository root.
  • Expect docs to be versioned in Registry and switchable with the version selector.
  1. Preview or troubleshoot publication when needed.
  • Use the HashiCorp preview process to inspect rendered docs before release when accuracy risk is high.
  • If docs are missing in Registry, check tag format, tag source branch, manifest file presence, and provider publication status.

Enforce Quality Bar

  • Keep documentation behaviorally accurate; never describe unsupported arguments or attributes.
  • Keep examples minimal, realistic, and runnable.
  • Keep terminology and naming consistent across provider, resources, and data sources.
  • Avoid duplicating generated argument/attribute blocks in manual templates.
  • Keep doc changes tied to the same PR as schema/API changes whenever possible.

Load References On Demand

  • Read references/hashicorp-provider-docs.md for source-backed rules and official links.
  • Load only the sections needed for the current change to keep context lean.

タスクに関連する項目

同じリポジトリから

関連する Skills

すべての Skills
bateau84
コミュニティ

behavioral-spec

Derive bounded, implementation-independent requirements from agreed product intent through goal refinement, coverage lenses, obstacle analysis, provenance tracking, and counterexample checks. Use to select, author, and reconcile Behavioral Requirements (BR), Quality Scenarios (QS), and Obligation Contracts (OC) without expanding scope. Not for concrete API/schema/protocol realization (use architectural-spec) or human-centered stories and scenarios (use user-stories-and-scenarios).

1時間の導入数
1
GitHub Stars
0
更新日
10月18日
bateau84
コミュニティ

desktop-ui-design

Desktop GUI design for native and hybrid applications: platform conventions (macOS HIG, Windows Fluent, GNOME HIG), menus, keyboard shortcuts, window management, session persistence, native vs Electron/Tauri trade-offs, and accessibility APIs. Use for Swift/AppKit, C/WinUI, GTK+, or Electron/Tauri/Flutter desktop design. Add web-ui-design for a web app shipped as a desktop wrapper. Not for browser-only interfaces, terminal applications (use tui-design), or command-line tools (use cli-design).

1時間の導入数
1
GitHub Stars
0
更新日
10月18日
bateau84
コミュニティ

git-commit-discipline

Small coherent commits, explanatory messages, shared-working-tree discipline, and safe undo/recovery. Use when asked to commit, when a diff mixes concerns, when agents share a working tree, or when undoing or recovering Git changes. Not for content conflicts (use git-conflicts).

1時間の導入数
1
GitHub Stars
0
更新日
10月18日
bateau84
コミュニティ

golang-dependency-injection

google/wire, uber-go/dig, uber-go/fx, samber/do, manual constructor injection, and service containers in Go. Use when designing service architecture, setting up dependency injection, refactoring tightly coupled code, or managing singletons and service factories.

1時間の導入数
1
GitHub Stars
0
更新日
10月18日