chrisrodz/dotfiles
Overview
This skill turns a GitHub issue into a single, self-contained, execution-ready specification for one feature or bugfix. It produces a concise scope block with explicit assumptions, file touchpoints, acceptance criteria, and an atomic task breakdown. The result enables coding agents or engineers to implement the change without follow-up.
How this skill works
The skill fetches the issue content, scans the repository for related files and patterns, and identifies precise touchpoints to modify or create. It resolves any blocking questions, drafts a scoped markdown block (summary, goals, touchpoints, tests, tasks), and presents it for confirmation before updating the issue. Each task is small, verifiable, and includes inputs, outputs, steps, validation, and complexity estimates.
When to use it
- An issue lacks clear scope, acceptance criteria, or validation steps.
- A report references a feature/fix but omits files or constraints to change.
- You need an execution-ready issue for a coding agent or CI-driven workflow.
- Convert an ambiguous bug report into a single-target patch spec.
- Prevent back-and-forth clarifications during implementation.
Best practices
- Keep scope focused to a single feature or fix; avoid epic-sized changes.
- Prefer explicit file paths and minimal, atomic tasks that can be independently validated.
- List assumptions and non-goals to prevent scope creep.
- Include both automated test commands and concise manual validation steps.
- Split tasks with complexity >7 into smaller pieces before publishing.
Example use cases
- Turn a dotfiles install failure report into a spec that lists modified shell scripts, expected outputs, and tests.
- Convert a missing alias request into a task list that updates specific shell config files and adds validation steps.
- Refactor a config loader bug into an issue that names the script to edit, required schema change, and test commands.
- Prepare a targeted fix for an install script that fails on a platform by specifying touchpoints and acceptance criteria.
FAQ
List the viable approaches briefly and recommend one unless the decision blocks implementation; document why it was chosen in the scope block.
How are task complexities estimated?
Complexity is a 1–10 estimate based on code familiarity and change scope; tasks above 7 must be split into smaller, verifiable steps.
