dxkit-feature

dxkit-feature

This skill drives forward development — building something new — the way dxkit-action drives the reverse (fixing what's flagged). Its two jobs:

1. Orient by graph, not by grep. Use the code graph to find where the feature plugs in, what patterns already exist, and what a change will touch — at a fraction of the tokens that repeated whole-file reads cost.
2. Close the loop a plain coding agent skips. After the edit, run the dxkit analyzers on the change and the guardrail check, so the new feature doesn't quietly ship a vuln, a test gap, or a quality regression.

Defer to a repo-specific feature/architecture skill first

This skill is deliberately generic — it claims the broad "add a feature / implement X" trigger. But many repos define their own skill for building a module or feature (an /add-module, a platform architecture guide, a domain-specific scaffolder) that encodes where code must live and what contract it must satisfy in that codebase. When such a skill exists, it wins on architecture: it decides the shape, the boundaries, the naming, the layering.

The two compose — they don't conflict:

• The repo skill owns the architecture contract — the "what and where."
• This skill owns the method — orient by graph instead of grep (step [2]), and verify the change didn't regress security/tests/quality before pushing (step [5]). Offer those as the layer that runs inside the repo's flow.

So when the user's request matches both, follow the repo-specific skill for the design decisions and fold this skill's orientation + verification steps into it — don't override the repo's conventions with the generic loop below. Only when the repo has no feature/architecture skill of its own does this skill drive the whole flow end to end.

The feature loop

[1] Clarify        → what's the feature + what does "done" mean
[2] Orient         → query the graph: where it lives, patterns, blast radius
[3] Plan           → ordered edits, reusing the patterns found in [2]
[4] Build          → read only the files the graph named, then implement
[5] Verify         → run the analyzers on the change; confirm nothing regressed
[6] Decide baseline→ commit, or re-baseline if the change is deliberately accepted