| name | md-add-improvement |
| description | Implement mdnest features/improvements from the backlog. Read the items in the mdnest brain (MyProjects/mdNest/Features), pick what to build, then implement them one by one — each on its own branch from develop, verified and merged straight into develop (no per-unit PR) — and finish with one clean release PR built on top of main. Say "/md-add-improvement". (Part of the md-* mdnest skill family alongside md-fix-bugs and md-ship.) |
Purpose
The feature/improvement counterpart to md-fix-bugs. Same disciplined flow, but
the backlog is enhancements rather than defects: read the items, agree what to
build (and how much), then ship each as its own clean PR into develop, and
finish with one release PR develop → main.
mdnest brain locations (the backlog lives here, not in the repo)
- Features / improvements (input):
@srv-ahsan-mini/mahsan_brain/MyProjects/mdNest/Features/
- TODOs (optional working notes):
@srv-ahsan-mini/mahsan_brain/MyProjects/mdNest/ToDos/
Read with mdnest read / mdnest list. Some feature notes (e.g.
SmallEnhancement.md) are lists of many items — treat each bullet as its own
unit, and when one ships, trim just that bullet rather than deleting the file.
Conventions (identical to md-fix-bugs)
- Clean commits — no attribution. No
Co-Authored-By: Claude / "Generated
with Claude Code" footer on commits or PRs (intentional override of the global
default).
- No per-unit PRs — merge each into
develop directly. Branch feat/<slug>
from the latest develop, verify, then git merge --no-ff into develop +
push (no PR). The only PR is the final release. Sequential, not parallel
(shared files like App.css / mdnest conflict otherwise).
- Scope discipline. Solve the actual improvement; don't over-engineer or
reach outside mdnest's box (see
CLAUDE.md → "Scope discipline"). Confirm
scope with the user when a feature is open-ended (offer options).
- Verify before merging to develop.
npm run build + npm test (frontend),
bash -n mdnest (CLI), and tests/cli-smoke-test.sh when CLI behavior changed.
For visual/UI work, headless-screenshot a mock against the built CSS, or rebuild
brain (./mdnest-server rebuild) so the user can eyeball it before release.
Steps
- Read & agree.
mdnest list .../Features then mdnest read each. For each
item, restate it, propose the smallest good approach, and (for anything
open-ended) offer 2–3 options before building. Park anything not worth doing.
- Implement each unit on
feat/<slug> from the latest develop. Match the
surrounding code style and the conventions in CLAUDE.md.
- Verify (build/test/smoke/visual as above). Don't merge red.
- Commit + merge into
develop directly (no PR; clean message, no
attribution), then mark the item done in the brain — delete a single-feature
note, or trim just the shipped bullet from a multi-item list.
- Repeat for the next unit, strictly sequential.
- Release exactly as in
md-fix-bugs step 6 — build one clean commit on
top of main (don't PR straight from develop, or it shows ~50 commits):
union develop+main in a throwaway branch (git merge -X ours origin/main),
reset a release/vX.Y.Z branch to origin/main and git checkout only the
changed files onto it, bump version + CHANGELOG, commit once, open ONE PR →
main. Squash-merge, tag, publish the GitHub Release, then reconcile
develop (git merge -s ours origin/main). Optionally run /md-ship.
Done criteria
- Every agreed item has a merged PR into
develop and a green verification.
- Backlog notes updated (shipped items removed/trimmed).
- One release PR
develop → main merged, version bumped, CHANGELOG + tag +
GitHub Release published; develop reconciled with main.
- Commit history clean (no Claude attribution).
