From developer-workflow
Orchestrates full dev cycle in isolated git worktree: task understanding, TDD implementation, quality review, draft PR, CI/CD monitoring to merge-ready PR. Explicit invoke via /developer-workflow:implement-task.
npx claudepluginhub kirich1409/krozov-ai-tools --plugin developer-workflowThis skill uses the workspace's default tool permissions.
**Explicit-only.** Run this skill only when directly requested via `/developer-workflow:implement-task` — not on every implementation task.
Implements features from chat context or description via full agent workflow without tickets, boards, or status updates. Loads domain skills, plans, codes, tests, and opens PR.
Orchestrates task execution with git worktree isolation, TDD implementation, validation loop, and merge for phrases like 'execute task N' or 'implement TASK-NNN'.
Executes tech plans via dependency-aware task batching, TDD, incremental commits, section code reviews, and PR creation. Use after planning phases.
Share bugs, ideas, or general feedback.
Explicit-only. Run this skill only when directly requested via /developer-workflow:implement-task — not on every implementation task.
Full autonomous implementation cycle — from understanding the task to a merge-ready PR. Ask the user only when a decision is architecturally significant or irreversible. Everything else: decide and proceed.
If any phase fails: identify the root cause — if it's in current changes, fix and re-enter the phase; if pre-existing, ask the user; if unclear, invoke superpowers:systematic-debugging.
Invoke superpowers:using-git-worktrees. All subsequent work happens in that worktree.
Establish three things before writing any code:
Ask one clarifying question if any of these is ambiguous. Otherwise proceed.
Timebox exploration. Read only the entry point and immediate change surface. The goal is knowing enough to write the first failing test — you'll learn more as you implement.
For tasks that touch more than one file or introduce a new abstraction, invoke superpowers:brainstorming before writing code. Skip for single-file changes and focused bugfixes.
Select the most specific applicable skill and invoke it:
| Task type | Skill |
|---|---|
| Android/Kotlin technology migration | developer-workflow:code-migration |
| KMP migration | developer-workflow:kmp-migration |
| Multi-step feature or architecture change | superpowers:writing-plans → superpowers:executing-plans |
| Bug or unexpected behavior | superpowers:systematic-debugging |
| Any other implementation work | superpowers:test-driven-development (default) |
Follow the chosen skill throughout implementation. Switch to a more specific skill if a better match emerges.
The core TDD contract: write a failing test before writing the implementation code it covers. If the codebase has no test infrastructure, proceed implementation-first and flag the gap in the PR description.
Invoke developer-workflow:create-pr with draft intent as soon as the first meaningful commit exists — even before implementation is complete. This gives CI a head start and keeps progress visible.
Update the PR description after each major change so it stays current.
Once implementation is complete, invoke developer-workflow:prepare-for-pr. It runs build, simplify, self-review, and lint/tests in a loop — exit criteria and hook behavior are defined inside that skill.
After prepare-for-pr exits clean, run code-review:code-review. Fix any non-minor issues, commit, push, and repeat until only minor issues remain.
Undraft the PR and update its title and description using the ready-for-review template from developer-workflow:create-pr (the "Description template — ready-for-review PR" section). The description must be self-contained — a reviewer with no prior context should understand what changed, why, and how to verify it.
# GitHub
gh pr ready
gh pr edit --title "<final title>" --body "<final description>"
# GitLab
glab mr update --remove-draft --title "<final title>" --description "<final description>"
Invoke developer-workflow:pr-drive-to-merge and let it run. This skill pauses only when human input is needed (out-of-scope issues, merge confirmation, stale review).
After the PR is merged, invoke superpowers:finishing-a-development-branch for worktree cleanup and branch deletion.
| Ask the user | Decide autonomously |
|---|---|
| Architecture choices with long-term implications | Which file to edit |
| Breaking changes visible outside the PR | Variable or method naming |
| Unclear done criteria before starting | Whether to add a test |
| Reviewer raises an architectural concern | Order of code review fixes |
| Merge confirmation (handled by pr-drive-to-merge) | Obvious lint fixes |
git add path/to/file, never git add .<type>(<scope>): <what and why> (feat, fix, refactor, test, chore, docs)--no-verify