klaude-plugin/skills/merge-docs/SKILL.md
Compare and merge two design docs for the same feature into a single source of truth. Use when you have competing or complementary design/implementation docs (e.g. from separate design runs) that need reconciling into one unified document.
npx skillsauth add serpro69/claude-starter-kit merge-docsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Goal: Produce a single, unified set of feature docs from two separate designs for the same feature.
Read capy knowledge base conventions at shared-capy-knowledge-protocol.md.
You have two feature directories under /docs/wip/ for the same feature — each with its own design, implementation plan, and task list — and you need to combine them into one coherent set of docs.
Mandatory order — grounding before merging. The flow below is strictly sequential. Do not categorize sections, surface contradictions, or write merged content until you have read both feature directories fully and built a codebase-grounded mental model. Merging without grounding produces decisions based on prose clarity rather than codebase reality — the wrong tiebreaker.
See merge-process.md for the detailed steps.
development
Guidelines describing how to test the code. Use whenever writing new or updating existing code, for example after implementing a new feature or fixing a bug.
development
Use after implementing tasks or mid-feature to verify code matches design docs and ensure they are in sync. Detects spec deviations, missing implementations, doc inconsistencies, and outdated docs in design and implementation documentation.
testing
Review design and implementation docs produced by design. Evaluates document quality, internal consistency, and technical soundness. Use after design completes and before starting implement.
testing
Compare and merge two design docs for the same feature into a single source of truth. Use when you have competing or complementary design/implementation docs (e.g. from separate design runs) that need reconciling into one unified document.