pi-critique

Structured AI critique for writing and code in pi. Submits a critique prompt to the model, which returns numbered critiques (C1, C2, ...) with inline markers in the document text. Pairs well with pi-annotated-reply and pi-markdown-preview but works standalone.

Non-destructive by default: /critique is intended to analyze, not edit, your source file.

Commands

| Command | Description | |---------|-------------| | /critique | Critique the last assistant response | | /critique <path> | Critique a file (non-destructive; original file is unchanged) | | /critique --code | Force code review lens | | /critique --writing | Force writing critique lens | | /critique --no-inline | Critiques list only, no annotated document | | /critique --edit | Load prompt into editor instead of auto-submitting | | /critique --help | Show usage |

How it works

/critique sends a structured prompt to the model asking it to:

1. Assess the document overall
2. Produce numbered critiques (C1, C2, ...) with type, severity, and exact quoted passage
3. Reproduce the document with {C1}, {C2} markers at each critiqued location

The model adapts critique types to the genre:

• Expository/technical: overstatement, credibility, evidence, wordiness, factcheck, ...
• Creative/narrative: pacing, voice, tension, clarity, ...
• Academic: methodology, citation, logic, scope, ...
• Code: bug, performance, readability, architecture, security, ...

Types are not fixed — the model chooses what fits the content.

Non-destructive behaviour

• For normal files, the extension reads content and sends it to the model for critique. It does not directly edit your source file.
• For large files (see below), the model is instructed to write annotations to a separate file: <filename>.critique.<ext>.
• During auto-submitted /critique <path> runs, a safety guard blocks write/edit tool calls to prevent accidental in-place edits.
• To actually apply changes to the original file, run a separate explicit editing step (for example via /reply + a follow-up prompt).

Lenses

The extension auto-detects whether content is code or writing based on file extension. Override with --code or --writing.

Code files (.ts, .py, .rs, .go, etc.) get a code review prompt. Writing files (.md, .txt, .tex, etc.) get a writing critique prompt. Extensionless files like Dockerfile and Makefile are detected as code.

Large files

Files over 500 lines are handled differently to save tokens: the extension passes the file path to the model (rather than embedding the content), and the model reads the file with its tools and writes an annotated copy to <filename>.critique.<ext> on disk.

The original file path is preserved; annotations are written to the *.critique.* copy.

Example output

## Assessment

Strong opening, but several unsupported claims weaken credibility...

## Critiques

**C1** (overstatement, high): *"Every study shows that context-switching destroys productivity"*
"Every study" is a universal claim that's easy to falsify. Consider: "Research consistently shows..."

**C2** (credibility, medium): *"No benchmark data is available yet, but informal testing confirms..."*
This sentence contradicts itself. Either provide numbers or drop the comparison.

## Document

Original text with markers showing where each critique applies.
Some text here. {C1} More text. {C2}

Reply loop

After receiving a critique, respond with bracketed annotations:

[accept C1]
[reject C2: the simplicity claim is intentional]
[revise C3: good point, will soften]
[question C4: can you elaborate?]

This works standalone in pi's editor, or with /reply from pi-annotated-reply for a smoother workflow.

Install

pi install npm:pi-critique

Or from GitHub:

pi install https://github.com/omaclaren/pi-critique

Or try it without installing:

pi -e https://github.com/omaclaren/pi-critique

License

MIT