jcosxgb/graphe

Graphe — One Question, Run as a Graph

Turn one consequential question or proposed workflow into a staged evidence graph:

PLAN → PARALLEL LANES → SKEPTIC → MERGE → HUMAN GATE

This skill is explicitly invoked with:

/graphe <question or workflow>

When to Use

Use /graphe when the user explicitly wants a consequential question, decision, investigation, or proposed workflow decomposed into independent evidence lanes, challenged by a separate skeptic, and returned to a human decision gate. It is especially useful for market validation, technical choices, operational design, and decisions where weak evidence could cause wasted work. Do not activate it implicitly for ordinary questions; the slash command is the opt-in.

An invocation is deliberate opt-in to multi-agent work. Do not downgrade it to an ordinary single-agent answer merely because the question looks simple.

Design principles

• Define the final outcome before drawing the jobs.
• Treat the graph as jobs connected by arrows; the arrows encode real dependencies, and the shared notes/results are the state.
• Build the smallest graph that materially improves quality. More agents can create duplicated noise.
• Remove fake waiting: independent jobs run in parallel; dependent jobs wait.
• Separate workers from checkers. The researchers do not grade their own work.
• Stop when the answer is good enough for the stated decision criterion.
• Preserve useful state—plan, evidence, sources, skeptic verdicts, and decision—when the user requests a reusable paper trail or the workspace already has a research-artifact convention.
• The orchestration tool is secondary to the workflow. For a new recurring graph, prove the shape manually before adding a heavier framework or external automation.

Non-negotiable rules

1. Sequence is strict. Do not merge before the skeptic finishes. Do not execute the recommendation before the human gate.
2. Research lanes are read-only. They may inspect sources, files, systems, and public information, but must not publish, send, purchase, delete, deploy, modify production, or contact people.
3. Evidence is claim-level. Every material factual claim needs a source URL/path, source type, and confidence. “The subagent said so” is not evidence.
4. Primary sources win. Prefer official docs, first-party data, source code, contracts, direct customer evidence, or original records. Label secondary evidence and inference.
5. The skeptic is a separate job. It independently attacks claims, checks original sources, finds contradictions, and marks each claim keep, qualify, or reject.
6. Only survivors merge. Rejected claims cannot appear as facts in the final recommendation.
7. The human chooses the next move. Use the clarify tool for the gate. Never silently choose or begin an option.
8. No fake parallelism. Use one batched delegate_task(tasks=[...]) call for independent lanes. Do not make sequential single-child calls for parallel lanes.
9. Respect Hermes async delegation. After a batch is dispatched, do not poll or claim completion. Research results re-enter the conversation when all lanes finish; then launch the skeptic.
10. Keep the output decision-sized. The merge is a one-page recommendation, not a dump of every lane report.

Stage 0 — Parse the invocation

Treat the text after /graphe as the question. Optional mode words may be supplied:

• fast: 2 lanes, narrow evidence pass.
• standard: 3 lanes; default.
• deep: 3 lanes with broader source coverage and explicit follow-up gaps.

If no question is supplied, ask one open-ended clarification: “What question or workflow should I run as a graph?” Do not start research without a target.

Stage 1 — PLAN

The parent agent owns planning. Before delegating, produce a compact graph plan with:

• Decision/question — one sentence.
• Output criterion — what a useful answer must decide or enable.
• Constraints — time, market, jurisdiction, budget, repo/system boundaries, and prohibited side effects.
• Lanes — 2 or 3 orthogonal research jobs, each with a clear question and stopping criterion.
• Gate — state that execution waits for the human choice.

Choose lanes for the domain rather than blindly reusing labels.

Default lane patterns

For market/product/business questions, prefer:

1. Customer pain / current behavior — how the target user handles the problem today; direct evidence, workarounds, urgency, and willingness to change.
2. Competitors / alternatives / economics — who already solves it, substitutes, positioning, pricing, switching costs, and failure modes.
3. Distribution / execution / constraints — how the audience is actually reached, operational feasibility, legal/security constraints, and cost to test.

For general research or technical decisions, prefer:

1. Ground truth / current state — primary facts, requirements, and system behavior.
2. Alternatives / counterevidence — competing approaches, disconfirming evidence, and trade-offs.
3. Execution / risk / verification — implementation path, dependencies, failure modes, and how to test safely.

For implementation workflows, keep all lanes read-only until the gate. Parallel agents may inspect different areas, but must not edit the same checkout or create external side effects.

Avoid redundant lanes. If two lanes would search the same sources for the same claims, redesign them.

Stage 2 — RESEARCH IN PARALLEL

Call delegate_task once with a batch of 2–3 leaf tasks. Give every child the full question, shared constraints, its lane mission, the evidence contract below, and the required output language.

Use a forgiving per-task output_schema requiring only fields the parent will read:

{
  "type": "object",
  "required": ["lane", "bottom_line", "claims", "gaps"],
  "properties": {
    "lane": {"type": "string"},
    "bottom_line": {"type": "string"},
    "claims": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["id", "claim", "evidence", "source", "locator", "source_type", "confidence"],
        "properties": {
          "id": {"type": "string"},
          "claim": {"type": "string"},
          "evidence": {"type": "string"},
          "source": {"type": "string"},
          "locator": {"type": "string"},
          "observed_or_published_at": {"type": "string"},
          "source_type": {"type": "string"},
          "confidence": {"type": "string"},
          "assumptions": {"type": "array"},
          "caveat": {"type": "string"}
        }
      }
    },
    "contradictions": {"type": "array"},
    "gaps": {"type": "array"},
    "candidate_next_moves": {"type": "array"}
  }
}

