About code-coder
A skill for handling small, unplanned coding tasks while following project rules and keeping diffs focused. It includes a test and code-review cycle, and redirects planned versions or GitLab issue work to other workflows.
Key features
- 01Implements focused coding tasks
- 02Loads project and harness rules
- 03Keeps changes limited to task scope
- 04Runs relevant tests
- 05Reviews diffs for critical issues
Use cases
- 01Fixing a bug outside a planned release
- 02Updating an isolated component or utility
- 03Making a small refactor or script change
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ nextstage-brasil/ skills --skill code-coderAfter installing, type/code-coderin Claude Code to confirm it loaded.
Bundled filesevals/evals.json
Details
From the project READMECode Coder
Implement ad-hoc coding tasks with minimal diff while respecting project rules.
Harness discovery
See ../nextstage-harness/references/harness-discovery.md. Load rules from {harness_root}/rules/*.md. Read architecture-rules.md first. Legacy: .cursor/rules/*.mdc only if {harness_root} is absent.
When to use
- Bug fixes and hotfixes outside a planned version
- Isolated component, hook, service, or utility
- Small refactors (≤ 1 file or tight group)
- Scripts, migrations, seeds outside version lifecycle
- "Just implement this" without
execution-handoff.md
For full planned versions with execution-handoff.md, follow
../execution-handoff-generator/references/run-implementation.md and update the
handoff per ../execution-handoff-generator/SKILL.md — not this skill's ad-hoc
cycle below.
If the request includes a GitLab issue URL (ISSUE_URL), use execution-gitlab-issue instead — not this skill.
Session inputs
| Variable | Required |
|---|---|
{product_root} | Yes (or infer if single obvious product) |
{task_description} | Yes |
{target_layer} | Infer when possible: frontend, backend, infra, tests, fullstack |
Scope isolation
Operate only under {product_root}/** plus harness docs. Do not read other products in a monorepo unless asked.
Boot (mandatory)
- Read
AGENTS.md - Load layer rules from harness when present (architecture always; backend/frontend/tests/e2e by layer)
- Load product context: follow Implementation boot rule in
../nextstage-harness/references/artifact-layout.md git statusandgit diff- Read target files before writing
Implementation rules
- Diff-first — only required lines; no unrelated formatting
- Prefer editing existing files over new files
- Large change gate: >1 file simultaneously, >20 lines in one file, or public contract change → one-line plan, wait for approval
- No commits unless human explicitly asks — when committing, see
../nextstage-harness/references/agent-git-identity.md - No SDD artifacts — no
task-NNN.md,requirements.md,execution-handoff.md - No gratuitous comments unless requested
- Run tests per
AGENTS.mdDocker and testing; project-specific container and commands live inarchitecture-rules.md
Per-task cycle
- Understand task
- Load rules
- Explore relevant files
- Identify minimal diff
- Apply (or present plan if large-change gate)
- Run tests if in scope
- Review loop — invoke
code-reviewerand iterate on findings (see below) - Report what changed, final review verdict, and follow-ups
Review loop (mandatory)
After tests pass (step 6), run an internal review loop before reporting done.
- Invoke
code-revieweron the working-tree diff (git diff) — noISSUE_URL, no version-closure path. Just the ad-hoc diff. - Max 3 rounds. After each review:
- No Critical Issues (satisfactory score) → proceed to report.
- Critical Issues with rounds left → apply the minimal diff that resolves each Critical (
code-revieweris read-only, so this skill applies the fixes), re-run tests if in scope, then re-review. - Rounds exhausted with Criticals still open → stop and report as blocked. List the unresolved Criticals. Do not report success.
- Keep fixes within the original task scope. If a Critical finding requires changes outside scope (public contract, cross-product, multi-day work), stop and escalate per Stop conditions instead of expanding the diff.
- Warnings and Suggestions do not block: carry them into the final report as follow-ups.
Stop conditions
| Condition | Action |
|---|---|
{product_root} unclear with multiple products | Ask once |
| Large change gate | Plan + wait |
| Public contract or cross-product boundary | Stop, explain, ask |
| Task needs multi-day SDD planning | Redirect to planning |
Related skills
code-reviewer— mandatory review loop after implementation (see Review loop)code-investigator— if blocked by unclear bugcode-autonomous— autonomous multi-agent execution (GitLab issue or local plan); for a GitLab issue, useexecution-gitlab-issueinstead
Forbidden
- SDD artifact generation
- Cross-product access without scope
- Commits without explicit request
- Refactors outside task scope