code-developmentlisted

Guides a feature, bugfix, or patch through three tasks in strict sequence: (1) scope and design — read the repo, research best practices, surface every open question and design choice, and stop for explicit sign-off on a written plan; (2) implement — feature branch, smallest change, security first, written to pass SonarQube/CodeQL/lint, no commit until local tests actually run and pass; (3) document — update or create README/docs with fresh Playwright screenshots from a local run or mocks, sweeping stale images even on a bugfix. Ends by pushing and opening a fully filled PR (stacked PRs for larger work), then hands CI to ci-pipeline. `/code-development init` records validated test, lint and PR conventions in `.claude/code-development.yml`. Use on /code-development, "develop a feature", "fix a bug", or any ask to build, implement, fix, or patch code — even if coding already started. Not for CI failures (/ci-pipeline), releases (/release), or reviewing others' PRs. Needs git and gh — Claude Code only.
dawg-io/claude-skills · ★ 0 · Code & Development · score 72

Install: claude install-skill dawg-io/claude-skills

# code-development Takes a feature, bugfix, or patch from "I want X" to an open pull request, in three tasks that run strictly in sequence — scope, implement, document — so no task steps on another. This skill has real side effects: it creates branches, commits, pushes, and opens PRs. It never touches the default branch directly and never commits code whose tests haven't actually passed. Everything repo-specific — how to run the tests, what CI enforces, which branch to cut from, whether PRs open ready or draft, whether screenshots are expected — comes from **`.claude/code-development.yml` in the repo being worked on**, written by `/code-development init`. Without that file the skill rediscovers the same facts on every single run and has no record of the answers you gave last time. Hard rules, restated up front because they're the ones that erode mid-task: 1. **Never guess on direction.** Any design decision with more than one viable approach is a stop-and-ask: present the options with tradeoffs and wait. Research first — the repo's own conventions, then current best practice — before proposing anything. 2. **Task gates are hard.** Task 2 does not start until the Task 1 plan has the user's explicit sign-off. Task 3 does not start until Task 2's tests are green and committed. No look-ahead, no "while I'm here." 3. **No commit until local tests pass.** Run them for real. If they can't run, there is no commit — say why and stop. Never claim a command ran that