From nexus-agents
Implements new features following project standards using interface-first design, TDD, quality gates with lint/typecheck/tests, and GitHub PR workflow.
npx claudepluginhub williamzujkowski/nexus-agentsThis skill is limited to using the following tools:
<!-- CANONICAL SOURCES:
Guides end-to-end feature implementation workflow as vertical slices covering data model, domain logic, API, and UI. Use for new features or feature request issues.
Guides feature development systematically: explore codebase with agents, clarify requirements, design architecture, implement, test, and review.
Guides systematic implementation of new features: clarify intent with scenarios and requirements, verify assumptions via docs, analyze existing code before changes.
Share bugs, ideas, or general feedback.
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 <noreply@anthropic.com>"
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 justification