agentleFS
HeyEddi-comHeyEddi-com/heyeddi-skills/skills/heyeddi-ci-config/SKILL.md

heyeddi-ci-config

Skill0 starsChanged 3 months agoMITView on GitHub

Author or update eddi-ci.yaml for HeyEddi CI and Spot runners. Prefer GHA + HEYEDDI_RUNS_ON for existing workflows; sealed pipeline only when opted in. Loads the live policy contract from cihook.heyeddi.com so knobs stay current.

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. About 0 are common, 1 is distinctive, and 15 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 15

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Never merge a PR without authorize merge in the current turn.

    line 18
  2. Very specific:

    Always load_policy_contract before authoring

    line 20
  3. Very specific:

    Prefer GHA + workspace runner mode over sealed pipeline: when .github/workflows/ already owns CI.

    line 22
  4. Very specific:

    Run load_policy_contract (or python …/scripts/load_policy_contract.py).

    line 28
  5. Very specific:

    Treat the returned guide, knobs, rules, and minimal_example as authoritative.

    line 29
  6. Very specific:

    Prefer human docs for narrative: docs_url (default https://ci.heyeddi.com/docs#policy).

    line 30
  7. Very specific:

    Read context/ANTI_PATTERNS.md for durable safety rules that never go stale.

    line 31
  8. Distinctive:

    Do not invent a config pass just because the file is absent.

    line 79
  9. Very specific:

    Run inspect_repo and apply the decision gate (including heyeddi_product).

    line 83
  10. Very specific:

    If adding because HeyEddi product was detected: default to Reviewer-only safe YAML.

    line 84
  11. Very specific:

    If adding/updating for other reasons: confirm intent — Reviewer-only policy vs GHA-on-Spot vs sealed pipeline vs both (Reviewer + sealed).

    line 85
  12. Very specific:

    If .github/workflows/ exists and the user wants CI on Spot: keep pipeline: {}, ensure the HEYEDDI_RUNS_ON hook, and defer mode setup to …

    line 87
  13. Very specific:

    Write eddi-ci.yaml at the repo root using only keys from the contract knobs.

    line 90
  14. Very specific:

    Prefer empty pipeline: {} unless sealed runners are requested and path filters are known.

    line 91
  15. Very specific:

    After loading the contract, write the contract’s minimal_example (or equivalent) with billable knobs off and pipeline: {}.

    line 105
  16. Very specific:

    Only after inspect_repo shows real commands and path prefixes, add pipeline jobs with filter.paths.

    line 109

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

HeyEddi CI Config

Authors a correct eddi-ci.yaml for HeyEddi Reviewer / optional Spot runners. Do not invent knobs from memory.

Safety

  • Never merge a PR without authorize merge in the current turn; never write auto_merge
  • Billable knobs and sealed Spot pipeline jobs need explicit opt-in
  • Always load_policy_contract before authoring
  • Spot is shipped — jobs can run when the workspace is entitled; never claim a job did run without Check/Spot evidence (@heyeddi-ci-runners)
  • Prefer GHA + workspace runner mode over sealed pipeline: when .github/workflows/ already owns CI; keep pipeline: {} to avoid double runs

Knowledge rule (mandatory)

The skill package does not ship a full knob table. On every run:

  1. Run load_policy_contract (or python …/scripts/load_policy_contract.py).
  2. Treat the returned guide, knobs, rules, and minimal_example as authoritative.
  3. Prefer human docs for narrative: docs_url (default https://ci.heyeddi.com/docs#policy).
  4. Read context/ANTI_PATTERNS.md for durable safety rules that never go stale.

Contract feed (production): https://cihook.heyeddi.com/api/public/eddi-ci-policy

Fallback order inside the script: local heyeddi-ci checkout → HEYEDDI_CI_POLICY_URL / production API → docs page text.

Decision gate: add the file or not (mandatory)

Missing eddi-ci.yaml is not a defect. Safe defaults already apply (runners off, on_ci_failure off). Decide before writing anything:

Write / create eddi-ci.yaml only when at least one is true

  • User explicitly asks to create, add, or configure eddi-ci.yaml
  • inspect_repo reports heyeddi_product.uses_heyeddi_product: true — the repo already uses a HeyEddi product (see signals below). Then add a Reviewer-only safe file (billable knobs off, pipeline: {}) unless the user declines.
  • User wants Reviewer policy beyond defaults (e.g. allow_external_prs, higher validation_max_attempts, document team rules)
  • User wants sealed Spot pipeline: jobs (no/minimal GHA, or niche checks) and accepts real commands + path filters — see @heyeddi-ci-runners
  • User wants GHA on Spot — still write Reviewer-only YAML (pipeline: {}) and point them at the HEYEDDI_RUNS_ON hook + workspace Runners mode (@heyeddi-ci-runners)
  • User is following the HeyEddi PR CTA and confirms they want to configure now (CTA alone ≠ auto-write; ask once if intent is unclear)

HeyEddi product signals (from inspect_repo → heyeddi_product.evidence):

  • .heyeddi/ workspace present
  • .agents/skills/heyeddi-* installed
  • skills-lock.json pins HeyEddi-com/heyeddi-skills (legacy HeyEddi-com/skills still counts)
  • PRODUCT.md / .heyeddi/product.md / README.md / package identity mention HeyEddi

Do not create the file when

  • The only signal is “file is missing” and no HeyEddi product markers
  • User only wants a normal code review and never opted into config / not a HeyEddi project
  • User declines after you explain that defaults are already safe
  • You would have to invent test commands or path filters to fill pipeline (still OK to add Reviewer-only YAML without pipeline jobs)

If not adding

Explain briefly: HeyEddi already runs with safe defaults; they can invoke @heyeddi-ci-config later when they want policy or runners. Stop. Do not write the file.

If updating an existing file

Edit only when the user asked to change policy/runners, or when fixing invalid YAML they already committed. Do not “improve” an untouched valid config unprompted.

When to use this skill

  • Any of the “write / create” conditions above
  • User asks how eddi-ci.yaml works (load contract + explain; create only if they then opt in)

When not to use

Do not invent a config pass just because the file is absent.

Instructions

  1. Run inspect_repo and apply the decision gate (including heyeddi_product). If not adding, explain and stop.
  2. If adding because HeyEddi product was detected: default to Reviewer-only safe YAML; ask before enabling sealed pipeline or on_ci_failure.
  3. If adding/updating for other reasons: confirm intent — Reviewer-only policy vs GHA-on-Spot vs sealed pipeline vs both (Reviewer + sealed).
  4. Load the live contract via load_policy_contract.
  5. If .github/workflows/ exists and the user wants CI on Spot: keep pipeline: {}, ensure the HEYEDDI_RUNS_ON hook, and defer mode setup to @heyeddi-ci-runners / workspace Settings.
  6. Finish repo inspect for languages / real test commands when sealed pipeline is in scope. Do not invent pytest / npm test without evidence.
  7. Confirm billable knobs against the contract: keep ai_review.on_ci_failure false unless the user explicitly opts in; add pipeline jobs only when sealed runners are wanted, commands are known, and you are not duplicating GHA.
  8. Write eddi-ci.yaml at the repo root using only keys from the contract knobs.
  9. Prefer empty pipeline: {} unless sealed runners are requested and path filters are known.
  10. Tell the user to commit/push; HeyEddi App lints the file when it changes on a PR. Execution claims need Check evidence later.

Tools

ToolPurpose
load_policy_contractFetch living knobs/guide/rules/example
inspect_repoHeyEddi product detection + languages / likely test cmds

Examples

Reviewer-only (safe / GHA repos)

After loading the contract, write the contract’s minimal_example (or equivalent) with billable knobs off and pipeline: {}.

Sealed runners when requested (no-GHA)

Only after inspect_repo shows real commands and path prefixes, add pipeline jobs with filter.paths. Never enable on_ci_failure without explicit opt-in. Never mirror existing workflow jobs.

Notes

  • Unknown top-level keys fail schema (extra=forbid).
  • Invalid YAML → App ignores file and uses safe defaults.
  • See context/EXAMPLES.md for shapes; always re-check knobs from load_policy_contract.
  • Depth on GHA overflow vs sealed pipeline: @heyeddi-ci-runners.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.