Reviews Python code changes for quality, correctness, and adherence to project conventions before commits or PRs. Checks for SOLID violations, DRY/YAGNI issues, missing tests, type safety, security concerns, and style compliance. Use when reviewing diffs, preparing PRs, after implementing features, or when the user asks to review code. Python-specific — covers ruff, pyright, pytest, and modern Python 3.13+ idioms by default (falls back to the project's pyproject.toml `requires-python` floor if it pins something lower). For deep silent-failure hunting or type-invariant design, use code-review's targeted agents instead.
Turn clear requirements into an ordered, verifiable implementation plan. Use when a spec or well-understood goal needs decomposition before coding — when the task feels too large to start, the order of work isn't obvious, or scope must be communicated. Trigger phrases include: "plan this", "break this down", "make an implementation plan", "how should we implement this", "create a task list", "what order should we build this in". This skill defines HOW to build and in what order — it assumes WHAT to build is already pinned down. If requirements are loose, unverified, or missing, first run the task-scoping skill (task-scope-and-spec: scope a loose engineering task into a tight, testable spec list) or gather inputs per the Input Gate below.
Scope a loose engineering task into a tight, testable spec list. Use when the user gives background for a piece of work and wants the requirements narrowed down before implementation. Trigger phrases include: "scope this", "what are the specs", "what's involved", "what would it take", "what's left for this task", "port this to", "bring this logic to", and "spec this ticket/issue". This skill defines WHAT must be true when the work is done — it does not produce an implementation plan, task ordering, or execution steps. For sequencing the specs into ordered, verifiable tasks, use planning-and-task-decomposition instead.
Bootstrap the .hac/ (Human-Agent Context) directory in any project. Use when the user says "set up hac", "add .hac", "set up working memory", "initialize hac", or when beginning multi-session work on a project that lacks a .hac/ directory. Language-agnostic — works for Python, TypeScript, Go, Rust, or any project type. Also trigger when migrating existing plan files into .hac/ or when resetting a stale .hac/ directory.
Write focused pytest tests covering critical paths, edge cases, and error handling. Avoids redundant tests that bloat codebase. Use for creating minimal but comprehensive test coverage of complex logic, public APIs, and failure scenarios.
Generates a minimal, clear PR description from the current branch's diff and the repo's PR template. Use at the end of any task when the user wants to open a PR or needs a PR description written.
Extracts what the user actually wants instead of what they think they should want. Achieves this through one-question-at-a-time interview until ~95% confidence about the underlying intent. Use when an ask is underspecified ("build me X" without "for whom" or "why now"), when the user explicitly invokes ("interview me", "grill me", "are we sure?", "stress-test my thinking"), or when you catch yourself silently filling in ambiguous requirements before any plan, spec, or code exists.
Implement a spec fully, verify each requirement with parallel agents, and produce a report. Use whenever the user runs /goal-workflow, mentions "implement spec", "verify against spec", or wants to go from requirements to verified implementation in one shot. Even if the request seems simple, invoke this skill — it handles both small and large specs.