config / workflows
CLAUDE.md1 starsChanged 8 days agoApache-2.0View on GitHub
Behavioral rules for .github/workflows/** and .github/actions/**. This repository is a distribution source — consumers pin workflows and composites by commit SHA. Design background: GitHub Workflows Design. Contracts: Specification.
- Reads credentials
- Commits and pushes
In this repository56 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .apm/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/agent-skills.mdcCursor rule
- .cursor/rules/bats.mdcCursor rule
- .cursor/rules/github-actions-workflow.mdcCursor rule
- .cursor/rules/go.mdcCursor rule
- .cursor/rules/go-test.mdcCursor rule
- .cursor/rules/instructions.mdcCursor rule
- .cursor/rules/markdown.mdcCursor rule
- .cursor/rules/shell-script.mdcCursor rule
- .cursor/rules/terraform.mdcCursor rule
- agent-skills-reviewSkill
- changelogSkill
- ci-sweeperSkill
- docs-creatorSkill
- docs-updaterSkill
- github-actions-reviewSkill
- github-actions-validationSkill
- github-issue-autofixSkill
- github-issue-triageSkill
- github-pr-bodySkill
- github-pr-reviewSkill
- github-pr-reviseSkill
- go-reviewSkill
- go-validationSkill
- instructions-reviewSkill
- loop-verifierSkill
- markdown-validationSkill
- refactorSkill
- shell-script-reviewSkill
- shell-script-validationSkill
- tech-debtSkill
- test-gapSkill
- agent-skills-reviewSkill
- changelogSkill
- ci-sweeperSkill
- docs-creatorSkill
- docs-updaterSkill
- github-actions-reviewSkill
- github-actions-validationSkill
- github-issue-autofixSkill
- github-issue-triageSkill
- github-pr-bodySkill
- github-pr-reviewSkill
- github-pr-reviseSkill
- go-reviewSkill
- go-validationSkill
- instructions-reviewSkill
- loop-verifierSkill
- markdown-validationSkill
- refactorSkill
- shell-script-reviewSkill
- shell-script-validationSkill
- tech-debtSkill
- test-gapSkill
The file
We split this CLAUDE.md into the rules it gives an agent
8 rules. About 0 are common, 3 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 49
MUST NOT: use ${GITHUB_WORKSPACE}/.github/actions/...
- Very specific: line 64
MUST NOT: use secrets: inherit.
- Very specific: line 66
When a reusable job sets environment:, environment-scoped secrets override caller-passed secrets with the same name — callers relying on …
- Distinctive: line 83
When reviewing or authoring a reusable workflow, ask: _“Would this default or branch surprise a consumer with a different repo layout?”_ If …
- Distinctive: line 91
When a loop step records failure metadata for run logs or action outputs:
- Very specific: line 96
MUST NOT: write raw git push, gh, or CLI stderr to committed logs without redaction.
- Very specific: line 145
Keep permissions least-privilege.
- Distinctive: line 146
Do not place real tokens in workflow examples or comments.
≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CLAUDE.md
Behavioral rules for .github/workflows/** and .github/actions/**. This repository is a distribution source — consumers pin workflows and composites by commit SHA.
Design background: GitHub Workflows Design. Contracts: Specification.
Pins
| Rule | Requirement |
| Config components | MUST use a full commit SHA (uses: org/repo/.github/...@<sha> # vX.Y.Z). Tags and branches are forbidden. |
| Third-party actions | MUST pin by full SHA; annotate upstream version in a comment when known. |
Consumer copies (example/, external repos) | MUST use remote SHA pins only. |
Reusable workflows (ci-*, cd-*) | MUST NOT use uses: ./.github/actions/... or uses: ./.github/workflows/.... Consumers fetch reusables remotely; local paths are not portable. |
Dogfood (on-* workflow steps) | MAY use ./.github/workflows/... or ./.github/actions/... while iterating unreleased graph changes — not in ci-* / cd-*. |
| Composite internals | MUST NOT use uses: ./.github/actions/... — unresolvable in consumer repositories. |
| Release | MUST bump SHA pins in ci-*, cd-*, and example/ in the same change set as new action/workflow releases (or per release checklist). |
Composition
| Rule | Requirement |
| Composite → composite | MUST NOT call another config composite via uses: (local or remote). One action pin must stay self-contained. |
| Workflow → composite | MUST call leaf composites via uses: only. |
Workflow → lib/run.sh | MUST NOT invoke action lib/run.sh from workflow YAML — bypasses the pin boundary. |
| Cross-action shared logic | MUST live under .github/actions/lib/<domain>/ (for example lib/loop/). |
| Action-specific orchestration | MUST stay in that composite's own lib/. |
| Sibling action scripts | MAY call ${GITHUB_ACTION_PATH}/../<sibling-action>/lib/... only for that sibling's owned behavior (for example CLI install). MUST NOT treat another composite's lib/ as a shared contract library. |
| Portability | MUST NOT hardcode consumer paths (scripts/, .agents/, skill trees, APM install targets) inside reusables or composites. |
Invoke shared or sibling scripts with run: + bash/source. Contexts are not expanded in uses:.
Path resolution
${GITHUB_ACTION_PATH} (same as ${{ github.action_path }} in composite run: steps) points to the pinned action directory in the runner's _actions/ cache — not the caller's GITHUB_WORKSPACE.
| Caller | Resolve shared lib as |
Composite action.yml run: step | ${GITHUB_ACTION_PATH}/../lib/<domain>/... |
Script under <action>/lib/*.sh | $(cd "$(dirname "${BASH_SOURCE[0]}")/../../lib/<domain>" && pwd)/... |
| Prefer | source .github/actions/lib/loop/_resolve.sh and use LOOP_ACTION_LIB_DIR when multiple paths are needed |
MUST NOT use ${GITHUB_WORKSPACE}/.github/actions/... in paths meant to work when the action is consumed remotely.
Reusable workflows and secrets
| Surface | Non-secrets | Credentials |
Reusable (workflow_call) | with: → inputs.* | secrets: only — declare under on.workflow_call.secrets |
| Composite action | with: → inputs.* | with: string inputs (no secrets: pass-through) |
Reusable workflow rules:
- MUST declare stable callee secret names (
AGENT_TOKEN,BOT_APP_*,GITHUB_TOKEN, …). - MUST require callers to pass an explicit
secrets:map (enables name remapping). - MUST NOT use
secrets: inherit. - MUST NOT pass tokens via
with:on reusable workflows. - When a reusable job sets
environment:, environment-scoped secrets override caller-passed secrets with the same name — callers relying on remapped repo secrets should leaveenvironmentempty unless the environment defines those names.
Loop callers pass configuration via with: on the reusable; avoid caller-level env: blocks for loop caller workflows.
Input defaults and discovery (reusable portability)
Reusable workflows (ci-*, cd-*) are distribution artifacts. Their inputs.*.default values and embedded step logic MUST stay portable — do not bake in this repository's layout, agent install trees, or gitignore habits.
| Rule | Requirement |
| Path/glob/exclude inputs | MUST default to empty ("") or equivalent “no filter”. Callers (on-*, example/) pass repo-specific values via with:. |
| Consumer layout | MUST NOT hardcode or default agent roots (.agents/, .claude/, .codex/, .cursor/, .kiro/), APM paths (.apm/, apm_modules/), scripts/, skill trees, or other consumer-only directories in reusables. |
| Gitignore assumptions | MUST NOT default excludes for paths that are normally absent from checkout (node_modules, vendor, .terraform, …). If a caller checks them out, it configures exclusions explicitly. |
| Discovery/prune logic | MUST NOT embed consumer-specific find/prune branches in reusable steps. Expose filters as inputs; keep step scripts generic. |
| Examples | MAY cite repo-specific examples in description: text only. MUST NOT encode those examples in default:. |
| Allowed defaults | Tool version pins, checksums, severity/level enums, and other tool-contract defaults that do not assume consumer directory layout. |
When reviewing or authoring a reusable workflow, ask: “Would this default or branch surprise a consumer with a different repo layout?” If yes, move it to the caller.
File prefixes: ci-* / cd-* (reusable), on-* (event caller), example/ (consumer template). Map key ordering: ORD-01 in companion github-actions-workflow rules.
Failure diagnostics
When a loop step records failure metadata for run logs or action outputs:
- MUST redact sensitive text before persistence (shared
lib/loop/redact.sh— do not duplicate patterns). - MUST record via shared
lib/loop/failure_record.sh(loop_failure_record). - MUST export to
GITHUB_OUTPUTvia sharedlib/loop/export_failure_diag.sh— do not add per-action export duplicates. - MUST NOT write raw
git push,gh, or CLI stderr to committed logs without redaction.
Anti-patterns
| Anti-pattern | Why |
uses: ...@main or @v1.x for config components | Unreproducible; policy violation |
uses: ./.github/actions/... inside a composite step | Broken in consumer repos |
uses: ./.github/actions/... in ci-* / cd-* workflows | Distribution break — use remote SHA; bump pin on release |
Nested uses: between config composites | Transitive pin drift |
${GITHUB_WORKSPACE}/.github/actions/.../lib/run.sh in workflows | Consumers lack that path |
${GITHUB_ACTION_PATH}/../../lib/... from action run: steps | Wrong depth — use ../lib/... from action root |
Shared logic in a composite's lib/ instead of actions/lib/ | Couples actions; blocks reuse |
| Consumer-specific paths in reusables/actions | Breaks portability |
Consumer-tuned inputs.*.default paths/globs/excludes in ci-* | Couples distribution to one repo layout |
Hardcoded discovery/prune lists in reusable run: steps | Callers cannot override without forking |
secrets: inherit on reusable callers | Blocks secret name remapping |
Credentials via with: on reusable workflows | Wrong channel |
Action → action via env.* from prior action GITHUB_ENV | Hidden contract — use steps.<id>.outputs.* |
Force-push over to.branch on pr_push | Drops commits from earlier serialized runs (#684) |
cancel-in-progress: true on pr-revise concurrency | Kills in-flight work; use queue + merge landing |
pr_push and PR-revise concurrency
Design background: PR Revise Workflow Design.
| Rule | Requirement |
| Same-PR serialize | on-loop-github-pr-revise.yaml MUST keep concurrency.group keyed by PR number with cancel-in-progress: false and queue: max |
| No last-run-only | MUST NOT cancel in-flight revise runs or force-push agent tips over to.branch to keep only the newest run |
pr_push merge | loop-finalize MUST land via merge of the agent branch into the latest to.branch (lib/push_target.sh); conflicts and non-fast-forward pushes MUST fail closed |
| Full clone | Jobs that finalize with pr_push MUST checkout with fetch-depth: 0 so merge can reach the latest origin/to.branch (shallow finalize checkout was a #677 loss vector) |
| Pin release | Changing loop-finalize pr_push behavior MUST ship with a SHA pin bump in ci-loop-agent.yaml (or temporary dogfood ./.github/actions/... per Pins); merged action code alone does not change dogfood execution |
| Landing contract | push_target.sh checks out origin/to.branch, merges origin/agent with --no-ff, pushes without force — same merge shape as legacy inline finalize, with explicit auth, agent≠to guard, extracted tests, and fail-closed errors |
pr_create untouched | Changes to pr_push landing MUST NOT alter the pr_create create-PR path |
Verification
Paired Bats under test/bats/github-actions/ when behavior changes (TEST-00). pr_push landing changes MUST include test/bats/.github/actions/loop-finalize/lib/push_target.bats.
Security
- Reference secrets only via
${{ secrets.NAME }}or${{ github.token }}; never echo tokens. - Keep
permissionsleast-privilege; documentzizmor: ignore[...]only with justification. - Do not place real tokens in workflow examples or comments.
- Mask or redact sensitive values in failure messages and logs before persistence.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

