# Mellea Fy Fixtures > Melleafy Step 4: Fixture Generation - Skill: `generative-computing/mellea-fy-fixtures` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add generative-computing/mellea-fy-fixtures` - Raw SKILL.md: https://api.skillmd.com/api/skills/generative-computing/mellea-fy-fixtures/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: generative-computing (https://skillmd.com/u/generative-computing) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/generative-computing/mellea-fy-fixtures --- # Melleafy Step 4: Fixture Generation **Version**: 4.2.1 | **Prereq**: Step 3 complete (skeleton emitted with finalised `run_pipeline` signature) | **Produces**: `fixtures_emission.json` > **Schema**: Output `intermediate/fixtures_emission.json` MUST conform to `schemas/fixtures_emission.schema.json` > **Output path rule** (Rule OUT-4): Step 4 produces **ONLY** `intermediate/fixtures_emission.json` in the intermediate directory. This JSON file contains fixture specifications that will be used by downstream processes. **DO NOT generate any Python source files** — no `fixtures/` directory, no `.py` files, no `__init__.py`. The fixture source code generation is handled by a separate process outside this skill. > **CRITICAL**: This step generates ONLY the JSON specification file. Step 4 generates fixture specifications for 5–8 test fixtures covering ≥3 C-categories. The output is a single JSON file conforming to the schema. > **Rule 4-1 — JSON-only fixture specification**: Generate all fixture specifications in a single JSON object conforming to `schemas/fixtures_emission.schema.json`. The invocation receives the `run_pipeline` signature, the element mapping summary, and the C-category coverage requirement, and returns **one JSON object** — not Python source. **This skill's output is ONLY the JSON file.** Do not generate Python fixture files, do not create a `fixtures/` directory, do not write `__init__.py` or individual fixture modules. --- ## CRITICAL: Input parameter matching **The keys in every fixture's `inputs` object MUST be identical to the parameter names of the `run_pipeline` function in `pipeline.py`.** This is not optional. A fixture with `{"text": "..."}` for a pipeline that expects `run_pipeline(user_query=...)` will fail at runtime with a `TypeError`. Before emitting JSON, verify the exact parameter names from the generated pipeline function. The schema cannot enforce this — it's the model's responsibility to match. --- ## Fixture structure The model emits one JSON object saved as `intermediate/fixtures_emission.json`. **This is the only output of Step 4.** _JSON output (conforms to `fixtures_emission.schema.json`):_ ```json { "fixtures": [ { "id": "positive_case", "description": "Critical priority ticket — should escalate to L2 immediately", "inputs": { "ticket_text": "URGENT: Production database is returning 500 errors for all queries.", "priority": "critical" } }, { "id": "clean_case", "description": "Routine request — should route to standard support queue", "inputs": { "ticket_text": "Can you update my email address in the portal?", "priority": "normal" } } ], "coverage_doc": "Fixture coverage:\n C1 Identity: all fixtures\n C2 Operating rules: positive_case\n C6 Tools: positive_case" } ``` ## Required fixture categories Generate at least one fixture per category. Not all categories apply to every skill — use judgment: | Category | Purpose | When to include | | -------------------------- | -------------------------------------------------------------- | ----------------------------------------------- | | **Positive case** | Clear input triggering the skill's primary behaviour | Always | | **Clean/negative case** | Input where the skill finds nothing or produces minimal output | Always | | **Edge case (structural)** | Empty input, very short, very long, missing optional fields | Always | | **Edge case (domain)** | Input at the boundary of the skill's scope | When the skill has meaningful domain boundaries | | **Mixed case** | Combination of positive and negative signals | For analysis/diagnosis archetypes | | **Out-of-scope case** | Input the skill should explicitly decline | When the spec defines "When NOT to Use" | --- ## C-category coverage requirement Fixtures must collectively exercise ≥3 dependency categories (C1–C9). This is R16's fixture coverage threshold. Document which categories each fixture exercises in the `description` field. Example — a ticket-triage skill with C1 (persona), C2 (operating rules), and C6 (tool calls): - Positive case exercises C1 (persona applied), C2 (escalation rule fires), C6 (Slack notification called) - Clean case exercises C1 and C2 (no escalation, no tool call) - Edge case (empty) exercises C2 (out-of-scope handling rule) --- ## Quality rules - Inputs must have realistic, non-trivial data — not placeholder text like `"some input here"` - The `description` field states the expected behaviour, not just what the input is - Do NOT use real credentials, personal data, or production system identifiers in fixtures - Fixtures should run without network access — if the pipeline makes tool calls, use mock tool implementations or `load_from_disk` with bundled fixture data --- ## Cross-checks before Step 4 declares done The schema (`fixtures_emission.schema.json`) and `intermediate/fixtures_emission.json` together enforce most of the contract structurally. The model is responsible only for content correctness: - Fixture count: 5 ≤ N ≤ 8 (enforced by `minItems`/`maxItems` in the schema) - At least 3 distinct C-categories exercised across all fixtures (model self-check; documented in `coverage_doc`) - Every fixture's `inputs` keys match the generated `run_pipeline` signature exactly (model self-check; verify against `pipeline.py` before emitting JSON) - Every fixture has a non-empty, realistic `inputs` value (not placeholder text) - `coverage_doc` is populated with C-category coverage notes