Skip to main content

rethink

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.

معلومات المصدر

المستودع
EpicenterHQ/epicenter
آخر نشاط في المصدر
٤ أكتوبر ٢٠٢٦ في ١٦:٢٤
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٤٬٨٢٢
التفرعات
٣٨٦

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

مستكشف الملفات
5 ملفات

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
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