134 lines
3.7 KiB
Markdown
134 lines
3.7 KiB
Markdown
---
|
|
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.
|
|
|
|
## Recommended artifact set
|
|
|
|
Use the artifact layout from `references/artifact_layout.md`.
|