NODEDC_1C/.codex/skills/domain-case-loop/SKILL.md

3.7 KiB

name: domain-case-loop description: Use this skill when a user wants to iteratively refine one NDC_1C domain case through a multi-agent loop: automated baseline capture, JSON analysis, minimal domain patch, rerun, and before/after verdict.

Domain case loop

This skill packages the standard workflow for iterating on one concrete domain case in NDC_1C.

Use this skill when

  • the user wants to improve one domain question end-to-end;
  • the answer exists but is noisy, heuristic, partial, or business-useless;
  • the route is wrong even if the wording looks better;
  • there is a gap between exact compute intent and actual fallback output;
  • there are follow-up / continuation bugs that corrupt business context.

Do not use this skill when

  • the user is asking for a broad architecture rewrite;
  • there is no concrete domain case or no reproducible input;
  • the task is only prose editing with no technical/domain component;
  • the task is a generic repo cleanup unrelated to domain capability behavior.

Repo-specific runtime map

Read references/repo_runtime_map.md before the first real cycle.

Use these repo-native capture paths:

  • automated capture: python scripts/domain_case_loop.py run-case ...
  • import existing technical export: python scripts/domain_case_loop.py import-export ...

Workflow

Step 1 - Normalize the case

Create artifacts/domain_runs/<case_id>/case_brief.md with:

  • domain name
  • raw user question
  • expected business meaning
  • expected exact capability
  • expected result mode
  • known constraints
  • acceptance criteria draft

Use references/case_brief_template.md.

Step 2 - Capture baseline

Preferred path:

  • run python scripts/domain_case_loop.py run-case ...

Fallback path:

  • if the user already has a copied technical export markdown, run python scripts/domain_case_loop.py import-export ...

Required artifacts:

  • baseline_output.md
  • baseline_debug.json
  • baseline_turn.json

Step 3 - Analyst verdict

Spawn domain_analyst and provide:

  • case_brief.md
  • baseline_turn.json
  • baseline_output.md
  • baseline_debug.json
  • optional relevant code excerpts or file paths

Require a full verdict using references/verdict_template.md.

Step 4 - Domain patch

Spawn domain_coder with:

  • the case brief
  • the analyst verdict
  • baseline artifacts

Require:

  • a minimal patch
  • zero architecture drift
  • rerun after changes

Step 5 - Rerun

Capture:

  • rerun_output.md
  • rerun_debug.json
  • rerun_turn.json
  • patch_summary.md

Step 6 - Before/after analysis

Spawn domain_analyst again for:

  • before/after comparison
  • final status recommendation
  • quality score from 0 to 100

Step 7 - Final status

Write final_status.md with one of:

  • accepted
  • partial
  • blocked
  • needs_exact_capability

Accepted requires:

  • quality score >= 80
  • no unresolved P0 defects
  • no silent heuristic masking

Hard rules

  • Do not count heuristic candidates as confirmed business answers.
  • If exact data should exist in 1C/MCP, prefer exact route work over prompt cosmetics.
  • If exact data does not exist yet in the reachable contour, return a technical insufficiency with a crisp blocker.
  • Never fabricate 1C data.
  • Keep domain fixes minimal and localized.
  • Preserve successful baseline scenarios.
  • Treat follow-up continuity as a state-machine problem, not a wording problem.

Domain-specific framing

For this repository:

  • architecture must remain unchanged;
  • 1C/MCP is the primary source of truth;
  • analyst output must be detailed and business-readable;
  • answers should be suitable for product hardening, not just debugging notes;
  • machine-readable turn artifacts are first-class inputs for analysis.

Use the artifact layout from references/artifact_layout.md.