← 返回 Skills 市场
qq280948982

Ansible Generator

作者 qq280948982 · GitHub ↗ · v0.1.0 · MIT-0
cross-platform ⚠ suspicious
247
总下载
0
收藏
0
当前安装
1
版本数
在 OpenClaw 中安装
/install ansible-generator
功能描述
Generate, create, or scaffold Ansible playbooks, roles, tasks, handlers, inventory, vars.
使用说明 (SKILL.md)

Ansible Generator

Trigger Phrases

Use this skill when the request is to generate or scaffold Ansible content, for example:

  • "Create a playbook to deploy nginx with TLS."
  • "Generate an Ansible role for PostgreSQL backups."
  • "Write inventory files for prod and staging."
  • "Build reusable Ansible tasks for user provisioning."
  • "Initialize an Ansible project with ansible.cfg and requirements.yml."
  • "Give me a quick Ansible snippet to install Docker."

Do not use this skill as the primary workflow when the request is validation/debug-only (syntax errors, lint failures, Molecule/test failures). Use ansible-validator for those cases.

Deterministic Execution Flow

Run these stages in order. Do not skip a stage unless the Validation Exceptions Matrix explicitly allows it.

Stage 0: Classify Request Mode

Determine one mode first:

Mode Typical user intent Deliverable
full-generation "create/build/generate" a full playbook/role/inventory/project file set Complete file(s), production-ready
snippet-only "quick snippet/example" without full file context Focused task/play snippet
docs-only explanation, pattern comparison, or conceptual guidance only Explanatory content, optional examples

Stage 1: Collect Minimum Inputs

If details are missing, ask briefly. If the user does not provide them, proceed with safe defaults and state assumptions.

Resource type Required inputs Safe defaults if missing
Playbook target hosts, privilege (become), OS family, objective hosts: all, become: false, OS-agnostic modules
Role role name, primary service/package, supported OS role name from task domain, Debian + RedHat vars
Tasks file operation scope, required vars, execution context standalone reusable tasks with documented vars
Inventory environments, host groups, hostnames/IPs production/staging groups with placeholders
Project config collections/roles dependencies, lint policy minimal ansible.cfg, requirements.yml, .ansible-lint

Stage 2: Reference Extraction Checklist

Before drafting content, extract the following from local references/templates.

Required references

  • references/best-practices.md
    • Extract: FQCN requirements, idempotency rules, naming, security expectations.
  • references/module-patterns.md
    • Extract: correct module/parameter patterns for the exact task type.

Required templates by output type

  • Playbook: assets/templates/playbook/basic_playbook.yml
  • Role: assets/templates/role/ (including meta/argument_specs.yml and molecule/default/ for test scaffolding)
  • Inventory (INI): assets/templates/inventory/hosts
  • Inventory (YAML): assets/templates/inventory/hosts.yml
  • Project config: assets/templates/project/ansible.cfg, assets/templates/project/requirements.yml, assets/templates/project/.ansible-lint

Extraction checks

  • Identify every [PLACEHOLDER] that must be replaced.
  • Decide module selection priority (ansible.builtin.* first).
  • Capture at least one OS-appropriate package pattern when OS-specific behavior is needed.
  • Capture required prerequisites (collections, binaries, target assumptions).

Stage 3: Generate

Apply these generation standards:

  1. Use FQCN module names (ansible.builtin.* first choice).
  2. Keep tasks idempotent (state, creates/removes, changed_when when needed).
  3. Use descriptive verb-first task names.
  4. Use true/false booleans (not yes/no).
  5. Add no_log: true for sensitive values.
  6. Replace all placeholders before presenting output.
  7. Prefer ansible.builtin.dnf for RHEL 8+/CentOS 8+ (legacy yum only for older systems).

Stage 4: Validate (Default) or Apply Exception (Fallback)

Use the matrix below to keep validation deterministic and non-blocking.

Validation Exceptions Matrix

Scenario Default behavior Allowed fallback What to report
full-generation Run ansible-validator after generation and after each fix pass If validator/tools are unavailable, run manual static checks (YAML shape, placeholder scan, FQCN/idempotency/security review) and provide exact deferred validation commands Explicitly list which checks ran, which were skipped, and why
snippet-only Skip full validator by default; do inline sanity checks Run full validator only if user asks or snippet is promoted to full file State that validation was limited because output is snippet-only
docs-only No runtime validation None needed State that no executable artifact was generated
Offline environment (no web/docs access) Continue with local references and templates Skip external doc lookups; prefer builtin-module implementations; provide notes for later external verification State offline constraint and impacted checks/lookups

