feat(voyage)!: bulk content rewrite ultra -> voyage/trek prose [skip-docs]

Sed-pipeline (16 patterns, longest-match-first) sweeper residuelle ultra*-treff
i prose, command-narrativ, agent-prompts, hook-kommentarer, doc-prosa.

Pipeline-utvidelser fra V4-prompten:
- BSD-syntax [[:<:]]ultra[[:>:]] istedenfor \bultra\b (BSD sed mangler \b)
- 6 compound-patterns for ultraplan/ultraexecute/ultraresearch/ultrabrief/
  ultrareview/ultracontinue uten -local-suffiks
- ultra*-stats glob -> trek*-stats glob
- Linje-eksklusjon redusert til ultra-cc-architect (Q8); session-state-
  eksklusjonen var over-protektiv
- File-eksklusjon utvidet til settings.json, package.json, plugin.json,
  hele .claude/-treet (gitignored + V5-territorium)

Q8-undantak holdt: architecture-discovery.mjs + project-discovery.mjs urort.
Filnavn-konvensjon holdt: .session-state.local.json + *.local.* preservert.

Manuell narrative-fix: tests/lib/agent-frontmatter.test.mjs linje 10
mangled "/ultra*-local" til "/voyage*-local" (ingen slik kommando finnes);
korrigert til "/trek*".

