workflow-validation

Stars9

Forks0

UpdatedApril 27, 2026 at 15:22

Use when validating repository workflows after changes to Docker-first Makefile targets, Dockerfiles, scripts, CI, release packaging, smoke tests, or documentation alignment. Do not use for repo redesign, GitHub-policy-only changes, or instruction-only skill edits with no workflow impact.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

CaseyLabs

CaseyLabs/kc-secure-repo-template

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	workflow-validation
description	Use when validating repository workflows after changes to Docker-first Makefile targets, Dockerfiles, scripts, CI, release packaging, smoke tests, or documentation alignment. Do not use for repo redesign, GitHub-policy-only changes, or instruction-only skill edits with no workflow impact.

Workflow validation

Use this skill when validating repository workflow changes.

Use this skill when

changing Makefile, Dockerfile, scripts/, tests, packaging manifests, or workflows
changing the default developer interface
modifying CI or release behavior
reviewing whether a workflow change is complete
checking whether implementation and documentation still match

Do not use this skill when

the task is primarily about adapting the repository to a new project shape
the task is only about GitHub-side settings guidance
the task is only about release-integrity design without running validation
the task is a small documentation-only edit with no workflow impact

Goals

Confirm that repository workflows still work end to end.
Catch regressions in build, test, example, CI, release, packaging, and reproducibility behavior.
Ensure documentation matches actual repository behavior.

Method

Prefer Docker-driven validation through the repository's public Makefile targets.
Run the smallest relevant set of checks first, then expand if risk is higher.
Verify that the documented public interface still matches the real workflow.
Check that local and GitHub Actions paths still align where expected.
Check that packaging manifests and shipped files remain aligned.
Use make scan for security and workflow checks when scanners, pinned actions, packaged guidance, or workflow validation are affected.
Use make dist for release artifact, SBOM, checksum, or integrity-output changes.
When a real bug lacks regression coverage, add or update a targeted test.

Minimum expectations

Validate the relevant subset of:

make build
make test
make scan
make dist
make example
documented CI helper scripts
documented release helper scripts
smoke or regression tests
documentation affected by the change

Output expectations

List the checks run.
List failures, risks, or skipped checks.
State whether the change meets the repository's definition of done.
Call out mismatches between docs and implementation.

More from this repository

same repository

pr-draft-summary

CaseyLabs/kc-secure-repo-template

Draft a concise pull request handoff after substantive repository changes are finished or ready for review. Trigger when wrapping up code, test, script, workflow, release, security, documentation-with-behavior-impact, or template customization changes and the user needs a PR title/body grounded in the real diff, commits, and validations run. Do not use for tiny chat-only answers, speculative plans, or changes that are not ready for PR handoff.

2026-04-289

github-hardening

CaseyLabs/kc-secure-repo-template

Use when updating or reviewing GitHub-side hardening guidance for derived repositories, including required settings, rulesets, scanning, review protections, and workflow permissions. Use terraform-hardening instead for Terraform-backed changes under config/infra. Do not use for ordinary in-repo implementation changes unless the task is primarily about documented GitHub controls.

2026-04-279

language-profile-guidance

CaseyLabs/kc-secure-repo-template

Use when adding or revising optional language-specific guidance for Go, Node.js, SQL, or small polyglot derived repositories without bloating the generic template. Keep language behavior optional. Do not use for generic template policy, routine validation, GitHub-settings-only work, or release-integrity-only work.

2026-04-279

release-integrity

CaseyLabs/kc-secure-repo-template

Use when reviewing or improving this template's release-integrity story, including artifact verification, SBOMs, attestations, vulnerability scanning, signing guidance, and release-workflow safety. Do not use for general CI validation, GitHub-settings-only work, or unrelated template customization.

2026-04-279

repo-adaptation

CaseyLabs/kc-secure-repo-template

Use when adapting or customizing this repository to meet the needs of the source code under `src/`, including language and framework needs, dependencies, runtime behavior, Docker, Makefile targets, and customization surfaces. Do not use for routine bug fixes, small refactors, pure workflow validation, GitHub-settings-only work, or release-integrity-only work.

2026-04-279

terraform-hardening

CaseyLabs/kc-secure-repo-template

Use when changing or reviewing the Terraform-backed GitHub repository hardening workspace under config/infra, including provider pins, rulesets, default branch protection, required checks, secret scanning, Dependabot security updates, token handling, plan/apply behavior, and infra documentation. Do not use for ordinary app code, generic release integrity, generic template adaptation, or non-infra GitHub Actions changes unless they directly affect hardening expectations.

2026-04-279

name	workflow-validation
description	Use when validating repository workflows after changes to Docker-first Makefile targets, Dockerfiles, scripts, CI, release packaging, smoke tests, or documentation alignment. Do not use for repo redesign, GitHub-policy-only changes, or instruction-only skill edits with no workflow impact.

Workflow validation

Use this skill when validating repository workflow changes.

Use this skill when

changing Makefile, Dockerfile, scripts/, tests, packaging manifests, or workflows
changing the default developer interface
modifying CI or release behavior
reviewing whether a workflow change is complete
checking whether implementation and documentation still match

Do not use this skill when

the task is primarily about adapting the repository to a new project shape
the task is only about GitHub-side settings guidance
the task is only about release-integrity design without running validation
the task is a small documentation-only edit with no workflow impact

Goals

Confirm that repository workflows still work end to end.
Catch regressions in build, test, example, CI, release, packaging, and reproducibility behavior.
Ensure documentation matches actual repository behavior.

Method

Prefer Docker-driven validation through the repository's public Makefile targets.
Run the smallest relevant set of checks first, then expand if risk is higher.
Verify that the documented public interface still matches the real workflow.
Check that local and GitHub Actions paths still align where expected.
Check that packaging manifests and shipped files remain aligned.
Use make scan for security and workflow checks when scanners, pinned actions, packaged guidance, or workflow validation are affected.
Use make dist for release artifact, SBOM, checksum, or integrity-output changes.
When a real bug lacks regression coverage, add or update a targeted test.

Minimum expectations

Validate the relevant subset of:

make build
make test
make scan
make dist
make example
documented CI helper scripts
documented release helper scripts
smoke or regression tests
documentation affected by the change

Output expectations

List the checks run.
List failures, risks, or skipped checks.
State whether the change meets the repository's definition of done.
Call out mismatches between docs and implementation.