Resource Generation Guidance

Playbooks

  • Use assets/templates/playbook/basic_playbook.yml as structure.
  • Include: header comments, pre_tasks/tasks/post_tasks as needed, handlers, tags.
  • Add health checks when service deployment/configuration is involved.

Roles

  • Build from assets/templates/role/ structure.
  • Keep defaults in defaults/main.yml; keep higher-priority role vars in vars/main.yml.
  • Include OS-specific vars (vars/Debian.yml, vars/RedHat.yml) when relevant.
  • Add meta/argument_specs.yml for variable validation.
  • Include molecule/default/ scaffold (from assets/templates/role/molecule/) for production-ready roles.

Task Files

  • Keep scope narrow and reusable.
  • Document required input variables in comments.
  • Use conditionals for environment/OS-sensitive operations.

Inventory

  • Build logical host groups and optional group hierarchies.
  • Use variable layering intentionally: group_vars/all.yml -> group -> host.
  • Default to INI format (hosts) for simple topologies; use YAML format (hosts.yml) when the user requests it or when the hierarchy is complex.

Project Configuration

  • Provide baseline ansible.cfg, requirements.yml, and .ansible-lint.
  • Keep defaults practical and editable.

Custom Modules and Collections

When the request depends on non-builtin modules/collections:

  1. Identify collection + module and required version sensitivity.
  2. Check local references/module-patterns.md first.
  3. If still unresolved and network/tools are available, query Context7:
    • mcp__context7__resolve-library-id
    • mcp__context7__query-docs
  4. If Context7 is unavailable, use official Ansible docs / Ansible Galaxy pages.
  5. If external lookup is unavailable, provide a builtin fallback approach and state the limitation.

Always include collection installation guidance when collection modules are used.

Canonical Example Flows

Flow A: Full Generation (Playbook)

User prompt: "Create a playbook to deploy nginx with TLS on Ubuntu and RHEL."

  1. Classify as full-generation.
  2. Gather/confirm required inputs (hosts, cert paths, become, service name).
  3. Extract required references (best-practices.md, module-patterns.md) and playbook template.
  4. Generate complete playbook with OS conditionals (apt/dnf), handlers, validation for config templates.
  5. Run ansible-validator.
  6. Fix issues and rerun until checks pass (or apply matrix fallback if tooling unavailable).
  7. Present output with validation summary, usage command, and prerequisites.

Flow B: Quick Snippet (Task Block)

User prompt: "Give me a snippet to create a user and SSH key."

  1. Classify as snippet-only.
  2. Extract minimal module patterns for ansible.builtin.user and ansible.builtin.authorized_key.
  3. Generate concise snippet with FQCN, idempotency, and variable placeholders.
  4. Perform inline sanity checks (YAML shape, FQCN, obvious idempotency/security).
  5. Present snippet and note that full validator run was skipped due to snippet-only mode.

Output Requirements

For generated executable artifacts, use this response structure:

## Generated [Resource Type]: [Name]

**Validation Status:** [Passed / Partially validated / Skipped with reason]
- YAML syntax: [status]
- Ansible syntax: [status]
- Lint: [status]

**Summary:**
- [What was generated]
- [Key implementation choices]

**Assumptions:**
- [Defaults or inferred values]