Residualer utenfor scope (V5 handterer): package.json + .claude-plugin/
plugin.json (Step 12-14 versjons-bump). .claude/* er gitignored
spec-historikk med tilsiktet BEFORE/AFTER-narrativ.

Part of voyage-rebrand session 3 (Wave 4 / Step 10).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen 2026-05-05 15:08:20 +02:00
commit 14ecda886c
81 changed files with 672 additions and 672 deletions

View file

@ -5,11 +5,11 @@ description: |
tech stack, patterns, anti-patterns, and key abstractions.
<example>
Context: Ultraplan exploration phase needs architecture overview
user: "/ultraplan-local Add authentication to the API"
Context: Voyage exploration phase needs architecture overview
user: "/trekplan Add authentication to the API"
assistant: "Launching architecture-mapper to analyze codebase structure and patterns."
<commentary>
Phase 5 of ultraplan triggers this agent for every codebase size.
Phase 5 of trekplan triggers this agent for every codebase size.
</commentary>
</example>

View file

@ -1,7 +1,7 @@
---
name: brief-conformance-reviewer
description: |
Adversarial reviewer for /ultrareview-local. Compares delivered code
Adversarial reviewer for /trekreview. Compares delivered code
against the task brief — every Success Criterion must trace to delivered
code, every Non-Goal must remain unbuilt. Emits findings with rule_keys
from the canonical RULE_CATALOGUE. Never praises.
@ -44,7 +44,7 @@ You will receive a prompt containing:
changed files with per-file content excerpts when the diff is too
large).
- **Triage map**`{file → deep-review|summary-only|skip}` from the
/ultrareview-local triage gate. Respect `skip` decisions; do NOT flag
/trekreview triage gate. Respect `skip` decisions; do NOT flag
skipped files unless the skip itself is wrong (then emit
`COVERAGE_SILENT_SKIP`).
- **Rule catalogue** — the 12-key catalogue in
@ -79,7 +79,7 @@ context is needed) and classify coverage:
| **Broken** | Code claims to implement the criterion but the verification fails or is structurally wrong | `BROKEN_SUCCESS_CRITERION` (BLOCKER) |
Cite the criterion text in `brief_ref` (e.g., `SC3 — "review.md is
parseable as input to /ultraplan-local"`).
parseable as input to /trekplan"`).
### 3. Trace each Non-Goal to delivered code

View file

@ -7,8 +7,8 @@ description: |
exploration with a flawed brief.
<example>
Context: Ultraplan runs brief review before exploration
user: "/ultraplan-local --project .claude/projects/2026-04-18-notifications"
Context: Voyage runs brief review before exploration
user: "/trekplan --project .claude/projects/2026-04-18-notifications"
assistant: "Reviewing brief quality before launching exploration agents."
<commentary>
Orchestrator Phase 1b triggers this agent after the brief is available.
@ -35,8 +35,8 @@ missing, vague, or contradictory.
## Input
You receive the path to a brief file (ultrabrief v2.0 format, produced by
`/ultrabrief-local`). Read it and evaluate its quality across five dimensions.
You receive the path to a brief file (trekbrief v2.0 format, produced by
`/trekbrief`). Read it and evaluate its quality across five dimensions.
A brief has these sections (see template for full structure):
- `## Intent` — why the work matters (load-bearing)
@ -115,18 +115,18 @@ Flag as **unclear scope** if:
### 5. Research Plan validity (NEW in v2.0)
The `## Research Plan` section declares topics that must be answered before
`/ultraplan-local` can produce a high-confidence plan. Validate:
`/trekplan` can produce a high-confidence plan. Validate:
**Per topic:**
- **Research question:** phrased as a question, ends in `?`, answerable by
`/ultraresearch-local` (not "figure out the architecture" but "what are
`/trekresearch` (not "figure out the architecture" but "what are
the tradeoffs between library X and library Y for our use case?")
- **Required for plan steps:** names specific kinds of steps that consume
this answer (e.g., "migration strategy", "library selection", "threat model")
- **Confidence needed:** one of `high`, `medium`, `low`
- **Estimated cost:** one of `quick`, `standard`, `deep`
- **Scope hint:** one of `local`, `external`, `both`
- **Suggested invocation:** copy-paste-ready `/ultraresearch-local` command
- **Suggested invocation:** copy-paste-ready `/trekresearch` command
**Cross-check with frontmatter:**
- `research_topics: N` matches the actual count of `### Topic` headings
@ -165,7 +165,7 @@ Rate each dimension on two parallel scales:
- **1** — section is effectively missing or contradictory (maps to Fail)
Use both. The verbal rating drives the human-readable verdict. The numeric
score drives callers (such as `/ultrabrief-local` Phase 4) that use the
score drives callers (such as `/trekbrief` Phase 4) that use the
review as a quality gate and need per-dimension granularity.
## Output format
@ -174,7 +174,7 @@ Produce **two artifacts in this order**:
1. A prose report (for humans and for `planning-orchestrator` Phase 1b).
2. A final fenced `json` block with per-dimension numeric scores (for callers
that gate on machine-readable output, such as `/ultrabrief-local` Phase 4).
that gate on machine-readable output, such as `/trekbrief` Phase 4).
The JSON block MUST be the last fenced block in your output so parsers can
find it by reading the last `json` code fence.
@ -202,7 +202,7 @@ find it by reading the last `json` code fence.
- **Suggestion:** {how to fix it}
### Suggested additions
{Questions that should have been asked during the ultrabrief interview, or
{Questions that should have been asked during the trekbrief interview, or
information that would strengthen the brief. List only if actionable.}
### Verdict

View file

@ -1,7 +1,7 @@
---
name: code-correctness-reviewer
description: |
Adversarial reviewer for /ultrareview-local. Finds real bugs in
Adversarial reviewer for /trekreview. Finds real bugs in
delivered code across 7 dimensions: error handling, fragile assumptions,
cross-file regressions, test coverage gaps, placeholder code, security
surface, hidden dependencies. Cites file:line for every finding. Never
@ -41,7 +41,7 @@ problems — every claim is anchored to quoted code.
You will receive a prompt containing:
- **Diff text** — unified diff of the changes under review.
- **Triage map**`{file → deep-review|summary-only|skip}` from the
/ultrareview-local triage gate. Respect `skip` decisions; only flag
/trekreview triage gate. Respect `skip` decisions; only flag
skipped files when the skip itself is wrong (then emit
`COVERAGE_SILENT_SKIP`). Files marked `summary-only` get a structural
pass — declared signatures, exports, top-level wiring — but no deep

View file

@ -6,8 +6,8 @@ description: |
and what developers actually encounter when using a technology.
<example>
Context: ultraresearch-local needs real-world experience data on a database migration
user: "/ultraresearch-local What's the real-world experience with migrating from MongoDB to PostgreSQL?"
Context: trekresearch needs real-world experience data on a database migration
user: "/trekresearch What's the real-world experience with migrating from MongoDB to PostgreSQL?"
assistant: "Launching community-researcher to find migration stories, GitHub discussions, and community experience reports."
<commentary>
Official docs won't cover migration regrets or production war stories. community-researcher
@ -16,8 +16,8 @@ description: |
</example>
<example>
Context: ultraresearch-local is building a technology comparison
user: "/ultraresearch-local Research community sentiment around adopting SvelteKit vs Next.js"
Context: trekresearch is building a technology comparison
user: "/trekresearch Research community sentiment around adopting SvelteKit vs Next.js"
assistant: "I'll use community-researcher to find discussions, blog posts, and community reports on both frameworks."
<commentary>
Framework comparisons live in community discourse, not official docs. community-researcher

View file

@ -6,8 +6,8 @@ description: |
answer might be wrong.
<example>
Context: ultraresearch-local has found evidence favoring a technology and needs the other side
user: "/ultraresearch-local We're leaning toward adopting Kafka for our event streaming needs"
Context: trekresearch has found evidence favoring a technology and needs the other side
user: "/trekresearch We're leaning toward adopting Kafka for our event streaming needs"
assistant: "Launching contrarian-researcher to find the strongest arguments against Kafka and what alternatives might serve better."
<commentary>
The research equivalent of plan-critic. When one option is emerging as the answer,
@ -16,8 +16,8 @@ description: |
</example>
<example>
Context: ultraresearch-local is comparing options and needs the downsides of the leading candidate
user: "/ultraresearch-local Compare Redis vs Memcached — initial research favors Redis"
Context: trekresearch is comparing options and needs the downsides of the leading candidate
user: "/trekresearch Compare Redis vs Memcached — initial research favors Redis"
assistant: "I'll use contrarian-researcher to find the strongest case against Redis and scenarios where Memcached wins."
<commentary>
Contrarian-researcher finds the downsides of the leading option — not to be negative,

View file

@ -7,11 +7,11 @@ description: |
documentation patterns. Uses concrete examples from the codebase.
<example>
Context: Ultraplan exploration phase for a medium+ codebase
user: "/ultraplan-local Add authentication to the API"
Context: Voyage exploration phase for a medium+ codebase
user: "/trekplan Add authentication to the API"
assistant: "Launching convention-scanner to discover coding patterns."
<commentary>
Phase 5 of ultraplan triggers this agent for medium+ codebases (50+ files).
Phase 5 of trekplan triggers this agent for medium+ codebases (50+ files).
</commentary>
</example>

View file

@ -5,11 +5,11 @@ description: |
how modules connect and what side effects they produce.
<example>
Context: Ultraplan needs to understand module relationships for a task
user: "/ultraplan-local Refactor the payment processing pipeline"
Context: Voyage needs to understand module relationships for a task
user: "/trekplan Refactor the payment processing pipeline"
assistant: "Launching dependency-tracer to map module connections and data flow."
<commentary>
Phase 5 of ultraplan triggers this agent to trace dependencies relevant to the task.
Phase 5 of trekplan triggers this agent to trace dependencies relevant to the task.
</commentary>
</example>

View file

@ -5,8 +5,8 @@ description: |
documentation, RFCs, vendor specifications, or Microsoft/Azure documentation.
<example>
Context: ultraresearch-local needs to ground an OAuth2 implementation in official specs
user: "/ultraresearch-local Research OAuth2 PKCE flow for our SPA"
Context: trekresearch needs to ground an OAuth2 implementation in official specs
user: "/trekresearch Research OAuth2 PKCE flow for our SPA"
assistant: "Launching docs-researcher to find the official RFC and vendor documentation for OAuth2 PKCE."
<commentary>
docs-researcher targets authoritative sources — RFCs, specs, official vendor docs —
@ -15,8 +15,8 @@ description: |
</example>
<example>
Context: ultraresearch-local encounters an Azure-specific technology
user: "/ultraresearch-local How should we configure Azure Service Bus for our event pipeline?"
Context: trekresearch encounters an Azure-specific technology
user: "/trekresearch How should we configure Azure Service Bus for our event pipeline?"
assistant: "I'll use docs-researcher with Microsoft Learn to get authoritative Azure Service Bus documentation."
<commentary>
Microsoft/Azure technologies have dedicated MCP tools (microsoft_docs_search,

View file

@ -7,8 +7,8 @@ description: |
that can confirm or challenge findings from other agents.
<example>
Context: ultraresearch launches gemini-bridge for an independent second opinion on a technology choice
user: "/ultraplan-local Should we use Kafka or NATS for our event streaming layer?"
Context: trekresearch launches gemini-bridge for an independent second opinion on a technology choice
user: "/trekplan Should we use Kafka or NATS for our event streaming layer?"
assistant: "Launching gemini-bridge for an independent second opinion on Kafka vs NATS."
<commentary>
Technology choice with significant architectural implications triggers gemini-bridge

View file

@ -5,11 +5,11 @@ description: |
code ownership, hot files, and active branches relevant to the task.
<example>
Context: Ultraplan exploration phase needs git context
user: "/ultraplan-local Refactor the database layer"
Context: Voyage exploration phase needs git context
user: "/trekplan Refactor the database layer"
assistant: "Launching git-historian to check recent changes and ownership of DB code."
<commentary>
Phase 2 of ultraplan triggers this agent for every codebase size.
Phase 2 of trekplan triggers this agent for every codebase size.
</commentary>
</example>

View file

@ -5,11 +5,11 @@ description: |
problems, never praises.
<example>
Context: Ultraplan adversarial review phase
user: "/ultraplan-local Implement WebSocket real-time updates"
Context: Voyage adversarial review phase
user: "/trekplan Implement WebSocket real-time updates"
assistant: "Launching plan-critic to stress-test the implementation plan."
<commentary>
Phase 9 of ultraplan triggers this agent to review the generated plan.
Phase 9 of trekplan triggers this agent to review the generated plan.
</commentary>
</example>
@ -168,7 +168,7 @@ cannot be decomposed into headless sessions).
### 10. Manifest quality (hard gate)
Manifests are the objective completion predicate. ultraexecute-local uses
Manifests are the objective completion predicate. trekexecute uses
them to determine whether a step is actually done — not just whether the
Verify command returned 0. A plan without valid manifests cannot drive
deterministic execution.
@ -199,7 +199,7 @@ Check plans with `plan_version: 1.7` (or later) against these rules:
**Backward compat:** For plans without `plan_version: 1.7` (legacy), emit
a single advisory note ("Plan is v1.6 legacy format — manifests will be
synthesized by ultraexecute with reduced audit precision") and skip this
synthesized by trekexecute with reduced audit precision") and skip this
dimension's scoring.
## Rating system

View file

@ -2,12 +2,12 @@
name: planning-orchestrator
description: |
Inline reference (v2.4.0) — documents the planning workflow that
/ultraplan-local executes in main context. This file is NOT spawned as a
/trekplan executes in main context. This file is NOT spawned as a
sub-agent anymore. The Claude Code harness does not expose the Agent tool
to sub-agents, so an orchestrator launched with run_in_background: true
cannot spawn the exploration swarm (architecture-mapper, task-finder,
plan-critic, etc.) and would degrade to single-context reasoning. The
/ultraplan-local command now orchestrates the phases below directly in the
/trekplan command now orchestrates the phases below directly in the
main session.
model: opus
color: cyan
@ -23,12 +23,12 @@ tools: ["Agent", "Read", "Glob", "Grep", "Write", "Edit", "Bash", "TaskCreate",
Orchestrator Phase 5 = Command Phase 8 (Deep planning)
Orchestrator Phase 6 = Command Phase 9 (Adversarial review)
Orchestrator Phase 7 = Command Phase 10 (Completion)
As of v2.4.0, /ultraplan-local runs these phases inline in main context
As of v2.4.0, /trekplan runs these phases inline in main context
instead of spawning this agent. Keep this file as the canonical
reference for what those phases do. -->
This document is the canonical workflow description for the ultraplan
pipeline as of v2.4.0. The `/ultraplan-local` command reads it as reference
This document is the canonical workflow description for the trekplan
pipeline as of v2.4.0. The `/trekplan` command reads it as reference
and executes the phases below **inline in the main command context**. It is
no longer spawned as a background sub-agent — that mode silently lost the
Agent tool and degraded the exploration swarm to single-context reasoning.
@ -40,9 +40,9 @@ tool, collects their results, synthesizes the plan, and writes it to disk.
## Input
You will receive a prompt containing:
- **Brief file path** — the task brief (produced by `/ultrabrief-local`)
- **Project dir** (optional) — path to an ultrabrief project folder when the user
invoked `/ultraplan-local --project`. If set, the plan destination is
- **Brief file path** — the task brief (produced by `/trekbrief`)
- **Project dir** (optional) — path to an trekbrief project folder when the user
invoked `/trekplan --project`. If set, the plan destination is
`{project_dir}/plan.md` and any `{project_dir}/research/*.md` files are
pre-existing research briefs to read.
- **Task description** — one-line summary (matches the brief's frontmatter `task`)
@ -219,14 +219,14 @@ Write a comprehensive implementation plan including:
- **Estimated Scope** — file counts and complexity
**Plan-version header:** Include `plan_version: 1.7` in the metadata line below
the title. This signals to ultraexecute-local that the plan includes per-step
the title. This signals to trekexecute that the plan includes per-step
verification manifests and enables strict audit mode. Plans without this
marker are treated as legacy v1.6 with synthesized minimal manifests.
### Mandatory step format — copy this exactly
The Implementation Plan section MUST contain numbered steps using the EXACT
format shown below. The executor (`ultraexecute-local`) parses plans with
format shown below. The executor (`trekexecute`) parses plans with
strict regex matching. Any deviation breaks parsing and forces the user to
re-run planning.
@ -283,7 +283,7 @@ not skip fields. Do not nest steps under sub-headings.
Every implementation step MUST include a `Manifest:` block as its last field,
after Checkpoint. The manifest is the objective completion predicate — the
machine-checkable contract that ultraexecute-local will verify after the
machine-checkable contract that trekexecute will verify after the
Verify command passes. A step cannot be marked passed if its manifest does
not verify.
@ -427,7 +427,7 @@ After both complete:
- Address all blockers and major issues by revising the plan
- **Manifest quality is a hard gate:** any manifest-related `major` finding
must be fixed before the plan can be handed off. This enforces the
principle that ultraexecute-local relies on the plan being
principle that trekexecute relies on the plan being
machine-checkable — a plan without verifiable manifests cannot drive
deterministic execution.
- Add a "Revisions" note at the bottom documenting changes
@ -437,7 +437,7 @@ After both complete:
When done, your output message should contain:
```
## Ultraplan Complete (Background)
## Voyage Complete (Background)
**Task:** {task}
**Plan:** {plan path}

View file

@ -2,11 +2,11 @@
name: research-orchestrator
description: |
Inline reference (v2.4.0) — documents the research workflow that
/ultraresearch-local executes in main context. This file is NOT spawned as
/trekresearch executes in main context. This file is NOT spawned as
a sub-agent anymore. The Claude Code harness does not expose the Agent tool
to sub-agents, so an orchestrator launched with run_in_background: true
cannot spawn the research swarm and would degrade to single-context
reasoning. The /ultraresearch-local command now orchestrates the phases
reasoning. The /trekresearch command now orchestrates the phases
below directly in the main session.
model: opus
color: cyan
@ -20,12 +20,12 @@ tools: ["Agent", "Read", "Glob", "Grep", "Write", "Edit", "Bash"]
Orchestrator Phase 4 = Command Phase 7 (Triangulation)
Orchestrator Phase 5 = Command Phase 8 (Synthesis + write brief)
Orchestrator Phase 6 = Command Phase 9 (Completion)
As of v2.4.0, /ultraresearch-local runs these phases inline in main
As of v2.4.0, /trekresearch runs these phases inline in main
context instead of spawning this agent. Keep this file as the canonical
reference for what those phases do. -->
This document is the canonical workflow description for the ultraresearch
pipeline as of v2.4.0. The `/ultraresearch-local` command reads it as
This document is the canonical workflow description for the trekresearch
pipeline as of v2.4.0. The `/trekresearch` command reads it as
reference and executes the phases below **inline in the main command
context**. It is no longer spawned as a background sub-agent — that mode
silently lost the Agent tool and degraded the swarm to single-context
@ -140,7 +140,7 @@ If no gaps exist, skip: "Initial research sufficient — no follow-ups needed."
### Phase 4 — Triangulation
This is the KEY phase that makes ultraresearch more than aggregation.
This is the KEY phase that makes trekresearch more than aggregation.
For each dimension of the research question:
@ -208,7 +208,7 @@ When done, your output message should contain:
You can:
- Read the full brief at {brief path}
- Feed into planning: /ultraplan-local --research {brief path} <task>
- Feed into planning: /trekplan --research {brief path} <task>
- Ask follow-up questions
```

View file

@ -5,11 +5,11 @@ description: |
APIs, or libraries where official documentation and known issues should be checked.
<example>
Context: Ultraplan detects external technology in the task
user: "/ultraplan-local Integrate Stripe payment processing"
Context: Voyage detects external technology in the task
user: "/trekplan Integrate Stripe payment processing"
assistant: "Launching research-scout to find Stripe documentation and best practices."
<commentary>
Phase 5 of ultraplan conditionally triggers this agent when external tech is detected.
Phase 5 of trekplan conditionally triggers this agent when external tech is detected.
</commentary>
</example>

View file

@ -1,7 +1,7 @@
---
name: review-coordinator
description: |
Judge Agent for /ultrareview-local. Receives findings from independent
Judge Agent for /trekreview. Receives findings from independent
reviewers (brief-conformance-reviewer, code-correctness-reviewer) and
applies BOUNDED operations: deduplication, severity ranking, HubSpot
Judge filters, Cloudflare reasonableness filter, verdict computation.
@ -47,7 +47,7 @@ You will receive a prompt containing:
`brief-conformance-reviewer` and `code-correctness-reviewer` (in `quick`
mode, only the latter).
- **Triage map**`{file → deep-review|summary-only|skip, reason}` from
the /ultrareview-local triage gate.
the /trekreview triage gate.
- **Brief metadata**`task`, `slug`, `project_dir`, `brief_path` from
the brief frontmatter.
- **Scope SHA range**`scope_sha_start`, `scope_sha_end`,
@ -128,7 +128,7 @@ trailing JSON block AND the Executive Summary's first sentence.
## Output: review.md content
Produce the full review.md content as your output. The
/ultrareview-local command writes it verbatim to disk.
/trekreview command writes it verbatim to disk.
### Frontmatter (block-style YAML, NOT flow-style)
@ -171,7 +171,7 @@ prefix). Flow-style `findings: [a, b]` breaks the frontmatter parser.
8. `## Suppressed Findings` (optional) — one-line per finding dropped by
Pass 2 or Pass 3, with the reason.
9. `## Remediation Summary` — bullet count per severity + 1 sentence on
what /ultraplan-local will consume.
what /trekplan will consume.
Each Findings subsection uses the `### {finding-id-40-char-hex}` heading
followed by these fields:
@ -208,7 +208,7 @@ The LAST fenced block in the file is a `json` block:
```
The JSON `findings[].id` array MUST match the frontmatter `findings:`
list. The downstream consumer (/ultraplan-local with
list. The downstream consumer (/trekplan with
`--brief review.md`) reads the JSON for full content and the frontmatter
for the ID list.

View file

@ -2,13 +2,13 @@
name: review-orchestrator
description: |
Inline reference (v3.2.0) — documents the review workflow that
/ultrareview-local executes in main context. This file is NOT spawned
/trekreview executes in main context. This file is NOT spawned
as a sub-agent. The Claude Code harness does not expose the Agent tool
to sub-agents, so a background orchestrator launched with
run_in_background: true cannot spawn the reviewer swarm
(brief-conformance-reviewer, code-correctness-reviewer, review-coordinator)
and would degrade silently to single-context reasoning. The
/ultrareview-local command now orchestrates the phases below directly in
/trekreview command now orchestrates the phases below directly in
the main session.
model: opus
color: red
@ -24,12 +24,12 @@ tools: ["Agent", "Read", "Glob", "Grep", "Write", "Edit", "Bash", "TaskCreate",
Orchestrator Phase 6 = Command Phase 6 (Coordinator dedup + verdict)
Orchestrator Phase 7 = Command Phase 7 (Write review.md)
Orchestrator Phase 8 = Command Phase 8 (Validate + stats)
As of v3.2.0, /ultrareview-local runs these phases inline in main
As of v3.2.0, /trekreview runs these phases inline in main
context instead of spawning this agent. Keep this file as the canonical
reference for what those phases do. -->
This document is the canonical workflow description for the ultrareview
pipeline as of v3.2.0. The `/ultrareview-local` command reads it as
This document is the canonical workflow description for the trekreview
pipeline as of v3.2.0. The `/trekreview` command reads it as
reference and executes the phases below **inline in the main command
context**. It is not spawned as a background sub-agent — that mode would
silently lose the Agent tool and degrade the reviewer swarm to
@ -50,7 +50,7 @@ explicitly forbidden in v1.0 (Judge Agent pattern).
## Input
You will receive a prompt containing:
- **Project dir** — path to the ultraplan-local project folder (the brief and
- **Project dir** — path to the trekplan project folder (the brief and
optional `progress.json` live here; the review will be written to
`{project_dir}/review.md`).
- **Brief path**`{project_dir}/brief.md`. Read it; the brief is the
@ -77,7 +77,7 @@ Execute these phases in order. Do not skip phases.
Run the arg-parser via Bash:
```
node ${CLAUDE_PLUGIN_ROOT}/lib/parsers/arg-parser.mjs --command ultrareview "$@"
node ${CLAUDE_PLUGIN_ROOT}/lib/parsers/arg-parser.mjs --command trekreview "$@"
```
Pull the structured flags from its JSON output. Reject unknown flags. If
@ -94,7 +94,7 @@ node ${CLAUDE_PLUGIN_ROOT}/lib/validators/brief-validator.mjs --soft --json {bri
```
If `valid: false` with REQUIRED-field errors: stop, ask the user to
re-run `/ultrabrief-local` first.
re-run `/trekbrief` first.
### Phase 3 — Discover scope SHA range
@ -221,7 +221,7 @@ Append a stats line to `${CLAUDE_PLUGIN_DATA}/trekreview-stats.jsonl`:
a runnable sub-agent. Background mode silently degrades — the harness
does not expose the Agent tool to sub-agents, so the reviewer swarm
collapses to single-context reasoning. Always run review agents from
the main /ultrareview-local command context.
the main /trekreview command context.
- **Reviewers run independently.** No cross-feeding of findings. The
coordinator is the only place where reviewer outputs are combined.
- **Coordinator scope is bounded.** Dedup, severity ranking, reasonableness
@ -234,7 +234,7 @@ Append a stats line to `${CLAUDE_PLUGIN_DATA}/trekreview-stats.jsonl`:
the Coverage section, even if its treatment is `skip`. Hidden truncation
is COVERAGE_SILENT_SKIP (MAJOR).
- **Cost:** Use Sonnet for all sub-agents. The orchestrator (the
/ultrareview-local command itself) runs on Opus.
/trekreview command itself) runs on Opus.
- **Privacy:** Never log secrets, tokens, or credentials. Findings citing
files with secret-like content must redact the secret in the `detail`.
- **Honesty:** If the diff is trivially small or all-skip, say so. Do

View file

@ -5,11 +5,11 @@ description: |
technical debt that could affect an implementation task.
<example>
Context: Ultraplan exploration phase identifies potential risks
user: "/ultraplan-local Migrate database from PostgreSQL to MongoDB"
Context: Voyage exploration phase identifies potential risks
user: "/trekplan Migrate database from PostgreSQL to MongoDB"
assistant: "Launching risk-assessor to identify failure modes and edge cases for this migration."
<commentary>
Phase 5 of ultraplan triggers this agent to find risks before planning begins.
Phase 5 of trekplan triggers this agent to find risks before planning begins.
</commentary>
</example>

View file

@ -5,11 +5,11 @@ description: |
requirements — catches scope creep and scope gaps.
<example>
Context: Ultraplan adversarial review phase checks scope alignment
user: "/ultraplan-local Add caching to the API layer"
Context: Voyage adversarial review phase checks scope alignment
user: "/trekplan Add caching to the API layer"
assistant: "Launching scope-guardian to verify plan matches requirements."
<commentary>
Phase 9 of ultraplan triggers this agent alongside plan-critic.
Phase 9 of trekplan triggers this agent alongside plan-critic.
</commentary>
</example>

View file

@ -5,8 +5,8 @@ description: |
dependency, or library — CVEs, audit history, supply chain risks, and OWASP relevance.
<example>
Context: ultraresearch-local is evaluating whether a dependency is safe to adopt
user: "/ultraresearch-local Research whether we should trust the `node-fetch` library"
Context: trekresearch is evaluating whether a dependency is safe to adopt
user: "/trekresearch Research whether we should trust the `node-fetch` library"
assistant: "Launching security-researcher to check CVE history, supply chain risk, and audit reports for node-fetch."
<commentary>
Before adopting a dependency, security-researcher checks the attack surface: known
@ -15,8 +15,8 @@ description: |
</example>
<example>
Context: ultraresearch-local is assessing the security posture of a technology choice
user: "/ultraresearch-local Evaluate the security implications of using JWT for session management"
Context: trekresearch is assessing the security posture of a technology choice
user: "/trekresearch Evaluate the security implications of using JWT for session management"
assistant: "I'll use security-researcher to check known JWT vulnerabilities, OWASP guidance, and community security reports."
<commentary>
Technology choices have security tradeoffs. security-researcher maps the threat surface

View file

@ -1,13 +1,13 @@
---
name: session-decomposer
description: |
Use this agent to decompose an ultraplan into self-contained headless sessions.
Use this agent to decompose an trekplan into self-contained headless sessions.
Reads a plan file, analyzes step dependencies, groups steps into sessions,
identifies parallelism, and generates session specs + dependency graph + launch script.
<example>
Context: User wants to run a plan across multiple headless sessions
user: "/ultraplan-local --decompose .claude/plans/ultraplan-2026-04-06-auth-refactor.md"
user: "/trekplan --decompose .claude/plans/trekplan-2026-04-06-auth-refactor.md"
assistant: "Launching session-decomposer to split the plan into headless sessions."
<commentary>
The --decompose flag triggers this agent to analyze and split the plan.
@ -27,15 +27,15 @@ color: green
tools: ["Read", "Glob", "Grep", "Write"]
---
You are a session decomposition specialist. You take a complete ultraplan implementation
You are a session decomposition specialist. You take a complete trekplan implementation
plan and split it into self-contained sessions optimized for headless execution.
## Input
You will receive:
- **Plan file path** — the ultraplan to decompose
- **Plan file path** — the trekplan to decompose
- **Plugin root** — for template access
- **Output directory** — where to write session specs (default: `.claude/ultraplan-sessions/`)
- **Output directory** — where to write session specs (default: `.claude/trekplan-sessions/`)
Read the plan file first. It contains the implementation steps, file paths, and
verification criteria you need.

View file

@ -6,11 +6,11 @@ description: |
structured code discovery.
<example>
Context: Ultraplan exploration phase needs task-relevant code
user: "/ultraplan-local Add authentication to the API"
Context: Voyage exploration phase needs task-relevant code
user: "/trekplan Add authentication to the API"
assistant: "Launching task-finder to locate auth-related code, endpoints, and models."
<commentary>
Phase 2 of ultraplan triggers this agent for every codebase size.
Phase 2 of trekplan triggers this agent for every codebase size.
</commentary>
</example>

View file

@ -5,11 +5,11 @@ description: |
discovers existing patterns, maps coverage gaps, and recommends what tests to write.
<example>
Context: Ultraplan exploration phase for medium+ codebase
user: "/ultraplan-local Add rate limiting to the API"
Context: Voyage exploration phase for medium+ codebase
user: "/trekplan Add rate limiting to the API"
assistant: "Launching test-strategist to analyze existing test patterns and design test coverage."
<commentary>
Phase 5 of ultraplan triggers this agent for medium and large codebases.
Phase 5 of trekplan triggers this agent for medium and large codebases.
</commentary>
</example>