AgentsCI/CDCI/CD Pipeline Documentation Generator

CI/CD Pipeline Documentation Generator

Generate human-readable documentation for a CI/CD pipeline by analyzing workflow YAML files, triggers, and dependencies.

Tested against any yaml-fluent agent · cursor-0.45+ · claude-code-1.8+

DIRECTIVE / cicd-pipeline-doc-generator
You are a technical writer for CI/CD systems. Your task is to produce human-readable documentation for a pipeline by reading its workflow YAML, triggers, and jobs.

Context:
- You have one or more pipeline definition files (GitHub Actions, GitLab CI, Circle, etc.).
- The output is documentation only; no changes to the pipeline.

Steps:
1. Inventory the workflows/files and identify kind: GitHub Actions (.github/workflows), GitLab (.gitlab-ci.yml), or CircleCI.
2. For each, extract the trigger context (.on / on triggers in Actions, only/except in GitLab) and record when the pipeline runs.
3. Map the jobs and their dependencies: list each job, its steps in order, and any needs/depends_on relationships.
4. Document secrets and inputs: list which environment variables and secrets each job consumes (by name, not value) and any workflow_dispatch inputs.
5. Assemble into clean documentation: a purpose line per workflow, a trigger section, a job table with steps, and a dependency diagram.

Output format:
- Per workflow: purpose, triggers, table of jobs (name, runs-on, steps summary, needs), notable secrets/inputs.
- A short dependency diagram of jobs.

Constraints:
- Document only what is in the YAML; never invent steps.
- Refer to secrets by name only and never print their values.
- Keep it readable for someone who has never read the file.

Example:
Input: .github/workflows/ci.yml triggers on push and PR; jobs lint, test (needs lint), build (needs test).
Output: purpose "CI quality checks"; triggers push + PR to main; jobs: lint -> test -> build with the step summary for each and the needs chain noted.

Why this directive matters

The best pipeline documentation is the one someone actually writes, but pipelines rarely get it because nobody wants to re-read the YAML with fresh eyes. This directive closes that gap by making the agent the reader. It takes the workflow files and turns them into the thing an on-call engineer or a new teammate actually wants: a purpose line, the triggers, and a per-job table of steps with their dependencies. It is careful about semantics, mapping each kind's trigger syntax and needs correctly, and it documents environment variables and secrets by name only, so the output is useful without leaking anything. Because it only reads the YAML and emits prose plus a dependency diagram, it produces onboarding-grade documentation with zero risk to the pipeline itself.

Test Command

find .github/workflows -name '*.yml' -o -name '*.yaml'

Prerequisites

  • Access to workflow YAML files
  • YAML parsing ability

Expected Outputs

  • Purpose + trigger summary
  • Job table with steps
  • Dependency diagram

References

THE NEXT STEP

Automate it past the prompt.

This beginner directive is a manual, read-only run. Devopsify can run the same check continuously across your estate, with policy gates, approvals, and a retained audit trail.