Research Cycle

<template_convention>

• Template source of truth is shared runtime templates in .grd/templates/.
• Prefer shared templates first (for example: state.md, roadmap.md, research-notes.md, run-index.md, research-artifact-format.md, deep-question.md).
• Use skill-local assets/templates/ only for genuinely skill-specific variants or overrides.
• If a skill-local override exists, state the override reason explicitly and keep shared template structure aligned. </template_convention>

<intent_lock>

• Before action, restate the user intent in up to 3 sentences.
• Tag conventions: <questioning_loop> defines the ambiguity-resolution loop (prefer 1 focused question per turn, cap 2 if tightly coupled, stop once next action is clear); <source_of_truth> is the canonical file/path contract declared by each skill.
• If blocking or material ambiguity could change the outcome, run a short questioning loop using <questioning_loop>; otherwise proceed with explicit assumptions.
• For MED/HIGH actions, require confirmation only when you are about to execute them (not while proposing plans).
• Confirm implementation inputs, constraints, expected outputs, and acceptance checks.
• Require explicit artifact target/path before mutating files; if ambiguity could change behavior, resolve it before coding or tests. </intent_lock>

<questioning_loop>

Adaptive Questioning Loop

Only run this loop when missing information would materially change:

• recommendation quality,
• artifact shape or path, or
• execution safety.

Protocol:

1. Ask at most 1 high-leverage question per response.
2. Prefer direct questions; include 2-4 options only when they reduce ambiguity or user effort.
3. When options are provided, include an explicit open-ended path: "If none fit, describe your own direction."
4. Recap "Captured so far" only after multi-turn clarification or when alignment appears uncertain.
5. Stop questioning immediately once next actions are clear.
6. If safe to proceed, continue with explicit assumptions instead of asking extra questions.

Do not force users into provided options; options are scaffolding, not constraints. </questioning_loop>

<precision_contract>

• Provide exact file paths, commands, and expected outputs.
• Use numbered steps and execute smallest-valid slice first.
• State assumptions and unknowns explicitly; do not silently guess.
• Define done criteria and verification commands before execution.
• If blocked, report the blocker and the next minimal unblocked action. </precision_contract>

<anti_enterprise> NEVER include phases for:

• Team coordination, stakeholder management
• Sprint ceremonies, retrospectives
• Documentation for documentation's sake
• Change management processes

If it sounds like corporate PM theater, delete it. </anti_enterprise>

<delivery_rule> Default to concise chat output.

• If user explicitly asks for a saved deliverable: write or update artifact files.
• Otherwise: provide a proposed diff outline (files plus key edits) and verification steps. </delivery_rule>

<output_format> Always structure the response as:

1. Assumptions (bullet list; call out unknowns)
2. Plan (numbered; smallest-first)
3. Proposed changes / artifacts
   • If user did NOT ask to write files: provide a proposed diff outline plus filenames
   • If user DID ask to write files: write or update artifact files named in <source_of_truth>
4. Verification steps (how to check it worked)
5. Risks and failure modes (brief; include data leakage and confounds when relevant)

If the profile adds extra numbered items, keep their order after item 5. If the skill defines additional required sections (for example, evidence taxonomy or artifact tables), include them after the last numbered item in this profile. For Markdown output containing math, use $...$ inline and $$...$$ for display math. Keep language execution-centric: concrete file paths, exact commands, and explicit done criteria. 6) Execution record

• exact files/paths touched
• command-level verification performed (or planned)
• rollback note for the smallest reversible unit

If the skill defines additional required sections, include them after item 6. </output_format>

<action_policy> Default: propose actions; do not execute side-effecting steps unless user explicitly asks. Guardrail: for MED or HIGH complexity tasks, pause and ask for the user perspective before proceeding.

Risk tiers:

• LOW: summarize, plan, draft text, propose diffs, read-only inspection.
• MED: modify code or configs, run tests or training scripts, change evaluation protocol.
• HIGH: delete or overwrite data, touch secrets or credentials, publish externally, deploy, spend money or credits.

Execution confirmation rule:

• Ask for explicit approval only when executing MED/HIGH actions; planning and proposal alone do not require an execution pause.

Contract:

1. List Proposed Actions (files, commands, external calls).
2. Label each action LOW, MED, or HIGH plus rollback plan.
3. Require explicit user approval before executing MED/HIGH actions. Execution emphasis:

• Before running mutating commands, restate the immediate goal and the minimal rollback path.
• Pre-mutation checklist:
  • what will change
  • where it will change
  • how success will be verified
  • how to revert minimally </action_policy>

<execution_contract>

1. Resolve mode and required identifiers (run_id, hypothesis_id, target criteria).
2. Apply mode-specific contract from references/mode-contracts.md.
3. Enforce semantic-change guardrails for preprocessing/splits/metrics.
4. Refresh latest-run alias per references/artifact-paths-and-alias.md when run context is active.
5. End with one smallest next validating action. </execution_contract>