- Home
- Skills
- Frontend & Web Apps
- Senior Web App Architect for Coding Agents
More screenshots
Works with the AI Agents you already use
Senior Web App Architect for Coding Agents
Messy, insecure, unfixable — that's what AI builds without architecture. This file is the architecture: 10 years of senior judgement on rendering, caching, security and SEO, so your agent builds it right from day one.
$9.99
Senior Web App Architect for Coding Agents
Example session with this skill installed
Starting a new app — public marketing pages plus a private customer dashboard. Set it up properly.
- Read your context and instructions
- Compiled the senior web app
Per route, four questions: differs per visitor? staleness tolerance? must it be indexed? cost to produce?
Landing page — same for everyone, must be indexed, staleness tolerable in minutes → static, regenerated on a schedule and purged the moment an editor saves.
Dashboard — per-visitor, no indexing, heavily interactive → client-rendered.
That split makes the API the real public surface. The dashboard's route guard is UX, not security — its HTML and JS are served to anyone who asks. So every endpoint touching private data checks authorisation server-side, against an attribute the caller cannot write: a signed role claim, not user != null. The day self-service sign-up gets enabled, "any signed-in user" means anyone on the internet.
Then prove it, from outside the UI:
Boundary probe — no token → 401, unprivileged account → 403, admin → 2xx.
Invalidation drill — edit content, watch the public page update in seconds, not when the TTL expires.
Clean clone — placeholder config, empty datastore: it must still build and render fallbacks.
Connects securely to your tools. The creator never sees your data.
About this skill
Turn any coding agent into a senior web architect. Eight files of production-audit judgement — the decisions, failure modes and orderings that separate apps that survive production from apps that get debugged there. If your agent writes web code, this is the skill it should be carrying.
The problem
Web applications fail in production because architectural decisions get made implicitly. The symptoms are always the same: content stays stale after an editor saves, hydration mismatch warnings, pages Google never indexes, social previews pointing at localhost, spam records appearing despite "validation", builds that only break on a clean clone, a site that gets a little slower every sprint — and security holes where the browser was trusted as a boundary. Generic AI output reproduces these failures, because the knowledge that prevents them is not in the docs. It is judgement.
What it does
- Rendering, decided per route — static, regenerated (ISR), server-rendered, streamed or client, chosen by four questions (differs per visitor? staleness tolerance? must it be indexed? cost to produce?) — plus an opinionated default posture: static shell with islands, purged automatically the moment an editor saves.
- Data and caching with one owner per fact — a reader pattern that never throws, per-record validation that drops one bad row instead of crashing the page, and writes paired with exactly the caches they invalidate. The "save button is broken" bug, designed out.
- A real security boundary — authorisation on an attribute the caller cannot self-assign, the six privilege-escalation shapes (self-promotion via writable records, open creates, unlisted upload paths, UI-filter "security" and more), the CSRF question, and the grant-then-tighten ordering that avoids locking your own admin out.
- SEO as architecture — canonical host discipline, honest status codes (no soft-404s), escaped structured data, breadcrumbs, and sitemaps enumerated from your datastore.
- Performance and assets, budgeted — images served at rendered size with the LCP image never lazy-loaded, fonts swapped without layout shift, JavaScript priced per route, third-party scripts governed like dependencies, and Core Web Vitals (LCP / INP / CLS at p75) mapped to their structural fixes.
- TypeScript and JavaScript defaults that are day-one-or-never — the compiler flags you cannot retrofit, typed boundaries, async discipline, and the money, date and JSON traps. Each item earns its place by the production failure it prevents.
- Verification drills — clean-clone builds, shipped-artefact checks, boundary probes (401 / 403 / 2xx), invalidation drills. The architecture gets proven, not intended.
Frameworks & tools
Stack-independent by design: Next.js, Nuxt, SvelteKit, Angular, Django, Rails, .NET — anything that serves HTML, with the framework vocabulary verified against current documentation. The language reference applies to any TypeScript or JavaScript codebase; the architecture applies regardless of language.
Why this beats prompting it yourself
A general model already knows what SSR and ISR are — nobody needs to buy definitions. What it reliably misses is when to choose which, what each choice costs, and how the wrong one fails. This skill encodes that judgement from audits of live production sites: the write-to-purge link whose absence gets reported as a broken save button, the escalation paths hiding behind client-side guards, the third-party tag audit nobody runs, the compiler settings that are day-one-or-never. Decisions and failure modes baked into the structure — not patched on after the incident.
Use cases
- Design the rendering and caching strategy for a content site or e-commerce catalogue, route by route.
- Audit an existing app for boundaries where the UI is the only gatekeeper.
- Debug stale-content reports by walking the invalidation path from write to CDN.
- Make generated detail pages discoverable: crawler-readable content, per-record structured data, datastore-driven sitemaps.
- Diagnose failing Core Web Vitals and fix them structurally — budgets, LCP priority, font swap, tag governance.
- Start a TypeScript project with the strict defaults that survive a clean-clone CI run.
What it deliberately is not
Application architecture only — honest scope is part of the product. It does not choose your stack, datastore or vendors; no framework tutorials, no UI design, no cloud-provider configuration, no native apps, no hosted CMS platforms (WordPress and similar). Every paragraph inside had to earn its place by encoding a decision or a failure mode; the padding was cut so your context window does not pay for it.
Compact by design: a lean SKILL.md loads on trigger; seven reference files load only when the agent needs that topic. One prevented incident — a leaked record, a locked-out admin, a week of stale-cache debugging — pays for this skill many times over.
Framework vocabulary drifts: the decision framework is stable, but what each strategy is called in Next.js, Nuxt or SvelteKit changes between major versions, so the skill directs the agent to verify current framework docs rather than guaranteeing today's API names. The biggest payoff is on new projects — on an existing codebase it works as an audit and refactoring guide, but retrofitting day-one decisions like compiler strictness and cache ownership is real work the skill can direct, not erase. It guides security decisions but is not a security audit: the boundary probe and escalation catalogue catch the common shapes, not everything a pentest would. And it is application architecture only — no stack selection, UI design, infrastructure-as-code, native apps, or hosted CMS platforms.
How to use
- 1
Connect your agent to the Agensi MCP
Copy the prompt and paste it into Claude, ChatGPT, Cursor or any agent that supports MCP. It sets up the connection for you. Manual setup
- 2
Sign in to Agensi
Your agent shows a sign-in link. Sign in and click Allow.
- 3
Ask for what you need
Your agent loads this skill and uses it on your task. It always asks before any payment.
Reviews
This skill has been used 1 time.
Trust & safety
Security scan
Security scan passed 3 months ago
Permissions
File Scopes
This skill is plain markdown reference material: it executes nothing on its own, calls no external services, and reads no environment variables. Terminal access is declared because its verification drills instruct your agent to run local commands (builds, greps, and curl probes against your own deployment) at your direction. The domains visible in the files are illustrative strings inside code samples — www.example.com is the standard documentation placeholder and schema.org appears only as the JSON-LD @context value. The skill never connects to either.