| name | review-project |
| description | Review a codebase and capture the findings as one lightweight Logics request — candidates for future work, not a commitment to do any of it. Use when asked to "review this project", "audit the codebase", or "what should we fix here". |
Review a project into a captured request
Read the codebase, write up what you found as a single Logics request. This is
capture, not design: a review surfaces candidates, it does not commit to them.
Hard rules
- Capture, do not scope. No backlog items, no tasks, no product brief. If a
finding turns out to deserve real work,
/corpus scaffolds it later, with the
scoping judgement that step deserves.
- One request for the whole review, not one per finding. A wall of requests
is not a review.
- Every finding must name evidence — a file, a line, a command whose output
you saw. A finding you cannot point at is a hunch; leave it out or label it.
- Write in English, whatever language the request came in.
- No real company, supplier, or client names in the doc.
- Do not fix anything. A review that quietly rewrites code is not a review.
Recipe
-
Check what is already known. Do not re-report work the corpus has already
captured:
logics-manager status
logics-manager health --format json
logics-manager sync search-docs "<topic>" --limit 10
-
Read the code, and run whatever the project's own validation says is
authoritative (tests, lint, type-check, audit). Record the actual commands
and their real results — including failures.
-
Capture the findings as one request:
logics-manager flow new request --title "Review findings: <area>" --complexity <Low|Medium|High>
Then fill its sections: Needs for what should change, Context for what you
observed and where, Acceptance criteria for what "addressed" would mean.
-
Validate and index:
logics-manager lint --require-status
logics-manager audit --group-by-doc
logics-manager index
-
Commit the request. Do not push: a review finding has not been verified
against anything yet.
Gotchas
- Rank findings by evidence strength, not by how alarming they sound. "This
test is skipped and has been since " beats "this design seems risky".
- Distinguish "wrong" from "not to my taste". Only the first belongs in
Needs; the second, if worth saying at all, belongs in Context.
- If the review found nothing worth acting on, say so and create no request.
An empty finding list is a valid result.
