implementation

Implements one planned task with code and tests, then runs the tests and records results.

Updated Aug 4, 2026
One-click install
npx skills add https://github.com/rombel00/game-processes --skill implementation-rombel00
Or copy as Structured Prompt for Agentā–¼
Please help me install this Agent Skill.
Skill: implementation
Source: https://github.com/rombel00/game-processes/tree/main/plugins/delivery/skills/implementation
Command: npx skills add https://github.com/rombel00/game-processes --skill implementation-rombel00

SYSTEM DOCUMENTATION & REQUIREMENTS

šŸ’” This Skill includes references (resource) components.

What problem does it solve? It prevents unfinished or unverified implementation work by enforcing that each task from a delivery plan is coded strictly to its description, tested by actually running the tests, and documented in a shared test report instead of being taken on faith. ## Core Features & Use Cases - Single-task implementation: Takes exactly one task from the plan, checks the test report history to find the first unclosed task, and implements it without scope creep or unsolicited refactoring. - Evidence-based testing: Writes end-to-end, unit, and regression tests, runs them, and distinguishes real proof from mock/stub-only coverage of production-relevant branches. - Cumulative test report: Maintains one test_report file per slice with an up-to-date acceptance criteria coverage table, changed files list, and per-task history. - Use Case: A game development team has a task plan for a playable slice; the skill picks the next open task, implements the board-rendering logic against the agreed wireframes, runs the full test suite, updates the coverage table, and commits before handing off to code review. ## Quick Start Ask the agent to implement the next open task from the plan and update the test report with the results.

Frequently Asked Questions about implementation

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement one task from a plan without scope creep?ā–¼

Take exactly one task, implement it strictly per its description, and treat anything beyond the description as an open question for the owner rather than silently expanding scope. Do not refactor existing code unless explicitly instructed.

How do I know which task to pick up next from the plan?ā–¼

The plan is a static list with no state, so compare it against the task history section in the existing test report and take the first unclosed task. The first task of a slice creates the report file.

Why is mock-only test coverage not accepted as proof?ā–¼

A branch covered only by fake models, mock providers, or stub runtimes is not considered verified. If the task specification requires live evidence for an acceptance criterion, that is a mandatory gate, and unverifiable checks must be marked as awaiting live verification.

What goes into the test report after implementing a task?ā–¼

Update the acceptance criteria coverage table and the changed files list in place at the top, then append a history entry with new tests, regression tests, and anything blocked by the environment. One report file serves the whole slice.

When should code review be triggered after implementation?ā–¼

Commit the work first, since the review gate diffs against the task specification base rather than the working tree. Then propose the code-reviewer gate to the owner for the whole delivery task, with a limit of two review cycles.