new-feature-implement
Implements one approved spec: a setup pre-flight, then the executor in three chained block groups, then it prints the git-publish command.
new-feature-implement, section by section
The sections of the skill's own SKILL.md, excerpted. Hover or click one to see which project rules, templates and references/ files it cites. The sections are also chips: click one to jump to it.
## Why this is Form 2 (manual skill)
Axis 2 (manual trigger) + axis 5 (procedural) + axis 8 (both). It was input row 3 of /new-feature until the two flows of the pipeline became two pieces: an implement run loaded the whole design procedure — about 10k tokens of steps 1–6 and consolidation it never runs — on every main-thread turn, and it ran on the opus the design needs. A subagent was rejected: the executor is already the isolated part, and this thread only chains it (@.claude/decisions/0135-new-feature-split-spec-and-implement.md).
Manual only. disable-model-invocation: true hides this skill from the model: the Skill tool can't call it, and trying is blocked. When a conversation reaches the point of running it, print the exact command for the user to type — don't attempt the call.
Pinned to sonnet: this thread runs a detection, chains three Agent calls and copies their findings — no design. The executor declares its own model (@.claude/decisions/0081-skill-model-required-per-class.md). A skill's model holds for the turn it runs in; a background executor's hand-back opens a new turn, which may run on the session's model — measured in the run's audit report, not assumed.
### 1 · Entry guardrail
Runs before any skill invocation, any delegation, and any question. Read @.claude/skills/new-feature/references/entry-guardrail.md and run its § 1 (survey and classify), then evaluate this table in order and stop at the first row that matches:
| # | Input | Result |
|---|---|---|
| 1 | empty | ✅ list the survey — each case with its status — and stop |
| 2 | EXACT, FOLDER, status approved | ✅ implement: § 2 onwards. The argument is the request; nothing is asked before the pre-flight |
| 3 | EXACT, FOLDER, status draft or (no spec) | ❌ <UC-NNN-slug> is <status> — design and approve it first — plus /new-feature <UC-NNN-slug> |
| 4 | EXACT, FOLDER, status implemented or implemented-blocked | ❌ already implemented — describe the change as a new feature — plus /new-feature <description> |
| 5 | no FOLDER, and the argument's UC-NNN resolves to exactly one folder on disk | ❌ <UC-NNN> is <real-slug>, status <status> — plus the exact command for that status: /new-feature-implement <real-slug> when approved, /new-feature <real-slug> when open |
| 6 | EXACT, no FOLDER, number resolving to zero or several folders | ❌ use case not found |
| 7 | UC_LIKE but not EXACT (slug plus context, malformed slug, two slugs, a path) | ❌ ambiguous argument |
| 8 | free text | ❌ this skill implements an approved case; to design one, /new-feature <description> |
| — | anything else | ❌ unrecognized argument |
Every error follows the rule of the reference's § 1 — fixed shape, ends the run, no side effect:
❌ /new-feature-implement: <reason>.
Usage: /new-feature-implement UC-NNN-slug → implement an approved case
/new-feature-implement → list
/new-feature <feature description> → design a new case… cut here, the rest is in the file
### 2 · Implement
- One-time setup pre-flight, before delegating. The executor is about to write the
… cut here, the rest is in the file
### 3 · Long-running background work
Implementing a complete feature takes dozens of minutes. An executor launched in the background doesn't survive the machine sleeping: the watchdog cuts the stream and execution dies where it was. This happened three times in a row on the first real feature, with not a single file written, because all three died still in the reading phase.
Before delegating the first group in the background, warn once and offer both options: keep the machine awake for the whole chain (caffeinate -i on macOS), or implement on the main thread, which is resumable. The executor writes by checkpoint precisely so that an interruption leaves reusable progress — but no checkpoint helps if execution dies before the first Write. A chain cut between groups resumes at the first group with open steps (§ Procedure, step 2).
### 4 · Final report
Last message of the run, and the only report: the spec path and its status:, the groups that ran and how each ended, every ## Infrastructure row of the spec, with what this run did to it — added or failed by the installer, already present, external with its address, or pending with the /docker-architect command (or "none") — every approved use case this run left unreachable end to end, with the backlog row that restores it named by its BL-NN (or "none"), every item deferred, with its owner (or "none"), every guarantee delegated to a consumer outside this project whose idempotency is assumed or unknown (or "none"), and every personal-data field that crosses a boundary in clear, with its receiver (or "none") — the findings come from the tests group's report, which carries every group's lines — and the next commands, in this order:
/clear
/git-publish feat(UC-NNN-<slug>): <one-line summary>[ — pre-existing: <paths>]
/new-feature <next feature description>/clear comes first: the commit then runs on a clean context, and SessionEnd has closed this run, so its report and history.jsonl line are on disk and enter the same commit instead of staying staged behind it. — pre-existing: is present only when the guardrail's worktree step listed changes from before the run, with the list itself (directories past 20 paths). /git-publish is the person's call and may be skipped or typed later. A clean context per use case keeps cost measurable per case. A failed group's report instead names the group, its failure, and /new-feature-implement UC-NNN-<slug> to resume there — no /git-publish.
## References
@.claude/decisions/0130-executor-split-by-block-group-implement-in-clean-session.md— the@.claude/decisions/0135-new-feature-split-spec-and-implement.md— why this flow is a@.claude/decisions/0067-implement-entry-row.md— the single door to the implement half,@.claude/decisions/0116-tests-defers-while-a-writer-subagent-runs.md— why the next@.claude/agents/commons-logging-installer.md— one-time logging/masking setup,@.claude/agents/mapstruct-installer.md— records the project's mapper mechanism once;@.claude/agents/compose-service-installer.md— adds the spec'smaterializeservices@.claude/decisions/0182-git-publish-printed-not-chained-by-the-feature-flows.md— why the@.claude/decisions/0137-pending-compose-service-decided-at-design-materialized-at-implement.md
## Entry into generated projects
Step 6.6 writes the skills into the project, this one included — the user runs /new-feature-implement UC-NNN-<slug> after /new-feature approves a spec.
What it reads, writes and refuses
The skill's own contract, from SKILL.md, in the original wording.
Class
orchestrator — skill_classes.orchestrator in @.claude/schemas/extensions.json, with overrides.new-feature-implement.write_allow: []: this thread writes nothing. Every write of a run is a subagent's, judged by its own agent_classes entry — the executor's and the installers' — never by this phase (@.claude/decisions/0059-agent-classes-territory-schema.md). The class keeps design_phase: true, so ArchHook.java guard refuses a Skill call to a build-class skill while the run is open.
Ownership
Feature spec→code orchestrator. Owns the pre-flight, the group chain, the hand-off between groups, and the /git-publish line an implemented case ends with. Does not own the spec — /new-feature writes it and its status: up to approved; java-spring-boot-developer writes implemented or implemented-blocked (@.claude/skills/new-feature/SKILL.md § Spec lifecycle).
Reads
- @.claude/skills/new-feature/references/entry-guardrail.md — survey, classification, error rule, worktree, project, disk; shared with /new-feature, owned there - docs/use-cases/UC-*/ — folder existence and each spec's status: line, by command - docs/use-cases/UC-NNN-<slug>/UC-NNN-spec.md — the checklist, to find where the chain starts, and ## Infrastructure, for the services the run adds and reports - @.claude/skills/docker-architect/references/compose-service-decision.md — what each ## Infrastructure decision means, and who acts on it - src/test/, the commons package, the root CLAUDE.md's Mappers: paragraph — by command, for the pre-flight
Writes (indirectly)
- src/**, pom.xml and the spec's checklist and status: — via java-spring-boot-developer - the ArchUnit tests and coverage gate — via test-architect setup mode → archunit-installer - the logging/masking classes — via commons-logging-installer, from this skill's templates/commons/*.example - the project's mapper mechanism — the **Mappers: paragraph, and for MapStruct the build wiring and every converted mapper — via mapstruct-installer, from this skill's templates/mapstruct/*.example - docker-compose.yml and what a service needs next to it — via compose-service-installer, which runs docker-architect for every materialize row of the spec
Writes (directly): none
Never runs `git add`, `git commit`, or `git push`, and never invokes `git-publish`
Git happens only through git-publish, which the person types after /clear, behind its two confirmations; the final report prints the command (@.claude/decisions/0182-git-publish-printed-not-chained-by-the-feature-flows.md). No end of this flow is left without an explicit git instruction.
Integrates with
1. test-architect (setup mode), commons-logging-installer and mapstruct-installer — pre-flight, each only when its gap is found; the first two when the user answers Install now, the third with whichever mechanism the user picks 2. java-spring-boot-developer — three chained delegations, one per block group 3. compose-service-installer — on success, only when the spec has a materialize row
Source: SKILL.md § Contract, at nerviz e4cae27.
What the guard does with it
orchestrator is the skill's class, and the list on the left is its territory. The phase opens when the skill runs on a prompt of its own, and ArchHook judges every write against that list. The text on the right is the hook's own.
write_allow of new-feature-implement
any file: the territory is empty
A refusal exits with code 2 and the message goes back to the model.
> /new-feature-implement … UserPromptSubmit guard prompt exit 0 # phase opened: new-feature-implement (class orchestrator) # write_allow: [] — this class writes no file
PreToolUse Write(pom.xml) guard write exit 2 ❌ `new-feature-implement` is class `orchestrator` — pom.xml is outside its territory. write_allow: (nothing — this class writes no file) Put the content in the spec as a code block, or finish the run and invoke the skill that owns this path. If the path is legitimately this skill's, widen skill_classes.orchestrator in .claude/schemas/extensions.json — retrying will not help.
Where it sits on the rail
Each card is a step of /new-feature-implement, the command this page describes.
/new-feature-implement orchestrator · sonnet