SDD 13 - Visual Knowledge Map
SDD Learning · Previous: Superpowers lab route · Next: Framework Comparison
The shared engineering problem is turning intent into a change that somebody can understand, verify and maintain. The tools in this Learning organize that work differently, but they depend on the same feedback: requirements guide implementation, tests reveal behavior and review sends corrections back into the decisions.
The diagram is a conceptual map of emphasis, not a dependency diagram. It does not say to install every tool or imply that their integrations are automatic. Open the scalable SVG for a larger view.
Read the colors
One color means one thing in every diagram of this Learning. The first six are the six levels of the SDD Learning, in order. Methods are white: color never ranks a framework.
Read the map in three layers
| Layer | Question | Examples |
|---|---|---|
| Method | How should we organize the work? | Matt Pocock Skills, Spec Kit, OpenSpec, BMAD Method, Superpowers |
| Durable knowledge and evidence | What did we decide, and how do we know it works? | Specs, ADRs, tasks, code, tests, review findings |
| Execution environment | What runs the work? | Coding agent, model, filesystem, shell, test runner, optional MCP tools |
The layers are connected but do not replace each other: a stronger model does not decide who owns a requirement, a good specification does not execute the test suite, and a tool connection does not decide whether a result satisfies the user.
Five useful organizing ideas
Matt Pocock Skills: choose a workflow, preserve the reasoning
Think in terms of clarification, domain language, durable decisions and small implementation slices. Project knowledge should be available to the next session through useful documents and precise pointers.
Spec Kit: make the requirement-to-implementation path explicit
The feature specification, technical plan and tasks provide reviewable handoffs. Project principles guide the work, and convergence asks whether the implementation and artifacts agree.
OpenSpec: keep current behavior separate from proposed change
The baseline describes the system's maintained contract. Change deltas describe what will be added, modified or removed. Acceptance should reconcile the two, so that the current contract is not scattered across old proposals.
BMAD Method: coordinate product thinking and delivery
Use appropriate planning depth and specialist perspectives to move from intent to a buildable change or story. Small changes can start directly with Build; larger efforts need clearer handoffs.
Superpowers: make engineering routines part of execution
Choose the right design path, work through short feedback loops, debug with evidence and verify before claiming completion. The process should respond to the scope of the actual change.
The feedback loop underneath all five
There are two different corrections in the loop. If the implementation violates an agreed requirement, fix the implementation. If the requirement itself was wrong or incomplete, revise the decision and its tests together. Hiding both cases under “the agent made a mistake” loses useful information.
Three kinds of memory
| Memory | Typical contents | Limitation |
|---|---|---|
| Conversation | Exploration, temporary hypotheses, working discussion | A new session may not receive it |
| Repository knowledge | Accepted specs, glossary, ADRs, agent instructions | It must be maintained and discoverable |
| Execution evidence | Test results, observed failures, reviewed revision | It becomes stale when the relevant code or environment changes |
Move decisions out of chat when they must survive. Keep transient guesses out of the authoritative contract. Associate evidence with the revision and environment that produced it.
Two independent review questions
| Question | Examine | Failure example |
|---|---|---|
| Did we build the intended thing? | Requirements, scenarios and user-visible behavior | JSON export exists but changes the default output |
| Is it built well enough? | Tests, design, compatibility and repository standards | Correct output is produced by duplicated, fragile parsing logic |
A passing answer to one question does not answer the other. This is why a useful completion report links the requirement, the diff and the executed checks.
From map to practice
Pick one recurring failure and one method to evaluate. Use the lab and its five routes if you want a controlled exercise, or choose a small real change with clear acceptance criteria. Afterward, inspect whether the next session starts from better knowledge.
The comparison article provides selection guidance and a trial protocol.
Checkpoint
Explain the difference between a method, a durable artifact and an execution tool. Then identify which information must survive when a new session starts.
Knowledge map complete. You can now describe each framework as a variation on the same loop.
Sources and further reading
Documentation checked on 2026-10-04. The grouping in the visual is an editorial synthesis of these primary sources.