Dap

Blueprint Assist — Dell Automation Platform

This skill provides a blueprint authoring reference distilled from the official Blueprint Developer's Guide (Feb 2026, Rev A01), plus CLI access to the Dell Automation Platform via the dap-bpa command.

Reference Files

Detailed reference material is in the references/ directory:

Routing — how-to / tutorial / workflow guide requests

If the user asks "how to", "walk me through", "guide me", "help me get started", or requests a step-by-step tutorial for any DAP workflow (writing blueprints, creating deployments, managing secrets, using plugins, deleting resources), load references/guides.md and follow its response guidelines.

Routing — update / Day-2 / drift requests

If the user asks to add or support update, Day-2 operations, drift checking, or reinstall on a blueprint (e.g. "add update support", "make this updatable", "add check_drift", "support deployment update"), first load packages/skills/dap-deployment-update/SKILL.md and follow its ND-009 authoring checklist before emitting YAML. A blueprint with update declared but no check_drift is incomplete — see ND-009 in blueprint-rules.md.

Routing — post-generation ISV onboarding

After blueprint lint passes, if the user has not yet uploaded or deployed the blueprint, load references/isv-onboarding-workflow.md and ask: "Would you like me to guide you through uploading and testing this blueprint in DAP?"

Runtime Mode

You are running in IDE mode with shell access. Use the dap-bpa CLI for BPA operations. Do not use the function interface unless explicitly instructed by the host.

Runtime-Specific References

Invocation Reference

Full CLI reference: references/cli-commands.md.

Invocation Examples

dap-bpa knowledge blueprints find "<query>"
dap-bpa blueprint lint --file blueprint.yaml --verify
dap-bpa blueprint validate-all --file blueprint.yaml

Plugin Lookup

When the user asks about a specific plugin (e.g. AWS, Kubernetes, Helm), retrieve plugin details on-demand via the CLI — no separate skill needed:

dap-bpa knowledge plugins list <plugin>        # List all node types for a plugin
dap-bpa knowledge plugins get <plugin> <type>  # Get node type properties
dap-bpa knowledge plugins docs <plugin>        # Plugin overview, auth, patterns
dap-bpa knowledge docs search "<query>" --plugin <name>  # Search plugin docs

Available plugins: ansible, aws, azure, docker, fabric, helm, hzp-edge, kubernetes, libvirt, openstack, redfish, storage, terraform, terragrunt, utilities, vcloud, vsphere.

Routing — DSL migration / conversion requests

If the user asks to migrate, convert, translate, or change the DSL version of a blueprint (e.g. "convert this from nativeedge_1_0 to dell_1_1", "migrate this blueprint to Dell DSL", "generate a new blueprint based on dell_1_1 dsl with the same structure", "change DSL version"), load references/migration-guide.md instead of the standard blueprint-rules.md.

Key indicators for migration:

• User mentions both a source DSL (nativeedge, cloudify, dell_1_0) and a target DSL (dell_1_1)
• User asks to "keep the same structure" or "preserve the structure"
• User uses verbs: migrate, convert, translate, change DSL, port, upgrade
• User says "generate based on X dsl" or "built on X dsl"

These are NOT migration requests (use standard workflow):

• User asks to generate a new blueprint from scratch
• User asks to improve or refactor an existing blueprint without DSL version change
• User asks to add features or functionality to an existing blueprint
• User asks to "change" or "update" a blueprint without mentioning DSL version
• User asks to "upgrade" dependencies or plugins without DSL version change

Migration workflow:

1. Load references/migration-guide.md
2. Read the original blueprint
3. Apply the migration rules first (DSL version, prefix replacement, NE-only property removal, import rename)
4. Preserve the original input structure, file structure, and node organization
5. After migration is complete, run the standard lint step (Step 7) — ND-003, IN-007, and other blueprint-rules.md compliance checks still apply to the migrated output
6. Inform the user the migration and lint are complete

Blueprint Generation Process

Follow these 8 steps in order. All blueprints must comply with the mandatory rules in blueprint-rules.md.

Skip steps 3 and 4 only when the user explicitly says "skip planning" or "just do it".

1. Combined search

Start with a broad search to find relevant docs, plugins, and examples:

dap-bpa knowledge search "<query>"

If dap-bpa knowledge search is not available, fan out manually:

