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.
In this repository51 other files it gives its agents.
- .cursor/rules/skill-authoring.mdcCursor rule
- backend-type-bridgerSkill
- composable-patternsSkill
- dart-type-bridgerSkill
- design-handoff-flutterSkill
- design-system-generalizerSkill
- engineering-excellenceSkill
- flutter-engineeringSkill
- flutter-patternsSkill
- heyeddi-designSkill
- heyeddi-handoffSkill
- heyeddi-intakeSkill
- heyeddi-orchestratorSkill
- heyeddi-productSkill
- heyeddi-pr-respondSkill
- heyeddi-pr-reviewSkill
- no-duplicate-uiSkill
- pre-merge-gateSkill
- primevue-openprops-architectSkill
- project-engineeringSkill
- ux-flow-auditorSkill
- verify-buildSkill
- visual-auditorSkill
- backend-type-bridgerSkill
- composable-patternsSkill
- dart-type-bridgerSkill
- design-handoff-flutterSkill
- design-system-generalizerSkill
- engineering-excellenceSkill
- flutter-engineeringSkill
- flutter-patternsSkill
- heyeddi-ci-failsSkill
- heyeddi-ci-guideSkill
- heyeddi-ci-runnersSkill
- heyeddi-designSkill
- heyeddi-handoffSkill
- heyeddi-intakeSkill
- heyeddi-orchestratorSkill
- heyeddi-productSkill
- heyeddi-pr-respondSkill
- heyeddi-pr-reviewSkill
- heyeddi-setupSkill
- heyeddiSkill
- no-duplicate-uiSkill
- pre-merge-gateSkill
- primevue-openprops-architectSkill
- project-engineeringSkill
- taste-penpotSkill
- ux-flow-auditorSkill
- verify-buildSkill
- visual-auditorSkill
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
- Very specific: line 18
Never merge a PR without authorize merge in the current turn.
- Very specific: line 20
Always load_policy_contract before authoring
- Very specific: line 22
Prefer GHA + workspace runner mode over sealed pipeline: when .github/workflows/ already owns CI.
- Very specific: line 28
Run load_policy_contract (or python …/scripts/load_policy_contract.py).
- Very specific: line 29
Treat the returned guide, knobs, rules, and minimal_example as authoritative.
- Very specific: line 30
Prefer human docs for narrative: docs_url (default https://ci.heyeddi.com/docs#policy).
- Very specific: line 31
Read context/ANTI_PATTERNS.md for durable safety rules that never go stale.
- Distinctive: line 79
Do not invent a config pass just because the file is absent.
- Very specific: line 83
Run inspect_repo and apply the decision gate (including heyeddi_product).
- Very specific: line 84
If adding because HeyEddi product was detected: default to Reviewer-only safe YAML.
- Very specific: line 85
If adding/updating for other reasons: confirm intent — Reviewer-only policy vs GHA-on-Spot vs sealed pipeline vs both (Reviewer + sealed).
- Very specific: line 87
If .github/workflows/ exists and the user wants CI on Spot: keep pipeline: {}, ensure the HEYEDDI_RUNS_ON hook, and defer mode setup to …
- Very specific: line 90
Write eddi-ci.yaml at the repo root using only keys from the contract knobs.
- Very specific: line 91
Prefer empty pipeline: {} unless sealed runners are requested and path filters are known.
- Very specific: line 105
After loading the contract, write the contract’s minimal_example (or equivalent) with billable knobs off and pipeline: {}.
- Very specific: line 109
Only after inspect_repo shows real commands and path prefixes, add pipeline jobs with filter.paths.
≈ “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.
Files
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
pipelinejobs need explicit opt-in - Always
load_policy_contractbefore 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; keeppipeline: {}to avoid double runs
Knowledge rule (mandatory)
The skill package does not ship a full knob table. On every run:
- Run
load_policy_contract(orpython …/scripts/load_policy_contract.py). - Treat the returned
guide,knobs,rules, andminimal_exampleas authoritative. - Prefer human docs for narrative:
docs_url(default https://ci.heyeddi.com/docs#policy). - Read
context/ANTI_PATTERNS.mdfor 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_reporeportsheyeddi_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, highervalidation_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 theHEYEDDI_RUNS_ONhook + 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-*installedskills-lock.jsonpinsHeyEddi-com/heyeddi-skills(legacyHeyEddi-com/skillsstill 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.yamlworks (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
- Run
inspect_repoand apply the decision gate (includingheyeddi_product). If not adding, explain and stop. - If adding because HeyEddi product was detected: default to Reviewer-only safe YAML; ask before enabling sealed
pipelineoron_ci_failure. - If adding/updating for other reasons: confirm intent — Reviewer-only policy vs GHA-on-Spot vs sealed
pipelinevs both (Reviewer + sealed). - Load the live contract via
load_policy_contract. - If
.github/workflows/exists and the user wants CI on Spot: keeppipeline: {}, ensure theHEYEDDI_RUNS_ONhook, and defer mode setup to@heyeddi-ci-runners/ workspace Settings. - Finish repo inspect for languages / real test commands when sealed
pipelineis in scope. Do not inventpytest/npm testwithout evidence. - Confirm billable knobs against the contract: keep
ai_review.on_ci_failurefalse unless the user explicitly opts in; addpipelinejobs only when sealed runners are wanted, commands are known, and you are not duplicating GHA. - Write
eddi-ci.yamlat the repo root using only keys from the contract knobs. - Prefer empty
pipeline: {}unless sealed runners are requested and path filters are known. - Tell the user to commit/push; HeyEddi App lints the file when it changes on a PR. Execution claims need Check evidence later.
Tools
| Tool | Purpose |
load_policy_contract | Fetch living knobs/guide/rules/example |
inspect_repo | HeyEddi 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.mdfor shapes; always re-check knobs fromload_policy_contract. - Depth on GHA overflow vs sealed pipeline:
@heyeddi-ci-runners.
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.

