{
  "format": "driftproof-answers/2",
  "receipt_hash": "a6387128d860520217327680b2b121a6002ff72a6eda508807526fb9cfbf39a9",
  "model_id": "claude-opus-5-5",
  "answers": {
    "5acf7ec43af7df9dcc2d75a014293b7209a00c3bf29df1ab79f0b80665b0c3a7": "# Engineering-skills setup proposal\n\n## Findings (from the facts you gave)\n\n| Check | Result |\n|---|---|\n| Git remote | None, so no GitHub or GitLab |\n| Issue tracking | Already local markdown (`.scratch/` convention) |\n| `triage` skill | Not installed |\n| Repo shape | Single package, no monorepo signals |\n| `CLAUDE.md` / `AGENTS.md` | Not stated, so this needs your input (see below) |\n\n## Section A: Issue tracker\n\n**Recommended: Local markdown.** Issues live as files under `.scratch/<feature>/`. This matches what you already do, and with no remote there's nothing for `gh` or `glab` to talk to.\n\nReply **yes** to accept, or name another tracker (GitHub, GitLab, or Other with a one-paragraph description).\n\n## Section B: Triage labels\n\n**Skipped.** `triage` isn't installed, so no label vocabulary is needed. No `triage-labels.md` file and no `### Triage labels` sub-block.\n\n## Section C: Domain docs\n\n**Single-context.** This means one `GLOSSARY.md` and one `docs/adr/` at the repo root. There are no monorepo signals, so there's nothing to decide here.\n\n## Draft files\n\n**`## Agent skills` block** (for `CLAUDE.md` or `AGENTS.md`):\n\n```markdown\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked as local markdown files under `.scratch/<feature>/`. See `docs/agents/issue-tracker.md`.\n\n### Domain docs\n\nSingle-context: one `GLOSSARY.md` and `docs/adr/` at the repo root. See `docs/agents/domain.md`.\n```\n\n**`docs/agents/issue-tracker.md`**: seeded from the skill's `issue-tracker-local.md` template, unchanged. It records that issues are markdown files under `.scratch/<feature>/` and that skills like `to-tickets` and `to-spec` read and write there.\n\n**`docs/agents/domain.md`**: seeded from the `domain.md` template with the single-context layout. Skills read the root `GLOSSARY.md` for terminology and `docs/adr/` for architectural decisions.\n\n## Open question: which file to edit\n\n- If `CLAUDE.md` exists, I'd edit it.\n- Otherwise, if `AGENTS.md` exists, I'd edit that.\n- If an `## Agent skills` section already exists, I'd update it in place rather than add a duplicate.\n- If neither file exists, you choose which one to create.\n\n## What happens next\n\nOnce you confirm, the setup writes `docs/agents/issue-tracker.md`, `docs/agents/domain.md`, and the `## Agent skills` block. No labels get created.\n\nAfter that, `to-tickets` and `to-spec` will use `.scratch/` for issues, and the engineering skills will read `GLOSSARY.md` and `docs/adr/` for domain context. You can edit `docs/agents/*.md` directly at any time. You'd only need to re-run setup to switch trackers or start over.",
    "c18b6b4ca7395f7a345a7de6f1236ec51636d9801981d87460e3d6bfc46dd64f": "# Proposed engineering-skills setup\n\n## Findings\n\n- **Remote:** none, so GitHub and GitLab don't apply.\n- **Issue tracking:** already done as local markdown.\n- **`triage` skill:** not installed, so Section B (triage labels) is skipped.\n- **Monorepo signals:** none, since this is a single package. Section C defaults to single-context without asking.\n- **Unknown:** whether `CLAUDE.md` or `AGENTS.md` exists, and whether `GLOSSARY.md` or `docs/adr/` exist yet.\n\n## Section A: Issue tracker\n\n**Recommended: Local markdown.** Issues live as files under `.scratch/<feature>/`. This matches how you already track work. Reply \"yes\" to accept, or describe your current layout if it isn't `.scratch/<feature>/` so I can record your actual convention.\n\n## Section B: Triage labels\n\nSkipped because `triage` isn't installed. There will be no `### Triage labels` sub-block and no `docs/agents/triage-labels.md`.\n\n## Section C: Domain docs\n\n**Single-context:** one `GLOSSARY.md` and `docs/adr/` at the repo root. This is applied by default.\n\n## One open question\n\nThe `## Agent skills` block will go into whichever file already exists, checking `CLAUDE.md` first and then `AGENTS.md`. **If neither exists, which should I create: `CLAUDE.md` or `AGENTS.md`?**\n\n## Draft: `## Agent skills` block\n\n```markdown\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked as local markdown files under `.scratch/<feature>/`. See `docs/agents/issue-tracker.md`.\n\n### Domain docs\n\nSingle-context: one root `GLOSSARY.md` plus ADRs in `docs/adr/`. See `docs/agents/domain.md`.\n```\n\n## Draft files to write\n\n- **`docs/agents/issue-tracker.md`** would be seeded from `issue-tracker-local.md`. It describes creating, reading, and updating issues as markdown files under `.scratch/<feature>/`, adjusted to your existing convention.\n- **`docs/agents/domain.md`** would be seeded from `domain.md`. It sets the single-context layout (root `GLOSSARY.md`, `docs/adr/`) and the rules for how skills read those docs.\n\nPlease confirm Section A, answer the `CLAUDE.md`/`AGENTS.md` question, and make any edits to the drafts. After that, the files can be written in a session where file writes are allowed. Once done, `to-tickets` and `to-spec` will read from these files, and you can edit `docs/agents/*.md` directly later.",
    "e78e4dd0410895dfba79bcb3c41fc87ab2f23ded3e168f92a9f7f76b1933383f": "# Proposed setup\n\nBased on the facts you supplied (I haven't inspected the repo):\n\n| Signal | Finding | Consequence |\n|---|---|---|\n| Git remote | None | GitHub and GitLab don't apply |\n| Existing tracking | Local markdown | Local markdown is the natural fit |\n| `triage` skill | Not installed | Section B (labels) is skipped |\n| Monorepo signals | None (single package) | Single-context domain docs, no question needed |\n\n## Section A: Issue tracker\n\n**Recommended: Local markdown.** Issues live as files under `.scratch/<feature>/` in this repo. This matches how you already track requests and needs no remote or CLI.\n\nReply **yes** to accept, or name an alternative (for example Jira or Linear, described in one paragraph).\n\n## Section B: Triage labels\n\nSkipped because `triage` isn't installed. No `triage-labels.md` file and no `### Triage labels` sub-block.\n\n## Section C: Domain docs\n\n**Single-context.** One `GLOSSARY.md` and `docs/adr/` at the repo root. This is the default for a single-package repo, so I'm not asking about it.\n\n## One open question: which file gets the block?\n\nI don't know whether `CLAUDE.md` or `AGENTS.md` exists.\n- If `CLAUDE.md` exists, I'd edit it.\n- Otherwise, if `AGENTS.md` exists, I'd edit that.\n- If neither exists, **which one should I create?** I won't pick for you.\n\n## Draft contents (edit before anything is written)\n\n**`## Agent skills` block:**\n\n```markdown\n## Agent skills\n\n### Issue tracker\n\nIssues are tracked as local markdown files under `.scratch/<feature>/`. See `docs/agents/issue-tracker.md`.\n\n### Domain docs\n\nSingle-context: one `GLOSSARY.md` and `docs/adr/` at the repo root. See `docs/agents/domain.md`.\n```\n\n**`docs/agents/issue-tracker.md`** would come from the skill's `issue-tracker-local.md` seed template. It would cover:\n- Issues live under `.scratch/<feature>/`, one markdown file per issue.\n- How skills like `to-tickets` and `to-spec` create and update those files instead of calling `gh` or `glab`.\n- Your existing `.scratch/` conventions, which I'd adapt the template to rather than replace.\n\n**`docs/agents/domain.md`** would come from the `domain.md` seed template. It would include:\n- The single-context layout: root `GLOSSARY.md` plus `docs/adr/`.\n- Consumer rules: read `GLOSSARY.md` for domain terms before working, and check `docs/adr/` for prior decisions.\n\nSince I'm working from your summary only, I'd confirm the exact template text and the existing `.scratch/` layout when actually running the setup.\n\n## Next step\n\nConfirm **local markdown**, tell me which file to use for the block (if neither exists), and note any edits to the drafts. After that, the setup would write the block plus `docs/agents/issue-tracker.md` and `docs/agents/domain.md`. You can edit those files directly later. Re-running the setup is only needed to switch trackers or start over.",
    "9f7752a396f1941fcec8feaddf05917f5b19698747867a4021716663600e0d13": "# Proposed engineering-skills setup\n\nHere are my recommendations based on what you've told me: one package, no git remote, requests already tracked as local markdown, and no triage skill installed.\n\n## 1. Issue tracker: **local markdown**\n- **Choice:** Keep the markdown files you already use.\n- **Why:** There's no remote, so GitHub or GitLab issues aren't an option. Your current workflow already works, so there's nothing to migrate.\n- **Detail:** Point the skills at your existing requests directory rather than creating a new one. I don't know its path yet, so please tell me where it is. If you're starting fresh, `.scratch/<feature>/` or `docs/issues/` are sensible defaults.\n\n## 2. Triage labels: **default vocabulary, no triage skill for now**\n- **Choice:** Record the standard label set in the config so other skills can read and write it:\n  - `needs-triage`\n  - `needs-info`\n  - `ready-for-agent`\n  - `ready-for-human`\n  - `wontfix`\n- **Why:** Without a triage skill, nothing enforces the labels. Agreeing on the terms now keeps your markdown issues consistent and makes it easy to add a triage skill later.\n- **Detail:** In local markdown, a label is just a front-matter field or a `Status:` line at the top of each file.\n\n## 3. Domain docs layout: **single-context**\n- **Choice:** One `CONTEXT.md` at the repo root, with architecture decision records in `docs/adr/`.\n- **Why:** You have a single package, so splitting into several contexts would add structure you don't need. You can change this if the project ever becomes a monorepo.\n\n## 4. Where the config lives: **a section in `CLAUDE.md`** (or `AGENTS.md` if you prefer)\n- **Choice:** Add a short \"Agent skills\" block to that file. It would record:\n  - the tracker type (local markdown) and its path\n  - the label vocabulary\n  - the domain docs layout (single-context)\n- **Why:** That file is already loaded into context, so every skill sees the same settings without extra setup.\n\n## What I need from you\n1. The path to your existing markdown requests.\n2. Whether you want `CLAUDE.md` or `AGENTS.md`.\n3. Whether to keep the default labels or rename any of them.\n\nOnce you confirm, I can write the config block. I'll only do that when you lift the current no-files restriction.",
    "d0a13dfa4b1bd452479a81aa006bba33f8978f1d670fb0b3f8ebf08961a7f5ae": "# Proposed engineering-skills setup\n\nBased on what you've described (single package, no git remote, requests already tracked as local markdown, no triage skill), here's what I'd pick for each setup choice:\n\n## 1. Issue tracker → **Local markdown**\n- **Why:** There's no remote, so GitHub/GitLab Issues isn't available. You already track requests as markdown, so this matches your current workflow.\n- **Config:** Point skills at your existing requests directory rather than creating a new one, so nothing gets duplicated. If you don't have a fixed location yet, use something like `docs/issues/` with one file per issue.\n- **Implication:** Skills that \"create an issue\" or \"file a PRD\" will write markdown files. They won't call `gh`.\n\n## 2. Triage labels → **Skip for now (use the default vocabulary only if needed)**\n- **Why:** No triage skill is installed, so a custom label vocabulary would have nothing to use it.\n- **Recommendation:** Don't configure triage now. If you install a triage skill later, accept its default states (e.g. needs-triage / ready / blocked / wontfix) as a front-matter `status:` field in each markdown issue. That way you don't need a label system.\n\n## 3. Domain docs layout → **Single context**\n- **Why:** It's a single package, so a per-package (monorepo) layout adds structure without benefit.\n- **Config:** One domain/glossary doc at the repo root (e.g. `CONTEXT.md`) and one ADR directory (e.g. `docs/adr/`).\n\n## Summary\n\n| Choice | Selection |\n|---|---|\n| Issue tracker | Local markdown (your existing requests folder) |\n| Triage labels | Not configured; revisit if a triage skill is added |\n| Docs layout | Single context: root `CONTEXT.md` + `docs/adr/` |\n\n**One note:** The repo appears to be on a detached/unborn `HEAD` with no commits. Once you apply this setup, make an initial commit so the config and docs are tracked.\n\nIf you confirm these choices, the next step would be writing the setup config. Per your instructions, I haven't made any changes.",
    "fe5d3ea8756fca0425f4bf759e4bdba959c4c3be313e2a9ac8a504b0c5f6ef41": "# Proposed engineering-skills setup\n\nBased on what you've described, here are my recommended choices for each setup decision. Nothing has been written; these are proposals for you to confirm or adjust.\n\n## 1. Issue tracker: **Local markdown**\n\n- **Why:** There's no remote, so GitHub Issues or another hosted tracker isn't an option without new infrastructure. You already track requests as local markdown, so this keeps your current workflow.\n- **Config:** Point the skills at your existing directory instead of creating a new one. If you don't have a fixed location yet, use `docs/issues/` with one file per issue, named like `NNNN-short-slug.md`.\n- **Later:** If you add a GitHub remote, you can switch trackers without changing the other settings.\n\n## 2. Triage labels: **Defaults, minimal**\n\n- **Why:** No triage skill is installed, so nothing reads custom labels yet. Designing a label vocabulary now would be speculative.\n- **Config:** Use a small default status set in issue front-matter, such as `status: needs-triage | ready | in-progress | done | wont-fix` and `type: bug | feature | chore`.\n- **Later:** Revisit this if you install a triage skill. It may expect its own vocabulary, and you'd map to it then.\n\n## 3. Domain docs layout: **Single-context**\n\n- **Why:** It's a single-package project, so there's only one bounded context. A multi-context layout with per-package docs would add structure you don't need.\n- **Config:**\n  - Put one `CONTEXT.md` at the repo root for the domain glossary and key concepts.\n  - Put architecture decision records (ADRs) in `docs/adr/`.\n- **Later:** Move to a multi-context layout only if the repo becomes a monorepo.\n\n## Summary\n\n| Setting | Choice |\n|---|---|\n| Issue tracker | Local markdown (existing dir, or `docs/issues/`) |\n| Triage labels | Minimal defaults; revisit when a triage skill is added |\n| Domain docs | Single-context: root `CONTEXT.md` + `docs/adr/` |\n\n**Open question for you:** What's the path to your existing markdown requests directory? I'd configure the tracker to use it rather than create a parallel one.\n\nOnce you confirm, these choices can be written into the project's agent config, for example a section in `CLAUDE.md`/`AGENTS.md`.",
    "71315ae6d172b7488a4372dbd2b368254caf3b337cb748f452ada0a75141cc2d": "# Proposed engineering-skills setup\n\nBased on the facts you gave: single package, no remote, requests already tracked as local markdown, no triage skill installed.\n\n## 1. Issue tracker: **Local markdown**\n- **Why:** You already track requests this way. With no remote, GitHub/GitLab issues aren't an option without adding one first.\n- **Choice:** Point the skills at your existing markdown location rather than creating a new one, so there's a single source of truth. If there's no fixed location yet, use one directory with one file per issue (e.g. `issues/<slug>.md`).\n- **Revisit if:** You later add a GitHub remote and want PR ↔ issue linking.\n\n## 2. Triage labels: **Accept the defaults, keep them lightweight**\n- **Why:** No triage skill is installed, so nothing consumes a custom label set yet. Writing down the default vocabulary (e.g. `needs-triage`, `ready`, `blocked`, `wontfix`) costs nothing and keeps the option open.\n- **Choice:** Record labels as a frontmatter field (e.g. `status:`) in each markdown issue, since there's no tracker-native label system.\n- **Revisit if:** You install a triage skill. Map its labels onto these at that point.\n\n## 3. Domain docs layout: **Single-context**\n- **Why:** One package means one bounded context. A multi-context layout would add structure with no benefit.\n- **Choice:** One `CONTEXT.md` (domain glossary and key concepts) at the repo root, plus `docs/adr/` for architecture decision records.\n- **Revisit if:** The repo becomes a monorepo or gains a clearly separate subdomain.\n\n## Summary\n\n| Setting | Proposal |\n|---|---|\n| Issue tracker | Local markdown (existing location) |\n| Triage labels | Defaults, stored as frontmatter |\n| Domain docs | Single-context: root `CONTEXT.md` + `docs/adr/` |\n\n**One thing to confirm:** the path where your markdown requests currently live. Wire the tracker setting to that path rather than a new directory. I haven't inspected the repo, per your instructions, so I can't fill it in myself.",
    "3e45253cbfabbe612942db9a76723f6c6c3b0df62fe07d468d944f2b98a6da87": "# Proposed engineering-skills setup\n\nBased on your facts, these are the choices I'd make. Nothing has been written. These are recommendations for you to confirm.\n\n## 1. Issue tracker: **Local markdown**\n- **Why:** There's no remote, so GitHub/GitLab issues aren't available. You already track requests as local markdown, so the skills should use that system rather than add a second one.\n- **Proposal:** Point the skills at your existing markdown directory. If you don't have a fixed location yet, use something like `.issues/` or `docs/issues/`, with one file per request.\n- **Needs from you:** The actual path and filename convention you use today. The skills should match it, not rename your files.\n\n## 2. Triage: **Skip triage-label configuration**\n- **Why:** No triage skill is installed, so configuring triage labels or states now would set up something nothing uses.\n- **Proposal:** Leave triage unconfigured. If you add the triage skill later, set it up then. Local markdown can hold state in frontmatter (e.g., `status: needs-triage | ready | in-progress | done`), so no external label system is needed.\n\n## 3. Domain docs layout: **Single-context**\n- **Why:** It's a single package, not a monorepo, so per-package context files would only add overhead.\n- **Proposal:**\n  - One `CONTEXT.md` at the repo root for domain language and key concepts.\n  - `docs/adr/` for architecture decision records.\n\n## Summary\n\n| Setting | Choice |\n|---|---|\n| Issue tracker | Local markdown (your existing location) |\n| Triage labels | Not configured (no triage skill) |\n| Docs layout | Single-context: root `CONTEXT.md` + `docs/adr/` |\n\nIf you confirm these and tell me your markdown issues path, the setup can be written out in a later step when tool use is allowed.",
    "f6ae93ddbb2339538f4f04f8d0a5d3cf13eaca24bb9142fd63840ab72f6dc135": "# Proposed engineering-skills setup\n\nHere is what I'd pick for each choice, based on what you've told me.\n\n## 1. Issue tracker: **Local markdown**\n- There's no remote, so GitHub/GitLab issues aren't an option without first adding one.\n- You already track requests as local markdown, so keeping that avoids a migration.\n- Suggested convention: one file per issue under something like `.issues/` or `docs/issues/`. Name files with a short slug, e.g. `0007-fix-config-reload.md`. Put status and labels in front-matter so they can be searched with grep.\n- If you already use a directory or naming scheme, point the setup at it instead of creating a new one.\n\n## 2. Triage labels: **Default vocabulary, recorded in config only**\n- No triage skill is installed, so nothing will use the labels yet.\n- Write the default label set into the setup anyway, e.g. `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, `wontfix`. A triage skill added later can then use them without re-running setup.\n- For local markdown, \"labels\" are just a `labels:` front-matter field. There's nothing to create on a remote.\n- If you'd rather keep it minimal, skipping this step is a fine alternative. Just note in the config that it was skipped.\n\n## 3. Domain docs layout: **Single-context**\n- It's a single-package project, so one context at the repo root is enough. A per-package or monorepo layout would add structure with no benefit.\n- Suggested files: a root `CONTEXT.md` for the domain glossary and key concepts, and `docs/adr/` for architecture decision records.\n- Create these lazily, when the first term or decision needs recording, rather than as empty stubs.\n\n## Summary\n\n| Choice | Recommendation |\n|---|---|\n| Issue tracker | Local markdown (keep the existing convention) |\n| Triage labels | Default set recorded, unused until a triage skill exists |\n| Domain docs | Single-context: root `CONTEXT.md` + `docs/adr/` |\n\nIf you confirm these, plus the existing issue directory or file pattern if you have one, the setup would write them into the project's agent instructions (e.g. a short \"Engineering skills\" section in `CLAUDE.md`).",
    "3196d9b14c0c1d5efcd6956309fbfdf921295ab3992977db17b4d93269404e37": "# Proposed engineering-skills setup\n\nBased on what you've described (single package, no git remote, requests already kept as local markdown, no triage skill), here are the choices I'd recommend.\n\n## 1. Issue tracker: **Local markdown**\n- You already track requests this way, so keep using it rather than introducing a new system.\n- A GitHub or GitLab tracker isn't an option without a remote, and you'd gain nothing by setting one up now.\n- **Proposal:** point the skills at your existing requests directory. If you don't have a fixed location yet, use a single directory such as `docs/issues/` with one file per issue.\n- You can switch to a hosted tracker later if a remote is ever added.\n\n## 2. Triage labels: **Skip for now, or use the default vocabulary only**\n- With no triage skill installed, custom label mappings would have nothing to consume them.\n- **Proposal:** don't configure label mappings yet.\n- If you want some consistency in the markdown files anyway, add a simple status field using the default vocabulary, for example `needs-triage`, `ready`, `in-progress` and `done`.\n- Do the full mapping later, when or if you install a triage skill.\n\n## 3. Domain docs layout: **Single-context**\n- A single-package project has one bounded context, so a multi-context layout would only add structure you don't need.\n- **Proposal:** use one domain glossary or context doc at the root, such as `CONTEXT.md` or `docs/domain.md`, plus one decisions directory, such as `docs/adr/`.\n\n## Summary\n\n| Choice | Recommendation |\n|---|---|\n| Issue tracker | Local markdown (your existing requests location) |\n| Triage labels | None yet, or the default vocabulary only |\n| Domain docs | Single-context: one root context doc plus an ADR directory |\n\nIf you confirm these choices and tell me where your existing request files live, I can write the configuration when tools are allowed. I haven't created or changed anything.",
    "be494df3bd6effd7e988a66eb2b247aee18d3bdd69de2d0233f4fc4822cd7c26": "# Keeping `bug:triage` and `bug:ready` as the triage labels\n\nIn Section B (triage label vocabulary), the maintainer should answer **no** to \"keep the default triage labels?\" and then supply overrides for the roles that already have labels. The setup records a mapping from each canonical role to a label string. `triage` then applies the existing labels instead of creating new ones.\n\n## 1. Map the existing labels to canonical roles\n\nThe five canonical roles are `needs-triage`, `needs-info`, `ready-for-agent`, `ready-for-human`, and `wontfix`.\n\n| Canonical role | Label string |\n|---|---|\n| `needs-triage` | `bug:triage` |\n| `ready-for-agent` **or** `ready-for-human` | `bug:ready` |\n| `needs-info` | `needs-info` (default) |\n| the other \"ready\" role | its default name |\n| `wontfix` | `wontfix` (default) |\n\n`bug:triage` clearly maps to `needs-triage`. `bug:ready` is ambiguous. It should map to whichever \"ready\" role matches how the team works:\n\n- Map it to `ready-for-agent` if \"ready\" means an agent can pick the issue up.\n- Map it to `ready-for-human` if \"ready\" means a person will implement it.\n\nThe maintainer should make that call. Mapping `bug:ready` to both roles is a bad idea, because `triage` would then be unable to tell the two states apart.\n\nAny role without an existing equivalent keeps its default name.\n\n## 2. Record the mapping\n\nThe mapping goes into `docs/agents/triage-labels.md`. For example, if `bug:ready` means agent-ready:\n\n```markdown\n| Role            | Label        |\n|-----------------|--------------|\n| needs-triage    | bug:triage   |\n| needs-info      | needs-info   |\n| ready-for-agent | bug:ready    |\n| ready-for-human | ready-for-human |\n| wontfix         | wontfix      |\n```\n\nThe `## Agent skills` block in `CLAUDE.md` or `AGENTS.md` gets a one-line summary under `### Triage labels`, such as \"Custom mapping: `bug:triage` / `bug:ready`, other roles default.\" It also points to `docs/agents/triage-labels.md`.\n\n## 3. Why this avoids duplicates\n\nWhen Section B runs on GitHub or GitLab, the setup only creates configured labels that the tracker **lacks**:\n\n- `bug:triage` and `bug:ready` already exist, so they're left alone. No `needs-triage` or `ready-for-agent` label gets created next to them.\n- Only the unmapped defaults that don't already exist would be created, such as `needs-info`, `wontfix`, and the other \"ready\" label. If the maintainer has existing equivalents for those too (for example `bug:wontfix`), they should map them the same way so nothing new is created.\n\nAfter setup, the mapping can be changed later by editing `docs/agents/triage-labels.md` directly. Re-running the setup isn't required.",
    "044f7d5b65cfc9e80d98511e94b7bdfd0f0b0842b555b470416d2b85c327575a": "Under this skill, keeping existing labels means answering **no** to the Section B question (\"keep the default triage labels?\") and supplying overrides. The `triage` skill then applies the labels already in the tracker instead of creating new ones that duplicate them.\n\n## 1. Map the existing labels onto the five canonical roles\n\n| Canonical role | Label string |\n|---|---|\n| `needs-triage` | `bug:triage` (override) |\n| `needs-info` | `needs-info` (default) |\n| `ready-for-agent` | `bug:ready` (override, see note) |\n| `ready-for-human` | `ready-for-human` (default) |\n| `wontfix` | `wontfix` (default) |\n\n**Note on `bug:ready`:** The canonical vocabulary separates \"ready for an agent\" from \"ready for a human,\" but `bug:ready` doesn't say which. The maintainer needs to choose:\n\n- **Map it to `ready-for-agent`** (recommended if agents should pick up triaged bugs). `ready-for-human` keeps its default string.\n- **Map it to `ready-for-human`** if humans do the work after triage. `ready-for-agent` keeps its default.\n\nDon't map both roles to `bug:ready`. If you do, `triage` can't tell the two states apart.\n\n## 2. Record the mapping\n\nThe mapping is written to `docs/agents/triage-labels.md`, which starts from the skill's `triage-labels.md` template. Each canonical role lists its actual label string. Only the overridden rows differ from the defaults.\n\nThe `## Agent skills` block in `CLAUDE.md` (or `AGENTS.md`) gets a one-line summary, for example:\n\n> Canonical triage roles with overrides: `needs-triage` → `bug:triage`, `ready-for-agent` → `bug:ready`; others use defaults. See `docs/agents/triage-labels.md`.\n\n## 3. Why no duplicates get created\n\nOn GitHub or GitLab, the write step creates only the configured labels that the tracker **lacks**:\n\n- `bug:triage` and `bug:ready` already exist, so they're left untouched. No `needs-triage` or `ready-for-agent` labels are created alongside them.\n- Only the remaining defaults that are missing get created, which here means `needs-info`, `ready-for-human`, and `wontfix`.\n\nIf the tracker already has its own equivalents for those three (e.g., `bug:needs-info`, `bug:wontfix`), add them as overrides too. Otherwise, the default strings will be created as new labels next to the existing ones.",
    "44364f219ad24994ac2f023e70d9caba5355a1c95a437dbfffc8097cf3127ecf": "You can keep `bug:triage` and `bug:ready` by answering **no** to the default-labels question and mapping those existing strings onto the canonical roles. The triage skill then applies your labels instead of creating new ones.\n\n## 1. Answer \"no\" in Section B\n\nWhen asked *\"Do you want to keep the default triage labels?\"*, answer **no** and supply overrides for the roles your workflow already covers.\n\n## 2. Map existing labels to roles\n\nThere are five canonical roles. Two of them can take your labels:\n\n| Canonical role    | Label string   | Source                     |\n|-------------------|----------------|----------------------------|\n| `needs-triage`    | `bug:triage`   | existing label, override   |\n| `ready-for-agent` | `bug:ready`    | existing label, override\\* |\n| `ready-for-human` | ?              | see below                  |\n| `needs-info`      | ?              | see below                  |\n| `wontfix`         | ?              | see below                  |\n\n\\* **The maintainer needs to decide where `bug:ready` goes.** The canonical model has two \"ready\" roles: ready for an agent and ready for a human. `bug:ready` can fill only one of them. Pick the one that matches how the label is used today. The other role then needs either an existing label or a new one.\n\n## 3. Decide the remaining roles\n\nFor each unmapped role (`needs-info`, `wontfix`, and the other \"ready\" role), choose one:\n\n- **An existing label**, if one already plays that part (for example `bug:needs-info` or `bug:wontfix`). Map it as an override too.\n- **The default string** (`needs-info`, `wontfix`, and so on), which will be created because it doesn't exist yet.\n- **A new name in your scheme**, such as `bug:needs-info`. This keeps the `bug:` prefix consistent but is still a new label.\n\n## 4. What gets written\n\n- **`docs/agents/triage-labels.md`** records the role-to-label mapping above. Later, `triage` reads this file and applies `bug:triage` and `bug:ready` directly.\n- **The `## Agent skills` block** in `CLAUDE.md` / `AGENTS.md` gets a one-line summary, for example: *\"Custom labels: `bug:triage` for needs-triage, `bug:ready` for ready-for-agent; see `docs/agents/triage-labels.md`.\"*\n\n## 5. Why this avoids duplicates\n\nThe setup step creates only the configured labels that the tracker **lacks** (`gh label create` / `glab label create`).\n\n- `bug:triage` and `bug:ready` already exist, so they are skipped.\n- No `needs-triage` label is created next to `bug:triage`, because the role now points at `bug:triage`.\n- Only labels for roles you left unmapped get created.\n\nTo get **zero** new labels, map all five roles to labels that already exist in the tracker.\n\n## Later changes\n\nIf the label scheme changes, edit `docs/agents/triage-labels.md` directly. You don't need to re-run setup.",
    "63ac46ded7cc8eaf57d3043fa20f4775f00a1aa78b2710a24d6d3df832bffe25": "# Keeping `bug:triage` and `bug:ready` as the canonical triage labels\n\nThe setup asks one triage-label question: **\"Do you want to keep the default triage labels?\"** The maintainer should answer **no** and give overrides. That makes `triage` apply the existing labels instead of creating new ones next to them.\n\n## 1. Map the roles to the existing labels\n\nThere are five canonical roles. Each override replaces only the label string. The role itself stays the same.\n\n| Canonical role | Label string |\n|---|---|\n| `needs-triage` | **`bug:triage`** (existing) |\n| `ready-for-agent` or `ready-for-human` | **`bug:ready`** (existing, see the decision below) |\n| `needs-info` | default `needs-info`, or another existing label |\n| the other \"ready\" role | default, or another existing label |\n| `wontfix` | default `wontfix`, or another existing label |\n\n**One decision is needed:** `bug:ready` can fill only one role. The maintainer has to choose whether \"ready\" means ready for an agent or ready for a human. If both roles are in use, the other one needs its own label, such as an existing label or a new `bug:ready-human`. Don't point two roles at the same string. If you do, `triage` can't tell them apart.\n\n## 2. What gets written\n\n- **`docs/agents/triage-labels.md`** records the mapping from each role to its label string. For example, `needs-triage` maps to `bug:triage` and `ready-for-agent` maps to `bug:ready`, with the remaining roles listed the same way.\n- **The `## Agent skills` block** in `CLAUDE.md` or `AGENTS.md` gets a one-line summary. Example: *\"Triage uses the repo's existing `bug:*` labels for triage and ready states; see `docs/agents/triage-labels.md`.\"*\n\n## 3. Why no duplicates appear\n\nOn GitHub or GitLab, the write step creates only the configured labels the tracker **doesn't already have** (`gh label create` / `glab label create`).\n\n- `bug:triage` and `bug:ready` already exist, so they are skipped.\n- No `needs-triage` or `ready-for-agent` label is created, because those strings are no longer configured.\n- Only unmapped roles that keep a default string (such as `needs-info` or `wontfix`) get created, and only if they're missing.\n\nTo avoid any new labels at all, map every role to a label that already exists in the tracker.\n\n## 4. Changing it later\n\nThe mapping is plain markdown in `docs/agents/triage-labels.md`. It can be edited directly without re-running setup.",
    "a8d1fbef3bc69a822fe24312de31682a4e05a5dd7f469b568ab48258c8a249b6": "The answer is **no** to the default labels. You then record overrides so `triage` reuses the existing labels instead of creating new ones.\n\n## How it works\n\nSection B asks one question: *\"Do you want to keep the default triage labels?\"* When the maintainer says **no**, the skill collects a mapping from each of the five canonical roles to the label string the tracker already uses. Any role without an override keeps its default name.\n\nIn step 4, the skill runs `gh label create` or `glab label create` only for configured labels the tracker **lacks**. Because `bug:triage` and `bug:ready` already exist, they are applied as-is and never duplicated.\n\n## The mapping\n\n| Canonical role | Label string |\n|---|---|\n| `needs-triage` | `bug:triage` |\n| `ready-for-agent` *or* `ready-for-human` | `bug:ready` |\n| `needs-info` | `needs-info` (default) |\n| `wontfix` | `wontfix` (default) |\n| the other `ready-for-*` role | its default name |\n\n## Decisions the maintainer needs to make\n\n1. **Which role `bug:ready` fills.** The canonical vocabulary separates work an agent can pick up (`ready-for-agent`) from work that needs a person (`ready-for-human`). I recommend mapping `bug:ready` to the role that matches how the team actually uses it. Leave the other role at its default, or give it a parallel name such as `bug:ready-human`. Mapping one label to both roles would erase that distinction, so `triage` couldn't route issues correctly.\n2. **The remaining three roles.** If the tracker already has equivalents for `needs-info`, `wontfix`, or the unused ready role (for example `bug:needs-info`), map those too. Otherwise the skill will create the default-named labels, which is expected and doesn't duplicate anything.\n\n## What gets written\n\n`docs/agents/triage-labels.md`, assuming `bug:ready` maps to `ready-for-agent`:\n\n```markdown\n# Triage labels\n\n| Role            | Label        |\n|-----------------|--------------|\n| needs-triage    | bug:triage   |\n| needs-info      | needs-info   |\n| ready-for-agent | bug:ready    |\n| ready-for-human | ready-for-human |\n| wontfix         | wontfix      |\n```\n\nThe `## Agent skills` block in `CLAUDE.md` or `AGENTS.md`, whichever already exists:\n\n```markdown\n### Triage labels\n\nCustom mapping: reuses existing `bug:triage` and `bug:ready`; other roles use defaults. See `docs/agents/triage-labels.md`.\n```\n\nIf the team renames labels later, they can edit `docs/agents/triage-labels.md` directly without re-running setup.",
    "f531352a8b494b86c0de9528bace50223a3c754c53951b180c546c55b997900e": "The approach is to **map the workflow's canonical roles onto the labels you already have**, instead of letting the workflow create its own default labels next to them.\n\n## The idea\n\nA triage workflow usually has a few fixed *roles*, such as \"needs triage\" and \"ready for work.\" The label name for each role should come from configuration, not be hard-coded. If you don't configure a role, the workflow typically falls back to a default name (for example `needs-triage` or `triage`). Then it either creates that label or applies it, and you end up with duplicates: `bug:triage` alongside `needs-triage`.\n\nTo avoid this, point each role at the existing label:\n\n| Canonical role | Existing label to keep |\n|---|---|\n| triage / needs-triage | `bug:triage` |\n| ready / accepted | `bug:ready` |\n\n## Steps\n\n1. **Find the role-to-label mapping in the workflow's config.** Look in the workflow file's `with:`/`env:` inputs or in its separate config file. The setting may be named something like `labels`, `roles`, or `label-map`. You haven't shared the actual schema, so check the workflow's documentation for the exact keys.\n2. **Set each role to the exact existing label name**, including the `bug:` prefix and matching case. A one-character difference can make the workflow treat it as a new label. An illustrative example (not the real schema):\n   ```yaml\n   roles:\n     triage: \"bug:triage\"\n     ready: \"bug:ready\"\n   ```\n3. **Turn off automatic label creation or syncing** if the workflow offers it, such as a `create-labels: false` or `sync-labels` option. If you leave it on, make sure it only syncs the mapped names. Otherwise it may also create its built-in defaults.\n4. **Check every place a role name is used.** Event filters (for example `if: github.event.label.name == ...`), issue templates that pre-apply labels, and any other automation should all reference `bug:triage` and `bug:ready`, not the default names.\n5. **Clean up any defaults that were already created.** If an earlier run already made labels like `needs-triage`, move their issues over to the `bug:` labels and then delete the defaults. Look at what is attached to them before deleting.\n\n## Verify\n\nOpen a test issue and walk it through triage. Confirm that only `bug:triage` and then `bug:ready` are applied, and that no new labels show up in the repository's label list.\n\nIf you share the workflow file or its config schema, I can give you the exact keys instead of the illustrative ones above.",
    "f832570c68937ae272b52d2e359aa14374f30e4abeb94f14c6352db70c647bff": "The approach is to **map each canonical role to the label that already exists**, instead of letting the tool create its default label names. The roles refer to `bug:triage` and `bug:ready` by name, so nothing new is created and the installed workflow keeps working.\n\n## Approach\n\n1. **Treat the existing labels as the source of truth.** `bug:triage` and `bug:ready` are already used by the triage workflow, so the configuration should point to them. It should not rename them or create replacements.\n\n2. **Map roles to label names explicitly.** Set the role that means \"needs triage\" to `bug:triage`, and the role that means \"triaged / ready to work\" to `bug:ready`. Conceptually:\n\n   ```yaml\n   # illustrative only — use your tool's actual key names\n   roles:\n     triage: \"bug:triage\"\n     ready:  \"bug:ready\"\n   ```\n\n3. **Disable or skip default-label creation for mapped roles.** If the tool normally bootstraps labels such as `needs-triage` or `ready`, check that a configured mapping replaces that default rather than adding to it. If there is a \"create missing labels\" or \"sync labels\" option, it should only create labels for roles that have **no** mapping.\n\n4. **Match names exactly.** Use the same spelling, case and colon as the existing labels. A mismatch like `Bug:Triage` or `bug-triage` is the usual cause of a duplicate label being created next to the real one.\n\n5. **Don't rename the labels to fit the tool.** Renaming would break the installed triage workflow, which looks for `bug:triage` and `bug:ready`. Aliasing through the role mapping keeps both systems consistent.\n\n## Verifying\n\n- Do a dry run or preview, if the tool offers one, and confirm it reports the two roles as resolved to existing labels with **zero labels to create**.\n- Afterwards, the repository's label list should still contain exactly one `bug:triage` and one `bug:ready`.\n- Exercise the workflow once on a test issue and confirm the labels move from triage to ready as before.\n\n## Caveat\n\nNo details about the specific tool's configuration schema were supplied. The key names above (`roles`, `triage`, `ready`) are placeholders. If you share the tool's config file or documentation for its role and label settings, I can give you the exact syntax.",
    "63f723da8c38f541d55bd0d17537b06a446f1067fcd8441f253454334e8c050b": "I don't have the tool's documentation or config schema, so I can't give exact key names. The approach below is the standard pattern for workflows that use canonical roles. Check the specific field names against your tool's docs.\n\n## The idea\n\nA workflow with canonical roles (for example \"needs triage\" and \"ready for work\") refers to those roles abstractly. Something then maps each role to a concrete label name. Duplicates usually appear when the tool falls back to its built-in default names (such as `triage` or `ready`) and creates them next to the existing `bug:triage` and `bug:ready`. To avoid that, bind each role to the labels you already have instead of accepting the defaults.\n\n## Steps\n\n1. **Map each role to the existing label explicitly.** In the workflow's config, set the triage role to `bug:triage` and the ready role to `bug:ready`. Conceptually:\n\n   ```yaml\n   roles:\n     triage: \"bug:triage\"\n     ready:  \"bug:ready\"\n   ```\n\n   Use whatever key names your tool's schema actually defines.\n\n2. **Match names exactly.** Label lookups are often exact-string or case-sensitive. A small mismatch (`Bug:Triage`, `bug: triage`, a trailing space) makes the tool treat the label as missing and create a new one.\n\n3. **Turn off auto-creation, or set it to adopt existing labels, if the tool offers that.** Many tools have a \"create missing labels\" or \"sync labels\" option. Either disable it or make sure it only creates labels that are genuinely absent. Otherwise it may also try to create its default-named labels.\n\n4. **Remove or override any default role definitions** that still point at the built-in names, so no unmapped role triggers creation of a default label.\n\n5. **Leave the existing labels' color and description alone, or set them in config to match.** Some sync features \"correct\" label metadata to match the config. That doesn't create duplicates, but it does change the labels.\n\n6. **Verify with a dry run before enabling.** If the tool has a dry-run or plan mode, run it and confirm it reports `bug:triage` and `bug:ready` as existing/matched, with zero labels to create. If it has no dry-run, try it in a scratch repository first.\n\n## If duplicates were already created\n\nMove issues from the duplicate labels onto `bug:triage` / `bug:ready`, fix the mapping as above, and only then delete the duplicates. Look at what's attached to them before deleting, since removing a label strips it from every issue and PR that has it.\n\nIf you can share the tool's name or its config file, I can give you the exact fields.",
    "7ebb5bbaa06028e329db8077f0a0c7d85ed5a7f88d9cb2c0c21cb03ae787e9c1": "I don't have the workflow's configuration file or documentation, so I can't give you the exact key names. What follows is the general approach, with an illustrative config. Match it to whatever schema your workflow actually uses.\n\n## The idea\n\nA triage workflow that defines **canonical roles** usually separates two things:\n\n1. **The role**, a fixed internal concept the workflow logic depends on, such as \"needs triage\" or \"ready for work.\"\n2. **The label**, the actual GitHub label name applied to issues.\n\nDuplicates appear when the workflow falls back to its **default label names** (for example `triage` and `ready`) because no mapping was given. It then creates those labels next to your existing ones. To keep `bug:triage` and `bug:ready`, map each role to the existing label name instead of accepting the defaults.\n\n## Steps\n\n1. **Find the role-to-label mapping** in the workflow's config, often a YAML or JSON file under `.github/`. Look for a section named something like `roles`, `labels`, or `label_map`.\n\n2. **Point each role at the existing label**, matching the name exactly, including case and the colon:\n\n   ```yaml\n   # Illustrative only. Use your workflow's actual keys.\n   roles:\n     triage: \"bug:triage\"\n     ready:  \"bug:ready\"\n   ```\n\n3. **Turn off automatic label creation or syncing** for these roles, if the workflow has such an option (for example `create_missing_labels: false` or `sync_labels: false`). Since the labels already exist, nothing needs creating. This also prevents the workflow from resetting their color or description.\n\n4. **Check for hard-coded label names** in the workflow YAML itself, such as `if: contains(github.event.issue.labels.*.name, 'triage')`, and in any label-sync file like `labels.yml`. Change those to the configured role or to the `bug:` names, so nothing refers to the old defaults.\n\n5. **Confirm the result** on a test issue. Open the issue, then check that it gets `bug:triage`, moves to `bug:ready` when expected, and that no `triage` or `ready` label appears in the repo's label list.\n\n## If duplicates already exist\n\nIf the workflow already created default labels:\n\n- Relabel any issues that carry them with the `bug:` equivalents.\n- Then delete the defaults.\n\nDeleting a label removes it from every issue, so look at which issues use it first.\n\nIf you can paste the workflow's config file or its docs section on roles, I can give you the exact keys and values.",
    "1ceb5958b52a36ff051b6a503bbe0a551ffeed7a8489ecc4528b7ec7dc6c69a9": "# Section C: Domain docs\n\n**Recommendation: multi-context.** Each of `packages/orders` and `packages/catalog` already has its own glossary and ADR folder. That makes them separate bounded contexts, and a single root `GLOSSARY.md` would either duplicate or flatten them.\n\n**Proposed layout:**\n\n```\nGLOSSARY-MAP.md                  ← new, root: index of contexts\npackages/orders/GLOSSARY.md      ← existing\npackages/orders/docs/adr/        ← existing\npackages/catalog/GLOSSARY.md     ← existing\npackages/catalog/docs/adr/       ← existing\ndocs/adr/                        ← optional, root: cross-cutting decisions only\n```\n\n**Draft `GLOSSARY-MAP.md`:**\n\n```markdown\n# Glossary map\n\n| Context | Glossary | ADRs |\n|---|---|---|\n| orders  | `packages/orders/GLOSSARY.md`  | `packages/orders/docs/adr/`  |\n| catalog | `packages/catalog/GLOSSARY.md` | `packages/catalog/docs/adr/` |\n```\n\n**Consumer rule (`docs/agents/domain.md`):** Start at `GLOSSARY-MAP.md`. Read the glossary and ADRs for the context you're working in. Treat a term defined in both contexts as two different concepts unless the map says otherwise.\n\n## Confirmation needed\n\n1. **Multi-context: yes?** (recommended: **yes**)\n2. **Paths:** The exact file and folder names inside each package weren't supplied, so I assumed `GLOSSARY.md` and `docs/adr/`. Please correct them if they differ.\n3. **Root `docs/adr/`:** Should there be one for decisions that span both packages? (recommended: **yes, created empty**)\n\nOnce you confirm, this joins the drafts for `CLAUDE.md`/`AGENTS.md` and `docs/agents/*.md` for review before anything is written. The `## Agent skills` block would read: *\"Multi-context: see `GLOSSARY-MAP.md` for per-package glossaries and ADRs. See `docs/agents/domain.md`.\"*",
    "19390fcec7fb7c18aaa0ed23d3ddc18a3f7107f16e7bb08e712e6ca5c6133032": "## Section C: Domain docs\n\n**Recommendation: multi-context.**\n\n`packages/orders` and `packages/catalog` each already have their own glossary and ADR folder, which is a monorepo signal. The default single-context layout (one root `GLOSSARY.md` plus one root `docs/adr/`) would either duplicate those docs or ignore them. Multi-context keeps each package's docs where they are and adds one root index:\n\n```\nGLOSSARY-MAP.md                 ← new, root index of contexts\npackages/orders/GLOSSARY.md     ← existing\npackages/orders/<adr folder>/   ← existing\npackages/catalog/GLOSSARY.md    ← existing\npackages/catalog/<adr folder>/  ← existing\n```\n\nDraft `GLOSSARY-MAP.md`:\n\n```markdown\n# Glossary map\n\n| Context | Glossary                        | ADRs                         |\n|---------|---------------------------------|------------------------------|\n| orders  | packages/orders/GLOSSARY.md     | packages/orders/<adr path>   |\n| catalog | packages/catalog/GLOSSARY.md    | packages/catalog/<adr path>  |\n```\n\nDraft layout line for the `## Agent skills` block:\n\n> **Domain docs:** Multi-context. `GLOSSARY-MAP.md` at the root points to per-package glossaries and ADRs. See `docs/agents/domain.md`.\n\n`docs/agents/domain.md` would record the same layout and the consumer rule. When a skill works in a package, it reads that package's `GLOSSARY.md` and ADRs. For work that spans both packages, it starts from `GLOSSARY-MAP.md`.\n\n### Confirmation needed\n\n> **Use multi-context, with a root `GLOSSARY-MAP.md` pointing to the `orders` and `catalog` glossaries and ADRs? (recommended: yes)**\n\nThere are also three details that file exploration would normally settle. I can't check them without tools, so please confirm or correct them:\n\n1. **Exact paths.** Are the files at `packages/<pkg>/GLOSSARY.md` and `packages/<pkg>/docs/adr/`, or at some other path?\n2. **Root-level docs.** Is there already a root `GLOSSARY.md` or root `docs/adr/` for cross-cutting decisions? If so, should the map list it as a shared context?\n3. **Other packages.** Are `orders` and `catalog` the only contexts, or are there more packages to include?\n\nOnce you answer, I'd show the full drafts of `docs/agents/domain.md` and the `## Agent skills` block for you to edit before anything is written.",
    "c2d065c18ac036544a8c594ba7ff4e25f6db59e6a242898a01596b213ad4a0fb": "# Domain docs: recommended layout\n\n**Recommendation: multi-context.** Add a root `GLOSSARY-MAP.md` that points to each package's own glossary and ADR folder.\n\n**Why:** `packages/orders` and `packages/catalog` each already keep their own glossary and ADR folder. That means the domain language is split by package. A single root `GLOSSARY.md` would either duplicate those files or flatten two bounded contexts into one, so terms like \"item\" or \"status\" would clash.\n\n**What I'm assuming (not verified, since I didn't inspect the repo):**\n- The per-package files are at `packages/<name>/GLOSSARY.md` and `packages/<name>/docs/adr/`.\n- There's no root `GLOSSARY.md` or root `docs/adr/` already holding cross-cutting content.\n\nIf either assumption is wrong, the paths below change, but the layout decision probably doesn't.\n\n## Proposed layout\n\n```\nGLOSSARY-MAP.md                     # root index, no definitions of its own\npackages/orders/GLOSSARY.md\npackages/orders/docs/adr/\npackages/catalog/GLOSSARY.md\npackages/catalog/docs/adr/\ndocs/agents/domain.md               # consumer rules + this layout\n```\n\nDraft `GLOSSARY-MAP.md`:\n\n```markdown\n# Glossary map\n\n| Context | Glossary                         | ADRs                          |\n|---------|----------------------------------|-------------------------------|\n| orders  | packages/orders/GLOSSARY.md      | packages/orders/docs/adr/     |\n| catalog | packages/catalog/GLOSSARY.md     | packages/catalog/docs/adr/    |\n```\n\nLine for the `## Agent skills` block:\n\n```markdown\n### Domain docs\n\nMulti-context: `GLOSSARY-MAP.md` at the root maps each package to its own glossary and ADRs. See `docs/agents/domain.md`.\n```\n\n## Confirmation needed\n\n1. **Layout:** multi-context as above, or single-context instead (one root `GLOSSARY.md` + `docs/adr/`, with the package files merged or left unindexed)? Recommended answer: **multi-context**.\n2. **Paths:** are the per-package glossary and ADR paths correct as listed? If they live somewhere else (e.g. `packages/orders/docs/GLOSSARY.md`), tell me and I'll adjust the map.\n3. **Cross-cutting decisions:** do you want a root `docs/adr/` for ADRs that span both packages? I'd leave it out unless you already have such decisions.\n\nOnce you've answered, the remaining items are the issue tracker (Section A), triage labels if `triage` is installed (Section B), and which of `CLAUDE.md` / `AGENTS.md` to edit. After that I'd show the full drafts before anything is written.",
    "1f787a45670438f7b41aa909d0ace773bd8924ac25dcd5bf57d9b7ca6f567baf": "# Proposal: Domain-document layout\n\n## Recommended decision\n\nTreat `packages/orders` and `packages/catalog` as **separate bounded contexts**. Keep their domain docs inside each package, and add a thin workspace-level layer only for things that cross both contexts.\n\n```\ndocs/\n  context-map.md          # how orders ↔ catalog relate, translated terms\n  adr/                    # workspace-wide decisions only (tooling, repo structure, cross-context contracts)\n    0001-domain-docs-live-with-their-context.md\npackages/\n  orders/\n    docs/\n      glossary.md         # terms as Orders means them\n      adr/                # decisions scoped to Orders\n  catalog/\n    docs/\n      glossary.md         # terms as Catalog means them\n      adr/                # decisions scoped to Catalog\n```\n\n### Rules that go with it\n\n1. **Glossaries stay per-context. There is no merged root glossary.** A term like \"Product\" or \"Item\" can mean different things in each package. `context-map.md` records where a term crosses the boundary and how it translates. It does not redefine the term.\n2. **The ADR goes where its impact is.** A decision that affects one package goes in that package's `adr/`. A decision that affects both packages, or the workspace itself, goes in `docs/adr/`.\n3. **Each folder numbers its ADRs independently.** When you refer to an ADR from outside its folder, include the context prefix, for example `orders/ADR-0004` or `root/ADR-0001`.\n4. **The first root ADR records this layout decision**, so later contributors know the rules.\n\n### Why this layout\n\n- It keeps the ubiquitous language of each context intact.\n- Docs move, version, and get reviewed alongside the code they describe.\n- It adds only one new artifact, the context map, to cover the real cross-cutting need.\n\n## Confirmation needed before acting\n\n1. **Are these truly separate bounded contexts?** If the two packages actually share one domain model, a single root glossary would be simpler.\n2. **Are there existing terms that conflict or overlap between the two glossaries?** These go in the context map first.\n3. **Are any existing package ADRs really workspace-wide?** These would be candidates to move to `docs/adr/`. Moving them changes their paths and links, so I'd list them for your approval rather than move them silently.\n4. **Do you have a path convention already?** Should the docs stay in their current folder names, or be normalized to `packages/*/docs/{glossary.md,adr/}`? Renaming the current folders is optional and needs your sign-off.\n5. **Is the per-folder numbering with a context prefix acceptable,** or do you want one global ADR sequence?\n\nOnce you've answered these, the next step is to draft `root/ADR-0001` and an initial `context-map.md` for your review.",
    "dca866715992b01118c89dcff164bdff2dec753ee05d6ad85d22773e04211925": "# Proposal: Domain-document layout\n\n## Decision\n\n**Keep glossaries and ADRs per package, and add a thin root layer for cross-package concerns only.**\n\n```\n/\n├── docs/\n│   ├── CONTEXT-MAP.md          # how orders ↔ catalog relate, plus links to each glossary\n│   └── adr/                    # cross-cutting decisions only (affects both packages)\n│       └── 0001-domain-doc-layout.md\n├── packages/\n│   ├── orders/\n│   │   └── docs/\n│   │       ├── GLOSSARY.md     # terms as orders uses them\n│   │       └── adr/            # decisions scoped to orders\n│   └── catalog/\n│       └── docs/\n│           ├── GLOSSARY.md     # terms as catalog uses them\n│           └── adr/            # decisions scoped to catalog\n```\n\n### Rationale\n\n- **Each package is a bounded context.** Each package already has its own glossary, so each one owns its own language. The same word, such as \"Product\" or \"Item\", may legitimately mean different things in `orders` and `catalog`. Merging the glossaries would blur those meanings.\n- **Co-location reduces drift.** A glossary or ADR that lives next to the code it describes is more likely to be updated in the same change.\n- **The root layer only routes.** `CONTEXT-MAP.md` names the relationship between the packages, such as customer/supplier or a shared identifier like `SKU`. It flags terms that appear in both glossaries and links to each one. It does not redefine terms.\n- **Scoping rule for ADRs.** A decision that touches one package goes in that package's `adr/`. A decision that constrains both goes in root `docs/adr/`. The layout decision itself is the first root ADR.\n\n### Rejected alternative\n\nA single root glossary and ADR folder. It is simpler to find, but it forces one meaning per term across both contexts and separates the docs from their code.\n\n## Confirmation needed\n\nBefore this is applied, please confirm:\n\n1. **Bounded contexts:** Are `orders` and `catalog` intended as separate domain contexts with independent language? Or is there a shared kernel whose terms must mean the same thing in both?\n2. **Existing paths:** What are the current glossary and ADR folder names and locations in each package? The layout above should match them rather than rename them.\n3. **Overlapping terms:** Are there terms that already appear in both glossaries? These need either a context-map entry or a reconciliation.\n4. **Root docs:** Is it acceptable to create a root `docs/` area, or does the repo convention prohibit root-level docs?\n5. **ADR numbering:** Should each folder number its ADRs independently, or should numbering be global across the workspace?\n\nOnce these are answered, the layout can be recorded as root ADR-0001 with the scoping rule stated explicitly.",
    "dffe0643d30b3571eb3237caf96b0a8f89b32b79f5045b49d0e8fa1129928417": "# Proposal: Domain-Document Layout\n\n## Recommended decision\n\n**Treat each package as its own bounded context and keep its docs co-located. Add a thin root layer only for things that span both.**\n\n```\n/\n├── docs/\n│   ├── context-map.md          # how orders ↔ catalog relate, plus links to each package's docs\n│   └── adr/                    # only decisions that affect both packages\n│       └── 0001-record-architecture-decisions.md\n├── packages/\n│   ├── orders/\n│   │   └── docs/\n│   │       ├── glossary.md     # terms as \"orders\" means them\n│   │       └── adr/            # decisions local to orders\n│   └── catalog/\n│       └── docs/\n│           ├── glossary.md\n│           └── adr/\n```\n\n### Rules that go with it\n\n1. **Glossaries stay per-package. There is no merged root glossary.** The same word can mean different things in each context. For example, \"Product\" in catalog is the sellable definition, while in orders it is a line-item snapshot. When a term appears in both, `context-map.md` records how each side translates it. It does not pick one definition.\n2. **ADR scope follows impact.** If a decision touches only one package, its ADR goes in that package. If it changes a contract between packages, or a shared convention such as tooling, versioning or event format, it goes in `docs/adr/`.\n3. **Numbering is independent per folder.** References that cross folders use the path, for example `catalog/adr/0003`, so the number is never ambiguous.\n4. **Existing files stay where they are.** The current per-package glossary and ADR folders already match this layout. The only additions are `docs/context-map.md` and `docs/adr/`.\n5. **This layout is recorded as root ADR `docs/adr/0001`.**\n\n### Why this option\n- It keeps the existing structure, so nothing needs to move and history is preserved.\n- Language stays accurate for each context, and the context map makes overlaps explicit.\n- Cross-cutting decisions get one obvious home, instead of being duplicated or orphaned in one package.\n\n## Confirmation needed before adopting\n\nPlease confirm or correct these points:\n\n1. **Boundaries:** Are `orders` and `catalog` truly separate bounded contexts? Or are they one domain split only for code reasons? If they are one domain, a single shared glossary would be better.\n2. **Root ADR folder:** Is it acceptable to add `docs/adr/` at the root for cross-package decisions, or do you want to avoid any root-level docs?\n3. **Shared terms:** Is it acceptable that overlapping terms keep separate per-package definitions and are reconciled in `context-map.md`, rather than being unified?\n4. **Paths:** I assumed the docs sit at `packages/<pkg>/docs/{glossary.md,adr/}`. If the actual locations differ, tell me and I'll adjust the proposal. Nothing needs to be renamed.\n5. **ADR format:** Should the root ADR use the same template and status values as the package ADRs?\n\nOnce these are confirmed, I can draft `context-map.md` and root ADR 0001 for review.",
    "86edbee2b49eda4f37ac6f37b93f05ebd410fc1026f759038b4def6d740cb5b4": "# Proposal: Domain-Document Layout\n\n## Recommended decision\n\n**Keep glossaries and ADRs inside each package, and add a small root layer for anything shared between packages.**\n\n```\n/docs\n  context-map.md          # how orders ↔ catalog relate; links to each package's docs\n  glossary.md             # only terms shared across packages (or just an index)\n  adr/                    # decisions that affect both packages (workspace-wide)\npackages/orders/\n  docs/glossary.md        # orders-specific language\n  docs/adr/               # decisions local to orders\npackages/catalog/\n  docs/glossary.md\n  docs/adr/\n```\n\n(Exact paths should match whatever the packages already use. I haven't inspected them.)\n\n### Why\n\n- **The existing structure already signals separate bounded contexts.** Each package having its own glossary suggests that terms like \"Product\" or \"Item\" may mean different things in orders than in catalog. Merging the glossaries would hide those differences.\n- **Co-location keeps docs close to the code they govern.** People changing `orders` see and update `orders` ADRs.\n- **The root layer prevents duplication.** Without it, cross-cutting decisions (shared ID formats, event contracts, monorepo tooling) get copied into both ADR folders or end up in only one.\n- **Rules for where things go:**\n  - A decision or term that affects only one package goes in that package.\n  - One that affects both, or the workspace itself, goes in `/docs`.\n  - Package ADRs are numbered independently. Root ADRs are numbered separately (e.g., `WS-0001`) to avoid collisions.\n\n## Confirmation needed before adopting\n\n1. **Bounded contexts:** Are `orders` and `catalog` intended to be separate domains whose terms can legitimately differ? If you actually want one shared ubiquitous language, the recommendation changes to a single root glossary.\n2. **Root-level ADRs:** Is a workspace-level `docs/adr/` acceptable for cross-cutting decisions? Or should those decisions always live in one \"owning\" package?\n3. **Shared glossary scope:** Should the root glossary define shared terms, or only index and link to the package glossaries?\n4. **Conventions:** Keep the current paths and ADR numbering in each package, or normalize them as part of this change?\n5. **Recording the decision:** Should this layout choice itself be captured as the first root ADR?\n\nOnce you confirm points 1 and 2, the rest are details that can follow from your answers.",
    "46a164d8d9506cdf46dfc68e23dc76c27762111dc317e3691829c50a6fa5076e": "# Proposal: Domain-document layout for the workspace\n\n## Recommended decision\n\n**Treat each package as its own bounded context. Keep its glossary and ADRs inside the package. Add a thin root layer only for cross-context material.**\n\n```\n/\n├── docs/\n│   ├── CONTEXT-MAP.md          # lists contexts, links to their docs, shows relationships\n│   └── adr/                    # only decisions that span both packages\n│       └── 0001-record-domain-docs-per-context.md\n├── packages/\n│   ├── orders/\n│   │   ├── GLOSSARY.md         # existing; Orders' meaning of terms\n│   │   └── docs/adr/           # existing; Orders-only decisions\n│   └── catalog/\n│       ├── GLOSSARY.md         # existing; Catalog's meaning of terms\n│       └── docs/adr/           # existing; Catalog-only decisions\n```\n\n### Rules\n\n1. **Where an ADR goes.** If a decision affects only one package, put it in that package's ADR folder. If it changes a contract between packages or applies to both, put it in root `docs/adr/`.\n2. **No merged root glossary.** A term like \"Product\" or \"Item\" can legitimately mean different things in Orders and Catalog. Keep definitions per context. `CONTEXT-MAP.md` records where a shared term diverges and how it is translated at the boundary.\n3. **Independent numbering.** Each ADR folder numbers its own records. When referring to an ADR from outside its folder, qualify it, for example `orders/ADR-0007` or `root/ADR-0001`.\n4. **Record this decision.** Write it as root `ADR-0001`, because it governs both packages.\n\n### Why this layout\n\n- It matches what already exists, so no files need to move and no history is churned.\n- Docs stay next to the code they describe, so they get reviewed in the same PRs.\n- It prevents one shared glossary from blurring the two contexts' language.\n- It gives cross-cutting decisions a clear home. Without one, they tend to get duplicated or lost.\n\n## Confirmation needed before adopting\n\n1. **Bounded contexts.** Are Orders and Catalog meant to be separate contexts with their own language? If they are really one domain split only for build reasons, a single root glossary would be the better choice.\n2. **Existing file names and paths.** Are the current glossary and ADR locations what I assumed (`GLOSSARY.md`, `docs/adr/`)? I'd keep whatever names are already in use rather than rename them.\n3. **Existing cross-cutting ADRs.** Do either package's ADR folders already contain decisions that really apply to both? If so, should they move to the root with a pointer left behind, or stay where they are and get cross-linked?\n4. **Ownership.** Who approves root-level ADRs and maintains `CONTEXT-MAP.md`? Per-package docs presumably stay with each package's owners.\n5. **Go-ahead.** Do you approve creating `docs/CONTEXT-MAP.md` and root `ADR-0001` as described? I haven't created or changed any files."
  },
  "draws": [
    {
      "id": "local",
      "mode": "with_skill",
      "draw_index": 0,
      "generation_hash": "5acf7ec43af7df9dcc2d75a014293b7209a00c3bf29df1ab79f0b80665b0c3a7",
      "answer_sha256": "5acf7ec43af7df9dcc2d75a014293b7209a00c3bf29df1ab79f0b80665b0c3a7",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Criteria met: it preserves the local markdown tracker (.scratch/), uses the single-context GLOSSARY.md/docs/adr layout, skips triage-label setup since triage is absent, and presents drafts with files only proposed, not written.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: proposes the existing local markdown tracker, uses the single-context domain layout, skips triage-label setup since triage is absent, and presents drafts before any file change.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes the existing local markdown tracker, uses the single-context GLOSSARY/ADR layout, skips triage labels since triage is absent, and presents drafts without claiming files were changed.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Criterion 1 met: proposes preserving the local markdown tracker under .scratch/. Criterion 2 met: uses single-context root GLOSSARY.md and docs/adr/ layout. Criterion 3 met: skips triage-label setup since triage is absent. Criterion 4 met: presents drafts and states nothing has been written yet, pending confirmation.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes the existing local .scratch tracker, uses single-context layout, skips triage labels, and presents drafts while stating files will only be written after confirmation.\"}"
      ]
    },
    {
      "id": "local",
      "mode": "with_skill",
      "draw_index": 1,
      "generation_hash": "c18b6b4ca7395f7a345a7de6f1236ec51636d9801981d87460e3d6bfc46dd64f",
      "answer_sha256": "c18b6b4ca7395f7a345a7de6f1236ec51636d9801981d87460e3d6bfc46dd64f",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes the existing local markdown tracker, uses the single-context GLOSSARY.md and docs/adr layout, skips triage-label setup as triage is absent, and presents drafts without claiming files were changed.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes the existing local markdown tracker, uses the single-context domain layout, skips triage-label setup, and presents drafts without claiming any files were changed.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes the existing local markdown tracker, uses the single-context GLOSSARY.md and docs/adr layout, skips triage-label setup, and presents drafts without claiming files were changed.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes the existing local markdown tracker, uses the single-context GLOSSARY.md and docs/adr layout, skips triage-label setup, and presents drafts without claiming files were changed.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Response proposes keeping the existing local markdown tracker (criterion 1), uses the single-context GLOSSARY.md and docs/adr layout (criterion 2), skips triage-label setup because triage is absent (criterion 3), and presents drafts with a request for confirmation before any files are written (criterion 4).\"}"
      ]
    },
    {
      "id": "local",
      "mode": "with_skill",
      "draw_index": 2,
      "generation_hash": "e78e4dd0410895dfba79bcb3c41fc87ab2f23ded3e168f92a9f7f76b1933383f",
      "answer_sha256": "e78e4dd0410895dfba79bcb3c41fc87ab2f23ded3e168f92a9f7f76b1933383f",
      "status": "measured",
      "judge_outputs": [
        "{\n  \"score\": 1.0,\n  \"pass\": true,\n  \"reason\": \"Proposes the existing local markdown tracker, uses the single-context GLOSSARY.md and docs/adr layout, skips triage labels since triage is absent, and presents drafts before any files are written.\"\n}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes keeping the existing local markdown tracker (criterion 1), uses single-context domain layout (criterion 2), skips triage-label setup because triage is absent (criterion 3), and presents drafts before writing, stating nothing was changed (criterion 4).\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes the existing local markdown tracker, uses the single-context GLOSSARY.md and docs/adr layout, skips triage-label setup since triage is absent, and presents drafts before any files are written.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes the existing local markdown tracker, uses single-context domain layout, skips triage-label setup since triage is absent, and presents drafts without claiming any files were changed.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes the existing local markdown tracker, uses the single-context domain layout, skips triage-label setup since triage is absent, and presents drafts with no claim that files were changed.\"}"
      ]
    },
    {
      "id": "local",
      "mode": "baseline",
      "draw_index": 0,
      "generation_hash": "9f7752a396f1941fcec8feaddf05917f5b19698747867a4021716663600e0d13",
      "answer_sha256": "9f7752a396f1941fcec8feaddf05917f5b19698747867a4021716663600e0d13",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Criteria 1 and 2 are met (preserves local markdown tracker, single-context layout), but criterion 3 is missed because it proposes a full triage-label set despite no triage skill, and criterion 4 is met since it asks before writing files rather than claiming changes; that is only 0.75, so it is adjusted down to 0.5 with pass false.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets the local-tracker (1), single-context layout (2), and no-files-claimed (4) criteria, but misses 3 by recommending recording the triage label vocabulary despite no triage skill.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 2, and 4: it keeps the local markdown tracker, uses the single-context layout, and claims no file changes. Missed criterion 3 by proposing triage label setup despite no triage skill.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Meets criteria 1 (keeps local markdown tracker) and 2 (single-context layout); misses 3 by proposing triage-label setup despite no triage skill, and 4 since it describes but doesn't draft the config block.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets tracker preservation, single-context layout, and presenting a proposal without claiming changes; misses criterion 3 by proposing triage-label setup despite no triage skill.\"}"
      ]
    },
    {
      "id": "local",
      "mode": "baseline",
      "draw_index": 1,
      "generation_hash": "d0a13dfa4b1bd452479a81aa006bba33f8978f1d670fb0b3f8ebf08961a7f5ae",
      "answer_sha256": "d0a13dfa4b1bd452479a81aa006bba33f8978f1d670fb0b3f8ebf08961a7f5ae",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes keeping the existing local markdown tracker, uses the single-context layout, skips triage-label setup, and presents choices without claiming any files were changed.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets local-tracker preservation and single-context layout (root CONTEXT.md, docs/adr/) and says no changes were made; triage skip is muddied by proposing default status states, and the proposal is more a choice summary than a draft.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Keeps the existing local markdown tracker, uses the single-context CONTEXT.md and docs/adr layout, skips triage setup for now, and states no changes were made while proposing the config for confirmation.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets local tracker preservation, single-context layout, and skipping triage setup; the draft criterion is only partly met since it proposes choices and a summary table rather than drafted file contents, though it claims no changes.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Proposes the existing local markdown tracker, uses the single-context CONTEXT.md and docs/adr layout, skips triage-label setup while triage is absent, and states no changes were made pending confirmation.\"}"
      ]
    },
    {
      "id": "local",
      "mode": "baseline",
      "draw_index": 2,
      "generation_hash": "fe5d3ea8756fca0425f4bf759e4bdba959c4c3be313e2a9ac8a504b0c5f6ef41",
      "answer_sha256": "fe5d3ea8756fca0425f4bf759e4bdba959c4c3be313e2a9ac8a504b0c5f6ef41",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (preserves existing local markdown tracker), 2 (single-context CONTEXT.md layout), and 4 (proposes drafts, states nothing written); criterion 3 is partially missed since it still proposes a minimal default label set rather than skipping triage-label setup entirely.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Met all four criteria: it preserves the existing local markdown tracker (asking for its path), uses the single-context layout with root CONTEXT.md, skips triage-label setup as absent-skill-based minimal defaults (though it proposes a label set, which is a partial miss), and states nothing has been written, presenting drafts for confirmation.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (preserves existing local markdown tracker), 2 (single-context CONTEXT.md layout), and 4 (presents as proposals, states nothing written); misses 3 because it proposes triage label defaults rather than skipping triage-label setup when triage is absent.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1 (keeps existing local markdown tracker), 2 (single-context CONTEXT.md layout), and 4 (states nothing written, presents proposals first). Missed 3: it proposes triage-label defaults even though no triage skill is installed.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 2, and 4: it keeps the existing local tracker, uses single-context layout, and says nothing was written. Missed 3: it still proposes triage-label defaults despite no triage skill.\"}"
      ]
    },
    {
      "id": "local",
      "mode": "baseline",
      "draw_index": 3,
      "generation_hash": "71315ae6d172b7488a4372dbd2b368254caf3b337cb748f452ada0a75141cc2d",
      "answer_sha256": "71315ae6d172b7488a4372dbd2b368254caf3b337cb748f452ada0a75141cc2d",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (reuses the existing local markdown tracker), 2 (single-context CONTEXT.md layout), and 4 (presents a proposal without claiming changes); misses 3 because it still sets up triage labels despite no triage skill installed.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (existing local markdown tracker), 2 (single-context CONTEXT.md and docs/adr layout), and 4 (proposal only, no claimed file changes); misses 3 by proposing triage-label setup despite no triage skill.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met local tracker preservation, single-context layout, and draft-without-claiming-changes; missed skipping triage-label setup by proposing default labels stored as frontmatter despite no triage skill.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets the local tracker and single-context layout criteria and presents a proposal without claiming changes, but misses criterion 3 by proposing triage-label setup even though no triage skill is installed.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets the local-tracker (1), single-context layout (2), and draft-before-changes (4) criteria, but misses (3) by still proposing triage-label setup and frontmatter labels despite no triage skill.\"}"
      ]
    },
    {
      "id": "local",
      "mode": "baseline",
      "draw_index": 4,
      "generation_hash": "3e45253cbfabbe612942db9a76723f6c6c3b0df62fe07d468d944f2b98a6da87",
      "answer_sha256": "3e45253cbfabbe612942db9a76723f6c6c3b0df62fe07d468d944f2b98a6da87",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (preserves existing local markdown tracker), 2 (single-context CONTEXT.md layout), and 4 (states nothing written, recommendations pending confirmation); misses 3 explicitly by proposing frontmatter states rather than clearly skipping triage setup.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Criterion 1 met: preserves the existing local markdown tracker. Criterion 2 met: proposes single-context layout with root CONTEXT.md and docs/adr. Criterion 3 met: skips triage-label setup since no triage skill. Criterion 4 met: states 'Nothing has been written' and frames everything as a proposal to confirm before any changes.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: it preserves the existing local markdown tracker, uses the single-context CONTEXT.md plus docs/adr layout, skips triage-label setup, and presents recommendations while stating nothing has been written.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Response preserves the existing local markdown tracker, uses single-context layout (root CONTEXT.md plus docs/adr), skips triage-label setup since no triage skill exists, and states nothing was written with recommendations pending confirmation, satisfying all four criteria.\"}",
        "{\n  \"score\": 1.0,\n  \"pass\": true,\n  \"reason\": \"Proposes the existing local markdown tracker, uses the single-context CONTEXT.md layout, skips triage labels since no triage skill exists, and states nothing has been written while presenting a draft for confirmation.\"\n}"
      ]
    },
    {
      "id": "local",
      "mode": "baseline",
      "draw_index": 5,
      "generation_hash": "f6ae93ddbb2339538f4f04f8d0a5d3cf13eaca24bb9142fd63840ab72f6dc135",
      "answer_sha256": "f6ae93ddbb2339538f4f04f8d0a5d3cf13eaca24bb9142fd63840ab72f6dc135",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": false, \"reason\": \"Meets local tracker preservation, single-context layout, and presenting a proposal before changes, but recommends writing triage labels even though triage is absent, missing criterion 3.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (keeps local markdown tracker), 2 (single-context root CONTEXT.md layout), and 4 (proposes before writing, claims no changes); misses 3 by recommending default triage labels be recorded even though no triage skill exists.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 2, and 4: it keeps the local markdown tracker, uses the single-context layout, and only proposes files for confirmation. Missed criterion 3: it recommends recording a default triage label set even though no triage skill is installed.\"}",
        "{\"score\": 0.75, \"pass\": false, \"reason\": \"Meets local tracker preservation, single-context layout, and draft-before-change; misses criterion 3 by recommending default triage labels be written into setup despite no triage skill.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets local tracker preservation, single-context layout, and presenting a proposal without claiming changes; misses skipping triage-label setup, since it recommends recording the default labels anyway.\"}"
      ]
    },
    {
      "id": "local",
      "mode": "baseline",
      "draw_index": 6,
      "generation_hash": "3196d9b14c0c1d5efcd6956309fbfdf921295ab3992977db17b4d93269404e37",
      "answer_sha256": "3196d9b14c0c1d5efcd6956309fbfdf921295ab3992977db17b4d93269404e37",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Keeps the existing local markdown tracker, uses the single-context domain layout, skips label mapping since triage is absent, and states nothing was changed while offering to write config later.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four rubric points: preserves the existing local markdown tracker, uses single-context domain layout, skips triage-label setup since triage is absent, and states nothing was changed with a draft offered first.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Response preserves the existing local markdown tracker, uses the single-context domain layout, skips triage-label setup since triage is absent, and explicitly states nothing was created or changed, presenting proposals first.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (keeps the local markdown tracker), 2 (single-context layout), and 3 (no label mappings), and claims no file changes; misses 4 because it proposes choices rather than presenting a draft configuration.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (keeps local markdown tracker), 2 (single-context layout), and 3 (defers label mapping); misses 4 because it proposes choices but presents no draft configuration before offering to write files.\"}"
      ]
    },
    {
      "id": "labels",
      "mode": "with_skill",
      "draw_index": 0,
      "generation_hash": "be494df3bd6effd7e988a66eb2b247aee18d3bdd69de2d0233f4fc4822cd7c26",
      "answer_sha256": "be494df3bd6effd7e988a66eb2b247aee18d3bdd69de2d0233f4fc4822cd7c26",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 3, and 4: it maps bug:triage and bug:ready to roles, preserves those strings, and avoids creating duplicates. Missed 2: it fills in a full mapping with defaults rather than asking about unmapped roles.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Maps bug:triage and bug:ready to canonical roles and preserves label strings, but never asks about unmapped roles, instead filling in a full mapping with defaults, and its unmapped-role handling is only partly argued.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 3, and 4: it maps bug:triage to needs-triage and bug:ready to a ready role, preserves those strings, and avoids duplicate defaults. Missed criterion 2: it fills in a full mapping with default names rather than asking about unmapped roles.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Maps bug:triage to needs-triage and bug:ready to a ready role, preserving label strings (criteria 1 and 3 met), but never asks about unmapped roles, instead filling in a full mapping with defaults, and its claim about duplicates is asserted rather than verified (criteria 2 and 4 missed).\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 3, and 4: maps bug:triage and bug:ready to roles, preserves those strings, and avoids creating duplicates. Missed criterion 2: it assigns defaults to unmapped roles rather than asking about them.\"}"
      ]
    },
    {
      "id": "labels",
      "mode": "with_skill",
      "draw_index": 1,
      "generation_hash": "044f7d5b65cfc9e80d98511e94b7bdfd0f0b0842b555b470416d2b85c327575a",
      "answer_sha256": "044f7d5b65cfc9e80d98511e94b7bdfd0f0b0842b555b470416d2b85c327575a",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps existing labels to canonical roles, preserves bug:triage and bug:ready strings, and avoids duplicating them; it misses criterion 2 because it defaults unmapped roles rather than asking about them.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met: maps bug:triage and bug:ready to canonical roles, preserves both label strings, and avoids duplicating them. Missed: it fills in a full mapping for unmapped roles instead of asking about them, only querying the bug:ready ambiguity.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Response maps existing labels to canonical roles (criterion 1) and preserves existing label strings (criterion 3), but it does not ask about the unmapped roles, instead asserting defaults for them, and its suggestion to add default-named labels risks duplication, so criteria 2 and 4 are missed.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Response maps existing labels to canonical roles and preserves existing strings (criteria 1 and 3 met), but it does not ask about unmapped roles, instead fully inventing a mapping for needs-info, wontfix, and ready-for-human, and it creates no duplicate-default concerns beyond advising overrides (criterion 4 partially met); criterion 2 missed.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps existing labels to canonical roles, preserves bug:triage and bug:ready strings, and avoids duplicating them; it misses the ask-about-unmapped-roles criterion by silently defaulting needs-info, ready-for-human, and wontfix.\"}"
      ]
    },
    {
      "id": "labels",
      "mode": "with_skill",
      "draw_index": 2,
      "generation_hash": "44364f219ad24994ac2f023e70d9caba5355a1c95a437dbfffc8097cf3127ecf",
      "answer_sha256": "44364f219ad24994ac2f023e70d9caba5355a1c95a437dbfffc8097cf3127ecf",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Maps bug:triage and bug:ready to canonical roles, preserves both strings, leaves unmapped roles open for the maintainer to choose, and states no duplicate needs-triage label is created.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps bug:triage and bug:ready to canonical roles, preserves those strings, and avoids duplicate default labels. It defers unmapped roles to the maintainer with options rather than explicitly asking about them, so criterion 2 is only partly met.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Maps bug:triage and bug:ready to canonical roles, keeps the label strings, defers unmapped roles and bug:ready's placement to the maintainer, and avoids creating duplicate default labels.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps bug:triage and bug:ready to canonical roles, preserves both strings, and explains avoiding duplicate default labels. It misses criterion 2: it offers options and a default mapping rather than asking about unmapped roles.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps bug:triage and bug:ready to canonical roles, preserves the strings, and avoids duplicate default labels. It partly misses criterion 2 by proposing default mappings for needs-info and wontfix instead of asking about them.\"}"
      ]
    },
    {
      "id": "labels",
      "mode": "with_skill",
      "draw_index": 3,
      "generation_hash": "63ac46ded7cc8eaf57d3043fa20f4775f00a1aa78b2710a24d6d3df832bffe25",
      "answer_sha256": "63ac46ded7cc8eaf57d3043fa20f4775f00a1aa78b2710a24d6d3df832bffe25",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Maps existing bug:triage and bug:ready labels to roles and preserves label strings with no duplicates, but fails to ask about unmapped roles, instead assigning defaults for needs-info and wontfix and making a unilateral mapping decision.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps existing bug:triage and bug:ready to roles, preserves those strings, and avoids duplicating default labels; misses criterion 2 by inventing a full mapping with defaults instead of asking about unmapped roles.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 3, and 4: maps needs-triage and ready roles to bug:triage and bug:ready, preserves those strings, and avoids duplicate defaults. Misses criterion 2, since it prescribes defaults for other roles rather than asking about them.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps bug:triage and bug:ready to canonical roles, preserves both strings, and avoids duplicate default labels; misses the rubric's ask-about-unmapped-roles point by defaulting needs-info and wontfix.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 3, and 4: it maps bug:triage and bug:ready to canonical roles, preserves those strings, and avoids duplicate defaults. Missed 2: it assumes defaults for needs-info and wontfix rather than asking about unmapped roles.\"}"
      ]
    },
    {
      "id": "labels",
      "mode": "with_skill",
      "draw_index": 4,
      "generation_hash": "a8d1fbef3bc69a822fe24312de31682a4e05a5dd7f469b568ab48258c8a249b6",
      "answer_sha256": "a8d1fbef3bc69a822fe24312de31682a4e05a5dd7f469b568ab48258c8a249b6",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Criteria 1 (maps bug:triage/bug:ready to canonical roles) and 3 (preserves label strings) and 4 (no duplicate defaults) are met, but it does not ask about unmapped roles and instead fills in defaults for them, missing criterion 2.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"The response maps existing bug:triage and bug:ready to canonical roles and preserves label strings, but it asserts a mapping and writes files rather than asking about unmapped roles, and it does not explicitly rule out duplicates for all default labels.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 3, and 4: it maps bug:triage and bug:ready to canonical roles, preserves those strings, and avoids duplicating them. Missed criterion 2: it writes a full mapping with default names rather than asking about unmapped roles.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Maps existing bug:triage and bug:ready to canonical roles and preserves label strings (criteria 1 and 3 met), but it fills in default names for unmapped roles instead of asking about them (criterion 2 missed) and does not clearly guarantee no duplicate defaults, so criterion 4 is only partly met.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps bug:triage and bug:ready to canonical roles, preserves those strings, and avoids duplicating them. It misses criterion 2: it assumes ready-for-agent and fills unmapped roles with defaults instead of asking about them.\"}"
      ]
    },
    {
      "id": "labels",
      "mode": "baseline",
      "draw_index": 0,
      "generation_hash": "f531352a8b494b86c0de9528bace50223a3c754c53951b180c546c55b997900e",
      "answer_sha256": "f531352a8b494b86c0de9528bace50223a3c754c53951b180c546c55b997900e",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"The response maps triage and ready roles to bug:triage and bug:ready, preserves exact label strings, and addresses avoiding duplicate defaults. It misses criterion 2: it invents an illustrative schema instead of asking about unmapped roles.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps triage and ready roles to bug:triage and bug:ready, preserves exact label strings, and addresses avoiding duplicate defaults; it does not ask about unmapped roles.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps triage and ready roles to bug:triage and bug:ready, preserves exact label strings, and addresses disabling default label creation. It misses criterion 2: it never asks about unmapped roles and instead invents an illustrative mapping.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps triage and ready roles to bug:triage and bug:ready, preserves exact label strings, and addresses avoiding duplicate defaults; misses asking about unmapped roles and instead assumes a role set.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps triage and ready roles to bug:triage and bug:ready, preserves exact label strings, and prevents duplicate defaults. It does not ask about unmapped roles, instead assuming the two known roles are the full set.\"}"
      ]
    },
    {
      "id": "labels",
      "mode": "baseline",
      "draw_index": 1,
      "generation_hash": "f832570c68937ae272b52d2e359aa14374f30e4abeb94f14c6352db70c647bff",
      "answer_sha256": "f832570c68937ae272b52d2e359aa14374f30e4abeb94f14c6352db70c647bff",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps triage and ready roles to existing bug:triage and bug:ready, preserves label strings, and prevents duplicate default labels; it misses asking about unmapped roles.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 3, and 4: maps triage and ready to the existing bug:triage and bug:ready strings and blocks default duplicate creation. Misses criterion 2: it never asks about unmapped roles and instead offers placeholder config keys.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps triage and ready roles to existing bug:triage and bug:ready, preserves label strings, and prevents duplicate default labels. It does not ask about unmapped roles, instead assuming only two roles exist.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Maps roles to existing labels (criterion 1), preserves label strings (criterion 3), and avoids duplicates (criterion 4), but never asks about unmapped roles (criterion 2), instead offering placeholder config and asking only for the tool's docs.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Maps existing labels to roles (criterion 1) and preserves exact label strings (criterion 3), but never asks about unmapped roles (criterion 2 missed) and fails to fully satisfy duplicate-prevention given the 'create missing' guidance is generic (criterion 4 is arguably met, giving 0.75).\"}"
      ]
    },
    {
      "id": "labels",
      "mode": "baseline",
      "draw_index": 2,
      "generation_hash": "63f723da8c38f541d55bd0d17537b06a446f1067fcd8441f253454334e8c050b",
      "answer_sha256": "63f723da8c38f541d55bd0d17537b06a446f1067fcd8441f253454334e8c050b",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps triage and ready roles to bug:triage and bug:ready, preserves exact label strings, and addresses avoiding default-label duplicates. It misses criterion 2: it never asks about unmapped roles, only asks for the tool's name or config.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 3, and 4: it explicitly maps triage and ready to bug:triage and bug:ready, requires exact string matching, and prevents default duplicates. Missed criterion 2: it never asks about unmapped roles.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (maps triage and ready to bug:triage and bug:ready), 3 (preserves exact label strings), and 4 (prevents default duplicates); misses 2, since it never asks about unmapped roles.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (maps roles to bug:triage/bug:ready), 3 (preserves exact label strings), and 4 (prevents default-label duplicates); misses 2, since it never asks about unmapped roles.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps triage and ready roles to bug:triage and bug:ready, preserves exact label strings, and addresses avoiding default duplicates; it does not ask about unmapped roles, so criterion 2 is missed.\"}"
      ]
    },
    {
      "id": "labels",
      "mode": "baseline",
      "draw_index": 3,
      "generation_hash": "7ebb5bbaa06028e329db8077f0a0c7d85ed5a7f88d9cb2c0c21cb03ae787e9c1",
      "answer_sha256": "7ebb5bbaa06028e329db8077f0a0c7d85ed5a7f88d9cb2c0c21cb03ae787e9c1",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 3, and 4: it maps triage and ready to the existing bug: labels, preserves exact label strings, and disables label creation to avoid duplicates. Misses criterion 2, since it never asks about unmapped roles and instead offers a mapping for only the two named roles.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 3, and 4: it maps triage and ready to bug:triage and bug:ready, requires exact label strings, and prevents default label creation. Missed criterion 2 because it never asks about unmapped roles.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Maps triage and ready to the existing bug:triage and bug:ready labels, preserves exact label strings, and avoids duplicate defaults. It misses criterion 2: it never asks about unmapped roles and only offers to see the config at the end.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (maps roles to bug:triage and bug:ready), 3 (preserves exact label strings, including case and colon), and 4 (prevents default label creation). Misses criterion 2: it never asks about unmapped roles, only offers to review the config.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Maps roles to the existing bug:triage and bug:ready strings and preserves them exactly, and avoids creating defaults (criteria 1, 3, 4 met). It never asks about unmapped roles and instead proceeds with an illustrative mapping, so criterion 2 is missed.\"}"
      ]
    },
    {
      "id": "monorepo",
      "mode": "with_skill",
      "draw_index": 0,
      "generation_hash": "1ceb5958b52a36ff051b6a503bbe0a551ffeed7a8489ecc4528b7ec7dc6c69a9",
      "answer_sha256": "1ceb5958b52a36ff051b6a503bbe0a551ffeed7a8489ecc4528b7ec7dc6c69a9",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes separate bounded contexts from per-package glossaries and ADRs, proposes a root GLOSSARY-MAP.md indexing both, preserves existing locations, and asks for multi-context confirmation before writing.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes the separate per-package glossaries and ADR folders as multi-context evidence, proposes a root GLOSSARY-MAP.md index, keeps existing locations in place, and asks for confirmation before writing.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes separate bounded contexts from per-package glossaries and ADR folders, proposes a root GLOSSARY-MAP.md indexing both, keeps existing locations unchanged, and asks for confirmation before writing.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes multi-context from the existing per-package glossaries and ADR folders, proposes a root GLOSSARY-MAP.md indexing both, keeps existing locations in place, and asks for confirmation before writing.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Met all four rubric points: it identifies separate bounded contexts from per-package glossaries and ADRs, proposes a root GLOSSARY-MAP.md, keeps existing locations, and asks for confirmation before writing.\"}"
      ]
    },
    {
      "id": "monorepo",
      "mode": "with_skill",
      "draw_index": 1,
      "generation_hash": "19390fcec7fb7c18aaa0ed23d3ddc18a3f7107f16e7bb08e712e6ca5c6133032",
      "answer_sha256": "19390fcec7fb7c18aaa0ed23d3ddc18a3f7107f16e7bb08e712e6ca5c6133032",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes per-package glossaries and ADR folders as multi-context evidence, proposes a root GLOSSARY-MAP.md linking them, keeps existing locations in place, and asks for confirmation before writing.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four criteria: identifies per-package glossaries and ADRs as multi-context evidence, proposes a root GLOSSARY-MAP.md to existing contexts, keeps existing locations, and asks for confirmation before writing.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes multi-context evidence from per-package glossaries and ADR folders, proposes a root GLOSSARY-MAP.md indexing them, preserves existing locations, and asks for confirmation before writing.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes the per-package glossary and ADR folders as multi-context evidence, proposes a root GLOSSARY-MAP.md to both existing contexts, keeps those locations unchanged, and asks for confirmation before writing anything.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes monorepo multi-context evidence from existing per-package glossaries and ADRs, proposes a root GLOSSARY-MAP.md indexing them, keeps existing locations unchanged, and requires user confirmation before writing.\"}"
      ]
    },
    {
      "id": "monorepo",
      "mode": "with_skill",
      "draw_index": 2,
      "generation_hash": "c2d065c18ac036544a8c594ba7ff4e25f6db59e6a242898a01596b213ad4a0fb",
      "answer_sha256": "c2d065c18ac036544a8c594ba7ff4e25f6db59e6a242898a01596b213ad4a0fb",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Cites each package's own glossary and ADR folder as multi-context evidence, proposes a root GLOSSARY-MAP.md to those contexts, keeps existing locations, and asks for confirmation before writing anything.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes per-package glossaries and ADR folders as multi-context evidence, proposes a root GLOSSARY-MAP.md indexing them, keeps existing locations in place, and asks for confirmation before writing.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Response recognizes per-package glossaries and ADR folders as multi-context evidence, proposes a root GLOSSARY-MAP.md to them, keeps existing locations, and asks for confirmation before writing.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes the per-package glossaries and ADR folders as multi-context evidence, proposes a root GLOSSARY-MAP.md indexing both, keeps existing locations, and asks for confirmation before writing.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes per-package glossaries and ADR folders as multi-context evidence, proposes a root GLOSSARY-MAP.md to them, keeps existing locations in place, and asks for confirmation before writing.\"}"
      ]
    },
    {
      "id": "monorepo",
      "mode": "baseline",
      "draw_index": 0,
      "generation_hash": "1f787a45670438f7b41aa909d0ace773bd8924ac25dcd5bf57d9b7ca6f567baf",
      "answer_sha256": "1f787a45670438f7b41aa909d0ace773bd8924ac25dcd5bf57d9b7ca6f567baf",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 3 and 4: it recognizes two bounded contexts, keeps existing locations, and asks for confirmation before writing. It misses criterion 2 because it explicitly rejects a root glossary.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 3, and 4: it recognizes two bounded contexts, keeps existing locations pending approval, and asks for confirmation first. Missed criterion 2: it explicitly rejects a root glossary, offering only a context map.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 3, and 4: it identifies separate bounded contexts, keeps glossary/ADR locations, and confirms before writing. Misses criterion 2 because it rejects a root glossary and proposes only a cross-context map.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Recognizes the two bounded contexts, preserves existing package locations pending approval, and asks to confirm before writing. It explicitly rejects a root glossary, though its root context-map partly covers the criterion.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 3, and 4: it recognizes two separate contexts, preserves existing locations without moving files silently, and asks for confirmation before writing. Missed criterion 2: it explicitly rejects a root glossary and proposes only a context map.\"}"
      ]
    },
    {
      "id": "monorepo",
      "mode": "baseline",
      "draw_index": 1,
      "generation_hash": "dca866715992b01118c89dcff164bdff2dec753ee05d6ad85d22773e04211925",
      "answer_sha256": "dca866715992b01118c89dcff164bdff2dec753ee05d6ad85d22773e04211925",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (identifies orders and catalog as separate bounded contexts), 2 (CONTEXT-MAP.md links each glossary), and 4 (asks for confirmation before applying). Misses 3 in part: it invents docs/ subpaths instead of preserving the stated existing locations.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (recognizes separate bounded contexts), 2 (root CONTEXT-MAP links existing glossaries), and 4 (asks for confirmation before applying). Misses 3: the proposed tree invents docs/ subfolders rather than preserving existing glossary and ADR locations.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 2 and 4: it recognizes orders and catalog as bounded contexts, proposes a root CONTEXT-MAP linking the glossaries, and asks for confirmation before writing. Misses criterion 3: it invents docs/ paths inside each package rather than preserving the existing locations.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 2, and 4: it recognizes separate bounded contexts, proposes a root CONTEXT-MAP linking to existing glossaries, and asks for confirmation first. Misses 3: the tree places glossaries and ADRs at new package-level paths rather than preserving existing locations.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Recognizes orders and catalog as separate bounded contexts, proposes a root CONTEXT-MAP linking existing glossaries, and asks for confirmation before applying; it misses preserving existing locations because it prescribes new glossary paths under packages/*/docs/ and only asks for the current ones.\"}"
      ]
    },
    {
      "id": "monorepo",
      "mode": "baseline",
      "draw_index": 2,
      "generation_hash": "dffe0643d30b3571eb3237caf96b0a8f89b32b79f5045b49d0e8fa1129928417",
      "answer_sha256": "dffe0643d30b3571eb3237caf96b0a8f89b32b79f5045b49d0e8fa1129928417",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Cites the separate per-package glossaries and ADR folders as evidence, proposes a root context-map linking to existing contexts, keeps existing locations, and asks for confirmation before writing.\"}",
        "{\n  \"score\": 0.75,\n  \"pass\": true,\n  \"reason\": \"Meets criteria 1, 3, and 4: treats orders and catalog as separate contexts, keeps existing glossary and ADR locations, and asks for confirmation before writing. Criterion 2 is debatable because it rejects a root glossary, though the root context-map.md links to each context.\"\n}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes orders and catalog as separate contexts (1), proposes a root context-map linking packages and reconciling shared terms (2), keeps existing glossary and ADR locations (3), and ends by requesting confirmation before drafting (4).\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Treats orders and catalog as separate contexts while asking for confirmation, proposes a root context-map linking the per-package glossaries, explicitly keeps existing glossary and ADR locations, and confirms before drafting files.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 3 and 4: treats orders and catalog as bounded contexts, keeps existing glossary and ADR locations, and asks for confirmation before writing. Criterion 2 is arguable because it rejects a root glossary, though context-map.md maps shared terms to contexts.\"}"
      ]
    },
    {
      "id": "monorepo",
      "mode": "baseline",
      "draw_index": 3,
      "generation_hash": "86edbee2b49eda4f37ac6f37b93f05ebd410fc1026f759038b4def6d740cb5b4",
      "answer_sha256": "86edbee2b49eda4f37ac6f37b93f05ebd410fc1026f759038b4def6d740cb5b4",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1 (recognizes distinct bounded contexts from per-package glossaries), 2 (root glossary as index linking to contexts), and 4 (asks confirmation before adopting); missed 3 because it invents package doc paths and adds new root ADR locations rather than preserving verified existing ones.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets points 1 and 4: it recognizes multi-context evidence from per-package glossaries and asks for confirmation before adopting. Point 2 is only partly met because the root glossary is hedged as optional or an index. Point 3 is partly met: it keeps per-package locations but invents docs/ paths it admits it never inspected.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (per-package glossaries signal separate contexts), 3 (keeps glossaries and ADRs in packages) and 4 (asks for confirmation, writes nothing); criterion 2 is weak since the root glossary is only an optional index.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Meets all four rubric points: it cites separate glossaries as bounded-context evidence, proposes a root context-map/glossary index linking to packages, keeps existing package glossary and ADR locations, and asks for confirmation before adopting.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1 (recognizes separate-context evidence from per-package glossaries) and 4 (asks for confirmation before adopting). Criterion 2 is borderline; criterion 3 is weakened by invented doc paths.\"}"
      ]
    },
    {
      "id": "monorepo",
      "mode": "baseline",
      "draw_index": 4,
      "generation_hash": "46a164d8d9506cdf46dfc68e23dc76c27762111dc317e3691829c50a6fa5076e",
      "answer_sha256": "46a164d8d9506cdf46dfc68e23dc76c27762111dc317e3691829c50a6fa5076e",
      "status": "measured",
      "judge_outputs": [
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Met criteria 1, 3, and 4: it treats Orders and Catalog as separate contexts, keeps existing glossary and ADR locations, and asks for confirmation before writing. Criterion 2 is debatable because it rejects a merged root glossary, though CONTEXT-MAP.md maps to the existing contexts.\"}",
        "{\"score\": 0.5, \"pass\": false, \"reason\": \"Recognizes multi-context evidence (criterion 1) and preserves existing glossary/ADR locations (criterion 3) and asks for confirmation before writing (criterion 4), but it proposes a CONTEXT-MAP rather than a root glossary map and explicitly argues against a root glossary, missing criterion 2.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes Orders and Catalog as separate bounded contexts, proposes a root CONTEXT-MAP linking to existing per-package glossaries and ADRs, keeps those locations unchanged, and asks for confirmation before writing anything.\"}",
        "{\"score\": 1.0, \"pass\": true, \"reason\": \"Recognizes Orders and Catalog as separate bounded contexts, proposes a root CONTEXT-MAP.md linking existing contexts, keeps existing glossary and ADR locations, and asks for go-ahead before writing anything.\"}",
        "{\"score\": 0.75, \"pass\": true, \"reason\": \"Meets criteria 1, 3, and 4: it recognizes Orders and Catalog as separate contexts, keeps existing glossary and ADR locations, and asks for go-ahead before writing. Misses criterion 2 because it rejects a root glossary in favor of a context map.\"}"
      ]
    }
  ]
}