# Generate Eou Candidates

> Generate a minimal, ranked candidate EOU set from a messy workflow using Foundry V2 constraints. Candidates are proposal-only and cannot be activated.

- Skill: `xiaolai/generate-eou-candidates-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add xiaolai/generate-eou-candidates-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/xiaolai/generate-eou-candidates-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: xiaolai (https://skillmd.com/u/xiaolai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/xiaolai/generate-eou-candidates-2

---


# Generate EOU Candidates

Generate candidate EOUs from `$workflow`.

## Inputs

- `$workflow` (required) — the workflow to analyze; may be a file path (YAML or Markdown) or a free-text description. If a file path, read it; if text, treat it as the workflow description.
- `workflow_slug` — derived from the workflow name or file stem, normalized to lowercase alphanumeric + hyphens (e.g., `code-review-workflow`). Used in the output filename.
- `captured_workflow` (optional, ECP-0017 / Rule 96) — when `foundry/captured-workflows/cw-{app_id}.yml` exists with all four `human_approval` gates populated, load it. Its `domain_values` block is consulted during candidate scoring per Step 6.5.

## Required reading

1. `foundry/constitution.yml`
2. `foundry/registry.yml`
3. `foundry/failure-taxonomy.yml`
4. `foundry/meta-eous/generate-eou-candidates.yml`
5. `schemas/eou.schema.yml`

## Stop conditions

Halt and report if any of the following hold:

- Workflow goal is unclear.
- Desired artifact or output is undefined.
- No failure modes are provided or inferable.
- Responsibility boundary is unclear.
- High-stakes workflow has no identified owner.

## Procedure

### Step 1 — Summarize the workflow

Extract: what actor does what action to produce what artifact, and what the known failure modes are. State any ambiguities as open questions.

### Step 2 — Identify decision boundaries

Locate where the success criterion changes — each boundary is a candidate EOU boundary, not each visible action. Separate deterministic steps (scriptable) from judgment steps (LLM or human required).

### Step 3 — Registry diff

For each candidate boundary, check `foundry/registry.yml` and `foundry/eous/` + `foundry/meta-eous/`:

- Does this candidate duplicate an existing EOU? → record and skip.
- Can it extend an existing EOU? → record the extension recommendation.
- Should it be a refactor instead of a new EOU? → record.
- Would a rule, schema field, validator, stop condition, regression case, or human checklist serve better? → record and prefer that over a new EOU.

### Step 4 — Minimality test (per candidate)

For each remaining candidate, answer:

1. Can this be a rule instead of an EOU?
2. Can this be a validator or schema field?
3. Can this be a regression case?
4. Can this be a human review checklist?

Keep the candidate only if none of the above applies. Record the minimality result.

### Step 5 — Classify and fill required fields

For each kept candidate:

| Field | Value |
|-------|-------|
| `function` | One of: `generate \| specify \| validate \| diagnose \| promote \| refactor \| audit \| propose \| activate \| implement \| retire` |
| `automation_mode` | `deterministic \| LLM_assisted \| hybrid \| human_executed` |
| `authority_level` | `suggest_only \| draft_only \| write_candidate \| write_inactive \| mutate_active \| approve \| publish` |
| `risk_level` | `low \| medium \| high \| critical` |
| `lifecycle_stage` | `candidate` (always — do not set active) |

Also fill: `purpose`, `non_goals`, `distinct_success_criterion`, `failure_modes`, `owner_required`, `activation_requirements`, `operational_value`, `arguments_against`, `minimality_result`.

### Step 6 — Operational value test (per candidate)

Reject any candidate whose only value is completeness, or that duplicates an existing EOU, or that has no distinct success criterion. Each kept candidate must answer at least one: prevents_failure, improves_decision, exposes_hidden_judgment, improves_traceability.

### Step 6.5 — Domain-value scoring (ECP-0017 / Rule 96)

**Skip if `captured_workflow` is not present or `human_approval` is incomplete.**

For each surviving candidate, score its `arguments_against` against the top-three priority `domain_values` from the captured_workflow:

1. Would executing this candidate clearly violate a priority-1 `domain_value`? → Reject the candidate; emit `arguments_against` citing the violated value id.
2. Does this candidate's `distinct_success_criterion` operationalize at least one top-three `domain_value`? → If not, revise the criterion to reference the value id explicitly OR demote the candidate.
3. Record the operationalized `domain_value.id` entries in the candidate's `distinct_success_criterion` text so Rule 96's validator can detect them.

### Step 7 — Rank and select minimal set

Budget: **max 7 candidates**. Rank by operational value descending. Select the minimal subset that covers the workflow's critical failure modes. Record rejected candidates with reasons.

## Output

Write to `foundry/self-evolution/candidate-sets/cs-generate-eou-candidates-{YYYYMMDD}-{hhmm}.yml` per `schemas/candidate-set.schema.yml` (ECP-0013):

```yaml
id: cs-generate-eou-candidates-{YYYYMMDD}-{hhmm}
generated_by: generate-eou-candidates
generated_at: {ISO-8601 UTC timestamp}
target_class: eou_spec
audit_status: pending_audit
source_workflow:
candidates:
  - id:
    status: candidate
    purpose:
    non_goals: []
    distinct_success_criterion:
    classification:
      function:
      automation_mode:
      authority_level:
      risk_level:
      lifecycle_stage: candidate
    failure_modes: []
    owner_required:
    activation_requirements: []
    operational_value:
    arguments_against:
    minimality_result:
audit_outcome:
  accepted: []
  merged: []
  demoted_to_rule: []
  demoted_to_validator: []
  demoted_to_stop_condition: []
  rejected: []
  minimal_recommended_subset: []
rejected_candidates:
  - id:
    reason:
    prefer_instead:   # rule | schema_field | validator | regression_case | checklist | existing_eou
open_questions: []
registry_diff_notes: []
```

The `audit_outcome` block is populated by `$audit-candidate-eou-set` (the downstream skill), not by this generator. Emit it with all seven keys present and empty; do not pre-populate. The generator's job ends at `audit_status: pending_audit`.

Record the run in `foundry/runs/{eou_id}/{run_id}.yml`. The `run_id` is `generate-eou-candidates-{YYYYMMDD}-{HHmmss}` using the current UTC time.

## Constraints

- Do not set `lifecycle_stage: active` on any candidate.
- Do not mutate `foundry/registry.yml` or any existing EOU spec.
- Do not weaken validators or change the constitution.
- Generate ≤ 7 candidates; if the workflow requires more, split the workflow first.
- Prefer fewer, sharper EOUs — a rule beats a new EOU every time.
- Do not proceed past Step 2 if the stop conditions are met — clarify before generating candidates.
- Every candidate in `recommended_minimal_set` must appear in the `candidates` list with all required fields populated.