---
name: rem-investigate-project
description: The steps for investigating a project's page, composed after rem-investigate when the subject is under projects/.
---

# Investigating a project

Why these rules: docs/rem-skills/rem-investigate.md

- **Sessions show intent, not repository state.** Check files before claiming
  anything shipped or passed.
- **Inspect the live repository paths supplied in the task.** Start with the
  evidence index and mapped paths. Use `git log`, `git show`, `README.md`,
  `pyproject.toml`, `package.json` and relevant source files to verify claims.
  Record the inspected path and revision or timestamp in each source
  citation. For a live file outside snapshots, cite
  `file:/absolute/path@<sha256>` (hash full bytes with `shasum -a 256`)
  so the cited version can be retained. The index names omitted files and size limits; an omitted body is
  not evidence that implementation is absent.
- `project-inventory` lists candidate files, not their contents. Do not cite
  `investigation:project-inventory`; cite the inspected file or a retained
  snapshot for file facts.
- Keep existing `Paths` without citing `investigation:page`. A new path needs
  a retained source.
- Put search-window limits in your final reply, not page `Uncertainties` or
  `Sources`; `investigation:coverage` is not citable project evidence.
- If the `project-input-scope` item says zero session inputs were assigned,
  keep `Insight` and `Open threads` as bare `Unknown`. Dated repository notes
  can explain the project and its history in `What it is` and `Where it
  stands`; they do not establish current user work or a live next action.
  The scope item is not an original and must not appear in `Sources`.
- Old files are not recent activity. Attribute README/manifest claims to their
  snapshot date or revision unless current code or a dated user report confirms
  them. `First seen` is an observed session, not project `Started`; leave
  `Started` Unknown without explicit evidence.
- `Status` and `Last activity` mean demonstrated project progress, not a Git
  branch or commit timestamp. Put a branch or commit in `Where it stands` as a
  dated checkout snapshot; leave those Facts Unknown unless a dated original
  ties actual work to this project. A commit alone does not establish the
  user's current task or next step.
- A workspace holds unrelated requests. An old request with no outcome is not
  necessarily pending. Cwd does not identify the subject. Require a distinctive
  project, package, component, file, version or behavior match to the supplied
  project evidence. Generic release, patch, test, reply or package-manager
  requests do not identify a project. Omit ambiguous status, insight and action.
- Assign unnamed follow-ups only when an earlier supplied input in the same
  session establishes this project's subject. If it names another product, or
  was not supplied, leave the follow-up unassigned despite its cwd. Exclude it
  from current findings, status, activity, issues, threads and next action.
- Audit the final `Now`, `Where it stands` and `Open threads` claims against
  each cited original before writing the candidate. A short input reporting a
  missed reply establishes that report only; it does not establish whether a
  listener is event-driven, what caused the miss, or what was implemented.
  Remove any mechanism, cause, status or next action absent from the cited
  original unless a second, separately cited source establishes it.
- A comment in source code reporting a test is a dated source note, not an
  independently verified execution result. Attribute it to the file and date;
  do not call it the latest run or a current outcome without a run log or
  another dated original that verifies that claim.
- For `Overview` and `Try it`, compare each step with the original source and
  with the other section. Preserve the documented order exactly; do not
  reverse prerequisite, capture, load or write steps. If the order is not
  explicit, omit `Try it` rather than inventing instructions.

## What to produce

`Facts` first (the repository remote, the stack from manifests, the first and
last session dates), then `Insight`. Three shapes, never their facts:
- `Now: stopped 2026-09-28 with the import half-merged; next the retry; blocked on review [3]`
- `Changed: moved from SQLite to files on 2026-09-02 after the lock bug [5][7]`
- `At stake: the 1 October demo needs the login, still failing [8]`

Before writing `Insight`, ask what changes a teammate's next decision. A branch
name, last commit date or list of README topics belongs in `Facts`, `Where it
stands` or `What it is`; it is not an Insight. Lead with a sourced constraint,
change or mismatch and its consequence. Put the decision-changing conclusion in
a short first sentence that fits a phone preview, then add evidence and limits.
If the packet supports none, write
`- Unknown` instead of filling the section with housekeeping.

Follow `rem-page-project`, skeleton headings exact. **`Overview` is required
when the material shows the architecture** (its parts and how work moves between
them): a closed `text` fence with arrows. Otherwise write
`Unknown — <what evidence is missing>`. An example file does not
prove an output. Current code is not a decision (local code ≠ a decision to stay
local).
Always keep the required `Open threads` heading. Write bare `Unknown` if no
current exchange is supported; do not omit the heading or invent an obligation.