Dec rendering architecture
Skill jpoindexter/design-engineering-canon/skills/dec-rendering-architecture
Frontend rendering and state architecture — CSR/SSR/SSG/ISR/streaming SSR/RSC chosen per route, state colocation and derived state, server-state vs client-state, Suspense and Error Boundaries as first-class. Use when choosing a rendering strategy, structuring component state, deciding what's server vs client, or designing loading/failure states.From its SKILL.md
npx -y skills add jpoindexter/design-engineering-canon --skill dec-rendering-architectureAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.7 KB, 264 tokens by cl100k_base, as published. Nobody here has run it
Rendering & Architecture
Where work happens (server vs client) and where state lives are the two highest-leverage frontend decisions.
- Rendering Strategies: CSR, SSR, SSG, ISR, streaming SSR, and React Server Components — chosen per route by data freshness and interactivity needs. Static content → SSG/ISR; personalized/fresh → SSR/streaming; highly interactive → client islands.
- State Colocation & Derived State: Keep state as close to where it's used as possible; derive rather than duplicate. Server state (cache of remote data) vs client state (UI) are different problems with different tools — don't conflate them.
- Suspense & Error Boundaries: Declarative loading and failure states as first-class architecture, not afterthoughts bolted on later.
How to apply
- Decide rendering route-by-route, not app-wide — match the strategy to each route's freshness/interactivity.
- Lift state only as high as it's actually shared; duplicated state is a bug — derive it.
- Use a server-cache library for remote data; reserve local state for genuine UI concerns.
- Wrap async boundaries in Suspense + Error Boundary so loading and failure are designed, not accidental.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most architecture codebase skills give in 264 tokens
Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-07
- Ask the user which candidate to explorein 45 of 811, across 15 files
- Apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
- Read any relevant architecture decision records firstin 31 of 811, across 8 files
- Use exact glossary terms in every suggestionin 30 of 811, across 10 files
- Accept dependencies instead of creating themin 24 of 811, across 5 files
- Include before and after visualisations for each candidatein 24 of 811, across 5 files
- Read the domain glossary before exploringin 24 of 811, across 6 files
- Return results instead of producing side effectsin 23 of 811, across 4 files
- Explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
- Introduce seams only where things varyin 22 of 811, across 3 files
- Reduce the number of methodsin 21 of 811, across 2 files
- Design deep modules with small interfacesin 21 of 811, across 3 files
Said here and by no other author read
- choose rendering strategy per route
- use SSG or ISR for static content
- use SSR or streaming for fresh content
- use client islands for interactive content
- keep state close to where it is used
- derive values instead of duplicating state
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.