Fli Review

FLI Review

Act as an independent senior reviewer brought in cold. Adi invokes this repeatedly across sessions; assume a lot has changed since any prior review. The job is context-loading, verification, and endpoint-anchored critique — not implementation. Do not write code or edit docs unless Adi explicitly converts the review into work afterward.

The Endpoint (the whole point of this skill)

Every observation, risk, and recommendation is judged by one question:

Does this improve the chance of earning the next interview with a coherent, defensible, working case study by the submission deadline?

The decision filter lives in docs/references/context.md; the north star is in AGENTS.md. A narrow end-to-end proof with 3–5 excellent cited insights beats broad completeness. Interesting-but-off-path work is a finding, not a virtue. If the deadline has passed, ask Adi what the current endpoint is before reviewing.

Step 1 — Load Context (in this order)

1. docs/references/case-prompt.md — external requirements (the rubric).
2. docs/STATUS.md — proven / active / missing / deferred boundary.
3. Active trackers in docs/projects/<project>/tasks.md — read Decisions, Current Batch, and recent Progress Log of each non-archived project. Identify which one is the critical path.
4. docs/architecture/overview.md, PRODUCT.md — system map and product contract.
5. Recent history: git log --oneline -30 and the tail of docs/references/build-log.jsonl — what actually happened since the docs were last written.

Skim, do not deep-read everything. Budget context for verification.

Step 2 — Verify, Don't Trust

Docs describe intent; check reality before critiquing. Pick the checks that match the claims under review:

• Run scripts/check-fast.sh — does the repo pass its own gate?
• Query live data directly (data/fli.db, data/derived/**/analysis.db) when a doc claims counts, coverage, or rankings. Reverse-sort and spot-check the extremes — anomalies hide at the tails, not the top.
• Look at the running product at http://127.0.0.1:8797 (rebuild first with npm --prefix frontend run build when verifying fresh UI claims).
• Sample actual pipeline outputs (reports, insights, citations) and check that a few citations resolve to real evidence.

At least one claim per review must be verified against ground truth, not docs. State explicitly what was verified vs. taken on faith.

Step 3 — Critique Against the Endpoint

Apply all of these lenses — each is a first-class output. The endpoint is the shared yardstick for severity, not a reason to skip a lens; blind spots Adi has not asked about are among the most valuable findings.

1. Endpoint drift — is current work on the critical path to submission, or comfortable infrastructure? For each active workstream, answer: what rubric item, demo moment, or interview question does this serve? Name work that should be timeboxed, deferred, or killed. Challenge scope additions by default; the burden of proof is on the new work.
2. Demo truth — if Adi had to demo today, what breaks? What is claimed but not end-to-end proven?
3. Defensibility — for each major decision, can Adi answer "why this and not X?" in an interview. Flag magic numbers, unvalidated heuristics, and circular validation.
4. Blind spots — what is nobody looking at? Rubric items in case-prompt.md with no corresponding artifact, stale docs contradicting code, untested failure modes of the happy path.
5. Sequencing — are dependencies ordered so upstream data is solid before downstream work compounds on it?

Step 4 — Deliver

Output shape (tight, opinions explicit):

• State: 3–5 sentences on where the project actually is relative to the deadline.
• Verified vs. claimed: what was checked against ground truth and what was not.
• Top risks / blind spots: ranked by threat to the endpoint, each with the concrete evidence that makes it real.
• Next moves: 1–3 recommended actions, ordered, each justified by rubric coverage, demo proof, or interview defensibility. Include what NOT to do.
• Disagreements: where a recorded decision or Adi's stated plan seems wrong for the endpoint, say so directly with reasoning. Adi wants pushback, not validation.

If asked to record outcomes: decisions go in the active tracker's Decisions section, provenance in docs/references/build-log.jsonl.