- name
- rethink
- description
- Use when the user asks whether there is a better or simpler way, wants to zoom out, questions why existing concepts or boundaries exist, or asks for rethink, redesign, greenfield thinking, first principles, radical alternatives, or a clean break. Also use when repeated complexity suggests the current ownership, lifecycle, representation, or API contract should be reconsidered. Skip routine fixes and local changes within a settled design.
# Rethink
Pursue the strongest vision of what this could become. Greenfield discovery is
the default: start from the desired outcome and actual users and callers, then
question the inherited boundaries, promises, and organizing idea. Discover what
deserves to be built before narrowing to whether an emerging proposal works.
Use [dialectic](../dialectic/SKILL.md) to make that vision concrete enough to
experience and challenge. Make the deletion prize and new complexity explicit:
what machinery, obligations, or planned work disappears, and what guarantees
replace it? A better design may introduce an abstraction that earns its place.
Establish which constraints are real, then work backward from the strongest
supported destination. Judge the whole bargain rather than the number of parts.
## Pursue the vision
Start with what the user wants to make possible and follow the idea all the way.
Let the surrounding system come into question when its shape limits the outcome.
Existing APIs, ownership boundaries, package layouts, and prior decisions can all
be reconsidered. The cost of changing them belongs in the path to the destination;
it need not define the destination before we have seen it.
[Greenfield thinking](references/greenfield.md) develops the desired whole.
[Radical options](references/radical-options.md) challenges assumptions that keep
that whole out of reach. Use these references as the question calls for them.
Neither is a requirement to produce a fixed number of alternatives.
When a promise of consistent file data drives coordination, use
[repairability](references/repairability.md) to distinguish information
protection from inconsistencies a human or agent could inspect and repair.
Develop the vision through dialectic: articulate what the system could become,
show how someone would use it, and let reactions to both deepen or revise the
proposal. Concrete expression makes ambition inspectable. Follow a caller,
interaction, or data flow far enough to expose the decisions the model makes
about ownership, state, policy, and lifetime.
Read the current system to learn what it reveals about the problem. Separate
inherited choices from demonstrated constraints. Investigate uncertain limits;
do not silently turn them into reasons to lower the ambition. Respect the user’s
explicit requirements, and surface a conflict when pursuing the vision would
require changing one.
Use independent explorations when they could reveal a better destination,
different boundary, or neglected caller need. A known blind spot is not required.
[adversarial-review](../adversarial-review/SKILL.md) owns that search and its
coordination. Bring discoveries back into the concrete vision through dialectic.
## Work backward from the destination
As the direction settles, describe the observable behavior that would make it
real. Derive the implementation from that target: what must be created, moved,
replaced, or removed, in what dependency order, and what evidence will establish
that it works? Let the destination determine the work.
Keep the reasons the vision is worth pursuing present through implementation.
A convenient intermediate shape must not quietly become the endpoint. Use
[clean breaks](references/clean-breaks.md) to carry the chosen direction through
consumers and retire the superseded shapes.
Distinguish a difficult step from a discovery that changes the destination.
Continue solving the former. Bring the latter back into dialectic with the
concrete consequence visible, then work backward from the revised understanding.
An already settled direction needs no repeated discovery exercise.
Carry out the work within the user’s authorization. A request to explore a
vision remains exploration; an authorized replacement should proceed without
an added confirmation ritual.
## Close against the vision
Judge the result against the destination and the qualities that made it worth
pursuing. Exercise its concrete use and verify the changed contracts. Explain
what now realizes the vision and identify consequential drift. Passing tests
alone does not establish that the intended system has been built.
عرض على GitHub