dap-bpa knowledge docs search "<query>"
dap-bpa knowledge blueprints find "<query>"

2. Targeted research

Drill into specifics with focused commands. Do NOT write YAML until all lookups are complete.

dap-bpa knowledge docs search "<query>"
dap-bpa knowledge plugins docs <plugin>
dap-bpa knowledge plugins get <plugin> <node_type>
dap-bpa knowledge blueprints find "<description>"
dap-bpa knowledge blueprints get <id> --include-files

3. Propose

Before doing ANY work, present a plan describing:

• Single-file or multi-file structure
• Plugins required and node types to use
• Number of files and key design decisions

4. Get user approval

Wait for explicit user confirmation. Ask for target directory. Do NOT proceed without confirmation.

5. Look up node types

Run dap-bpa knowledge plugins get <plugin> <node_type> for every node type in the approved plan. This retrieves the exact properties, required fields, and defaults.

6. Build the blueprint

Write YAML using the looked-up properties. Comply with all mandatory rules from blueprint-rules.md:

• Always multi-file: blueprint.yaml, inputs.yaml, capabilities.yaml (BS-010)
• Use dell.* prefix, NOT cloudify.* or nativeedge.* (TD-002)
• Use capabilities:, NOT outputs: (CP-001)
• Secrets: Use type: secret_key, never literal passwords (SC-001, SC-002)
• CHANGELOG.yaml is mandatory (BS-009)
• No inline code (ND-005). For custom Python operations, load the dap-scripts skill.

7. Lint

CRITICAL: Run the linter BEFORE validation. Do NOT run validation commands until linting passes.

dap-bpa blueprint lint --file blueprint.yaml --verify

After generating the blueprint, run the linter. Fix all errors and re-lint until errorsFound: false. Then review warnings — fix what you can, skip only if you have a clear technical reason.

Do NOT confuse this with dap-bpa blueprint validate — that checks plugin schemas, not blueprint-rules.md compliance.

8. Validate

After lint passes, validate node properties against plugin schemas:

dap-bpa blueprint validate-all --file blueprint.yaml

Fix any schema errors and re-validate until clean.

Blueprint Authoring Reference

TOSCA Structure

Every blueprint starts with:

tosca_definitions_version: dell_1_1

imports:
  - dell/types/types.yaml
  - plugin:<plugin-name>?version= >=<major>.<minor>

description: >
  Purpose of this blueprint.

Inputs (Summary)

Inputs define deployment-time parameters:

inputs:
  vm_name:
    type: string
    display_label: VM Name
    description: Name for the virtual machine
    default: my-vm
    hidden: false
    allow_update: true
    display:
      group: vm_settings
    constraints:
      - pattern: '^[a-zA-Z][a-zA-Z0-9-]*$'
        error_message: Must start with a letter, alphanumeric and hyphens only.

Input Properties Reference

Constraint Types

input_groups Structure

input_groups:
  vm_settings:
    display_label: VM Settings
    index: 1
    collapsible: true
    inputs:
      - vm_name
      - vm_size

Valid keys: display_label, index, collapsible, inputs. The inputs list must exactly match names defined in inputs: — no extras, no typos. Every non-hidden input must appear in exactly one group.

Node Templates

node_templates:
  my_node:
    type: dell.nodes.<plugin>.<Type>
    properties:
      <property>: <value>
    interfaces:
      dell.interfaces.lifecycle:
        create:
          implementation: <plugin>.<module>.<function>
          inputs:
            <input>: <value>
    relationships:
      - type: dell.relationships.depends_on
        target: other_node

Lifecycle completeness (ND-003): Every node with create MUST define delete. Every node with start MUST define stop. Before writing lifecycle operations, load the full reference: dap-bpa knowledge docs get general/lifecycle-operations

Never invent node types. Only use types returned by dap-bpa knowledge types get <type> or dap-bpa knowledge plugins list <plugin>. If the type is not in the result, it does not exist.

Relationships

For plugin-specific relationship types, run_on_host, and decision guidance, see knowledge/docs/general/relationships.md. For lifecycle operation patterns (ND-003, ND-004), load dap-bpa knowledge docs get general/lifecycle-operations.

Intrinsic Functions

