heyeddi-com/heyeddi-skills

heyeddi-ci-config

Author or update eddi-ci.yaml for HeyEddi CI and Spot runners. Use when enabling HeyEddi CI, runners, or the user asks to create/configure eddi-ci.yaml. Loads the live policy contract from cihook.heyeddi.com so knobs stay current.

First seen Aug 1, 2026

Installation

$ npx skills add heyeddi-com/heyeddi-skills --skill heyeddi-ci-config

Also in this package

Other skills from heyeddi-com/heyeddi-skills · top by installs.

npx skills add heyeddi-com/heyeddi-skills

Browse all from heyeddi-com/heyeddi-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

License LICENSE
Default branch main
Open issues 0
Status Active

Skill metadata

Parsed from SKILL.md frontmatter.

Version1.1.0

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 5,667 B
  • docs SUMMARY.md 255 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 42 installs

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 Spot pipeline jobs need explicit opt-in
  • Always loadpolicycontract before authoring
  • Spot runners are fail-closed / placeholder — declare YAML only; never claim jobs ran (@heyeddi-ci-runners)

Knowledge rule (mandatory)

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

  1. Run loadpolicycontract (or python …/scripts/loadpolicycontract.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 → HEYEDDICIPOLICY_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, oncifailure 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
  • inspectrepo reports heyeddiproduct.usesheyeddiproduct: 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. allowexternalprs, higher validationmaxattempts, document team rules)
  • User wants Spot / isolated runners (pipeline: jobs) and accepts that those jobs need real commands + path filters
  • 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 inspectrepoheyeddiproduct.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 inspectrepo and apply the decision gate (including heyeddiproduct). If not adding, explain and stop.
  2. If adding because HeyEddi product was detected: default to Reviewer-only safe YAML; ask before enabling runners or oncifailure.
  3. If adding/updating for other reasons: confirm intent — Reviewer-only policy vs runners vs both.
  4. Load the live contract via loadpolicycontract.
  5. Finish repo inspect for languages / real test commands when runners are in scope. Do not invent pytest / npm test without evidence.
  6. Confirm billable knobs against the contract: keep aireview.onci_failure false unless the user explicitly opts in; add pipeline jobs only when runners are wanted and commands are known.
  7. Write eddi-ci.yaml at the repo root using only keys from the contract knobs.
  8. Prefer empty pipeline: {} unless runners are requested and path filters are known.
  9. Tell the user to commit/push; HeyEddi App lints the file when it changes on a PR.

Tools

Tool Purpose
loadpolicycontract Fetch living knobs/guide/rules/example
inspect_repo HeyEddi product detection + languages / likely test cmds

Examples

Reviewer-only (safe)

After loading the contract, write the contract’s minimal_example (or equivalent) with billable knobs off.

Runners when requested

Only after inspectrepo (or equivalent) shows real commands and path prefixes, add pipeline jobs with filter.paths. Never enable onci_failure without explicit opt-in.

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 loadpolicycontract.