From nexus-agents
Implements new features following project standards with constraint-driven design, TDD, and quality gates. Triggers on 'implement', 'add feature', 'create', 'build'.
How this skill is triggered — by the user, by Claude, or both
Slash command
/nexus-agents:implement-featureThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!-- CANONICAL SOURCES:
Full workflow: CONTRIBUTION_GUIDE.md
TZ='America/New_York' date && git statusgh issue list --state openWhen the problem has multiple plausible approaches (e.g., "event-driven or polling?", "synchronous vs queue-based?", "monolithic helper vs split modules?"), do not generate the same solution three times with different variable names. Instead, articulate 2–3 distinct constraints first, then sketch one solution per constraint and compare.
Anchor constraints in real tradeoffs:
Three constraints that each eliminate ~70% of the solution space leave you searching ~2.7% of it — a focused region, not blind sampling. (Pattern adapted from itigges22/ATLAS PlanSearch; the math is theirs.)
Apply this discipline only for genuinely-multivalent decisions. Indicators:
Out of scope: routine work where the approach is dictated by canonical paths or existing patterns. Don't over-apply.
// Define interface FIRST
interface IFeature {
method(input: Input): Promise<Result<Output, Error>>;
}
See CONTRIBUTION_GUIDE.md for boundary checklist.
pnpm test -- --watchpnpm lint && pnpm typecheck && pnpm test
git commit -m "feat(scope): description
Closes #<issue>
Co-Authored-By: Claude Opus 4.6 <[email protected]>"
gh pr create --title "feat(scope): description" --base main
See CODING_STANDARDS.md for full checklist.
Before marking ANY technique or feature as "implemented", verify ALL of the following:
integration_filesany types (use unknown instead)pnpm lint passes with zero errorspnpm typecheck passespnpm test passes (relevant tests)docs/research/registry/techniques.yaml: status: implemented, decision_history entrydocs/research/registry/papers.yaml: implementation_status updateddocs/research/RESEARCH_INDEX.md: Quick Stats updated if counts changedDo NOT mark as implemented if: tests fail, implementation is partial, or feature is behind a flag.
Build the smallest end-to-end working piece first, then expand. Avoid implementing the whole feature in one pass — each slice should leave the system in a working, testable state.
Implement → Test → Verify → Commit → Next slice
For each slice:
test-driven-development skill)If you're about to write more than ~100 lines without testing, stop. Either:
Larger commits hide bugs, fight git bisect, and bloat code review surface. Small commits compound; large commits accumulate risk.
| Excuse | Counter |
|---|---|
| "It's all related, makes sense to commit together" | "Related" hides the failure boundary. Atomic commits separate "the failing change" from "everything else." |
| "I'll test it all at the end" | The end is when you're already deep into the next problem. The cycle catches issues while you still have context. |
| "Splitting this is artificial" | Each slice should be end-to-end (vertical, not horizontal). If you can't make a slice end-to-end, the design is too coupled. |
| "This is faster as one big push" | Maybe per-keystroke. Per-PR-merged-to-main, the cycle is faster because debug time grows superlinearly with diff size. |
| "I'll commit when tests pass" | Tests passing is the floor, not the ceiling. Each slice gets its own commit; tests passing is what makes the commit safe. |
pnpm test failingeslint-disable justificationnpx claudepluginhub nexus-substrate/nexus-agentsGuides systematic implementation of new features: clarify intent with scenarios and requirements, verify assumptions via docs, analyze existing code before changes.
Implements features using parallel subagents with scope control, reflection, and MCP servers for memory/context. Activates on implement/build/create requests in JS/TS projects.
Orchestrates building a brand-new feature end to end — research, plan, TDD, review, and gated commit — by delegating each phase to the matching ECC agent.