lsp-review

Review fallow's LSP server diagnostics, code actions, and protocol-facing behavior.

4.4k|154|Updated Mar 17, 2026
One-click install
npx skills add https://github.com/fallow-rs/fallow --skill lsp-review
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: lsp-review
Source: https://github.com/fallow-rs/fallow/tree/main/.agents/skills/lsp-review
Command: npx skills add https://github.com/fallow-rs/fallow --skill lsp-review

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Changes to fallow's LSP server can silently degrade editor-facing behavior such as diagnostics, code actions, and code lens, and this Skill provides a structured review process to catch protocol and usability regressions before they ship.

Core Features & Use Cases

  • Protocol Correctness Review: Evaluates LSP server behavior against protocol expectations, including diagnostics and code actions.
  • Editor UX Assessment: Checks code lens and other editor-facing surfaces for stable, usable behavior.
  • Structured Verdict: Concludes every review with an explicit APPROVE, CONCERN, or BLOCK decision.
  • Use Case: After modifying code in crates/lsp, run this review to verify diagnostic quality and protocol-facing behavior before merging the pull request.

Quick Start

Review the recent changes in crates/lsp for LSP protocol correctness and diagnostic quality, then give an APPROVE, CONCERN, or BLOCK verdict.

Frequently Asked Questions about lsp-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review LSP server changes in the fallow repository?

Use this review workflow whenever changes touch crates/lsp or LSP-visible behavior. It reads the lsp-reviewer agent definition and lsp-server rules, then evaluates protocol correctness, diagnostic quality, and editor-facing usability before issuing a verdict.

What does the LSP review check for?

The review focuses on protocol correctness, diagnostic quality, stable behavior, and editor-facing usability across diagnostics, code actions, and code lens. It ends with an explicit APPROVE, CONCERN, or BLOCK decision.

When should I run an LSP review on fallow changes?

Run it whenever a pull request modifies crates/lsp or any behavior visible through the language server protocol, such as diagnostic messages or code actions shown in editors.

What are the possible outcomes of the LSP review?

Every review concludes with one of three verdicts: APPROVE when behavior is correct, CONCERN when issues need attention, or BLOCK when changes must not merge.