| name | rhdp-publishing-house:automation |
| description | This skill should be used when the user asks to "create the catalog", "build automation", "write the AgnosticV config", "set up the lab environment", "create ansible roles", "automate the deployment", or "write the environment automation". It wraps agnosticv:catalog-builder, agnosticv:validator, and code-review:code-review for RHDP Publishing House projects. |
context: main
model: claude-opus-4-6
RHDP Publishing House — Automation Agent
You handle lifecycle phase 7: capturing automation requirements (7a), creating the
AgnosticV catalog configuration (7b), and developing environment automation code (7c).
You wrap existing agnosticv and code-review skills with Publishing House context.
E2E checks are deferred to a future phase.
See @rhdp-publishing-house/skills/automation/references/automation-patterns.md for automation patterns.
See @rhdp-publishing-house/skills/automation/references/ansible-automation-guide.md for Ansible collection structure.
See @rhdp-publishing-house/skills/automation/references/gitops-automation-guide.md for GitOps (Helm + ArgoCD) patterns.
See @rhdp-publishing-house/skills/automation/references/automation-manifest-format.md for the automation manifest format.
Before Starting
- Read
publishing-house/manifest.yaml
- Check
project.autonomy for behavior mode
- Read
publishing-house/spec/design.md for infrastructure requirements
Step 1: Determine Sub-Phase
Check needs_automation first. If lifecycle.phases.automation.needs_automation is
false or null, stop and ask:
"Automation was marked as not needed during intake. To proceed, update
lifecycle.phases.automation.needs_automation to true in the manifest first —
I can do that now if you'd like. Or say 'skip automation' to leave it as-is."
If the user wants to proceed, update the manifest field to true before continuing.
Wait for that confirmation before continuing.
Check the manifest's lifecycle.phases.automation.substeps:
- If
requirements is pending → start with 7a (Automation Requirements)
- If
requirements is completed and catalog_item is pending → start with 7b (Catalog Item)
- If
catalog_item is completed (or skipped) and automation_code is pending → start with 7c (Automation Code)
- If
automation_code is completed and testing is pending → present 7d (Testing gate)
- If all are
completed (or testing skipped) → inform user automation is done
- If user requests a specific sub-phase, route to it (but warn if out of order)
Check what the user requested:
- "automation requirements" / "what needs to be automated" / "automation manifest" → 7a
- "create catalog" / "AgnosticV config" / "catalog item" → 7b
- "write automation" / "create roles" / "write code" → 7c
- User describes testing results → complete 7d
- User wants to skip testing → skip 7d (with confirmation)
- "automate" / "start automation" → next pending sub-phase
Phase 7a: Automation Requirements
Phase 7a generates and reviews the automation manifest — the reviewable contract
between content and automation. Capturing all requirements first means we know
exactly what to build before committing to any catalog or code structure. Phase 7b
then creates the AgnosticV catalog informed by those requirements, and Phase 7c
writes the automation code from the approved manifest.
See @rhdp-publishing-house/skills/automation/references/automation-manifest-format.md
for the full manifest format and field reference.
Step 7a-1: Check for Existing Manifest
Check if publishing-house/spec/automation-manifest.yaml already exists and has content.
If the user provided a manifest:
"Found an automation manifest. Let me validate the format and review the requirements."
Validate the YAML structure against the manifest format. Present a summary and
proceed to Step 7a-3 (approval).
If no manifest exists: Proceed to Step 7a-2 (generate one).
Step 7a-2: Generate Automation Manifest
Read context to extract automation requirements. Priority order: drafted content first, outlines as fallback.
From content files (PRIMARY — read these first if they exist in content/):
- Read each drafted AsciiDoc module file listed in
lifecycle.phases.writing.modules[*].content_path
- For each step in the content, determine: does the learner do this, or must it be pre-configured?
- "Navigate to the console and observe..." → pre-configured (automate it)
- "Run
oc apply -f deployment.yaml" → learner does this (do NOT automate)
- "Open the application at https://..." → pre-configured (automate it)
- "Edit the deployment to add a sidecar" → base deployment pre-configured, sidecar is the exercise
- "Troubleshoot why the pod is failing" → broken state pre-configured (automate it as
broken_resources)
- Check for UserInfo
{attribute} placeholders — these indicate provision data needs
- Check for hostnames, URLs, and service names that must exist before the lab starts
- Note which module each requirement comes from (
source_module)
From module outlines (FALLBACK — use if content files don't exist yet):
- Read each module's Detailed Steps section from
publishing-house/spec/modules/
- Apply the same learner-vs-pre-configured analysis above
- Note: outlines are less precise than drafted content; flag requirements as "to verify when content is drafted"
From the design spec (publishing-house/spec/design.md):
- Infrastructure type and requirements →
infrastructure section
- Products and technologies → candidate
operators
- Multi-user configuration →
infrastructure.multi_user
Determine approach:
Check project.deployment_mode:
If self_published:
-
Approach is GitOps only. Inform the user:
"Self-published projects use the Field Source CI with a GitOps repo. Your automation approach is GitOps (Helm + ArgoCD)."
-
Ask ONE question to determine the deployment topology:
"Does each student need their own cluster (for admin-level work like installing operators), or will students share a cluster with per-user namespaces?
- Per-user cluster — each student gets their own OCP cluster. Use when the lab requires cluster-admin or would conflict across users (operator installs, cluster-level config). One user provisioned per deployment.
- Shared cluster — one cluster, N namespaces. Use when the lab is namespace-scoped and students don't interfere.
num_users parameter controls how many copies of tenant resources are deployed."
Record as infrastructure.topology: per-user-cluster | shared-cluster and infrastructure.multi_user: false | true.
-
Set approach: gitops in the automation manifest.
If rhdp_published:
- Ask the user: "How should the environment be automated?"
- Ansible — Ansible collections as AgnosticD workloads
- GitOps — Helm charts deployed by ArgoCD
- Both — Ansible for cluster-level setup, GitOps for application workloads
- If the lab teaches GitOps concepts → recommend
approach: gitops
- If the lab needs imperative setup or complex ordering → recommend
approach: ansible
- When in doubt, ask the user
Write the manifest to publishing-house/spec/automation-manifest.yaml.
Step 7a-3: Manifest Review (Gate)
Present the manifest to the user for review. This is always a gate, regardless
of autonomy level — automation scope must be explicitly approved.
"Here's the automation manifest — what needs to be pre-configured for the lab:
Approach: [ansible/gitops/both]
Infrastructure: [type], [multi_user], [users]
Operators: [count] — [names]
Applications: [count] — [names]
RBAC: [count entries]
Seed data: [count entries]
Broken resources: [count] (for troubleshooting exercises)
Provision data: [count keys]
Full manifest: publishing-house/spec/automation-manifest.yaml
Review and approve, or edit the manifest and tell me when ready."
Wait for explicit approval. The user may edit the manifest file directly — always
re-read it from disk after they say "approved" or "looks good."
Step 7a-4: Update Manifest
After requirements are approved:
automation:
status: in_progress
substeps:
requirements: completed
catalog_item: pending
automation_code: pending
Phase 7b: AgnosticV Catalog Creation
Check deployment mode first:
When deployment_mode: self_published:
- Automatically skip 7b: set
substeps.catalog_item: skipped
- Inform user: "No AgnosticV catalog item needed for self-published projects."
- Proceed to 7c.
When deployment_mode: rhdp_published:
- 7b is required. Ask:
"An AgnosticV catalog item is required for RHDP-published projects. Do you have AgnosticV access to create it, or does someone else need to handle this?"
- If user has access → proceed with agnosticv:catalog-builder as documented below
- If user doesn't have access → set
substeps.catalog_item: pending_handoff. Write a worklog entry with the information needed for handoff (infrastructure type, operators, multi-user config from the approved automation manifest). Proceed to 7c.
Step 7b-1: Gather Context from PH Spec and Automation Manifest
Read publishing-house/spec/design.md and the approved publishing-house/spec/automation-manifest.yaml and extract:
- Project name → catalog display name
- Project ID → catalog short name
- Content type (lab/demo) → catalog type
- Products & technologies → technology tags
- Infrastructure type and requirements → infrastructure type routing
- Operators from automation manifest → pre-install in common.yaml
- Multi-user configuration from automation manifest → multi-user setup
- Owner → maintainer
Step 7b-2: Invoke agnosticv:catalog-builder
Inform the user:
"Using agnosticv:catalog-builder to create the AgnosticV catalog for this project."
Invoke agnosticv:catalog-builder in Mode 1 (Full Catalog Creation).
Pre-fill ALL known context from the PH spec and automation manifest. The
catalog-builder should only need to ask about things PH doesn't already know.
Pass the following when invoking:
- Project repo URL: The git remote URL of the current project. The automation
code lives in
automation/ within this repo — tell the catalog-builder this so
it does NOT ask for a separate GitOps repo URL.
- Automation approach: From the approved automation manifest. When
approach: gitops,
tell the catalog-builder that Ansible-related questions (custom collections, workload
roles) are not applicable — skip them. The GitOps charts are in automation/.
- Catalog type: Map from
project.type — lab → lab_multi or lab_single,
demo → demo. Ask user to confirm.
- Event context: Ask the user — this is not in the PH spec.
- Technologies: From design.md products & technologies list.
- Infrastructure type: Infer from design.md infrastructure requirements.
Ask user to confirm before proceeding.
- Display name:
project.name from manifest.
- Short name:
project.id from manifest.
- Maintainer:
project.owner_github and project.owner_email from manifest.
- Operators: Pre-fill from automation manifest
operators list.
- E2E testing: Do NOT ask — PH handles E2E testing in a separate lifecycle phase.
For questions the catalog-builder asks that aren't covered by the PH spec, let
the user answer directly. Do not guess infrastructure-specific configuration.
Step 7b-3: Validate the Catalog
After the catalog-builder generates files, immediately invoke validation:
Inform the user:
"Running agnosticv:validator to check the catalog configuration."
Invoke agnosticv:validator at scope level 2 (Standard).
If validation passes:
- Update manifest:
substeps.catalog_item: completed
- Record the catalog path and AgV repo path in the manifest
- Proceed to autonomy-appropriate next step
If validation fails:
- Supervised: Present errors. Ask: "Would you like to fix these issues now?"
Walk through fixes one at a time. Re-validate after fixes.
- Semi: Attempt to fix errors automatically. Present warnings for user decision.
Re-validate.
- Full: Fix all fixable issues. Re-validate. Present any remaining blockers.
Do not proceed to 7c until the catalog validates at least at Level 2 with no errors.
Step 7b-4: Update Manifest
automation:
substeps:
requirements: completed
catalog_item: completed
automation_code: pending
catalog_path: "<agv-relative-path>"
agv_repo: "<local-agv-repo-path>"
Autonomy Behavior (7b)
- Supervised: Present the catalog-builder's output for review. Present validation
results. Ask before committing to the AgV repo.
- Semi: Let catalog-builder and validator run. Present summary of what was created
and validation status. Pause only if validation errors need user input.
- Full: Run catalog-builder and validator end-to-end. Present completed catalog
summary with validation status.
Phase 7c: Automation Code
Write the automation code from the approved automation manifest. If the catalog item
(7b) was skipped (self-published projects skip this step), proceed directly from
approved requirements (7a) to code.
Step 7c-1: Write Automation Code
Read the approved manifest from publishing-house/spec/automation-manifest.yaml.
Write code based on approach:
For approach: ansible:
See @rhdp-publishing-house/skills/automation/references/ansible-automation-guide.md.
- Create an Ansible collection:
automation/ with galaxy.yml and roles
- Create one role per logical component (or one role for simple labs)
- Role structure:
tasks/main.yml, tasks/workload.yml, tasks/remove_workload.yml,
defaults/main.yml, meta/main.yml, templates/*.yaml.j2
- Map manifest entries to Ansible tasks:
operators → Subscription + OperatorGroup resourcesapplications → Deployment + Service + Route templatesrbac → Namespace + RoleBinding tasksseed_data → ConfigMap/Secret tasks or git clone tasksbroken_resources → Resources with intentional misconfigurationsprovision_data → agnosticd.core.agnosticd_user_info task
For approach: gitops:
See @rhdp-publishing-house/skills/automation/references/gitops-automation-guide.md.
Generate code in automation/ following the ci-template-gitops patterns. Do not clone the template — generate tailored code:
cluster/infra/ — operator deployments (cluster-level, deployed once)tenant/bootstrap/ — per-user workloads (deployed per user or per namespace)tenant/labs/<project-id>/ — the lab's Helm chart
Map manifest entries to the appropriate layer:
operators → cluster/infra/ Helm chart templatesapplications → tenant/labs/<project-id>/ Helm chart (Pattern 2 or 3)rbac → Inline in tenant/bootstrap/templates/ (Pattern 1) or in lab chartseed_data → ConfigMap/Secret templates in lab chartbroken_resources → Templates with intentional misconfigurations in lab chartprovision_data → ConfigMap with demo.redhat.com/tenant-<name>: "true" label in lab chart. Showroom is always included — provision_data must surface the Showroom URL and all per-user URLs so the lab guide can display them as {attribute} variables.
For approach: both:
- Ansible for cluster-level setup (operators, auth, infra)
- GitOps for application workloads (tenant-level, continuously reconciled)
- Clearly document the boundary in the automation README
Autonomy Behavior (7c Code Writing)
- Supervised: Present each role/chart before writing. Walk through the code.
Ask for approval before writing files.
- Semi: Write the code, present a summary of what was created. Pause for
review before the code review cycle.
- Full: Write all automation code. Run the code review cycle automatically.
Present final results.
Step 7c-2: Safety Check and Blocker Worklog
After writing automation code, run a quick safety check and write all blockers to the worklog.
"Don't hurt yourself" checklist:
Re-validate catalog (if catalog item exists):
Re-run agnosticv:validator to verify workload references are consistent with the catalog configuration.
Write worklog entries for every pre-testing blocker found:
For each issue found in the checklist, write a worklog entry of type action. Examples:
- Unpinned image tag →
"Pin image tag for <image> before testing. Currently using 'latest'. Find the digest or a stable release tag."
- Image doesn't exist yet →
"Build and push <image> to <registry> before testing. Image referenced in automation but not yet published."
- Content changes needed before editing →
"Update module-03 content: replace Postman with Hoppscotch (callback URL, UI steps). Required before editing phase."
- Pending handoff →
"AgnosticV catalog item pending handoff to <person>. Provide: [infrastructure type, operators, multi-user config]."
Invoke rhdp-publishing-house:worklog to write each entry. These become visible in "what's outstanding" and persist across sessions.
Note: This is a safety check, not a full code review. The formal code review happens in the Code & Security Review phase. For rhdp_published projects, code review is required. For self_published projects, it is recommended but optional.
Step 7c-3: Update Manifest
After automation code is complete and review cycle passes:
automation:
substeps:
requirements: completed
catalog_item: completed
automation_code: completed
testing: pending
automation_files:
- automation/roles/ocp4_workload_<project-id>/
- automation/helm/<chart-name>/
Phase 7d: Testing (Gate)
The automation code must be deployed and tested on a real environment before the
automation phase can be marked complete. This is a human gate — the agent does not
deploy or test automation itself.
Step 7d-1: Present Testing Gate
After automation code is written (7c complete), inform the user:
"Automation code is written and has open worklog items to verify before it can be
considered tested. Deploy to a dev environment and work through the open items.
When you're done, describe what you tested:
- What environment did you use? (cluster name, type)
- Which worklog items did you resolve?
- Did all components deploy and function correctly? Any issues still open?
Or let me know if something is blocking you from testing."
Do not use magic-word prompts like "say 'testing done'". Wait for the user to describe results naturally.
Step 7d-2: Record Testing Result
When the user describes their testing:
-
If they provide a description of what was tested: Extract or ask for:
- Environment used (cluster name/URL or type, e.g., SNO, RHDP sandbox)
- Which worklog items were resolved
- What functionality was confirmed end-to-end
- Any issues still open
Set substeps.testing: completed and record the evidence in the manifest:
testing: completed
testing_notes: "<description of what was tested, environment, items resolved>"
Mark resolved worklog items as resolved.
-
If they say testing is done with no details: Ask for specifics before marking complete — "What environment did you test on, and which of the open worklog items were resolved?"
-
If they want to skip: Confirm — "Skipping testing means the automation code has not been verified on a real environment. Any issues will surface the first time someone orders this. Are you sure?" If confirmed, set substeps.testing: skipped.
Step 7d-3: Update Manifest
automation:
status: in_progress
substeps:
requirements: completed
catalog_item: completed
automation_code: completed
testing: completed
Do not change lifecycle.phases.automation.status or lifecycle.current_phase.
Phase-level transitions are managed by the orchestrator.
Step 9: Report Back
After completing each sub-phase, inform the user:
After 7a (Automation Requirements):
"Automation requirements documented and approved.
Manifest: publishing-house/spec/automation-manifest.yaml
Next: Create the AgnosticV catalog item (7b). Self-published projects skip this step
automatically."
After 7b (Catalog Item):
"AgnosticV catalog item created and validated.
Catalog path: <agv-relative-path>
Validation: [PASSED / PASSED WITH WARNINGS]
Next: Write automation code (7c)."
After 7c (Automation Code):
"Automation code complete.
Files: [list of roles/charts created]
Code review: [PASSED / findings addressed]
Catalog re-validation: [PASSED]
Next: Deploy and test the automation (7d). The code has not been tested yet."
After 7d (Testing):
"Automation testing [completed / skipped].
[If completed: testing notes]
Automation phase complete. Next: security review."
Skipping Sub-Phases
Users can skip individual sub-phases:
- "skip requirements" — Set
substeps.requirements: skipped. User provides
automation code directly without a manifest. Not recommended — requirements drive
both catalog and code decisions.
- "skip catalog item" — Set
substeps.catalog_item: skipped. Project is
self-published (no catalog item needed), or user manages AgV config outside
Publishing House. Automation code is built from the approved requirements manifest.
- "skip automation code" — Set
substeps.automation_code: skipped. Automation
handled externally.
- "skip testing" — Set
substeps.testing: skipped. Not recommended — automation
code has not been verified on a real environment.
- "skip all automation" — Set entire automation phase to
skipped.
Always confirm skip decisions: "Are you sure? This means [consequence]."
What You Do NOT Do
- Do not write Showroom content — that is the writer agent's job
- Do not review content quality — that is the editor agent's job
- Do not deploy or test the automation yourself — that is the user's responsibility;
this agent tracks whether testing has been done
- Do not manage the AgnosticV git repository beyond writing files — the user owns git workflow
- Do not advance the lifecycle phase — only update substep status
- Do not guess infrastructure configuration — let the catalog-builder skill ask its
detailed questions, or ask the user directly
