daneel

Use when you have a written implementation plan to execute in a separate session with review checkpoints

Runs the Daneel GitHub admin CLI for labels, milestones, project board sync, issues, pull requests, releases, and review threads against the GitHub REST and GraphQL APIs. Use when the user or workflow needs GitHub repository or project maintenance, creating or updating PRs and issues (including bodies from files), syncing labels or milestones, posting verification comments, or any task matching the commands in this skill's reference.

Updates project tracking whenever a task transitions lifecycle state (started, blocked, ready-for-merge, done). Receives task context from the calling workflow, resolves the associated work item if one exists, then updates its status and posts a comment. Exits gracefully when no work item is found. Depends on the github-admin skill for GitHub operations.

Use proactively at the end of each implementation slice when project workflow requires it, or when a user asks to refactor, simplify, clean up, or restructure code while preserving behavior. Do not wait for an explicit user request if the workflow already mandates a post-implementation pass (features and bug fixes). Applies Martin Fowler style refactoring discipline and points to one reference file per refactoring from the official catalog.

Use when executing implementation plans with independent tasks in the current session; requires a refactoring skill pass at the end of each implementation slice (features and bug fixes) before the next review gate

Use when implementing any feature or bugfix, before writing implementation code

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs or MRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

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.

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

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

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

Use when you have a spec or requirements for a multi-step task, before touching code