dev-plan

Builds and rebuilds game development plans as playtest-verifiable tasks and milestones.

Updated Apr 27, 2024
One-click install
npx skills add https://github.com/IgorGribowsky/rts-sandbox --skill dev-plan-igorgribowsky
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dev-plan
Source: https://github.com/IgorGribowsky/rts-sandbox/tree/main/rts-sandbox-src/.claude/skills/dev-plan
Command: npx skills add https://github.com/IgorGribowsky/rts-sandbox --skill dev-plan-igorgribowsky

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Game development plans often degrade into task lists that cannot be verified or lose their status history when rebuilt. This Skill structures plans so every task can be checked with a single playtest and every rebuild preserves existing statuses and IDs. ## Core Features & Use Cases - Playtest-driven task slicing: Splits work into vertical slices where each task is verified by one playtest, with a mandatory "How to verify" section describing what to press and what should happen. - Milestone and version management: Orders tasks so playability arrives early, keeps exactly one version as current, and parks deferred work in a backlog milestone. - Merge-based plan rebuilds: Rebuilds plans without resetting statuses, reusing IDs, or reopening closed versions, using board.js for ID allocation and validation. - Use Case: When running /plan on an RTS engine project, generate a first version covering scene setup, player control, combat, defeat/restart, and scoring, each task verifiable in one playtest. ## Quick Start Ask the assistant to run /plan and build or rebuild the development plan for the current game version.

Frequently Asked Questions about dev-plan

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

FAQPage Schema
How do I structure a game development plan into tasks?

Slice work into vertical tasks where each one can be verified by a single playtest, such as "enemy chases and dies from a bullet" rather than infrastructure layers. Every task must include a "How to verify" section describing what to press and what should happen.

How to rebuild a project plan without losing task statuses?

Treat rebuilds as merges, not regeneration: keep existing IDs and statuses, edit only titles, bodies, and ordering. Allocate new IDs with board.js --next-id, mark dropped tasks as cancelled or move them to backlog, and never touch closed versions.

What order should tasks follow in a first game version?

Order tasks so playability appears as early as possible: entry point and scene, player control, core action, opposition, defeat and restart, then feedback like score. The principle is playable first, variety later, and the order can be freely rearranged.

How do I validate a development plan file?

Run node .claude/scripts/board.js --validate and expect zero errors. Also confirm every task has a filled "How to verify" section, the first version ends in something playable, and no status was reset compared to before the rebuild.

When should a task be split into subtasks?

Split a task when it does not fit in one work session or cannot be verified by a single playtest. Subtasks get suffixed IDs via board.js --next-id with the parent ID, and the parent becomes a container that is never taken into work directly.