structural-reviewing

Reviews code changes, migrations, and operational diffs for structural risks like silent failures and unbounded growth.

Updated May 27, 2026
One-click install
npx skills add https://github.com/ybaspinar/agent-work-skills --skill structural-reviewing-ybaspinar
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: structural-reviewing
Source: https://github.com/ybaspinar/agent-work-skills/tree/main/skills/structural-reviewing
Command: npx skills add https://github.com/ybaspinar/agent-work-skills --skill structural-reviewing-ybaspinar

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often drift into style debates and naming preferences while missing the structural defects that cause production incidents: swallowed errors, unbounded caller-controlled input, race conditions, and irreversible changes. This Skill provides a disciplined review framework that focuses on what an attacker or unlucky caller could turn into a catastrophe. ## Core Features & Use Cases - Structured Review Output: Organizes findings into Must fix, Consider, and Evidence requested sections so feedback is proportionate and actionable. - Structural Review Lenses: Applies concrete lenses including locality, boundaries, silent swallow, unbounded growth, race/replay, acquire/release, blast radius, and contract tests. - Red Flag Detection: Identifies anti-patterns like happy-path-only reviews, style-based justifications for unchecked input, and tests coupled to internals. - Use Case: When reviewing a pull request that adds a new API endpoint with a database migration, use this Skill to check boundary parsing, idempotency of retries, rollback compatibility, and whether failures are silently swallowed. ## Quick Start Review this pull request diff using structural review lenses and list must-fix issues, considerations, and evidence I should request from the author.

Frequently Asked Questions about structural-reviewing

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

FAQPage Schema
How do I review a pull request for structural issues instead of style?

Focus on what an attacker or unlucky caller could turn into a catastrophe: unchecked input at boundaries, swallowed errors, unbounded growth, and race conditions. Organize findings into must-fix items, proportionate considerations, and evidence requests rather than commenting on naming or formatting.

What should I check when reviewing database migrations or endpoint changes?

Check blast radius and reversibility: expand/contract patterns, rollback compatibility, and preservation of old consumers. Also verify boundary parsing, bounded payload sizes, and that failures produce signals rather than silent fallbacks.

How do I detect silent failure patterns in code reviews?

Look for empty catch blocks, ignored error returns, promises with no rejection path, and fallbacks that emit no signal or metric. These silent swallows hide corruption and make incidents hard to diagnose, so they belong in the must-fix category.

When should a code review comment be a blocker versus a suggestion?

Block only what has wide blast radius, external control, silent corruption potential, or irreversible unsafe steps. For everything else, name the cost and let proportionate trade-offs ship as considerations rather than demanding ceremony.

What are the limitations of structural code review?

Structural review does not replace running-system verification, load testing, or security penetration testing. It identifies risky patterns in diffs but cannot prove runtime behavior, so it should be paired with tests, metrics, and rollout evidence.