Project Architecture

C3SC0-V4113/Scaffold/skills/project-architecture

by C3SC0-V4113ba1fac59145ed48f727247299ebb09289b87f27bApache-2.03 starsListed Oct 9, 2026Updated Oct 9, 2026Repository updated 3 days ago

Trigger: UI change, layout, component architecture, state flow, theming, server/client boundary, Astro island. Keep Next.js or Astro apps server-first.

Instructions onlySoftware Development
AI-generated overview

Guardrails for keeping Next.js or Astro apps server-first when changing UI, layout, state flow, or server/client boundaries.

What it does
This skill provides architecture guardrails for Next.js and Astro projects, instructing the agent to detect the framework before acting and keep rendering server-first. It routes the agent to framework-specific reference files for server/client boundary rules and Astro island rules. It also requires explicit loading, empty, and error states, reuse of existing components and design tokens, and a pre-close checklist. The output reports the detected framework, every server/client boundary added or moved with its reason, and checklist answers.
When to use it
Use it before changing UI, layout, component structure, state flow, theming, data display, or the server/client boundary of a Next.js or Astro app. It is meant for work where client-side surface should be minimized and framework boundaries respected.
Requirements
No scripts; instructions only. It expects a Next.js or Astro project with a package.json and root config files, and may reference project files such as DESIGN.md and optional installed skills. It also expects the agent to read the installed framework's own documentation.

Project Architecture Guardrails

Activation Contract

Load this skill before changing UI, layout, component structure, state flow, theming, data display, or the server/client boundary of a Next.js or Astro app.

Hard Rules

  1. Detect the framework from the project before acting; never assume it.
  2. Keep rendering server-first. Add client-side code only when the interaction cannot work without it, and keep that surface as small as possible.
  3. Read the installed framework's own docs before changing framework APIs or project structure.
  4. Follow DESIGN.md for visual and UX decisions when it exists.
  5. Build from existing shadcn primitives and semantic tokens before writing custom markup or styles; load shadcn-component-boundaries when it is installed.
  6. Make loading, empty, and error states explicit for every data display.
  7. Add tests proportional to risk, using the test tooling the project already has.

Decision Gates

Project signalFrameworkGuidance
next in package.json dependencies, or a next.config.* fileNext.jsreferences/next.md [blocked]
astro in package.json dependencies, or an astro.config.* fileAstroreferences/astro.md [blocked]
Both or neitherUnknownStop and ask which app the change targets

Execution Steps

  1. Read package.json and list the root config files to detect the framework.
  2. Load the matching reference and apply its boundary rules.
  3. Search existing components, routes, and styles before creating new ones.
  4. Implement the change with the smallest client-side surface that works.
  5. Answer the pre-close checklist, then load project-min-evaluation when it is installed, or run the project's quality scripts.

Pre-close checklist:

  • Did the change add unnecessary client-side surface?
  • Does it follow DESIGN.md?
  • Are loading, empty, and error states explicit?

Output Contract

Report the detected framework, every server/client boundary added or moved (with its reason), and the checklist answers.

References

  • references/next.md [blocked] — Next.js server/client boundary rules.
  • references/astro.md [blocked] — Astro island boundary rules.

Source and attribution

Source:C3SC0-V4113/Scaffoldinskills/project-architectureat commitba1fac5

License: Apache-2.0

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal