Preset examples

These examples are generated from the same preset data the builder uses. Open a preset landing page for more context, or jump straight back into the generator with the preset query param applied.

Next.js Static Export

# Project Purpose
- Project name: Next.js Static Export
- Purpose: Generate and maintain a focused Next.js Static codebase with explicit agent rules.
- Preset: nextjs-static
- Primary runtime: TypeScript + Next.js App Router
- Package manager: npm

# Hard Constraints
- Do not add API routes, server actions, or middleware.
- Do not add remote AI calls or repository scanning.
- Do not weaken static export to support convenience features.

# Setup and Verification Commands
- Install: `npm install`
- Dev: `npm run dev`
- Lint: `npm run lint`
- Typecheck: `npm run typecheck`
- Build: `npm run build`
- Test: `npm run test`

## Testing Instructions
- Cover markdown section order and omission behavior with Vitest.
- Cover lint heuristics for missing rules, duplicate commands, and placeholder text.

# Code Conventions
- Use TypeScript strict mode and explicit exported types.
- Keep generation and lint logic deterministic and side-effect free.
- Prefer small components and plain CSS over framework-heavy abstractions.

# Safety Rules
- Keep all draft data in browser memory and localStorage only.
- Do not add runtime remote fetches, cookies, auth, or analytics SDKs.

# Git Workflow Rules
## Commit Rules
- Use Conventional Commits.
- Commit only after lint, typecheck, test, and build pass.

## Branch Rules
- Create a feature or fix branch for non-trivial work off the default branch.
- Keep each branch scoped to one logical unit.

## Pull Request Rules
- Summarize the changed preset or route behavior and list validation commands.
- Call out SEO, localStorage, or static-export impacts explicitly.

# Directory or Architecture Notes
- Keep routes in /app, reusable UI in /components, static preset and template copy in /content, and pure generation or linting helpers in /lib. Preserve static export compatibility across every route.

# Optional Project-Specific Notes
- Prefer query-param preset entry points such as `/?preset=nextjs-static` for landing-page CTAs.
# Project Purpose
- Project name: Vite React App
- Purpose: Generate and maintain a focused Vite React codebase with explicit agent rules.
- Preset: vite-react
- Primary runtime: TypeScript + React + Vite
- Package manager: npm

# Hard Constraints
- Do not add backend proxy endpoints or hosted prompt services.
- Do not add global state libraries without approval.
- Do not add form frameworks for simple structured inputs.

# Setup and Verification Commands
- Install: `npm install`
- Dev: `npm run dev`
- Lint: `npm run lint`
- Typecheck: `npm run typecheck`
- Build: `npm run build`
- Test: `npm run test`

## Testing Instructions
- Test deterministic builders and linters separately from UI shells.
- Prefer small fixture-driven tests over snapshot-heavy suites.

# Code Conventions
- Use strict TypeScript and explicit props for exported components.
- Keep browser-only state in client hooks and pure text generation in utilities.
- Avoid over-abstracting small UI flows.

# Safety Rules
- Keep user-entered content in browser storage only.
- Do not add telemetry, tracking pixels, or runtime data sync.

# Git Workflow Rules
## Commit Rules
- Use Conventional Commits.
- Keep commits scoped to one feature or bug fix.

## Branch Rules
- Use `feature/` or `fix/` branches for behavior changes.
- Avoid mixing unrelated UI and logic changes in one branch.

## Pull Request Rules
- Explain why the preset or lint guidance changed.
- List manual UI paths exercised when visual behavior changes.

# Directory or Architecture Notes
- Keep entry wiring near /src/main, colocate feature UI by domain, keep shared components obvious, and isolate pure utilities from browser-coupled hooks.

# Optional Project-Specific Notes
- Prefer plain inputs and repeatable rows instead of drag-and-drop builders.

Chrome Extension MV3

# Project Purpose
- Project name: Chrome Extension MV3
- Purpose: Generate and maintain a focused Chrome Extension codebase with explicit agent rules.
- Preset: chrome-extension-mv3
- Primary runtime: TypeScript + Chrome Extension Manifest V3
- Package manager: npm

# Hard Constraints
- Do not add remote code loading or eval-like behavior.
- Do not request host permissions broader than the feature needs.
- Do not hide permission changes in unrelated commits.

# Setup and Verification Commands
- Install: `npm install`
- Dev: `npm run dev`
- Lint: `npm run lint`
- Typecheck: `npm run typecheck`
- Build: `npm run build:extension`
- Test: `npm run test`