get_capability notes: Can use get_attribute, get_secret, concat inside capability values. get_property and get_input resolve at deploy-time and cannot be used inside capability values — capability values are evaluated at runtime, after deploy-time resolution has already completed.

Capabilities & Outputs

Use capabilities, not outputs — capabilities expose values to both users and other deployments. Every capability must have value and description fields. outputs is a legacy alias.

capabilities:
  vm_ip:
    description: "IP address for VM"
    value: { get_attribute: [ vm, ip ] }

Labels

Both labels and blueprint_labels are required:

labels:
  # csys-obj-type classifies the deployed object for the DAP catalog
  csys-obj-type:
    values:
      - environment
  environment:
    values:
      - production

blueprint_labels:
  # env tags the blueprint; non-orchestrator (utility/helm) blueprints also
  # set csys-blueprint-type, while the top-level orchestrator sets env only
  env:
    values:
      - Dell
  csys-blueprint-type:
    values:
      - utility

Each label key maps to an object with a single key values, which must be a list containing exactly one string. The repo validator (scripts/validate_blueprints.sh) enforces csys-obj-type under labels, env under blueprint_labels, and csys-blueprint-type on every non-orchestrator blueprint.

Workflows

Built-in workflows: install, uninstall, update, execute_operation.

Custom workflow definition:

workflows:
  clear_cache: my_plugin.cache_module.clear_cache_method
  update_app:
    mapping: my_plugin.update_module.run_updates
    parameters:
      app_version:
        description: Version to update to

Security Best Practices

1. Never pass a literal string to get_secret — always resolve via { get_secret: { get_input: secret_input } } (SC-001)
2. Never put get_secret in capabilities or outputs — values display in orchestrator UI
3. Never log secret values — ctx.logger.info with ctx_parameters containing secrets leaks them
4. Never store secrets in runtime_properties — retrievable via API
5. Never use get_secret as default in node type properties — readable in blueprint source

Available Plugins

Exception: the NativeEdge plugin (nativeedge) still uses nativeedge.* node type prefixes. All other plugins use dell.*.

Blueprint Directory & Multi-File Patterns

A blueprint lives in a directory on disk.

Always use multi-file structure: blueprint.yaml, inputs.yaml, capabilities.yaml. Single-file is not production-ready.

Key rules:

• Name the main file blueprint.yaml
• Only blueprint.yaml imports plugins and dell/types/types.yaml
• YAML anchors (dsl_definitions) are scoped to the file they are defined in. Each imported file must define its own dsl_definitions block if it needs anchors. To share values across files, use inputs or namespaced imports — not YAML aliases.
• Node template IDs must be unique across ALL files

CLI Quick Reference

Full CLI reference with all flags, fields, and workflows: references/cli-commands.md

For troubleshooting failed deployments and uploads: references/troubleshooting.md

Always attempt commands immediately. Do not ask the user whether credentials are configured. Just run the command; if credentials are missing, dap-bpa returns a clear error.

Essential commands

# Find example blueprints
# Query can be positional OR --query flag
dap-bpa knowledge blueprints find "<description>"
dap-bpa knowledge blueprints find --query "<description>" --plugin <name>
dap-bpa knowledge blueprints get <id> --include-files

# Look up node types
dap-bpa knowledge plugins list <plugin>
dap-bpa knowledge plugins get <plugin> <node_type>
dap-bpa knowledge types get <type_name>
dap-bpa knowledge types list
dap-bpa knowledge plugins docs <plugin>

# Search documentation
dap-bpa knowledge docs search "<query>"
dap-bpa knowledge docs search "<query>" --plugin <name>

# Lint and validate
dap-bpa blueprint lint --file <path> --verify
# Run lint first. Do not run validate-all until lint --verify passes.
dap-bpa blueprint validate-all --file <path>

# Upload
dap-bpa orchestrator blueprints upload --file blueprint.yaml --id <id> --revision <ver>

# Deploy
dap-bpa orchestrator deployments create --blueprint-id <id> [--inputs <file>]

# Troubleshoot
dap-bpa orchestrator executions list
dap-bpa orchestrator executions get <id> --fields id status error error_structured
dap-bpa orchestrator events get <execution_id>

Monitor

Runs a full install/uninstall lifecycle for a blueprint with auto-fix. Trigger: 'monitor this', 'did it pass', 'last run', 'check status', 'any failures'. Load references/monitor.md.