formal-review

Solid

This skill should be used when the user asks to "formal review", "formal lens review", or invokes /formal-review. A fixed-lens PR review for this repository's formally-structured protocol changes: it pins a Category Theory / Type Theory / Operational Semantics lens panel plus a gap scan over only the files changed in a PR, analyzes each lens in isolation, adversarially cross-verifies the findings, and posts the survivors as a single consolidated PR comment. Project-local contributor tooling.

Code & Development 125 stars 11 forks Updated today MIT

Install

View on GitHub

Quality Score: 84/100

Stars 20%
70
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
50
License 10%
100
Description 5%
100

Skill Content

# Formal Lens Review A one-pass review of a PR diff through a **fixed formal lens panel** — Category Theory ∥ Type Theory ∥ Operational Semantics — plus a gap scan, posted back to the PR as a single consolidated comment for human reviewers. This is the project-local specialization of the general, frame-driven `/lens-review` (epistemic-cooperative): that skill lets `/frame` derive whatever lenses fit the diff, whereas this skill **pins** the formal triple on every run so a formally-structured protocol change gets a meticulous, complete formal review on the same three axes each time. ## Why this is a project skill The formal triple (morphism coherence, type soundness, evaluation-order consistency) is **this repository's** standing review axis — protocol `SKILL.md` files carry category-theoretic formal blocks, `TYPES` / `PHASE TRANSITIONS`, and operational-semantics state machines. `/frame`, run generically, is unlikely to select all three formal lenses at once on a given diff; pinning them here guarantees the formal partial review is exhaustive every run. The fixed panel is therefore project-specific and belongs in the project skill layer, while the general frame-driven pipeline stays in the `/lens-review` plugin. This skill is self-contained — it composes `/frame` and `/gap` but does not depend on the `/lens-review` plugin skill being installed. ## Caller Signature ``` /formal-review [scope?] scope : PR number | (implicit) -- optional; PR number, or...

Details

Author
jongwony
Repository
jongwony/epistemic-protocols
Created
7 months ago
Last Updated
today
Language
JavaScript
License
MIT

Bundled in these plugins

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Solid

lens-review

One-pass multi-perspective PR review that posts findings as a single consolidated PR comment. /frame derives the review lenses that fit the diff, plus a gap scan, over only the files changed in a PR; each lens analyzes in isolation, then the findings are adversarially cross-verified before the survivors are posted. Composes prothesis:frame and syneidesis:gap. User-invoked via /lens-review.

125 Updated today
jongwony
Code & Development Featured

two-lens-review

Run pixtuoid's review protocol at either scope — the mandatory pre-merge DIFF gate (2+ differentiated-lens agents on the diff) or a whole-codebase AUDIT (subsystem × factor fan-out over the whole tree). Both draw ONE shared factor taxonomy + verify contract + disposition; they differ only in population and orchestration. Use before merging ANY PR, on 'review this PR/branch' / 'is this ready to merge' (diff scope), or on 'whole-codebase review' / pre-release / periodic audit (whole-codebase scope). Encodes the five hard requirements, the escalation triggers, the adversarial finder→verify fan-out, and the disposition sweep the repo learned the hard way.

421 Updated today
IvanWng97
Code & Development Listed

pr-review

Team baseline for PR and code review — produces scope, blockers, nits, and strengths. Auto-triggers when you say review this PR, check this diff, review these changes, pre-review before I share, what do you think of this PR, or review the diff on this branch. Defers to any other installed skill whose description identifies it as handling PR review, code review, or diff review — if such a skill is present, prefer it over this one (jig's version is a slim baseline). Does not defer to the generic built-in `review` skill. Do not use for: spec-compliance review of a finished slice (use `/jig:independent-review` instead); standalone architecture-doc review (use `/jig:arch-review`, or a richer installed arch-review skill, instead); single-line typo fixes or trivial whitespace changes (just merge and move on).

4 Updated 2 days ago
ramboz