← Back to Recruitment · project planning pack

Skill · Version 1.0.0

Smallest complete solution

Finds a narrow end-to-end solution that reuses existing capabilities while retaining the quality needed for everyday operation.

minimal-complete-solution-design

Agents using this skill

See how it helps

When is it useful?

Use it when delivery must stay small but incomplete error handling or manual repair would make the result unusable.

What does it help you do?

  • Inventories existing primitives before adding new components.
  • Cuts scope by complete user journey instead of omitting quality.
  • Includes permissions, recovery and recurring operational effort.

Try asking this

Design the smallest usable export flow without requiring manual database repairs. Cover request, progress, failure, retry and authorized download using existing jobs and storage. A failed export must be recoverable from the product interface.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Minimal Complete Solution Design

Use this skill during planning, design, and implementation to shape the Minimal Complete Solution: the smallest change that delivers a whole, trustworthy user workflow from start to finish.

Minimal Complete vs. Half-Baked

A minimal solution must still be complete:

  • Minimal Complete: A narrower workflow that works end-to-end, enforces permissions, persists data safely, handles errors cleanly, and requires zero manual database surgery by operators.
  • Half-Baked (Never Acceptable): A broad UI or API surface where happy paths appear to work, but edge cases silently corrupt data, authorization is skipped "for v1", errors swallow user input, or operators must manually fix records every day.

Workflow

  1. Inventory existing codebase primitives first:
    • Inspect existing database tables, domain services, UI components, validation schemas, background job runners, and auth middleware before designing anything new.
    • Prefer extending a proven existing pattern over introducing a second competing pattern in the same repository.
  2. Cut scope vertically (by user scenario), never horizontally (by quality layer):
    • Good cut: Support CSV export synchronously for up to 10,000 rows first, deferring async multi-gigabyte S3 export jobs until dataset sizes require it.
    • Bad cut: Build both CSV and Excel export UIs, but skip tenant isolation or leave failed exports stuck in 'processing' forever.
  3. Eliminate speculative configuration and meta-systems:
    • Replace proposed database-driven rule builders, custom DSLs, or dynamic form engines with direct, well-typed code when rules change only through engineering deploys.
    • Hardcode sensible defaults or use a single typed config object until concrete multi-tenant or user-editable requirements exist.
  4. Account for operational and manual toil:
    • Never propose a "simple" code shortcut that pushes recurring manual work onto support, operations, or users without explicitly quantifying that recurring burden and getting agreement.
    • If an administrative action occurs once a quarter, a safe CLI command or seeded migration is appropriate; if it occurs 50 times a day per customer, self-service UI and automated validation are part of the minimal complete solution.
  5. Sequence delivery in thin, verifiable vertical slices (Kent Beck):
    • Structure the implementation plan so step 1 produces a working, testable end-to-end skeleton, and subsequent steps layer only the remaining required behaviors.

Included files 1

  • SKILL.md