project-starter-template-en-ai

Instantiates this template into a real project through a guided interview — detects whether the project is new or existing, fills in the placeholders, adapts the docs to the project type, and decides the permissions policy. Use this when someone clones/adopts this template and wants to configure it for their project (e.g. "instantiate this template", "set up this template for my project", "bootstrap the project from this base").

Scaffolds a new lightweight change spec by copying the spec template directory into a named spec folder. Use this when the user wants to start a spec, plan a change/feature, or create a design doc before implementing (e.g. "spec out the checkout redesign", "create a spec for the new auth flow").

Ports the current branch's change to this template's sibling variants (es/en × with-AI/no-AI) — translates the content, adapts or removes the AI layer depending on the target, and leaves each variant with a PR-ready branch. Use this when a template change must be replicated in the other variants (e.g. "port this change to the Spanish template", "replicate this in the variants").

Cuts a new version — moves the CHANGELOG's Unreleased section to a dated SemVer version, creates the commit and the tag, and optionally the GitHub release. Use this when someone asks to publish/cut a version or prepare a release (e.g. "cut version 1.2.0", "prepare the release", "publish a new version"). Does not push without confirmation.

Brings into this project the improvements its origin template received after instantiation — reads .template-origin, computes the tooling diff (skills, hooks, scripts, workflows) against the current template and offers to apply it. Use this when someone wants to update/sync the project with the template (e.g. "update the template", "pull in the template's new improvements").

Drafts and creates a GitHub issue by filling out the right template from .github/ISSUE_TEMPLATE/ based on the type (bug, feature, documentation, task, or question). Use this when the user asks to open/create an issue, report a bug, or record a task/request (e.g. "open an issue for this bug", "create an issue for the new feature", "log this task"). Does not close or comment on existing issues.

Reviews a database migration before it ships to make sure it is safe — reversible, non-destructive, and backward-compatible — following the project's database conventions. Use this whenever you create, review, or approve a schema or data migration (e.g. "check this migration", "is this migration safe to deploy?").

Checks UI changes for accessibility — color contrast, keyboard navigation, focus management, ARIA usage, and alt text. Use this when the user asks for an a11y/accessibility review, to check WCAG compliance, keyboard support, screen-reader friendliness, or focus handling (e.g. "is this modal accessible?", "audit a11y on the form").

Updates CHANGELOG.md in the Keep a Changelog format, adding the current changes under the Unreleased section. Use this when the user asks to update the changelog, add a changelog entry, or record what changed for the release notes (e.g. "add this to the changelog", "update CHANGELOG for these commits").

Writes a Conventional Commits message for the staged changes and creates the commit, including the AI attribution co-author line. Use this when the user asks to commit, write a commit message, or save changes (e.g. "commit this", "make a commit for these changes"). Does not push.

Reviews or produces user-facing copy (UI text, headings, buttons, error messages, marketing) in the project's voice and tone. Use this when the user asks to write/improve copy, fix wording, check tone, or draft microcopy (e.g. "write the empty-state text", "make this error message friendlier", "review the landing headline").

Audits UI code against the project's design system — semantic tokens, allowed components, required interaction states, and the accessibility baseline. Use this when the user asks to audit/check design-system compliance, verify tokens are used instead of raw values, or confirm a component follows the design guidelines (e.g. "does this component follow our design system?", "audit the new card").

Checks internationalization parity — that every translation key exists in all locales and that no user-facing strings are hardcoded — following the project's i18n conventions. Use this when the user asks to check translations, verify locale parity, find missing/hardcoded strings, or audit i18n (e.g. "check i18n", "are all locales in sync?").

Scaffolds a new Architecture Decision Record (ADR) by copying the ADR template into the next-numbered file and registering it in the decisions index. Use this when the user wants to record an architecture decision, create/add an ADR, or document a technical choice (e.g. "write an ADR for switching the database", "add a decision record").

Drafts a pull request for the current branch by filling out the repository's PR template based on the branch's changes. Use this when the user asks to open/create a PR, prepare a pull request, or write a PR description (e.g. "open a PR", "draft the pull request for this branch"). Does not merge.

Improves code structure and readability WITHOUT changing observable behavior, in small safe steps guided by the project conventions, keeping tests green. Use this when the user asks to refactor, clean up, restructure, or reduce duplication in code without adding features or fixing bugs (e.g. "refactor this module", "clean up this function", "extract this logic").

Audits a page or route's SEO metadata (title, description, canonical, Open Graph, robots) against the project's SEO conventions and lists what is missing or wrong. Use this when the user asks to check/audit SEO, review meta tags, or verify a page is search-ready (e.g. "audit SEO on the pricing page", "check meta tags for this route").