
ns-coder
(NS) Ad-hoc coding — bug fixes, refactors, scripts, migrations — without full SDD. Entry priority 5: "just implement this", "quick fix", or coding without execution-handoff (C2 under ns-autonomous). Do NOT: ISSUEURL (ns-execution-gitlab-issue), multi-day/version (ns-spec-driven), product bug report / screen expected-vs-actual without diagnosiscomplete (ns-bug-report-diagnosis), diagnosis-only stack/CI (ns-investigator), when execution-handoff.md exists. Do NOT generate requirements/tasks/handoff.
- Installs
- 125
- Last 24h
- —
- Trending rank
- —
- Security
- Not audited
Install
Works with every agent the skills CLI supports.
npx skills add https://github.com/nextstage-brasil/skills --skill ns-coder- 01
Install
Run the command in your project. The CLI asks which agents to install for.
- 02
Describe the task
Ask your agent for something this skill covers. It loads ns-coder automatically when relevant.
- 03
Review the result
The agent follows the SKILL.md steps, scripts and references bundled with the skill.
SKILL.md
The instructions your agent reads when the skill is triggered.
Code Coder
Central execution worker for ad-hoc diffs (and C2 under ns-autonomous). Not front door — host picks entry per ../../ns-harness/references/code-skill-routing.md.
Workflow mode (mandatory)
Fixed workflow, not loose checklist. Steps in order; handoffs = named skills or harness bridges (coder-agent / reviewer-agent per ../../ns-harness/references/subagent-dispatch.md). No platform Task personas or improvised review.
Canonical review gate: ../ns-reviewer/references/review-gate-workflow.md — steps 7–9 ad-hoc / C2 only. Code review only via reviewer-agent then ns-reviewer (MUST bridge when available; else direct); then ns-judge in-session only if Code Review: Approved. Max 3 rounds per gate; Approved = score 10 only. Score 9 = Rejected (Lift + mandatory re-review). No success without both Approved or blocked. After Delivery Review: Approved: Living specs (8) if match, then Final report (9).
Exception — SDD handoff mode: caller run-implementation / execution-handoff.md (or dispatch says SDD task mode): skip review gate + living specs. Parent owns review at version closure. See When invoked under execution-handoff.
Routing (read first)
| Signal | Redirect |
|---|---|
GitLab ISSUE_URL detected | Stop — ns-execution-gitlab-issue |
| Multi-day / version / SDD scope | ns-spec-driven |
Product bug report / screen expected vs actual without diagnosis_complete | ns-bug-report-diagnosis |
BRD handoff with diagnosis_complete: true | Implement — do not return to ns-bug-report-diagnosis |
| Obscure bug, root cause unclear (stack/CI) | ns-investigator |
| Ad-hoc diff ready | reviewer-agent then ns-reviewer; ns-judge only if Code Review: Approved |
Entry priority 5 (default). Harness table: ../../ns-harness/references/code-skill-routing.md. Trigger phrases: references/entry-triggers.md.
When to use (entry)
- Bug fixes / hotfixes outside 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
When invoked as C2 (engine mode)
ns-autonomous dispatches as work-unit subagent in existing worktree: unit scope only. Do not re-route to ns-execution-gitlab-issue on ISSUE_URL in code/comments — context, not routing. Escalate destructive doubts to caller (A), not GitLab skills. No living-spec consolidator as C2 — version closure/caller owns. Engine / multi-unit C2: implement only — defer review to G Phase 4 or A standalone closure (same as SDD handoff). Complete ad-hoc Review loop only when caller is ad-hoc face and did not say defer review.
When invoked under execution-handoff (SDD task mode)
Parent run-implementation (classic SDD) or dispatch SDD handoff / execution-handoff:
- Scope: classic = one batch (same-layer consecutive
pending, prefer 4–7, hard max 7; size 1 = single task) perreferences/run-implementation.md. Partitioned slice = that slice's tasks. Parent owns handoff file updates. - Read each task card (header through Validation criteria); open
Detailed descriptionon demand (ambiguity orblocked) —../ns-spec-driven/references/task-schema.md. - Implement + unit/integration only. No E2E.
- Forbidden:
reviewer-agent/ns-reviewer/ns-judge, living-spec consolidator,Code Review:/Delivery Review:verdict lines. - Before report complete: public-export grep (Pre-review). Still no reviewer.
- Report to parent per task: files changed, tests run, blockers, tokens (split or
~N),Layout SSoT: {path} read | none registered,Skipped / not checked / risk:(format:../ns-reviewer/references/review-gate-workflow.mdFinal report). Parent marks rows. Version closure (steps 4–6):references/run-implementation-closure.md— not the per-batch file. Session boot: cold start this agent = full boot persession-boot.md; same agent continuing = no full re-read unlessagents.local.md/ harness rules changed.
Session boot
See ../../ns-harness/references/session-boot.md. Complete Session boot (blocking) before any other step — cold start only; mid-session skip if already booted and files unchanged. Never tool-Read AGENTS.md.
After session-boot steps 1–6:
- Load all
.nextstage-harness/rules/*.mdmarked always-applicable in harnessmanifest.json, plus layer rules for target layer. - Load agent-requested rules when
manifest.jsondescriptionmatches task scope (persistence, auth, tenancy, build). No manifest: scanrules/*.md; read files whose scope matches. - Unread mandatory rules = incomplete boot. Do not pick stack default to fill gap.
- Stack signals: detected stack implies expected sibling rule —
../../ns-harness/references/architecture-rules/stack-signals.md. Rule present: load. Absent: ask or markneeds-clarification— never assume framework default.
Session inputs
| Variable | Required |
|---|---|
{task_description} | Yes |
{target_layer} | Infer when possible: frontend, backend, infra, tests, fullstack |
Scope isolation
Operate only inside the repo + harness docs.
Boot (mandatory)
Session boot (../../ns-harness/references/session-boot.md) — one rule for ad-hoc, C2, SDD handoff:
| Agent state | Action |
|---|---|
| Cold start (this agent/subagent just started) | Full Session boot (steps 1–6). Bridge may have done local + architecture/project rules — finish layer rules + context |
| Same agent continuing; steps 1–6 done; files unchanged | Do not re-read rule corpus |
agents.local.md or harness rules changed since last boot | Re-boot |
Then:
- Obey
AGENTS.mdorders (already in context) — no invented paths git statusandgit diff- Read target files before writing
Success: AGENTS.md orders + project rules + task scope. Invented paths or SDD artifacts (except handoff updates when parent owns them) = failure.
Implementation rules
- Constitution over card: card prescribes persistence/API/gate/pattern rules forbid — implement rules path; annotate
card deviation: {card} -> {rules}in## Execution notes. Large/ambiguous deviation:blocked. - Grounding check before diff: card names class/command absent from repo and rules — stop and report. Do not implement.
- Persistence source: persistence path from
architecture-rules.md+ mandatory project rules (Session boot). Forbidden to assume ORM or upsert default when rules silent — ask orblocked. - Rules + code same turn: rule request + code delivers diff same turn, not harness text only.
- Diff-first — only required lines; no unrelated formatting
- Prefer editing existing files over new files
- Minimal change — reuse ladder, no speculative code, root-cause fix at shared callers:
references/minimal-change.md - 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
../../ns-harness/references/agent-git-identity.md - No SDD version artifacts — no
task-NNN.md,requirements.md,execution-handoff.md, ordocs/versions/writes. Conditional living-spec updates underdocs/specs/vians-living-specallowed (see Living specs). - No gratuitous comments unless requested
- Tests per
AGENTS.mdDocker + testing; container/commands inarchitecture-rules.md - Ask before (gate — stop, ask): new dependency; abstraction without 2 concrete uses; DB schema or shared contract change; CI/deploy/infra config; moving files across packages
- Protected tests: paths listed as Domain invariants / protected tests in
architecture-rules.md— keep green; never weaken, delete, or skip to pass - Library divergence: docs/rules disagree with real library API → follow library, report drift
- Under
execution-handoff.md/run-implementation: unit/integration only — no E2E (human at version end); no review gate (parent Step 5)
Complement delegation
spec-driven / gitlab presets install complements via depends (check .agents/skills/ once per session). Delegate — do not duplicate their workflows inline.
| Signal | Skill | When |
|---|---|---|
Frontend UI without Layout SSoT registered for screen being built (reference-sources.md role: ui-layout, or card cites *-visual.md) | ns-frontend-design | Before large UI diff (step 4–5) or when task is primarily visual |
| Layout SSoT registered for screen being built | (none — read SSoT) | Open cited guide/prototype before diff; match registered pattern + project UI approach; do not invoke ns-frontend-design anti-slop |
| Security headers, CSP/CORS, dep CVE sweep, a11y/Web Interface Guidelines audit | ns-best-practices | On explicit request, or after frontend work before review when hygiene was in scope |
README / docs/ guides (not code comments) | ns-docs-writer | On explicit request or version/doc closure — not every ad-hoc fix |
MR/SOLID review stays ns-reviewer only. Missing complement: continue with harness rules; recommend install once per session (../ns-spec-driven/references/skill-integrations.md).
Per-task cycle
SDD handoff mode: one dispatch may cover a batch; still stop after step 6; report per task to parent; skip 7–9.
- Understand task
- Load rules — obey
AGENTS.mdalready booted; Session boot again only if cold start this agent or files changed - Explore (grep/head large fixtures — no full test dumps)
- Identify minimal diff — apply
references/minimal-change.md - Apply (or plan if large-change gate)
- Run tests if in scope + public-export grep (Pre-review)
- Review loop — ad-hoc only: MUST
reviewer-agentwhen available (elsens-reviewer); thenns-judgein-session only ifCode Review: Approved;../ns-reviewer/references/review-gate-workflow.md. Skip when SDD handoff / engine defer. - Living specs (conditional) — see below
- Final report — mandatory fields; never skip verdict or round count
Pre-review (before step 7; also before SDD report complete)
- Run default tier only (unit/integration / default
test— see Test tiers in../../ns-harness/references/docker-and-testing.md). Never run live tier unless human asks this run. - New tests needing real LLM or live third-party → put in live group/marker; report how to trigger; do not run them.
- Diff removes exports/constants/env flags/public symbols: search remaining call sites; resolve before review.
- List new or newly exported public names (
return { },module.exports,export,public/public static, window/global attach). - Grep each: no caller outside defining module — keep private/unexported. Continue (ad-hoc: review; SDD: report parent). Forbidden reviewer in SDD handoff.
- Internal/private/nested helpers: keep.
Review loop (mandatory ad-hoc; skip SDD handoff / engine defer)
After step 6, run ../ns-reviewer/references/review-gate-workflow.md before done — except SDD handoff or caller says defer review / engine C2 / G single-unit dispatch (return to parent; no reviewer, no judge). Rejected map/fix/re-review path: that workflow only (exhaustive → one coder → delta + prior IDs) — no restated rubric here.
- MUST invoke
reviewer-agentwhen available (elsens-reviewer) on working-tree diff (git diff) — reviewer bridge/skill begins Session boot at cold start then reviewer workflow; noISSUE_URL, no version-closure path. Ad-hoc diff only. Reviewer MUST NOT dispatch judge. - Max 3 code rounds.
Code Review: Approved= score 10 only.Rejected/Blocked: do not runns-judge.- Pass:
Code Review: Approved(score = 10, zero Criticals). Then read../ns-judge/SKILL.mdin-session (adhoc). Skip AC proof unless--requirements/--ac-file. Max 3 judge rounds.Delivery Review: Approvedonly at 10. Product files changed after judge Rejected: code review again (must Approved) then judge again. - Rejected with rounds left: apply map per
review-gate-workflow.mdCode rounds (one coder, map verbatim, re-review prompt =delta+ prior map IDs).reviewer-agent/ns-reviewer/ns-judgeread-only — this skill applies fixes. MUSTreviewer-agentwhen available; elsens-reviewer. - Stop:
Blockedor call 3 not score 10 or 3 rounds exhausted → report blocked. No coder onBlocked. List unresolved Criticals and/or last score. No success. Skip step 8.
- Pass:
- Fixes within original task scope. Critical (or score-blocking Warning) needs changes outside scope (public contract, cross-product, multi-day): stop, escalate per Stop conditions.
- Suggestions (P2) alone do not block when code
Approved. Score 9 still Lift even if only P2.
Living specs (step 8, conditional)
Only after Delivery Review: Approved (not as C2). Invoke ns-living-spec ad-hoc when all true:
docs/specs/exists- Diff behavioral (API, schema, UX, or domain behavior) — skip cosmetic / rename-only / pure refactor
- Skill available (installed via
depends)
Pass: mode ad-hoc, {task_description}, approved git diff. Read consolidator SKILL.md, follow it. No invent {version_san} or write under docs/versions/.
Skip (note reason in final report) when any condition fails, delivery not Approved, or consolidator reports skipped.
Final report (step 9)
No success language until both gates pass or blocked (review-gate-workflow.md). SDD handoff: report implement status to parent; no Code Review: / Delivery Review: lines — version closure owns verdict.
Every ad-hoc / C2 closure response must include fields in ../ns-reviewer/references/review-gate-workflow.md Final report, including exact Code Review: and Delivery Review: lines (n/a on delivery if code never Approved).
Then: what changed, follow-ups, blocked Criticals if applicable.
Stop conditions
| Condition | Action |
|---|---|
| Large change gate | Plan + wait |
| Public contract change | Stop, explain, ask |
| Ask-before gate (dep / abstraction / schema / CI / cross-package move) | Stop, ask |
| Protected-test change would weaken coverage | Stop; fix behavior or ask |
| Library API ≠ docs/rules | Follow library; report drift |
| Task needs multi-day SDD planning | Redirect to ns-spec-driven |
Related skills
ns-reviewer— code quality gate after implementation (Review loop)ns-judge— delivery proof in-session afterCode Review: Approvedns-living-spec— conditional ad-hoc living-spec update afterDelivery Review: Approved(Living specs)ns-investigator— blocked by unclear stack/CI bugns-bug-report-diagnosis— product report / screen story; bounce only if nodiagnosis_completens-autonomous— autonomous multi-agent execution (GitLab issue or local plan); GitLab issue usens-execution-gitlab-issueinsteadns-frontend-design— UI/design work (Complement delegation)ns-best-practices— security/CSP/a11y hygiene pass (Complement delegation)ns-docs-writer— README /docs/guides on request (Complement delegation)
Forbidden
- SDD version artifact generation (
docs/versions/, handoff, requirements/tasks) - Living-spec consolidator before
Delivery Review: Approved, or whendocs/specs/missing - Out-of-repo access without scope
- Secrets/keys/connection strings in versioned files
- Commits without explicit request
- Refactors outside task scope
- Review substitutes — Cursor Task subagents (
senior-tech-lead-reviewer,bugbot,security-review) or any review not viareviewer-agent/ns-reviewerSKILL.md. Harnessreviewer-agentallowed. Judge = in-sessionns-judgeafter Approved; nojudge-agentin v1 - Judge before code Approved —
ns-judgewhile lastCode Review:is notApproved - Skipping re-review — success after
Rejected(including score 9) without a newApprovedround on that gate (ad-hoc / C2) - Success without verdict — ad-hoc / C2 closure without mandatory Final report fields and parseable
Code Review:+Delivery Review:lines - Per-task / mid-batch review under handoff —
reviewer-agent/ns-reviewer/ns-judgeduringrun-implementationtask or batch (parent owns Step 5)
FAQ
What does the ns-coder skill do?
(NS) Ad-hoc coding — bug fixes, refactors, scripts, migrations — without full SDD. Entry priority 5: "just implement this", "quick fix", or coding without execution-handoff (C2 under ns-autonomous). Do NOT: ISSUEURL (ns-execution-gitlab-issue), multi-day/version (ns-spec-driven), product bug report / screen expected-vs-actual without diagnosiscomplete (ns-bug-report-diagnosis), diagnosis-only stack/CI (ns-investigator), when execution-handoff.md exists. Do NOT generate requirements/tasks/handoff.
How do I install ns-coder?
Run npx skills add https://github.com/nextstage-brasil/skills --skill ns-coder in your project. The skills CLI detects the agents you use and copies the skill into the right folder. For Claude Code you can also place the skill folder at ~/.claude/skills/ns-coder/ (personal) or .claude/skills/ns-coder/ (project).
Which AI agents can use ns-coder?
Any agent that supports the open Agent Skills format (a folder with a SKILL.md file), including Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, Windsurf, Cline, OpenCode and more.
Is ns-coder safe to install?
No partner security audit is available yet. Skills can run commands and scripts, so read the SKILL.md and any bundled files before installing.
Who maintains ns-coder?
It is published by nextstage-brasil in nextstage-brasil/skills. It has 125 recorded installs.
More from nextstage-brasil/skills
ns-gitlab-board-sync
nextstage-brasil/skills
(NS) Sync existing GitLab issues with local planning/execution — milestone, RF labels, status, assignee, estimates, spent time. Use during implementation when tasks link to GitLab issues or after plan-version-from-gitlab sync — not for creating new issues (use mcp-gitlab-usage). Always atomic setissuelabels and three-step status cycle.
ns-spec-driven
nextstage-brasil/skills
Open the skill to read its SKILL.md instructions.
ns-gitlab-ci-generator
nextstage-brasil/skills
Open the skill to read its SKILL.md instructions.
ns-project-manager
nextstage-brasil/skills
Open the skill to read its SKILL.md instructions.
mcp-gitlab-usage
nextstage-brasil/skills
Open the skill to read its SKILL.md instructions.
Popular code quality & workflow skills
grill-me
mattpocock/skills
A relentless interview to sharpen a plan or design.
improve-codebase-architecture
mattpocock/skills
Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.
handoff
mattpocock/skills
Compact the current conversation into a handoff document for another agent to pick up.
domain-modeling
mattpocock/skills
Build and sharpen a project's domain model. Use when discussing codebase terminology, writing or editing a GLOSSARY.md, or recording or editing an ADR.
codebase-design
mattpocock/skills
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.
diagnosing-bugs
mattpocock/skills
Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.