pierre-guard

Featured

Guard against breaking the @pierre/diffs integration in Plannotator's code review UI. Use this skill whenever modifying DiffViewer.tsx, upgrading the @pierre/diffs package, changing unsafeCSS injection, adding new props to FileDiff, or touching shadow DOM selectors or CSS variables that cross into Pierre's shadow boundary. Also trigger when someone asks "will this break the diff viewer", "is this safe to change", or when reviewing PRs that touch the review-editor package.

Code & Development 7,386 stars 535 forks Updated today Apache-2.0

Install

View on GitHub

Quality Score: 93/100

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

Skill Content

# Pierre Integration Guard Plannotator's code review UI wraps `@pierre/diffs` — an open-source diff renderer that uses Shadow DOM. The integration is concentrated in a single file but relies on undocumented internals (shadow DOM selectors, CSS variable names, grid layout assumptions). This skill helps verify changes don't break that contract. ## Source of Truth - **Upstream repo**: https://github.com/pierrecomputer/pierre/tree/main/packages/diffs - **Local types**: `node_modules/@pierre/diffs/dist/` (`.d.ts` files) - **Integration point**: `packages/review-editor/components/DiffViewer.tsx` - **Current version**: check `packages/review-editor/package.json` for the pinned version Always verify against the upstream repo or local `.d.ts` files — don't rely on memory of the API shape. ## What We Import ```typescript import { FileDiff } from '@pierre/diffs/react'; import { getSingularPatch, processFile } from '@pierre/diffs'; ``` These are the only three imports. `DiffViewer.tsx` is the only file that touches Pierre. ## API Surface to Guard ### 1. Component Props (`FileDiff`) Read the current prop types from `node_modules/@pierre/diffs/dist/react/index.d.ts` or the upstream source. The props we use: | Prop | Type | Notes | |------|------|-------| | `fileDiff` | `FileDiffMetadata` | From `getSingularPatch()` or `processFile()` | | `options` | `FileDiffOptions<T>` | See options table below | | `lineAnnotations` | `DiffLineAnnotation<T>[]` | `{ side, lineNumber, metadata }`...

Details

Author
backnotprop
Repository
backnotprop/plannotator
Created
7 months ago
Last Updated
today
Language
TypeScript
License
Apache-2.0

Similar Skills

Semantically similar based on skill content — not just same category

Code & Development Listed

deep-review

Use this skill before committing significant changes, after a refactor, or when you want a second opinion on a diff — not for auditing a third-party skill/plugin's safety before install (use /ievo:security-check for that). Structured 11-point gap-detection review of a diff before commit. Spawns a deep-reviewer subagent for independent eyes (fresh context, separate token budget). Catches issues that survive pre-commit hooks, linters, and test suites but surface in human PR review — completeness gaps, test/impl drift, dead code from partial refactors, naming/behaviour mismatch, doc-paraphrase drift, cross-file consistency, error-path coverage, API contract fidelity, security surface, concurrency/state, and leaked secrets. Supports scope modes — staged changes (default), working tree, or arbitrary git range.

0 Updated today
ievo-ai
Code & Development Solid

code-reviewer

Reviews a code diff or pull request for correctness bugs, security vulnerabilities, and quality/maintainability problems, producing severity-ranked findings with file/line references and concrete fix suggestions. Use this skill when the user asks to "review this PR", "review my diff", "code review", "look over these changes", "check this code before merge", "find bugs in this change", or pastes a diff/patch and wants feedback. Applies to git diffs, GitHub/GitLab PRs, staged changes, or a set of changed files in any language.

3 Updated today
JayRHa
Code & Development Listed

pr-human-guide

Analyzes a PR diff and appends a categorized review guide to the PR description, highlighting where human judgment is needed: security, config/infrastructure, new dependencies, data model changes, novel patterns, and concurrency/state. Use this whenever a user wants to prepare a PR for human review or flag areas for reviewer attention — including casual phrasing like "prep this for review", "what should reviewers look at?", "add a review guide", or "flag this for human review".

2 Updated 2 days ago
WhatIfWeDigDeeper