design-review

Validate GraphReFly public API designs against Q5–Q9 invariants.

1|Updated Mar 29, 2026
One-click install
npx skills add https://github.com/graphrefly/graphrefly-ts --skill design-review-graphrefly
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: design-review
Source: https://github.com/graphrefly/graphrefly-ts/tree/main/.claude/skills/design-review
Command: npx skills add https://github.com/graphrefly/graphrefly-ts --skill design-review-graphrefly

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevents architecture drift and long-term abstraction failures by validating that a proposed public API or primitive fits GraphReFly’s design invariants before implementation, when changes are cheapest.

Core Features & Use Cases

  • Q5–Q9 API design lens: Checks the right abstraction (Q5), long-term solution quality and caveats (Q6), reactive/composable/explainable shape (Q7), and at least two viable alternatives (Q8).
  • Single-symbol or single-file or single-diff review: Targets new exports introduced via diff, or a specific file path, or a specific symbol name.
  • Spec + composition precedent alignment: Reviews against design invariants, composition guidance, active work items, and nearby precedent in the same code directories.

Quick Start

Use the design-review skill to review the new public symbols introduced in your current diff for GraphReFly.

Frequently Asked Questions about design-review

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

FAQPage Schema
How do I validate API design for new TypeScript exports before coding?▼

API design validation for new TypeScript exports is performed by applying the Q5–Q9 design-review lens to single-symbol, single-file, or single-diff changes, ensuring they fit design invariants before implementation. This process checks abstraction quality and reactive graph composability.

When do I need a design review for new public API surfaces?▼

A design review for new public API surfaces is needed when introducing new exports via a diff, a specific file path, or a specific symbol name. It prevents architecture drift by validating reactive graph composability and abstraction quality before implementation.

What is the Q5–Q9 API design lens for spec validation?▼

The Q5–Q9 API design lens for spec validation checks the right abstraction level, long-term solution quality, reactive and explainable shape, and requires at least two viable alternatives. It aligns new primitives with design invariants and composition guidance.

Can I review cross-language parity for reactive graph composability?▼

Cross-language parity for reactive graph composability can be reviewed using single-symbol or single-diff checks. The review validates that new public API surfaces maintain explainability and spec invariants across TypeScript and other languages.

Does this design review process check for viable API alternatives?▼

Yes, the design review process requires producing at least two viable API alternatives as part of the Q8 check. It evaluates these alternatives alongside spec validation to provide a structured recommendation and log residual risks.

What are the limitations of using a single-diff design review for maintainability?▼

A single-diff design review for maintainability is limited to single-symbol, single-file, or single-diff scopes affecting exports and reactive graph composability. It logs residual risks or follow-ups when gaps remain but does not cover multi-file architectural overhauls.