Lane evidence contract

Each lane must:

• Investigate independently; do not coordinate with sibling lanes.
• Use current, original sources where accessible.
• Cite a URL, file path with line/page reference, or direct record identifier for every material claim.
• Assign stable claim IDs and include a quote, page, line, section, timestamp, or other locator when available.
• Separate observed fact, reported claim, calculation, and inference.
• Include dates for time-sensitive evidence.
• Report contradictory evidence and unknowns, not hide them.
• If context is missing, report the blocker or clearly label an assumption; children cannot ask clarification and must not guess.
• Stop when its stated stopping criterion is met or when additional searching has sharply diminishing returns.
• Make no external changes.

After the dispatch tool confirms the batch is running, briefly state which lanes are active. Do not fabricate their results and do not poll.

Stage 3 — SKEPTIC

When the consolidated lane results re-enter the conversation, normalize them into a claim/evidence matrix keyed by stable claim ID, then launch one new leaf delegate_task as the skeptic. Supply the original question, constraints, normalized matrix, and all lane outputs.

The skeptic must:

1. Attack the highest-impact decision-critical claims first.
2. Open/check the cited original source when accessible; a citation string alone is insufficient.
3. Test source quality, recency, relevance, sample bias, causal leaps, hidden assumptions, arithmetic, source dependence, and circular corroboration.
4. Search specifically for disconfirming evidence and contradictions across lanes.
5. Mark each claim keep, qualify, or reject, give a reason, and label the defect fatal, material, or minor when applicable.
6. Distinguish factual errors from preference disagreements.
7. Identify what evidence would change the decision and the smallest additional check that could resolve each material objection.
8. Recommend no more than three low-cost next moves that resolve the biggest uncertainties.
9. Perform no side effects.

Use an output schema requiring:

{
  "type": "object",
  "required": ["claim_verdicts", "contradictions", "decision_risks", "best_next_tests"],
  "properties": {
    "claim_verdicts": {"type": "array"},
    "contradictions": {"type": "array"},
    "decision_risks": {"type": "array"},
    "best_next_tests": {"type": "array"}
  }
}

After dispatching the skeptic, state that the evidence attack is running. Do not merge early and do not poll.

Stage 4 — MERGE

When the skeptic result returns, the parent agent creates a one-page recommendation using only keep and clearly qualified qualify claims. Re-open any source needed to resolve a material ambiguity; subagent summaries are not proof of external side effects or live system state.

Use this exact structure:

# Recommendation

**Decision:** <one sentence>
**Confidence:** <low / medium / high, with one-line reason>

## Why
- <surviving claim + citation>
- <surviving claim + citation>
- <surviving claim + citation>

## What did not survive
- <rejected or materially weakened claim + reason>

## Key risks and unknowns
- <risk/unknown>

## Best next moves
1. <smallest test that reduces the largest uncertainty>
2. <second option>
3. <third option, only if useful>
4. Pass — take no action now

Keep it to roughly one rendered page. Link or cite sources inline. Put detailed lane material in an appendix only if the user asks.

Stage 5 — HUMAN GATE

Immediately after the one-page merge, call clarify in single-select mode with no more than four choices:

• Up to three concrete next moves derived from the evidence.
• Always include Pass — take no action now.

Put each option only in the choices array; do not duplicate the choices in the question prose. Ask: “Which next move do you want to authorize?”

Do not execute any option until the user's selection arrives. The /graphe invocation itself is never approval for a side effect. After selection:

• Restate the selected next move and authorized analytical scope in one sentence.
• If the move would send a message, publish, purchase, change an account, deploy, delete a file, mutate an API, or cause another external side effect, present the exact target/account/workspace, proposed payload/command/change, expected cost and audience, reversibility/rollback plan, duplicate-prevention strategy, verification method, and unresolved risks before execution; obtain any additional approval ordinary safety rules require.
• Execute only the authorized move.
• Apply ordinary safety/approval rules for sends, purchases, deployments, destructive actions, secrets, or production changes.
• Read back or fetch the resulting object and report only independently verified effects.

Failure and fallback behavior

• A lane fails: Retry once only if the failure is transient. Otherwise continue with the remaining lanes and prominently lower confidence.
• Sources are inaccessible: Report the access failure; never replace missing evidence with plausible prose.
• Lanes conflict: Preserve the conflict through the skeptic stage. Do not average incompatible claims.
• Delegation unavailable: Say that the requested multi-agent graph cannot run as designed. Offer a clearly labeled single-agent fallback; do not silently substitute it.
• Question changes mid-run: Stop the old graph, restate the revised decision, and re-plan. Do not splice unrelated lane results into the new question.
• Unsafe or disallowed request: Normal safety rules override the graph. Decline or narrow the unsafe portion while preserving safe analysis.

Quality checklist

Before opening the human gate, confirm:

• The parent produced an explicit plan.
• 2–3 independent lanes ran in one parallel batch.
• Every material claim has traceable evidence.
• A separate skeptic attacked the evidence.
• Rejected claims were excluded from the recommendation.
• The merge is concise and decision-oriented.
• No external side effect occurred before the gate.
• The human is offered concrete choices including Pass.