dotfiles

Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Also use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT use for non-coding requests (general knowledge, prose, translation, summaries, recipes).

Read a tasks.json file, resolve dependencies, and implement each task in the correct order using the task-pipeline CLI. Use when a tasks.json exists and needs execution. Do NOT use when there is no tasks.json (use implement instead).

Convert a Product Requirements Document (PRD) into a structured tasks.json file with tasks, dependencies, priorities, and estimated effort. Use when a PRD exists and the user wants to break it down into implementable tasks. Do NOT use when there is no PRD or when the user wants to skip planning.

Structured brainstorming session using proven ideation techniques. Generate creative ideas, explore alternatives, and document your brainstorming session. Use when exploring new features, solving problems creatively, or needing multiple solution approaches before deciding.

When requirements are ambiguous, incomplete, or the agent is not 100% sure about what to implement — stop and ask clarifying questions before writing code or making changes.

A relentless one-question-at-a-time interview that stress-tests a plan or design while writing the shared vocabulary and hard decisions down as it goes. Produces a PRD.md at the end. Use when starting a new feature or project and you need deep requirements understanding before implementation.

Directly implement a feature or fix without tasks.json orchestration. Use when: the task is simple (single file, config change, straightforward feature), or when there is no tasks.json and the user wants to start coding immediately. Do NOT use when: there is a tasks.json (use implement-tasks instead), or when requirements are unclear (use grill-with-docs first).

Deep research skill for exploring codebases, searching the web, and understanding technical context. Uses Feynman Technique to ensure comprehension before proceeding. Use when you need to understand existing code, find documentation, research best practices, or gather context before implementing.

Format and lint Markdown files following standard conventions and best practices. Use when the user asks to format markdown, lint markdown files, fix markdown formatting, or ensure markdown follows style guidelines. Do NOT use when the user wants to convert between formats (Markdown to HTML, etc.) or when processing non-Markdown content.

Quality assurance and testing validation after implementation. Runs tests, validates acceptance criteria, checks edge cases, and ensures the implementation meets requirements. Use when: implementation is complete and needs validation, or when the user asks to "test this", "QA check", or "validate implementation". Do NOT use when: no implementation exists yet, or for code review (use review skill).

Comprehensive code review after implementation. Analyzes code quality, security, performance, and adherence to patterns. Use when: code has been implemented and needs review before merging, or when the user asks to "review this", "check my code", or "PR review". Do NOT use when: no code changes exist, or during initial implementation (review happens after).

Read and modify Pi settings (global or per-project) based on user instructions. Knows the settings schema, file locations, and how to apply changes.