skills

Assists agents with when to ask questions via tools vs prose. Use when a request is ambiguous, has multiple valid interpretations, or needs a discrete choice before proceeding. Do not use when user input is not required, or a request has clear discrete options with concise descriptions.

Relentless Socratic interviewing on technical implementation choices — language, framework, dependencies, project structure — once a spec/PRD exists. Use when implementation is the question. When non-code/tech decisions, use `grilling`. When terminology, use `domain-grilling`.

Relentless Socratic interviewing focused on Domain-Driven Design (DDD) alignment — bounded contexts, ubiquitous language, glossary, terminology. Use when the user has a vague idea and conceptual/terminology alignment is the goal. When non-DDD decisions, use `grilling`. When code/tech with a spec, use `code-implementation-grilling`.

Relentless Socratic interviewing to extract clear decisions from vague ideas. Use when the user wants to think through an ambiguous decision that is neither code/tech nor domain modeling or terminology alignment — business strategy, product direction, design choices, process, organizational decisions, and similar non-implementation decisions. Do not use for code/technical implementation choices — use `code-implementation-grilling` instead. Do not use for domain modeling or terminology alignment — use `domain-grilling` instead.

Coordinate implementation of a normalized ticket set — builds the dependency DAG, groups same-file tickets, dispatches each group to a sub-agent with a fresh context, runs a judge LLM against acceptance criteria, and commits one commit per ticket. Use when a batch of tickets should be implemented in parallel/sequential order with per-ticket commits and an end-of-run report. Do not use for a single ticket (implement it directly), tickets not yet generated (use spec-to-tickets first), or non-ticket work.

Create implementation tickets with dependency graphs and Independent/Collaborative classification. Use when a user wants to break down a spec or tasks into tickets, or wants to create implementation tickets. Don't use when - spec is incomplete or vague (use grilling first, or domain-grilling if the resolution needs DDD alignment), a different granularity is needed (epics, tasks), direct implementation is the goal, or the user explicitly wants to send tickets to an issue tracker without dependency graphs or classification.

Generates an ecosystem-aware, user-facing markdown changelog by analyzing git history, transforming commit messages, and categorizing changes into logical sub-projects. Use when the user wants to write a changelog/release notes, or wants to know what happened between two specified versions. Do not use for summarizing git commit changes.

Guides users through the design, refinement, and deterministic translation of a new agent skill, ensuring the design follows established agent-skill conventions without performing file system writes. Use when creating or designing a new skill. Do not use when making minor tweaks to existing skills.

Configures a host repository to use the alastairlundy AI-agent skill family by writing four agent-consumable docs (issue-tracker, triage-labels, domain/GLOSSARY, decision-ledger-audit) and adding the `## Agent skills` block to AGENTS.md or CLAUDE.md. Use when setting up a new repo for AI agents, switching the repo's issue tracker, or re-running after a config change.

Audit a project's third-party dependencies for staleness, bloat, tight coupling, deprecation, and recent major changes. Use when a user asks to review dependencies, generate a dependency report, scan for unmaintained packages, or check for upgrade pressure. Also activate when an agent is judging dependency health as part of a broader review.