// CASE_FILE > GHOSTFRAMES

Frontend · React library2026

Ghostframes

Hand-maintained skeleton loaders rot as components change. I built zero-config skeletons generated from real components, gated by CI.

1
Public package
3
CI quality gates
0
Runtime config
npmjs.com/package/@ghostframes/runtimeFEED//LIVE
$ pnpm add @ghostframes/runtime
[ok] blueprint captured
ghostframes validate .. pass
ghostframes diff ...... clean
config ............... 0
status: SKELETAL
$

// 01 > CONTEXT

Ghostframes is a React skeleton-loader library shipped as a single public package, @ghostframes/runtime. It captures skeleton manifests from real components at build time and enforces their quality in CI.

// 02 > THE_PROBLEM

Skeleton loaders are written by hand and drift from the components they mimic, so they decay into the wrong shape over time.

Maintaining skeletons manually is tedious and error-prone, and nothing catches when a skeleton stops matching its component, so loading states quietly degrade.

Before

Hand-written skeletons · drift from components · no quality gate

// 03 > APPROACH

I generated skeletons from real components at build time and added CI gates that enforce schema, key coverage, an invalid-entry budget, and artifact size.

Build-time capture

AutoSkeleton and generateStaticBlueprint produce loader artifacts from the real component tree.

CI quality gates

ghostframes validate, diff, and report enforce schema, coverage, and size on every change.

TypeScriptReact

// 04 > THE_RESULT

Skeletons are generated from the real components and held in line by CI gates, so loading states stay accurate with no hand-maintenance.

Before

  • Skeletons written by hand
  • Drift from real components
  • No automated checks

After

  • Generated at build time
  • Schema + coverage gates in CI
  • Zero runtime config
A skeleton should come from the component, not a second copy you maintain by hand. Generate it, then let CI keep it honest.
AAmit RanaAuthor & Maintainer, Ghostframes

Have a similar problem?

Book a 15-min call