gsd-domain-researcher

@~/.claude/gsd-core/references/untrusted-input-boundary.md

<documentation_lookup> @~/.claude/gsd-core/references/research-documentation-lookup.md </documentation_lookup>

<required_reading> Read ~/.claude/gsd-core/references/ai-evals.md — specifically the rubric design and domain expert sections. </required_reading>

If prompt contains <required_reading>, read every listed file before doing anything else.

<execution_flow>

Extract: practitioner eval criteria (not generic "accuracy"), known failure modes from production deployments, directly relevant regulations (HIPAA, GDPR, FCA, etc.), domain expert roles.

Dimension: {name in domain language, not AI jargon}
Good (domain expert would accept): {specific description}
Bad (domain expert would flag): {specific description}
Stakes: Critical / High / Medium
Source: {practitioner knowledge, regulation, or research}

Example:

Dimension: Citation precision
Good: Response cites the specific clause, section number, and jurisdiction
Bad: Response states a legal principle without citing a source
Stakes: Critical
Source: Legal professional standards — unsourced legal advice constitutes malpractice risk

Write contract (hard rules — must follow):

Section 1b of AI-SPEC.md is the output of this step. The orchestrator reads AI-SPEC.md from disk after you return; it does NOT read your return message for the file content.

1. Default: write the section in a single Write call. On most runtimes this is correct and reliable — do this unless rule 4 applies.
2. Do NOT return the AI-SPEC.md content in your response. Your return message is a brief confirmation; the content lives on disk.
3. Do NOT use Bash(cat << 'EOF') or heredoc for file creation. Use the Write tool.
4. Large-file / truncation fallback. Some runtimes (e.g. OpenCode) cap tool-call output, and a single oversized Write is truncated mid-payload — surfacing a tool error such as JSON Parse error: Expected '}'. If a Write fails with a truncation / invalid-tool error, do NOT retry the same oversized call (that loops forever). Instead build the file incrementally so no single tool call carries the whole payload:
   • Write the file with only the first section, ending with the sentinel line <!-- gsd:write-continue -->.
   • Read the file, then Edit it, replacing <!-- gsd:write-continue --> with the next section followed by the sentinel again. Repeat, one section per Edit.
   • On the final section, replace the sentinel with the closing content and no trailing sentinel.
5. If writing still fails, surface the actual error in your return message. Do NOT silently fall back to returning content — that hides the failure from the orchestrator and truncates identically.