@estebanforge/pi-ts-review
TypeScript / React code-review tool for Pi. Grades your git diffs against a focused TS + React rubric (2 sections, 14 entries: TypeScript type-system + React/JSX semantic mistakes). Targets .ts/.mts/.cts/.tsx. Each entry has a bad/good pair; the LLM propo
Package details
Install @estebanforge/pi-ts-review from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:@estebanforge/pi-ts-review- Package
@estebanforge/pi-ts-review- Version
1.1.0- Published
- Jul 9, 2026
- Downloads
- 462/mo · 23/wk
- Author
- estebanforge
- License
- MIT
- Types
- extension
- Size
- 30.4 KB
- Dependencies
- 0 dependencies · 0 peers
Pi manifest JSON
{
"extensions": [
"./extensions"
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
@estebanforge/pi-ts-review
TypeScript / React code review against a focused TS + React rubric. Registers a ts_review tool that reads git diffs, filters to .ts/.mts/.cts/.tsx/.jsx, and attaches the rubric (18 entries across 2 sections: TypeScript types + React/JSX, including security and performance flaws). The rubric targets flaws that typescript-eslint (strict) and eslint-plugin-react-hooks do not reliably catch. Every rule is grounded in a confirmed online source — see Sources.
Sibling to @estebanforge/pi-go-review, pi-php-review, pi-rust-review, and pi-js-review. Pair with typescript-eslint and eslint-plugin-react-hooks for lint coverage; this tool focuses on the semantic mistakes those linters may not flag.
Install
pi install npm:@estebanforge/pi-ts-review
Usage
Ask Pi: "review my TypeScript changes" or "review my React changes."
The tool runs git in one of five modes:
| Mode | Description | Needs ref |
|---|---|---|
working |
Unstaged changes | No |
staged |
Staged (cached) changes | No |
all |
All changes vs HEAD | No |
commit |
A specific commit | Yes (SHA) |
range |
A commit range | Yes (e.g. main..HEAD) |
Narrow scope with path (a file or directory). The tool runs git from that path — so path can point into a nested repo (e.g. a package inside a workspace whose root is not itself a git repo).
What it does
- Reads the git diff filtered to
*.ts/*.mts/*.cts/*.tsx/*.jsx. - Attaches the TS + React rubric (18 entries, 2 sections).
- The LLM reviews the diff and returns findings that propose a corrected snippet:
| Severity | Meaning |
|---|---|
| Bug / Critical | Must fix |
| Suggestion | Should consider |
| Nit | Minor improvement |
| Good pattern | Well done |
Each finding cites the entry number (e.g. #6), the file + code fragment, and a corrected snippet. Ends with a Verdict: Approve / Request Changes / Needs Discussion.
Rubric sections
| Section | Entries |
|---|---|
| 1. TypeScript Types | #1 - #3 |
| 2. React / JSX | #4 - #14 |
Scope note: this rubric deliberately excludes mistakes that typescript-eslint (strict) and eslint-plugin-react-hooks already enforce (e.g. any, non-null !, Rules of Hooks, exhaustive-deps, @ts-expect-error via ban-ts-comment). It targets the semantic gaps those linters miss: effect cleanup, fetch races, unstable effect deps, derived state, direct state mutation, stale updaters, unsafe as casts, falsy && render, dangerouslySetInnerHTML, plus React-specific security and performance flaws (URL injection, token storage, memoization-defeating inline props, context re-renders).
Sources
The rubric's rules were validated against confirmed online sources during research (searched via Exa and Brave). The sources live here in the README (not embedded in the rubric) to keep the per-call prompt lean.
| # | Entry | Source |
|---|---|---|
| 1 | Unsafe as assertion |
Effective TS — Item 9: Prefer annotations to assertions · basarat — type-assertion |
| 2 | unknown not narrowed |
Total TypeScript — Narrowing unknown |
| 3 | Missing return types | typescript-eslint — explicit-module-boundary-types |
| 4 | Effect without cleanup | React — Lifecycle of Reactive Effects |
| 5 | Direct state mutation | React — Updating Objects in State |
| 6 | Stale state update | React — Queueing a Series of State Updates |
| 7 | dangerouslySetInnerHTML |
React — dangerouslySetInnerHTML · OWASP XSS Prevention |
| 8 | Derived state via effect | React — You Might Not Need an Effect |
| 9 | Fetch-in-effect race | React — Synchronizing with Effects · Lifecycle of Reactive Effects |
| 10 | Controlled value/onChange | React — <input> reference |
| 11 | && falsy render |
React — Conditional Rendering |
| 12 | Index-as-key | React — Rendering Lists |
| 13 | setState in render loop | React — Components and Hooks must be pure |
| 14 | Unstable value in deps array | React — Removing Effect Dependencies |
| 15 | Untrusted URL in href/src |
Pragmatic Web Security — Preventing XSS in React (Part 1): Data binding and URLs · OWASP XSS Prevention |
| 16 | Auth token in localStorage |
OWASP — HTML5 Web Storage Security · IETF OAuth 2.0 for Browser-Based Apps |
| 17 | Inline props vs React.memo |
React — memo reference · LogRocket The React pattern everyone uses that quietly kills performance |
| 18 | Context value recreated |
Kent C. Dodds — How to optimize your context value |
Primary authorities: Effective TypeScript (Dan Vanderkam), typescript-eslint, React docs (react.dev), Total TypeScript.
TUI rendering
Custom rendering for both the tool call and its result: mode, file count, insertions/deletions, and truncation status at a glance.
License
MIT