FrogBaek
UserClaude Code plugins for AI-assisted development. cue-dev records the requirement, design, rejected alternatives and outcome next to your code, so you can trace back from any line.
Categories
Indexed Skills (14)
init
Use when setting up cue-dev in a repository for the first time, or when changing the conventions it already uses - the commit marker prefix, record language, or remote name. Also use when /cue-dev:start reports the repository is not initialized. Safe to run again on an initialized repository.
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
redo
Use when a cue-dev stage needs to be done over - the requirement was wrong, the design was wrong, the plan was wrong, or the implementation went off the rails. Do not hand-roll git reset or revert a stage marker yourself; use this instead.
requesting-code-review
Use when dispatching a code reviewer over a whole branch - how the reviewer is briefed, what range it reads, and how the diff reaches it. Whether an item gets one at all is settled by its check level at /cue-dev:start, not here.
status
Use when you or your human partner need to know where a cue-dev work item stands, when you have lost track of which stage is in progress, or after a compaction. Also use before redoing a stage, to see what will be discarded.
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
using-cue
Use when starting any conversation - establishes how to find and use skills, and how to recover the in-progress cue-dev stage after a compaction
using-git-worktrees
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
verification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
design
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
finish
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work
implement
Use when executing implementation plans with independent tasks in the current session
plan
Use when you have a spec or requirements for a multi-step task, before touching code
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.