| name | web-architecture-pattern-application |
| description | Apply Yu Inao's personal catalogue of web architecture grand-design patterns. Use when designing, reviewing, or documenting whole-system web architecture decisions and selecting the relevant reference pattern from this skill.
|
| license | CC-BY-NC-4.0 |
| metadata | {"author":"Yu Inao","author_email":"84360+japboy@users.noreply.github.com","copyright":"Copyright (c) 2026 Yu Inao.","version":"0.1.0","license_url":"https://creativecommons.org/licenses/by-nc/4.0/","commercial_use":"Commercial use requires separate permission from the author."} |
Web Architecture Pattern Application
Purpose
Use this skill to reason about web architecture as a whole-system design
problem, not as isolated frontend implementation work.
The expected output is an architectural decision, critique, or pattern proposal
that selects and applies the relevant reference pattern from this catalogue.
Architectural Axioms
Apply these axioms consistently:
- Declarative
- Self-describing
- Deterministic
- Explicit state
- Finite state
- Self-documenting
- Exhaustive
- Predictable
Prefer designs where important behavior is derived from explicit models instead
of scattered procedural side effects.
Working Model
Start by identifying the architectural level of the user's question:
- conceptual model
- information architecture
- application state
- runtime boundary
- data or observability model
- operational contract
- governance or review policy
Then load only the reference files needed for that level. Do not import one
reference pattern's assumptions into unrelated architecture decisions.
Reference Catalog
Available references:
| Reference | Use when |
|---|
| Route-State-Based Product Analytics | The task involves product analytics, tracking, declarative instrumentation, route transition logs, URL-as-state, IA-aligned route design, or DWH semantic modeling from web behavior logs. |
Review Stance
When applying a pattern:
- Separate project facts from pattern recommendations.
- Identify which reference pattern is being applied.
- Keep each reference pattern's scope explicit.
- Avoid applying a pattern merely because it is available.
- Surface tradeoffs, missing evidence, and unknowns explicitly.
- Prefer declarative, self-describing models over scattered procedural
conventions.
Output Shape
For design guidance, prefer this structure:
- Decision: the recommended architecture or review outcome
- Why: the architectural rationale
- Reference: which catalogue reference was applied
- Model: the explicit states, contracts, boundaries, or schemas involved
- Risks: ambiguity, coupling, refactoring hazards, or semantic drift
- Checklist: concrete validation questions
Keep the answer grounded in the actual project artifacts when reviewing a real
codebase.
License Notes
This skill catalogue is licensed as documentation and knowledge material under
CC-BY-NC-4.0. Attribution to Yu Inao is required for permitted use. Commercial
use is not granted by this license and requires separate permission from the
author.
