JUNERDD Reduce Reinvention
Reduce duplicated effort by making existing assets discoverable, assessing whether reuse is justified, and turning repeated work into maintained shared capabilities without forcing premature abstraction.
Requested Outcome
Run the steps needed for the user's deliverable. An audit or plan returns evidence and recommendations without automatically consolidating code, creating a catalog, or starting governance work. When implementation is requested, verify candidates and continue within that existing authorization; similarity scores or an audit report do not grant additional scope.
Core workflow
- Frame the scope. Identify the capability being duplicated, the affected repos/teams/domains, target outcome, constraints, and whether the user wants a quick audit, a refactor plan, a governance model, or an implementation patch.
- Search before building. Inspect local code, docs, package manifests, design systems, service catalogs, ADRs/RFCs, tickets, and team conventions before proposing new work. When external alternatives, current package health, pricing, licenses, or APIs matter, research current sources before deciding.
- Classify the duplicate. Label each finding as exact copy, near clone, same business rule, same platform workflow, overlapping service/API, duplicated template/docs, abandoned fork, or justified divergence. Treat similarity as a clue, not proof.
- Decide reuse strategy. Prefer reuse when the existing asset is fit, owned, maintained, secure, compatible, and cheaper to adopt than to rebuild. Prefer local divergence when domains are likely to evolve separately or abstraction cost exceeds duplication cost.
- Choose an intervention. Recommend one of: adopt as-is, adapt through extension points, wrap behind a stable façade, extract a shared module, merge services, publish a template/golden path, deprecate a duplicate, archive dead assets, or document a justified exception.
- Make reuse obvious when delivering a shared asset or catalog. Add or update the metadata, ownership, lifecycle, examples, migration guidance, and verification needed for that deliverable. A reusable asset without owner and examples is usually just hidden maintenance debt.
- Plan safe migration. Move in small behavior-preserving steps with tests, rollback points, compatibility notes, and a deprecation schedule. Keep user-facing behavior stable unless explicitly changing product semantics.
- Measure the requested outcome. Use before/after evidence for a local consolidation; track adoption, catalog coverage, migrated consumers, support load, or stale assets when an ongoing reuse program is in scope.
Use bundled resources
- For the end-to-end practice model, read references/reuse-playbook.md.
- For repo/org audit tactics, search queries, and evidence gathering, read references/audit-checklist.md.
- For build-vs-reuse scoring and recommendation rules, read references/decision-matrix.md.
- For ready-to-fill outputs, read references/templates.md.
- To scan a repository for duplicate-code and reinvention signals, run:
python3 scripts/reinvention_audit.py <repo-path> --output reinvention-audit.md - To produce a lightweight reusable-asset inventory, run:
python3 scripts/reuse_catalog.py <repo-path> --output reuse-catalog.md - Treat script output as candidate evidence. Confirm semantics, ownership, consumers, and change cadence before recommending consolidation.
Output expectations
When delivering an audit, decision, or plan, include:
- Evidence: file paths, symbols, repo/package names, docs, search terms, owners, and known consumers.
- Confidence: high/medium/low plus why the evidence supports or weakens the duplicate hypothesis.
- Recommendation: adopt, adapt, wrap, extract, consolidate, sunset, or justify divergence.
- Cost/risk: migration effort, test surface, security/license concerns, owner load, and compatibility risk.
- Next actions: minimal PRs/tasks, owners, acceptance criteria, and the metric that proves reinvention decreased.
Guardrails
- Do not eliminate duplication solely because code looks alike; first verify shared domain knowledge, change cadence, and future evolution.
- Do not create a shared library, platform service, or golden path without an accountable owner, examples, versioning/deprecation policy, and support expectations.
- Do not centralize every variation; sometimes duplication is cheaper than an unstable abstraction.
- Do not rely only on automated clone detection. Combine script output with code review, domain context, ownership data, and usage evidence.
- Do not leave decisions implicit. For material choices, create or update an ADR/RFC that records context, alternatives, consequences, and status.