ktg-plugin-marketplace/plugins/ultraplan-local/templates/research-brief-template.md
Kjell Tore Guttormsen 0508edff15 feat(voyage)!: rename type discriminators across validators + fixtures [skip-docs]
- brief-validator: BRIEF_TYPE_VALUES ['ultrabrief','ultrareview'] -> ['trekbrief','trekreview'] + dependent branches
- research-validator: 'ultraresearch-brief' -> 'trekresearch-brief'
- review-validator: 'ultrareview' -> 'trekreview'
- 3 templates frontmatter type:
- 4 synthetic fixtures: ultraplan-synthetic/ultrareview-synthetic -> trek* (frontmatter only; bodies untouched, Jaccard floor preserved)
- 2 trekreview fixtures: type: trekreview
- 6 validator-test fixtures + asserts
- agents/review-coordinator.md frontmatter example

Atomic: validator + fixtures committed together — partial state would cause vacuous
test passes or hard validator rejection.

Part of voyage-rebrand session 2 (W3.3 / Step 5).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-05 14:40:25 +02:00

3.8 KiB

type created question confidence dimensions mcp_servers_used local_agents_used external_agents_used
trekresearch-brief
YYYY-MM-DD
{research question}
0.0-1.0
N
list
list
list

{Research Question Title}

Generated by ultraresearch-local v{version} on {YYYY-MM-DD}

Research Question

{The full research question as clarified during interview.}

Executive Summary

{3 sentences maximum. The answer, the confidence level, and the key caveat.}

Dimensions

Each dimension represents one facet of the research question, explored by both local and external agents. Confidence is rated per dimension.

{Dimension Name} -- Confidence: {high | medium | low | contradictory}

Local findings:

  • {Finding with source citation (file path or agent name)}

External findings:

  • {Finding with source citation (URL)}

Contradictions:

  • {If local and external disagree, explain both sides with evidence. Omit this sub-section if no contradictions exist for this dimension.}

Repeat for each dimension.

Local Context

Findings from codebase analysis agents. Omit sub-sections where no relevant findings exist.

Architecture

{Architecture patterns, tech stack, relevant components from architecture-mapper}

Dependencies

{Import chains, data flow, external integrations from dependency-tracer}

Conventions

{Coding patterns, naming, test conventions from convention-scanner}

History

{Recent changes, code ownership, hot files from git-historian}

External Knowledge

Findings from external research agents. Omit sub-sections where no relevant findings exist.

Best Practice

{Official documentation, recommended patterns from docs-researcher}

Alternatives

{Other approaches, competing solutions from community-researcher + contrarian-researcher}

Security

{CVEs, audit history, supply chain risks from security-researcher}

Known Issues

{Common pitfalls, gotchas, real-world problems from community-researcher}

Gemini Second Opinion

Independent research result from Gemini Deep Research. Provides a second perspective for triangulation. Omit this section if gemini-bridge was not used or was unavailable.

{Gemini findings reformatted into key findings, sources cited, and areas of agreement/disagreement with other agents.}

Synthesis

Cross-cutting insights that emerge from combining local and external knowledge. This is NOT a summary of the sections above. It is NEW insight from triangulation -- things that only become visible when local context meets external knowledge.

{Example: "The codebase uses pattern X (local), but best practice has shifted to pattern Y (external). However, our dependency on Z (local) makes a direct migration impractical -- a hybrid approach using Y for new code while maintaining X for existing modules is the pragmatic path."}

Open Questions

Things that remain unresolved after research. Each is a candidate for follow-up research or an assumption to carry forward.

  • {Question 1 -- why it remains open}
  • {Question 2 -- why it remains open}

Recommendation

If the research was decision-relevant, provide a concrete recommendation with reasoning. If the research was exploratory (understanding, not deciding), omit this section entirely.

{Recommendation with rationale, citing specific findings from above.}

Sources

# Source Type Quality Used in
1 {URL or codebase path} {official / community / codebase / gemini} {high / medium / low} {dimension name}

Quality assessment:

  • high — official documentation, verified codebase analysis, peer-reviewed
  • medium — reputable community source, well-maintained blog, established project
  • low — unverified, outdated (>1 year), single-source claim, opinion piece