dev-kit-work_skill

Overview

This skill implements existing tickets autonomously by reading ticket files in .dev-kit/tickets/, executing all acceptance criteria, and preparing the repository changes for review. It acts as a developer: parsing requirements, applying project standards, running tests, and producing a clear implementation summary. It stops before finalizing the ticket move and asks the user for confirmation to mark the ticket completed.

How this skill works

The skill loads a specified ticket file, extracts the user story, category, acceptance criteria, dependencies, and resources, then verifies prerequisites against other tickets and project documentation in .dev-kit/docs/. It implements each acceptance criterion by creating or modifying files, adding tests, and following repository patterns and type-safety rules. After testing and verification it summarizes changes, test results, and any follow-up work, then requests user approval to move the ticket to .dev-kit/tickets/completed/.

When to use it

• You have a Feature, Bug, Enhancement, or Chore ticket in .dev-kit/tickets/ that should be implemented end-to-end.
• You want an autonomous developer agent to write code, tests, and documentation following project patterns.
• You need to enforce project standards (type safety, import aliases, styling patterns) during implementation.
• You want the agent to surface discovered out-of-scope work and create follow-up tickets when necessary.
• You need a reproducible implementation summary and a curated list of modified/created files.

Best practices

• Only target non-Research tickets; Research tickets are redirected to the research skill.
• Write clear, complete acceptance criteria in ticket files so the agent can implement without repeated clarifying questions.
• Keep project docs up to date in .dev-kit/docs/ so the agent can verify standards and architecture.
• Allow the agent to run tests and modify the repo but require user confirmation before moving tickets to completed.
• When the agent discovers larger scope work, have it create follow-up tickets rather than silently expand the current task.

Example use cases

• Implementing a UI feature described in a ticket with acceptance criteria and adding unit and integration tests.
• Fixing a bug by following the ticket's reproduction steps, patching code, and adding regression tests.
• Applying an enhancement that touches multiple modules while maintaining project import and styling conventions.
• Completing a chore such as upgrading a dependency, updating configuration, and validating CI test runs.
• Detecting and extracting out-of-scope refactors into new tickets with clear dependency links.