turtle_ai

Use this to generate a concise, repo-aligned implementation plan for a selected backlog item, or the next unchecked backlog item when none is provided. Produces atomic, checkbox-based steps scoped to the current feature. Do NOT write code or modify backlog state.

Use this when generating a final, concise git commit message for a completed feature, based on plans, feature docs, backlog updates, and modified files. Typically used after implementation, verification, and documentation are complete. Do not use for planning, implementation, debugging, or modifying code.

Use this when diagnosing failures detected in VERIFY, TEST, ENGINEER CHECKPOINT, or runtime validation, and determining the minimal safe fix and correct routing (EXECUTE or TEST). Do not use for planning, feature implementation, or routine changes.

Use this to implement exactly the first unchecked step in the active plan file, or apply minimal fixes after VERIFY fails. Do not skip steps, expand scope, modify plan state, update backlog status, test, review, or perform multi-step changes.

Use this when creating or updating docs/features/<feature_slug>.md to document a completed feature, including summary, decisions, architecture impact, tests, and follow-ups. Typically used after implementation, verification, and backlog updates are complete. Do not use for planning, implementation, debugging, or testing.

Use this only after a feature has fully completed the Plan-Driven State System and needs to be marked done in docs/backlog.md. This skill updates one matching backlog item from unchecked to checked. Do not use for creating backlog items, planning, implementation, debugging, testing, or summarizing the backlog.

Use this to determine and implement the minimal, correct set of tests for the current active plan step, ensuring behavior validation without modifying feature logic or expanding scope.

Use this to verify the engineer’s understanding of the current plan step after VERIFY passes, via a one-question-at-a-time checkpoint interview with scoring, confidence tracking, and recovery. Do not use for planning, implementation, debugging, or testing.

Use this to review the latest implementation for the current plan step and determine PASS or FAIL based on correctness, scope, risks, and alignment with the plan. Do not implement fixes or expand scope.

Use this when analyzing a repository to build or refresh understanding of its architecture, modules, data flow, and testing patterns. Typically used when starting in a new repo, entering unfamiliar areas, or when repository context is incomplete or outdated. Do not use for feature planning, implementation, debugging, or routine small changes.

Use this when reviewing a completed feature for performance risks across API, database, and frontend paths. Typically run after implementation and verification, before finalization. Do not use for planning, implementation, debugging, or testing.

Use this when reviewing a completed feature for security risks across authentication, authorization, data handling, and API boundaries. Typically run after implementation and verification, before finalization. Do not use for planning, implementation, debugging, or testing.

Use this to safely mark the current plan step as complete only after the full loop (EXECUTE → VERIFY → ENGINEER CHECKPOINT → TEST → DEBUG if needed) has passed, ensuring strict state integrity. Do not use for planning, implementation, debugging, or partial progress.

Use this when generating grounded feature ideas and improvements based on the current repository. Typically used at the start of the discovery phase or when identifying gaps in UX, architecture, testing, or developer experience. Do not use for planning, implementation, debugging, or backlog structuring.

Use this when converting IDEATE output into a structured backlog or when updating docs/backlog.md with new items. Typically used after ideation or when refining product scope. Do not use for planning, implementation, debugging, or testing.

Use this when creating or updating repo_map.md to provide a high-level navigation map of the repository, including key directories, modules, entry points, and protected paths. Typically used when onboarding, analyzing a new codebase, or when repository structure has changed. Do not use for planning, implementation, debugging, or testing.

Use this when creating or updating agents.md to define repository rules, coding conventions, and safety constraints. Typically used at project setup or when conventions are unclear or outdated. Do not use for planning, implementation, debugging, or testing.

Use this when creating or updating architecture.md to define the system blueprint, including components, data flow, and architectural constraints. Typically used during initial project setup or when the system structure has changed significantly. Do not use for feature planning, implementation, debugging, or testing.