pell

Use ONLY when the user explicitly names this skill — e.g., "use autonomous-build", "kick off with autonomous-build", or an equivalent explicit request. Do NOT auto-fire on generic "build me X" / "new project" / "take it further" phrasings; those go through the normal flow.

Use when writing commit messages during greenfield product-building sessions, multi-commit feature series, or any session that will produce more than 5 commits. Also use when the commit history is itself serving as the product's design narrative (e.g., an investor will read `git log`, or the session is being captured as a skill).

Use when ranking a feature backlog under a "next level / take it further / mad jelly" mandate, when writing a product roadmap for someone who wants differentiation (investors, launch partners, review threads), or when asked to file GitHub issues for a list of candidate features.

Use when building or extending a product in an autonomous multi-hour session with an ambiguous "go big / next level / use the time well" mandate, and you could build either shallow-horizontal (more features of the same kind) or deep-vertical (each commit deepens the product's reach into a new semantic layer of purpose).

Use when the user grants an autonomous multi-hour budget ("4 hours", "keep going until I stop you", "you have 2.6h left"), or when the user asks you to check in on the clock, or when working quiet stretches with no per-change user feedback.

Use when a task is large enough to split across multiple subagents that you coordinate as the lead, rather than doing it all yourself in one context.

Use when working a long autonomous build or design session with little per-change user feedback, and you want grounded outside eyes on each change without the user having to review everything themselves.

Use at the START of any user-facing UI work in a Pell repo — building React components, pages, layouts, design systems, styling, Tailwind/CSS, marketing pages, dashboards, forms, or any task whose deliverable is something a human will look at in a browser.

Use when about to explain something inherently visual — architecture or data-flow diagrams, state machines, geometry or layout, before/after comparisons, tree or graph structures, timelines, or table-heavy comparisons — and a rendered view in a browser would communicate it better than terminal prose. Also use when soliciting a choice that's clearer as clickable options than as text.