mcpField
D
ds-blueprint

ds-blueprint

github.com/aicodekingDevelopment150273 installsUpdated 6d ago
Repository

About ds-blueprint

ds-blueprint is a coding skill for shaping a code design before implementation. It guides developers and coding agents through competing sketches, compilation checks, user approval, and incremental implementation.

Key features

  1. 01Read affected modules first
  2. 02Create two structural design sketches
  3. 03Compare public surface and repository fit
  4. 04Compile sketches before implementation
  5. 05Implement and test one stub at a time
  6. 06Revise the design when implementation disproves it

Use cases

  1. 01Planning a change across several modules
  2. 02Getting design approval before implementation
  3. 03Checking a design through compilation and tests

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/aicodeking/deepseek-stack --skill ds-blueprint

After installing, type/ds-blueprintin Claude Code to confirm it loaded.

Details

From the project README

ds-blueprint

Fix the shape of the code before writing the bodies, so the model fills in a plan instead of inventing one as it goes.

Steps

  1. Ground yourself. Read every module the new code will touch. If you cannot explain how they fit together, run /ds-explain first. Skip this only for code with no surrounding system.
  2. Write at least two structurally different sketches. Each sketch is real files with types, signatures, module boundaries and stub bodies that raise "not implemented", plus short pseudocode. Use /ds-best-of-n to produce them in parallel when the design matters.
  3. Compare the sketches. Prefer the one with the smaller public surface that hides more inside. Prefer the one where a change that looks right from a single file is also right for the whole repo. Note what you rejected and why.
  4. Run the type checker or compiler on the chosen sketch. Paste the output. Stubs must compile.
  5. Show the user the chosen sketch and wait for agreement before you fill in bodies. In an unattended run, record the choice with /ds-ledger instead.
  6. Implement one stub at a time. After each, run the type checker and the relevant tests. If the sketch turns out wrong, stop and revise the sketch, not just the body.
  7. Delete leftover stubs, dead sketches and unused types. Grep for "not implemented" to prove none remain.

Stop when

  • Every stub is implemented, the type checker passes and the tests pass, with output shown.
  • Or the sketch needed three revisions during implementation. Stop and redesign with the user.

Rules

  • Signatures change only through step 6's revise path, never silently.
  • Keep each sketch file small enough to read in one pass.
  • Evidence is compiler and test output, not "it should work".

Comments

Markdown supported