Loading...
Loading...
Found 13 Skills
Only when explicitly invoked by the user or precisely delegated by the Planner, implement a single DevFlow Task that has already passed planning and test review, or a Defect that has been attributed as an implementation issue; follow the original repository style, source branch, allowed paths, and change budget, add necessary tests and submit verification evidence, and do not take responsibility for review or merge.
Design and execute tests for an approved DevFlow Spec only when explicitly invoked by the user or precisely delegated by the Planner; maintain an acceptance traceability matrix; complete feature, contract, integration, E2E, regression, and real-scenario verification; output a test report and defect evidence bound to the Commit SHA; do not modify production code.
Actively use when the user requests software development, bug fixing, project continuation, refactoring, migration, or infrastructure changes; first confirm the host, installation scope, and same-source integrity, supplement the DevFlow Skill and the current platform's native roles as needed, and then continuously route four-role delivery. Explanations, general advice, standalone review or testing, documentation-only changes, and minimal risk-free edits do not start the full process.
Acts as the sole DevFlow Planner only when explicitly invoked by the user or precisely routed after entry preparation is complete; responsible for requirements, repository takeover, Spec, Task DAG, global state, coordination, and merging; does not write production code, and is not used for explanation, general advice, or mere documentation editing.
Independently review DevFlow's repository baseline, Spec, test plan, code commits, or release readiness only when the user explicitly invokes it or Planner precisely delegates; output structured conclusions based on file and version evidence, without modifying reviewed artifacts or implementing functionality.
Bug Fixing Skill - Read bugs/pending.csv to select bugs and automatically execute the 8-stage repair process
You MUST use this when verified work awaits a decision on how it leaves the branch - merging it, pushing it, opening a pull request (PR), keeping the branch, discarding the branch, or cleaning up a worktree or workspace - in any repository. Not for work that is not verified yet (verify), open review findings (cr-received), a plain commit with no integration decision, or release work with its own checklist. Replaces devflow branch-finish.
This skill should be used when reviewing pull requests, performing comprehensive code review, analyzing code changes before merge, or when the user asks for thorough/ultra-critical code review. Performs EXTREMELY CRITICAL 6-pass analysis identifying runtime failures, code consistency issues, architectural problems, environment compatibility risks, and verification strategies. Posts structured review as GitHub PR comment. Use when user asks to "review PR", "review this code", "review changes", "check this PR", "analyze PR", "post review", or for Phase 3 of devflow. Supports parallel review mode with multiplier (code-review-3, code-review 6X) for consensus-based reviews. This is an ultra-critical reviewer that does not let things slip and desires only perfection.
You MUST use this when work has to be designed before any code is written - a new feature, a change to product or UX behavior, an architecture change, success criteria that are still unclear, or a choice between two materially different approaches - including a spec revision after a document review. A fully specified mechanical refactor, a localized fix whose expected behavior is known, or a config change with a single possible outcome gets no spec; the skill hands it to implement in one sentence. Turns the request into a spec with checkable acceptance criteria behind an explicit approval. Replaces devflow scope-triage.
You MUST use this when an existing implementation plan is to be executed, either directly in the current session or through subagents, including resuming an interrupted execution from the plan's execution record, or when one or two edits with an obvious approach need doing without a plan. Covers task-by-task execution with evidence, drift handling and blockers, and a resumable execution record. Replaces devflow inline-plan-dev and subagent-plan-dev. Not for writing a plan (plan-craft), checking finished work (verify), acting on review findings (cr-received), or merging, pushing, or opening a pull request (finalize).
You MUST use this when anyone - you, a subagent, or the user - is about to state that work is done, fixed, ready, or mergeable, and before the commit that completes it, a merge, opening a pull request, or a handoff report, including work that has no plan. Covers every promise behind the claim - spec criteria, plan tasks, journal entries, accepted review fixes, and the caller's words - proven with fresh checks on the current tree and given one verdict, without editing code. Not for fixing failures (implement) or reviewing (cr-request). Replaces devflow verification-gate.
You MUST use this when a spec the user approved, an accepted design, or requirements already agreed in the conversation have to be turned into an ordered, multi-step implementation plan before any code is written - including a spec from specify, work with no spec yet, and a plan revision after a document review. Replaces devflow plan-crafting. Covers whether a plan is needed, task order, acceptance-criteria coverage, and the execution choice. Not for open design (specify) or executing a plan (implement).