## Testing Instructions
- Cover manifest-sensitive builders or guards with unit tests.
- Verify permission-related lint rules whenever commands or surfaces change.

# Code Conventions
- Keep extension permissions minimal and explicit.
- Isolate browser API wrappers from view components.
- Document which scripts run in which extension context.

# Safety Rules
- Do not inject remote scripts or remote config fetches.
- Keep extension permissions and storage usage minimal.

# Git Workflow Rules
## Commit Rules
- Use Conventional Commits.
- Call out manifest or permission changes in the commit body when relevant.

## Branch Rules
- Use isolated branches for popup, content script, or manifest changes.
- Avoid bundling permission changes with unrelated UX polish.

## Pull Request Rules
- Highlight manifest or permission changes near the top of the summary.
- List the extension surfaces manually exercised.

# Directory or Architecture Notes
- Separate extension surfaces clearly: popup, options, background, and content scripts should not share accidental globals. Keep manifest generation and permission declarations easy to audit.

# Optional Project-Specific Notes
- Keep generated AGENTS rules explicit about popup, background, and content-script boundaries.

Node CLI in TypeScript

# Project Purpose
- Project name: Node CLI in TypeScript
- Purpose: Generate and maintain a focused Node CLI codebase with explicit agent rules.
- Preset: node-cli-ts
- Primary runtime: TypeScript + Node.js CLI
- Package manager: npm

# Hard Constraints
- Do not add background services or daemons.
- Do not add remote dependency on hosted APIs for core behavior.
- Do not bypass validation for file writes or destructive commands.

# Setup and Verification Commands
- Install: `npm install`
- Dev: `npm run dev`
- Lint: `npm run lint`
- Typecheck: `npm run typecheck`
- Build: `npm run build`
- Test: `npm run test`

## Testing Instructions
- Test builders and linters as pure functions.
- Add fixture-sized tests for command parsing or output formatting when behavior changes.

# Code Conventions
- Keep CLI side effects explicit and easy to trace.
- Return structured results from pure helpers instead of printing deep inside them.
- Prefer small command modules over large switch-heavy entrypoints.

# Safety Rules
- Do not shell out to untrusted input without validation.
- Avoid hidden network calls or telemetry in CLI flows.

# Git Workflow Rules
## Commit Rules
- Use Conventional Commits.
- Keep commits focused on one command or output behavior at a time.

## Branch Rules
- Use `feature/` or `fix/` branches for CLI behavior changes.
- Do not batch unrelated command changes together.

## Pull Request Rules
- List affected CLI commands and exact verification commands.
- Call out any filesystem or output format changes.

# Directory or Architecture Notes
- Keep command entrypoints small, put argument parsing and validation near the CLI boundary, and keep text formatting or filesystem logic in pure utilities when possible.

# Optional Project-Specific Notes
- Use concise imperative guidance because CLI repos benefit from highly scannable AGENTS files.
# Project Purpose
- Project name: Python CLI
- Purpose: Generate and maintain a focused Python CLI codebase with explicit agent rules.
- Preset: python-cli
- Primary runtime: Python CLI
- Package manager: uv

# Hard Constraints
- Do not add web backends, auth, or hosted sync features.
- Do not add hidden network access for core flows.
- Do not replace deterministic builders with AI generation.

# Setup and Verification Commands
- Install: `uv sync`
- Dev: `uv run python -m your_package`
- Lint: `uv run ruff check .`
- Typecheck: `uv run pyright`
- Build: `uv run python -m build`
- Test: `uv run pytest`

## Testing Instructions
- Use pytest for builder and linter regression cases.
- Keep fixtures small and deterministic.

# Code Conventions
- Prefer typed functions and explicit return values.
- Keep CLI parsing close to the entrypoint and move business logic into modules.
- Avoid hidden globals and environment-dependent defaults.

# Safety Rules
- Do not send user content to remote APIs.
- Validate filesystem and subprocess inputs before use.

# Git Workflow Rules
## Commit Rules
- Use Conventional Commits.
- Keep Python environment or packaging changes isolated from feature work.

## Branch Rules
- Use focused feature or fix branches.
- Do not combine CLI UX changes with packaging overhauls in one branch.

## Pull Request Rules
- List `uv` commands used for validation.
- Call out packaging or entrypoint changes clearly.

# Directory or Architecture Notes
- Keep package code under a single import root, keep CLI entrypoints thin, and keep formatting or parsing helpers pure enough for fast unit tests.

# Optional Project-Specific Notes
- Replace placeholder module names like `your_package` before exporting the final file.