Thin orchestrator for discovery, intake routing, and evidence-first fact-finding. Routes to specialized modules and emits analysis-ready artifacts for /lp-do-analysis. For understanding-only briefings, use /lp-do-briefing.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Thin orchestrator for discovery, intake routing, and evidence-first fact-finding. Routes to specialized modules and emits analysis-ready artifacts for /lp-do-analysis. For understanding-only briefings, use /lp-do-briefing.
Fact Find Orchestrator
/lp-do-fact-find is the intake and routing layer. Keep this file thin.
This orchestrator does five things:
Discovery and selection (topic)
Sufficiency gate
Classification (track, deliverable)
Module routing (load only one relevant module, plus mixed-track add-on when needed)
Artifact persistence using shared templates + automatic critique
Do not embed long templates, long checklists, or API payload blocks here.
Global Invariants
Operating mode
FACT-FIND ONLY
Repo actions (allowed)
Read/search files and docs.
Run non-destructive commands (for example rg, targeted tests, targeted lint/typecheck) when needed for evidence.
Inspect targeted git history.
Prohibited actions
Code changes, refactors, migrations, or production data writes.
Destructive shell/git commands.
Analysis/planning/build execution (this skill ends at fact-find output).
Unknowns must include a concrete verification path.
Omit sections with no evidence, or collapse to a one-line Not investigated: <reason>.
Process-affecting work must capture the current process map area by area. A touched-file list is not enough when the change alters CI/deploy/release lanes, approvals, orchestration, lifecycle states, or multi-step operator flows.
Keep signal high:
max 10 key files/modules in primary evidence list
max 10 risks
max 8 open questions
Required Inputs
Minimum intake before investigation:
Concrete area anchor (feature/component/system)
At least one location anchor (path guess, route, endpoint, error/log, user flow)
Provisional deliverable family
If any item is missing, ask only the minimum follow-up questions needed to unblock.
Phase 0: Queue Check Gate
Load and follow: ../_shared/queue-check-gate.md (fact-find mode).
Phase 1: Discovery and Selection
Fast path (argument provided): If argument is a topic, proceed directly to sufficiency gate.
Discovery path (no argument): Scan docs/plans/ for directories with fact-find.md; show list; ask user to select or provide new topic.
Phase 2: Context Hydration
If a matching fact-find.md already exists at docs/plans/<feature-slug>/fact-find.md, read it and use existing findings and open questions as starting context. Otherwise, start fresh from the topic anchor.
Optional CASS Retrieval (Pilot, recommended)
Before deep investigation, run CASS retrieval for reusable prior evidence:
Retrieval is fail-open. If CASS is unavailable, continue with normal investigation.
Keep canonical evidence in the fact-find artifact itself (paths, tests, docs, call sites).
Do not treat retrieval snippets as proof without verifying source paths directly.
Access Declarations
Before the investigation begins, list every external data source, service, or system that will be needed to answer the questions in this fact-find. For each source:
Name the source and required access type.
Check memory/data-access.md (~/.claude/projects/<project-hash>/memory/data-access.md); if absent/unlisted, mark UNVERIFIED (do not block).
Record sources discovered mid-investigation under ## Access Declarations.
Follow schema: docs/plans/startup-loop-build-reflection-gate/task-01-schema-spec.md § 3. If no external dependencies, write None.
Phase 3: Sufficiency Gate
Do not start repository investigation until minimum intake is satisfied. If insufficient, ask targeted questions only, each tied to a decision it unlocks.
Use routing/deliverable-routing.yaml to map family/channel/subtype to canonical Deliverable-Type. Keep Deliverable-Type in canonical downstream format expected by /lp-do-plan and /lp-do-build. Execution skill IDs are canonicalized without leading slash (e.g., lp-do-build).
Hard branches:
If invocation includes --website-first-build-backlog, set Startup-Deliverable-Alias: website-first-build-backlog before routing.
If Startup-Deliverable-Alias: website-first-build-backlog, route immediately to the website-first-build module and skip generic business/code checklists that do not apply.
If Startup-Deliverable-Alias: website-upgrade-backlog, route immediately to the website-upgrade module and skip generic business/code checklists that do not apply.
If Startup-Deliverable-Alias: startup-loop-gap-fill, route immediately to the loop-gap module. Set Loop-Gap-Trigger from the argument (block/bottleneck/feedback) or ask one targeted question. Output path and outcome (briefing vs planning) are determined by the module based on trigger type. Skip Phase 6 standard output paths — use trigger-specific paths defined in the module.
startup-loop-gap-fill alias: modules/outcome-a-loop-gap.md (output path determined by trigger type inside the module)
For Execution-Track: code | mixed, also load:
../_shared/engineering-coverage-matrix.md
Use it to fill ## Engineering Coverage Matrix in the artifact with explicit Required / N/A treatment for every canonical row.
Phase 5.4: Current Process Map (Non-omittable)
Before rehearsal, write ## Current Process Map in the fact-find draft.
This section may be a single line None: local code path only only when the work does not change any multi-step process, workflow, lifecycle state, CI/deploy/release lane, approval path, or operator runbook.
For process-affecting work, map the current state area by area:
trigger/start condition
step-by-step current flow
owners/systems/handoffs
end condition
known issues already visible in current state
evidence refs for each area
If you cannot explain the current process end-to-end from trigger to end state, the fact-find is not ready for analysis. Expand the investigation first.
Phase 5.5: Scope Rehearsal
Load and follow: ../_shared/simulation-protocol.md
Run a scope rehearsal of the investigation completed in Phase 5. This is not a code execution trace — it is a scope-gap check. Walk through each evidence area identified in the investigation and apply the scope rehearsal checklist defined in the shared protocol (5 categories: concrete investigation path, investigation ordering, system boundary coverage, circular investigation dependency, missing domain coverage).
Write a ## Rehearsal Trace section into the fact-find draft (before persisting in Phase 6) with one row per scope area:
Scope Area
Coverage Confirmed
Issues Found
Resolution Required
Yes / Partial / No
None — or: [Category] [Severity]: description
Yes / No
Apply the blocking/advisory threshold exactly as defined in ../_shared/simulation-protocol.md. Do not restate or weaken the threshold here.
Phase 5.6: Scope Signal (Two-Way)
After rehearsal, classify scope posture using evidence from the investigation:
constrained: scope is too broad/risky for current evidence or capacity; narrow it.
right-sized: scope is realistic and appropriately bounded.
limited-thinking: scope is safely expandable now based on clear evidence.
When limited-thinking, add 1-3 concrete expansion suggestions. Each suggestion must include:
what to add now,
expected upside,
added risk/cost.
Do not emit limited-thinking without explicit evidence that dependencies, risks, and validation burden remain manageable.
Always include the routing header fields in frontmatter.
Dispatch-routed path:
single packet -> write Dispatch-ID
bundled work package -> write Dispatch-IDs and Work-Package-Reason
Canonical artifact name:fact-find.md is the formal loop output artifact for this skill. Required sections and frontmatter fields are defined in docs/business-os/startup-loop/contracts/loop-output-contracts.md (Artifact 1). The path above is authoritative; do not store this artifact at any other location.
Progressive-disclosure sidecar: after validators pass, generate docs/plans/<feature-slug>/fact-find.packet.json per docs/business-os/startup-loop/contracts/do-stage-handoff-packet-contract.md.
If the queued work item carries self_evolving.discovery_contract, the fact-find must emit a machine-readable discovery output in the brief body. This is required for unknown or hypothesized prescriptions and is not optional narrative.
Write a ## Discovery Contract Output section with:
Gap Case ID: <gap_case_id>
Recommended First Prescription: <prescription_id>
Required Inputs: flat list
Expected Artifacts: flat list
Expected Signals: flat list
Prescription Candidates: one flat bullet per candidate, each including:
Prescription ID
Prescription Family
Required Route
Required Inputs
Expected Artifacts
Expected Signals
Rules:
Narrative may explain the recommendation, but it cannot replace these machine fields.
Recommended First Prescription must match one candidate in Prescription Candidates.
If evidence is still insufficient, keep the section but mark unresolved fields explicitly; do not omit the section.
Phase 6.5: Open Question Self-Resolve Gate
Before running the evidence gap review or critique, review every question currently marked as Open.
Self-resolve any question answerable from available evidence and business constraints; move it to Resolved with evidence/logic. Keep a question in Open only when operator-only knowledge is required (undocumented preference/intent, unavailable real-world fact, or genuine preference fork). Default posture: reason and recommend rather than defer.
Phase 7: Mandatory Evidence Gap Review (Outcome A)
If unresolved blockers remain, classify the blocker type before setting status:
Recoverable (missing evidence, awaiting user input, resolvable with more investigation): set Status: Needs-input, ask the minimal blocking questions, and stop.
Structural / infeasible (architecture prevents this, risk is prohibitive, fundamental scope mismatch, or no viable path exists regardless of evidence gathered): set Status: Infeasible, write a ## Kill Rationale section with a one-sentence explanation, and stop. Do not route to planning.
Minimum Evidence Floor Gate
Before critique, ensure minimum substance exists. If floor fails, set Status: Needs-input and stop (do not critique empty briefs):
Code: ≥1 entry-point path, ≥1 key module with role, test landscape present.
Record once per materially updated fact-find artifact.
Include the actual stage-local modules loaded in Phase 5 and any extra repo inputs that materially contributed context size.
Codex token usage is auto-captured when CODEX_THREAD_ID is available.
Claude token usage is auto-captured via project session logs (sessions-index.json → debug/latest fallback). Explicit --claude-session-id still takes priority when supplied.
Completion Message
Fact-find complete. Brief saved to docs/plans/<feature-slug>/fact-find.md. Status: <Ready-for-analysis | Needs-input | Infeasible>. Primary execution skill: <skill>. Evidence gap review complete. Critique: <N> round(s), final verdict <credible | partially credible | not credible>, score <X.X>/5.0.
Status-dependent next action (execute immediately, do not wait for user):
Ready-for-analysis → automatically invoke /lp-do-analysis <feature-slug> to continue the pipeline.
Needs-input → surface the specific blocking questions, then stop. Do not invoke /lp-do-analysis.
Infeasible → surface the kill rationale, then stop. Pipeline ends here.
Quick Validation Gate
Phase 0 queue check run — matching queued packet confirmed or direct-inject path taken
Access declarations listed and verified (or None recorded) before investigation begins
Routing header computed and written to frontmatter
Dispatch-routed metadata written correctly (Dispatch-ID for single packet, Dispatch-IDs + Work-Package-Reason for bundled packet sets)
Only relevant module(s) loaded
Scope signal classified (constrained, right-sized, or limited-thinking) with evidence-backed rationale
## Outcome Contract present and populated (dispatch payload or trigger frontmatter; fallback Why: TBD, Source: auto when unavailable)
## Current Process Map present (or explicit None: local code path only)
For code/mixed work, ## Engineering Coverage Matrix present with all canonical rows
Outcome A evidence gap review completed and recorded
lp-do-factcheck run if fact-find contains codebase claims (file paths, function names, coverage assertions)
Deterministic validators run (validate-fact-find.sh; and for code/mixed validate-engineering-coverage.sh)
fact-find.packet.json generated after validators pass
Workflow-step telemetry appended after validators pass
Status classified as Ready-for-analysis, Needs-input, or Infeasible (not left ambiguous)
If Ready-for-analysis: /lp-do-analysis <feature-slug> automatically invoked
