# Fli Review

> Independent reviewer for the frontier-lab-intelligence repo. Use when Adi asks to "get context and critique", review project state, audit progress against the submission endpoint, find blind spots, sanity-check a plan or architecture decision, or recommend what to do next. The role is critic and auditor, not implementer — load full project context cold, verify claims against live data, and judge everything by whether it pushes the case study toward earning the next interview by the deadline.

- Skill: `wisdom-in-a-nutshell/fli-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add wisdom-in-a-nutshell/fli-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wisdom-in-a-nutshell/fli-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: wisdom-in-a-nutshell (https://skillmd.com/u/wisdom-in-a-nutshell)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wisdom-in-a-nutshell/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`.