agentic-skills

Use when setting up a project's structure, or when the agent needs the stack, folder layout, data flow, schemas, and the hard boundary rules it must never cross. Use when code keeps crossing layers (UI logic in API routes, DB calls in components).

Use when planning what to build and in what order — splitting a project into sequenced, scoped feature phases so the agent never has to decide "what's next" on its own. Use when work feels like random feature-hopping.

Use when establishing or enforcing how code is written in a project — naming, conventions, file structure, error handling — so the agent stays consistent across sessions instead of drifting into its own style by week two.

Use when a project depends on third-party libraries and the agent needs project-specific usage rules — and must check for an MCP server or current docs — before coding against a library it only half-remembers.

Use when tracking build progress across sessions — a living checklist updated as features complete, so a new session knows exactly where work left off without re-explaining.

Use when starting a new project, or when the agent lacks a clear picture of what's being built, who it's for, and what is explicitly out of scope. Use when a build keeps producing things nobody asked for.

Use when tracking which UI components exist and their exact classes, so the agent reuses components instead of rebuilding divergent ones. The living index maintained alongside the imprint skill.

Use when defining how a product's UI looks and behaves — layout, cards, buttons, badges, typography — so every page feels like one product instead of the agent inventing a new style each session.

Use when setting up a project's visual primitives — colors, spacing, radii, type scale — as variables, so the agent never hard-codes hex values or invents inconsistent spacing across pages.

Use before building any non-trivial feature — when a prompt would otherwise make the agent guess at data models, API shape, auth, state, or module boundaries that haven't been decided yet. Use when you catch yourself about to "just start coding" something with real structure.

Use after building or changing UI — when new components were added and the design system could drift (buttons, spacing, colors, badges diverging across pages). Use when you suspect UI inconsistency has crept in across sessions.

Use when a session has gone wrong and you don't know why — the agent is spiraling, fixes aren't landing, output contradicts earlier work, or you're hours in and stuck. Use before trying yet another random fix.

Use at the end of a work session, before /clear, or when the context window is filling — when the next session would otherwise start cold and re-explain decisions already made. Also use the moment a durable decision or convention gets established mid-session.

Use after a feature or substantial change is built, before committing or moving on — when code was just generated and skimming it risks shipping a bug, a plan deviation, or an architecture-boundary violation you won't notice for days.