Frontend Functionality Docs

Goal

Produce or update a code-grounded frontend functionality reference that explains what each route or page does, what users can see, and what they can do from the UI.

When to use

Use this skill when the user asks for things like:

• "document all frontend functionality"
• "refresh the route-by-route UI docs"
• "build an all-pages feature inventory"
• "update the frontend sitemap or page reference"

Inputs to resolve

Before writing, determine:

• the frontend root or app package to inspect
• the target documentation file; if none exists, default to docs/frontend-functionality.md
• the routing system in use, if it is not obvious from the file tree

Quick start

1. Run the route inventory helper:

   bash skills/frontend-functionality-docs/scripts/collect-frontend-routes.sh <repo-or-frontend-root>
   

2. Compare the current route inventory against the existing documentation and any maintained sitemap, navigation manifest, or AGENTS.md route notes.

3. For each route, inspect the route entry file first, then follow imports into stateful or complex UI components.

4. Update the documentation so every documented behavior is backed by source code or explicitly marked as inferred/runtime-observed.

Route inventory sources

Use real route entrypoints as the primary source of truth. Common patterns include:

• Next.js App Router: app/**/page.*
• Next.js Pages Router: pages/** excluding pages/api/** and framework files such as _app
• Remix / React Router file routes: app/routes/**
• File-based routers such as TanStack Router: src/routes/**
• Explicit router configs that define paths in code

Treat sitemap docs, nav configs, and rule files as cross-checks, not authoritative sources.

What to document per route

• Purpose: what the page is for in one sentence
• Layout and content: major sections, tables, cards, forms, tabs, drawers, modals
• States: empty, loading, error, disabled, gated, feature-flagged, or permission-gated states that are visible from the UI
• Interactions: buttons, links, filters, search, toggles, inline edits, keyboard-visible behavior, pagination, sorting, selection
• Navigation behavior: route params, query params, redirects, tabs, breadcrumbs, deep links
• User-triggered external writes: label any create, edit, delete, upload, auth, integration, or other write action as an external write without speculating about backend outcomes

Documentation rules

• Prefer URL paths as headings when they are easy to infer; otherwise use the route file path and note the likely URL.
• Keep a consistent schema across routes so diffs stay readable.
• If a route is present in code but missing from docs, add it.
• If docs describe behavior no longer present in code, remove or correct it.
• If a route exists but is clearly internal, experimental, or gated, document that status.
• Call out important shared components only when they materially change page behavior.

Suggested workflow for complex routes

When a route is thin and delegates most behavior elsewhere:

1. Read the route entry file to identify layout, data hooks, guards, and child components.
2. Follow imports into the main content component, modal, table, or form components.
3. Check nearby hooks, providers, or route loaders/actions when they affect visible states or interactions.
4. Summarize only what is user-visible or necessary to explain a route's behavior.

Guardrails

• Do not infer backend side effects beyond what the UI clearly initiates.
• Do not copy implementation details that do not affect user-visible behavior.
• Mark uncertain items as inferred instead of presenting them as confirmed.
• If runtime verification is possible and the code is ambiguous, use the running app as a secondary check.