**Usage:**
```bash
[Exact command(s)]

Prerequisites:

  • [Collections, binaries, environment needs]

## Done Criteria

This skill execution is complete only when all applicable items are true:

- Trigger decision is explicit (`full-generation`, `snippet-only`, or `docs-only`).
- Required references/templates were consulted for the selected artifact type.
- Generated output has no unresolved placeholders.
- Validation followed default behavior or a documented exception from the matrix.
- Any skipped checks include a concrete reason and deferred command(s).
- Final output includes summary, assumptions, usage, and prerequisites.
安全使用建议
This skill appears to be a focused Ansible scaffolder, but its runtime instructions expect many local template files and validator tools that are neither bundled nor declared. Before using or installing: (1) Confirm whether your agent/workspace actually contains the referenced paths (assets/templates/, references/). If not, the skill will either prompt for missing info or attempt to read your filesystem, which may expose unexpected files. (2) Expect the skill to try running validators (ansible-validator, ansible-lint) and possibly accessing external docs — ensure those binaries and network access are acceptable. (3) Ask the skill author/maintainer to either include the templates or declare required config paths and required binaries in the metadata so dependencies are explicit. (4) If you allow it, run the skill in a sandboxed agent or workspace first and review generated output carefully for placeholders or injected content. (5) If you have sensitive files in your workspace, restrict the agent's filesystem access until the skill's required file list is clarified.
功能分析
Type: OpenClaw Skill Name: ansible-generator Version: 0.1.0 The ansible-generator skill is a well-structured tool designed to scaffold Ansible playbooks, roles, and inventories. It follows industry best practices, such as enforcing Fully Qualified Collection Names (FQCN), ensuring idempotency, and explicitly instructing the agent to use 'no_log: true' for sensitive values. There is no evidence of data exfiltration, malicious execution, or prompt injection; the skill focuses entirely on its stated purpose of configuration generation and validation (SKILL.md).
能力评估
Purpose & Capability
The skill's name and description (generate/scaffold Ansible playbooks, roles, inventory) are coherent with the SKILL.md's generation rules and standards. However, the instructions assume a set of local reference files/templates and validation tooling that are not included or declared in the skill metadata, which is an implementation mismatch (expected but undeclared resources).
Instruction Scope
The SKILL.md instructs the agent to extract data from many explicit local paths (e.g. references/best-practices.md, assets/templates/playbook/basic_playbook.yml, assets/templates/role/, molecule/default/) and to run validators (ansible-validator, ansible-lint). Those files/tools are not part of the skill bundle nor declared as required config paths or required binaries. This means at runtime the agent will attempt to read arbitrary workspace paths and invoke local tooling — behavior not obvious from the metadata and potentially broader than a user expects.
Install Mechanism
No install spec and no code files — lower risk because nothing is written during install. But because the skill expects local templates and validators, missing install instructions or bundled templates reduces transparency: users won't know what the skill actually depends on or needs present on the agent host.
Credentials
The skill requests no environment variables or credentials, which is proportionate to a scaffolding skill. However, it references handling of sensitive values (no_log) and external doc lookups; it also expects validators and possibly network access. The lack of declared binaries/tools (ansible-validator, ansible-lint) is a discrepancy to note.
Persistence & Privilege
always:false and no install-time hooks or config writes are declared. The skill does not request permanent presence or elevated privileges in the metadata.
如何使用
  1. 确保已安装 OpenClaw(本地或 Docker 部署)
  2. 在对话框中输入安装命令:/install ansible-generator
  3. 安装完成后,直接呼叫该 Skill 的名称或使用 /ansible-generator 触发
  4. 根据 Skill 的参数说明提供必要输入,即可获得结构化输出
版本历史
v0.1.0
ansible-generator 0.1.0 - Initial release of the Ansible Generator skill. - Generates, creates, or scaffolds Ansible playbooks, roles, tasks, handlers, inventory, and vars. - Provides deterministic, stage-based execution flow for request classification, input collection, reference/template extraction, content generation, and validation. - Includes clear validation exception handling and reports, supporting both online and offline environments. - Uses best-practice standards for Ansible file structure, module usage, and idempotency. - Supports production-ready outputs and quick snippet generation, with detailed trigger phrase guidance.
元数据
Slug ansible-generator
版本 0.1.0
许可证 MIT-0
累计安装 0
当前安装数 0
历史版本数 1
常见问题

Ansible Generator 是什么?

Generate, create, or scaffold Ansible playbooks, roles, tasks, handlers, inventory, vars. 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件,目前累计下载 247 次。

如何安装 Ansible Generator?

在 OpenClaw 或 Claude Code 对话框中运行命令「/install ansible-generator」即可一键安装,无需额外配置。

Ansible Generator 是免费的吗?

是的,Ansible Generator 完全免费,采用 MIT-0 许可证,可自由下载、安装和使用。

Ansible Generator 支持哪些平台?

Ansible Generator 跨平台运行,可在任意部署了 OpenClaw / Claude Code 的环境中使用(cross-platform)。

谁开发了 Ansible Generator?

由 qq280948982(@qq280948982)开发并维护,当前版本 v0.1.0。

💬 留言讨论