Standalone Web App
Purpose
Provide app-level defaults for self-contained browser apps and local web tools that should stay simple, readable, and maintainable without unnecessary framework or build-system overhead.
When to use this skill
- Creating a standalone browser app or local web tool.
- Refactoring a no-build web app that is getting too large.
- Deciding whether the app can stay framework-free or should escalate to a full React and Next app.
- Choosing local assets and browser-loadable libraries for a whole standalone app.
Scope Boundaries
- Use this skill for whole browser-only apps and local web tools you control directly.
- Use
ref-sp-js-next-template when the user explicitly wants a full React and Next app rather than a no-build browser app.
- Use
ref-sp-js-react or ref-sp-js-next only after the app has deliberately crossed into those frameworks.
- Use
ref-sp-js-userscript when the code runs inside a userscript manager on someone else's page.
- Use
ref-sp-js-javascript for detailed JavaScript module, JSDoc, and runtime-surface questions once the standalone app model itself is chosen.
- Use
ref-sp-dev-projects-architecture when the question is about repo-wide structure rather than one browser app.
Defaults
- Start with one self-contained HTML file for small and medium apps.
- Use semantic HTML before reaching for generic containers — choose the element for the behaviour it
carries, not for how it looks. Element table, landmarks, and heading rules:
.agents/skills/ref-sp-ux-accessibility/references/semantic-structure.md.
- Prefer no package manager or build pipeline by default.
- If Node-based tooling becomes necessary, prefer Yarn for dependency management and scripts.
- For richer no-build UI, prefer browser-loadable UI libraries over re-creating every control from scratch.
- Do not introduce React or a build pipeline by default.
- Keep styles and scripts local unless extraction clearly improves readability.
Task Framing
| Command or action |
What |
Why |
When |
Expected outcome |
| Start with the smallest viable app |
Keep HTML, CSS, and JS local until complexity proves extraction is needed. |
Standalone tools become harder to move and maintain once they inherit premature infrastructure. |
When creating a new browser-only app. |
The app is easy to open, reason about, and iterate on. |
| Split a growing app locally |
Extract sibling CSS or JS files inside the same folder when the inline version gets hard to scan. |
Local extraction improves readability without creating cross-app coupling. |
When one file is becoming mentally heavy. |
Structure is clearer but the app still ships as an independent unit. |
| Compare no-build versus framework escalation |
Decide whether the requirement still fits a no-build browser app or has crossed into full-app territory. |
Framework escalation is expensive when the app could stay local and simple. |
When state, routing, or deployment expectations start growing. |
The chosen app model matches the real complexity. |
Core Rules
Structure
- Use semantic sections such as
header, main, section, form, and dialog where they fit.
- Keep the app layout obvious from the markup alone.
- Extract CSS or JS into local sibling files only when the inline version becomes hard to scan.
- Initialize app state and construct any singletons from one entry script rather than as a side effect of an imported helper module; keep extracted JS siblings inert on import. See
ref-sp-js-javascript for the general import-side-effect rule.
Local asset boundaries
- Keep the main page on
.html and colocate any extracted CSS, JS, and assets inside the same app folder.
- Extract local assets only when the single-file version has become hard to scan.
- If the app also ships with a userscript, keep that handoff explicit and route the userscript-specific details to
ref-sp-js-userscript.
Independence
- Assume one standalone browser app should not need another app's runtime files.
- If local assets or helpers exist, keep them inside the same app folder.
- Only create shared runtime layers when the user explicitly wants repository-wide reuse.
Example Layouts
Single-file local app
src/features/example-mini-lab/
example-mini-lab.html
Standalone app with local sibling assets
src/features/example-dashboard-kit/
index.html
css/styles.css
js/app.js
assets/empty-state.svg
Validation
- The app remains understandable without framework knowledge.
- HTML is semantic, JS responsibilities are clear, and repeated values are named.
- Local extraction improved readability instead of adding ceremony.
- The app does not introduce hidden coupling, unnecessary framework assumptions, or avoidable build machinery.
- Lower-level JavaScript module and JSDoc choices are delegated to
ref-sp-js-javascript instead of being duplicated here.
References
- MDN HTML Element Reference: https://developer.mozilla.org/en-US/docs/Web/HTML/Element
- MDN JavaScript Modules: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules
- Read
ref-sp-js-javascript for detailed JS module, JSDoc, and runtime-surface guidance inside the chosen standalone app model.
- Read
./references/checklist.md for a quick standalone-app review pass.
- Read
./references/library-recommendations.md when choosing browser-loadable UI or utility libraries for a no-build app.
- Read
./assets/trigger-eval-queries.example.json when testing trigger quality for standalone app and browser-tool prompts.
- Review
./evals/evals.json when validating output quality for structure or extraction guidance.
1---2name: ref-sp-js-web-standalone-template3description: App-level guidance for standalone HTML, CSS, and JavaScript tools that should run without framework or build-system overhead. Use when: creating or reviewing a whole browser-only app, deciding whether it can stay no-build, or choosing local assets and browser-loadable libraries.4license: MIT5---67# Standalone Web App89## Purpose1011Provide app-level defaults for self-contained browser apps and local web tools that should stay simple, readable, and maintainable without unnecessary framework or build-system overhead.1213## When to use this skill1415- Creating a standalone browser app or local web tool.16- Refactoring a no-build web app that is getting too large.17- Deciding whether the app can stay framework-free or should escalate to a full React and Next app.18- Choosing local assets and browser-loadable libraries for a whole standalone app.1920## Scope Boundaries2122- Use this skill for whole browser-only apps and local web tools you control directly.23- Use `ref-sp-js-next-template` when the user explicitly wants a full React and Next app rather than a no-build browser app.24- Use `ref-sp-js-react` or `ref-sp-js-next` only after the app has deliberately crossed into those frameworks.25- Use `ref-sp-js-userscript` when the code runs inside a userscript manager on someone else's page.26- Use `ref-sp-js-javascript` for detailed JavaScript module, JSDoc, and runtime-surface questions once the standalone app model itself is chosen.27- Use `ref-sp-dev-projects-architecture` when the question is about repo-wide structure rather than one browser app.2829## Defaults3031- Start with one self-contained HTML file for small and medium apps.32- Use semantic HTML before reaching for generic containers — choose the element for the behaviour it33 carries, not for how it looks. Element table, landmarks, and heading rules:34 `.agents/skills/ref-sp-ux-accessibility/references/semantic-structure.md`.35- Prefer no package manager or build pipeline by default.36- If Node-based tooling becomes necessary, prefer Yarn for dependency management and scripts.37- For richer no-build UI, prefer browser-loadable UI libraries over re-creating every control from scratch.38- Do not introduce React or a build pipeline by default.39- Keep styles and scripts local unless extraction clearly improves readability.4041## Task Framing4243| Command or action | What | Why | When | Expected outcome |44| --- | --- | --- | --- | --- |45| Start with the smallest viable app | Keep HTML, CSS, and JS local until complexity proves extraction is needed. | Standalone tools become harder to move and maintain once they inherit premature infrastructure. | When creating a new browser-only app. | The app is easy to open, reason about, and iterate on. |46| Split a growing app locally | Extract sibling CSS or JS files inside the same folder when the inline version gets hard to scan. | Local extraction improves readability without creating cross-app coupling. | When one file is becoming mentally heavy. | Structure is clearer but the app still ships as an independent unit. |47| Compare no-build versus framework escalation | Decide whether the requirement still fits a no-build browser app or has crossed into full-app territory. | Framework escalation is expensive when the app could stay local and simple. | When state, routing, or deployment expectations start growing. | The chosen app model matches the real complexity. |4849## Core Rules5051### Structure5253- Use semantic sections such as `header`, `main`, `section`, `form`, and `dialog` where they fit.54- Keep the app layout obvious from the markup alone.55- Extract CSS or JS into local sibling files only when the inline version becomes hard to scan.56- Initialize app state and construct any singletons from one entry script rather than as a side effect of an imported helper module; keep extracted JS siblings inert on import. See `ref-sp-js-javascript` for the general import-side-effect rule.5758### Local asset boundaries5960- Keep the main page on `.html` and colocate any extracted CSS, JS, and assets inside the same app folder.61- Extract local assets only when the single-file version has become hard to scan.62- If the app also ships with a userscript, keep that handoff explicit and route the userscript-specific details to `ref-sp-js-userscript`.6364### Independence6566- Assume one standalone browser app should not need another app's runtime files.67- If local assets or helpers exist, keep them inside the same app folder.68- Only create shared runtime layers when the user explicitly wants repository-wide reuse.6970## Example Layouts7172### Single-file local app7374```text75src/features/example-mini-lab/76 example-mini-lab.html77```7879### Standalone app with local sibling assets8081```text82src/features/example-dashboard-kit/83 index.html84 css/styles.css85 js/app.js86 assets/empty-state.svg87```8889## Validation9091- The app remains understandable without framework knowledge.92- HTML is semantic, JS responsibilities are clear, and repeated values are named.93- Local extraction improved readability instead of adding ceremony.94- The app does not introduce hidden coupling, unnecessary framework assumptions, or avoidable build machinery.95- Lower-level JavaScript module and JSDoc choices are delegated to `ref-sp-js-javascript` instead of being duplicated here.9697## References9899- MDN HTML Element Reference: <https://developer.mozilla.org/en-US/docs/Web/HTML/Element>100- MDN JavaScript Modules: <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules>101- Read `ref-sp-js-javascript` for detailed JS module, JSDoc, and runtime-surface guidance inside the chosen standalone app model.102- Read `./references/checklist.md` for a quick standalone-app review pass.103- Read `./references/library-recommendations.md` when choosing browser-loadable UI or utility libraries for a no-build app.104- Read `./assets/trigger-eval-queries.example.json` when testing trigger quality for standalone app and browser-tool prompts.105- Review `./evals/evals.json` when validating output quality for structure or extraction guidance.
swiftpostlabs