v1.3-template-quality-review

Template Quality Review

A pause point before building more serious modules, miniapps, templates and websites.

Why this exists

SiteFactory has proven the workflow. Now the goal is to improve quality, consistency and usefulness before creating more modules, miniapps, templates, interfaces or pages.

This workspace pauses expansion and reviews the current templates, modules, workspaces, previews and prototypes before SiteFactory is used for serious app-building or website work.

Review scope

The review covers the current SiteFactory foundation and the reusable pieces that already exist.

minimal-landing template

Reusable static landing page starter.

component-library

First reusable component reference workspace.

create-project-flow

Standard project creation workflow.

prompt-builder

Agent-neutral prompt structure workspace.

registry

Main index for components, modules, miniapps, templates, projects and previews.

Sthlm Electro prototype

First real project prototype from the minimal landing template.

todo-list miniapp

First functional portable miniapp.

Review areas

Use these panels to judge whether a module, template, miniapp or workspace is ready for serious project use.

Design quality

Layout, hierarchy, spacing and visual restraint should support real content without decoration becoming the product.

Copy quality

Copy should be short, useful and adaptable. Templates need patterns, not filler that every project must remove.

Naming consistency

Names should follow NAMING.md. A button stays a button, a card stays a card, and a panel stays a panel.

Portability

Source files should remain plain, local-first and reusable outside the Astro preview shell.

Reuse

Reusable pieces should be easy to copy without dragging in project-specific assumptions.

Composability

Modules should fit together with other cards, panels, sections, workflows and miniapps without needing a redesign.

Integration readiness

Interfaces should make future data, API, upload, settings or state integration paths easy to identify.

State handling

Functional miniapps should make empty, loading, working, complete and error states clear when those states exist.

Agent readability

Future agents should be able to inspect sections, ids, class names and state files without needing chat history.

Preview flow

Canonical source and browser preview copies should stay clearly separated and easy to verify.

Registry accuracy

The registry should reflect what exists, where it lives, and whether it is draft, prototype, preview, working or live.

Deployment readiness

Deployment paths should be documented before a project is treated as production-ready.

Minimal landing review

The first landing template is useful for website-style outputs, but SiteFactory should also improve module and interface templates before treating any pattern as default.

  • works as source template
  • visually calm
  • easy to copy
  • no Astro dependency
  • needs stronger content patterns before serious use
  • may need variants later

Module and website readiness checklist

Use this checklist before starting a real module, miniapp, dashboard, interface or website from a template.

  • clear project purpose
  • real content, interface or functionality direction
  • visual identity
  • sections, panels, cards or views selected
  • source template selected
  • preview path defined
  • registry update planned
  • deployment path known

What not to do yet

These choices would add surface area before the current manual workflow has earned it.

  • do not create more artist pages just to test
  • do not create more modules without a clear reuse reason
  • do not overbuild design system
  • do not add dependencies
  • do not make templates too specific too early
  • do not build database/automation until manual flow becomes painful

Recommended next decisions

Quality should improve through a small number of deliberate choices.

  • improve minimal-landing only where website use cases need it
  • improve reusable module patterns before expanding output types
  • create a second template only if needed
  • refine Sthlm Electro only when content direction is clearer
  • keep using registry as the source of overview
  • only build new projects when they serve a real purpose

Next action options

Choose one path before adding more projects, modules or templates.

Improve minimal-landing template

Strengthen content patterns and adaptation guidance.

Improve component-library

Clarify the first reusable components through real examples.

Improve todo-list miniapp

Review the functional miniapp before extracting more app patterns.

Start real Sthlm Electro content work

Only move forward when the content direction is specific enough.

Create a stricter project brief template

Define the minimum purpose, reuse case, content, functionality and integration notes needed before a new build starts.