skills

Use when the user wants to bootstrap a docs-driven AI+human development workflow in a new project, including PRODUCT.md, MILESTONES.md, milestone records, BUG_FIXES.md, bug-fix records, BUSINESS_RULES.md, business-rule records, COORDINATION.md, decision records, plans, checkpoints, research notes, setup docs, CHECKS, MANUAL_QA, ENV_VARS, SECURITY, changelog impact fields, templates, and coding-agent instructions for following the workflow; also use when upgrading an older existing planning workflow to the current conventions.

Use when the user asks to create, draft, add, or update a milestone in an existing project planning workflow, including finding the planning root, reading GUIDE.md, choosing the next three-digit milestone number, creating or updating milestones/NNN-slug.md, and updating MILESTONES.md without duplicating milestone detail into the index.

Use when the user asks to create, draft, add, or plan a new implementation plan in an established planning workflow, including finding the planning root, reading GUIDE.md, choosing the next milestone-scoped plan number, updating the target milestone record, creating a phase/checkpoint-ready plan file, and asking whether implementation should start afterward.

Use when the user asks to document, capture, record, create, or supersede an architecture/product/security/operational decision in an existing project planning workflow, including ADR-style decision records for major durable choices. If called with no explicit decision text, infer the latest major durable decision from the current chat; if there are multiple plausible decisions or the decision is unclear, ask a concise clarifying question before editing.

Use when the user asks to validate, audit, check, lint, or inspect a .specs planning workflow for structural consistency, missing required files, broken links, stale placeholders, invalid statuses, malformed plan/checkpoint names, missing changelog impact fields, or incomplete CHECKS.md and MANUAL_QA.md setup. Includes a bundled deterministic validator script.

Create a design guide / design system spec document (typically DESIGN.md) for a web or mobile UI project. Trigger whenever the user asks to "create a design guide", "write a design system doc", "create DESIGN.md", "write design guidelines", "draft a style guide", or wants any general visual / UX style document an LLM or developer can use as a reference when building components, pages, or screens. Also trigger for design specs for a webapp, SPA, mobile app, dashboard, or component library — even when they don't say "design guide" verbatim. Accepts optional context like framework (React, Vue), styling (Tailwind, CSS), UI library (shadcn/ui, Base UI, Radix, MUI), brand color, theme name, and product name. With no arguments, inspects the current project to infer them; missing fields are left open rather than guessed.

Use when the user asks for a prompt to start a fresh chat/agent for implementing an existing project plan, e.g. "write a prompt for Plan 003-001", "create the next plan implementation prompt", or "handoff prompt for .specs/plans/MMM-PPP-*.md". Also useful to continue a plan implementation that was stopped and is still in progress. After generating the prompt, ask whether implementation should start now.

Retrieves up-to-date documentation, API references, and code examples for any developer technology. Use this skill whenever the user asks about a specific library, framework, SDK, CLI tool, or cloud service -- even for well-known ones like React, Next.js, Prisma, Express, Tailwind, Django, or Spring Boot. Your training data may not reflect recent API changes or version updates. Always use for: API syntax questions, configuration options, version migration issues, "how do I" questions mentioning a library name, debugging that involves library-specific behavior, setup instructions, and CLI tool usage. Use even when you think you know the answer -- do not rely on training data for API details, signatures, or configuration options as they are frequently outdated. Always verify against current docs. Prefer this over web search for library documentation and API details.

Use when the user asks to generate, update, draft, or compare a CHANGELOG.md or release notes from .specs, planning docs, milestones, checkpoints, bug-fix records, decisions, business rules, manual QA, checks, security, env, setup, or other spec-based project records. Produces a prepend-only, non-destructive dated changelog block in product/spec language instead of summarizing commit messages.

Generate a Conventional Commit message for the repository's current staged changes. Use when the user asks for a commit message, commit title, git commit message, or conventional commit summary based on staged changes. The output must be only the message as plaintext code, with no explanation or follow-up text.