generate-captured-workflow-from-references

# Generate Captured Workflow from References Synthesize a Stage 0 `captured_workflow` for `$app` from a structured reference set and constraints. ## What this skill does One sentence — synthesize the inputs that D2.4 step 6 (`$generate-eou-candidates`) needs, plus the per-app constitutional `domain_values` layer, from a user goal + 5-role reference set + constraints + explicit user contributions. ## Inputs required - `$app` (required) — the app or domain identifier; used in the output filename `cw-{slug}.yml`. - `user_goal` (required) — outcome category in plain language ("I want to make X"). - `reference_set` (required) — mapping with all 5 role slots filled, each with `{ref, why}` entries: - `aspirational` — what the user wants to make - `anti_reference` — similar surface, wrong soul - `boundary_case` — edge of the field - `mainstream_baseline` — the median of the field - `outlier` — "I dislike this but it succeeds" (mandatory V1 defense against blind-spot encoding) - `constraints` (required) — audience, scale, budget, time, risk_tolerance, desired_effect. - `negative_constraints` (required) — what the user rejects explicitly. - `user_contributed_references` (required) — ≥1 reference per role slot that the AI did not propose (V2 anti-abdication enforcement). - `starter_pack` (optional) — `engine/starter-packs/{domain}.yml` if present and the user opts in. ## Inputs forbidden - Pre-existing workflow prose — that input belongs to `$generate-eou-candidates`, not this skill. If the user can already articulate a workflow, this skill returns the `operational_value_test` reject decision and recommends `$generate-eou-candidates` directly. ## Required reading 1. `schemas/captured-workflow.schema.yml` 2. `dev-docs/06-values-over-rules.md` 3. `dev-docs/08-stage-0-design.md` 4. `engine/meta-eous/generate-captured-workflow-from-references.yml` ## Stop conditions Halt and report if any of the following hold: - Any role slot is empty after best-effort elicitation. - `user_contributed_references` is empty for any slot (V2 violation). - Fewer than 3 surviving `domain_values` after inclusion-test filtering. - More than 8 surviving `domain_values` (cap mirrors foundry V1–V8 sizing). - Counterfactual swap audit reveals fewer than 3 flips out of 5 tests (the value layer is decoration). - User can articulate a workflow unaided (skill is the wrong tool; use `$generate-eou-candidates` directly). - The app is governance scaffolding only with no real craft domain. ## Output path `foundry/captured-workflows/cw-{slug}.yml` (one file per run; `{slug}` derived from `$app`). Trace at `foundry/runs/generate-captured-workflow-from-references/{run_id}.yml` per ECP-0014 trace obligation. ## Procedure ### Step 1 — Validate inputs Refuse early if any role slot is empty or `user_contributed_references` is empty per slot. These are V1 and V2 defenses; do not silently degrade. ### Step 2 — Per-reference justification Each reference entry must have a `why`. If missing, prompt the user (or propose then require user confirmation in LLM_assisted mode). ### Step 3 — Counterfactual deconstruction → hidden_judgments For each reference, ask: "What choices did the maker face? What judgments resolved them? What would have killed this work?" Surface the judgment predicates that explain the choices. Each judgment links to a candidate `domain_value` via `governed_by_value`. ### Step 4 — Negative-space analysis → failure_modes Across the reference set and especially across the anti-references, surface failure patterns. Each failure mode links to a `domain_value` it violates (or to the literal `"multiple"` for meta-failures that don't map cleanly). ### Step 5 — Comparative analysis → decision_boundaries Where references make consistently-different choices, name the decision boundary. Each boundary links to the `domain_value` that governs it (and optionally a `secondary_value` when multiple values are implicated). ### Step 6 — Convergence → artifact_target Use reference convergence plus `constraints` to define what the app will produce, at what scale, with what shape. ### Step 7 — Synthesis → captured_workflow prose Write the operating logic implied by Steps 3–6. Keep it tight; the prose is the human-readable summary, not the data layer. ### Step 8 — Pattern detection → candidate domain_values Across the reference set, detect trade-offs that were repeatedly resolved the same way. For each, propose a `domain_value` in **contested form** ("X over Y" where Y must be a real opposing value, not a strawman). For each, run the 6-test inclusion check (`prevents_domain_failure`, `resolves_rule_conflict`, `exposes_hidden_judgment`, `resists_false_success`, `protects_invariant`, `removal_makes_practice_dangerous`); ≥1 true required. ### Step 9 — Priority ordering + canonical_or_personal Surviving `domain_values` MUST be priority-ordered as a total order (exactly the integers `{1, ..., N}` for N values, no ties, no gaps). For each, mark `canonical_or_personal` (`field_canonical`, `user_personal`, `user_diverges_from_canonical`); when non-canonical, require `justification_if_diverges`. ### Step 10 — Confidence calibration For each section (`artifact_target`, `hidden_judgments`, `failure_modes`, `decision_boundaries`, `domain_values`), record confidence as `low`, `medium`, or `high`. Be honest — `medium` is the default for taste-extraction outputs; `high` requires strong evidence. ### Step 11 — Bundle output + multi-gate approval Write `cw-{slug}.yml` per the schema. Require user approval at **four separate gates**: 1. `reference_set_approved_by` 2. `constraints_approved_by` 3. `domain_values_approved_by` 4. `bundle_approved_by` Same identity may fill multiple gates (e.g., a solo founder), but the gates are separately recorded so future governance can distinguish per-gate approval if needed. ## What this skill REFUSES to do 1. Refuse to produce `eou_candidate` or `candidate_set` artifacts. That is `$generate-eou-candidates`' job (D5.1 separation of judgment kinds). 2. Refuse to write outside `foundry/captured-workflows/` and the skill's own run-trace directory. Specifically refuse to touch `foundry/eous/`, `foundry/meta-eous/`, `foundry/registry.yml`, `foundry/self-evolution/`, `schemas/`, `engine/`. 3. Refuse to invent canonical practitioner claims without source citation. The skill never asserts "X is canonical in domain Y" — that is `domain_authority_claim`, listed in `forbidden_outputs`. 4. Refuse to mark `captured_workflow` at any `lifecycle_stage` other than `candidate`. The artifact stays at candidate permanently per the schema. 5. Refuse to produce a `domain_value` that contradicts a foundry V1–V8 invariant. Per D5.5, domain values can STRENGTHEN but cannot WEAKEN foundry values. ## Mechanism, not content This skill contains zero domain assertions. The procedure above works for cooking, code, cinema, music, writing, therapy, teaching, investing — any craft domain. All domain content lives in the produced `captured_workflow` artifact and in the user's reference choices. The skill prose stays mechanism-only; if a future edit smuggles a domain assumption (e.g., "extract craft choices" presupposes that all domains have "craft"), audit the prose and remove the assumption. ## Constraints - The output `captured_workflow` is `lifecycle_stage: candidate` permanently. It is never promoted higher. - `risk_level: medium` (per ECP-0015 risk_level_decision) — errors propagate to every downstream EOU's success criteria via `domain_values` invocation; audit cadence is per major version. - Single-output specialization of rule-95 generating-EOU pattern — the skill produces ONE `captured_workflow` per run (`max_candidates: 1`); the multi-element structure is INSIDE the artifact (5 role slots × ≤5 refs; 3–8 domain_values; etc.). - Trace is mandatory per ECP-0014; record at `foundry/runs/generate-captured-workflow-from-references/{run_id}.yml`. ## Scope Note **Upstream:** top of the Stage 0 pipeline. Receives user goal, reference set, constraints from the user directly (or from a starter pack if opted in). **Downstream:** produces `foundry/captured-workflows/cw-{slug}.yml`, consumed by `$generate-eou-candidates` (when present + approved, scoring consults `domain_values` per Rule 96), by `$audit-candidate-eou-set` (Set Value Coverage Test), and by `$eou-audit` (Value Operationalization Test on specs at `pilot` or higher). **Related:** `$generate-eou-candidates` (downstream consumer); `$audit-candidate-eou-set`, `$eou-audit` (downstream auditors that enforce Rule 96). **Pipeline:** `user goal + references → generate-captured-workflow-from-references → captured_workflow → generate-eou-candidates → audit-candidate-eou-set → human review → eou-specify → eou-audit` **Optionality:** Stage 0 is OPTIONAL. Apps without a captured_workflow use `$generate-eou-candidates` directly with workflow prose, exactly as before.