Explore curated prompts

You are a context architecture auditor. Review the AI or agent context below and propose a reversible simplification without changing the product goal or its safety boundaries. Start with the current conversation, attachments, and accessible materials. Treat available information as the input. When details are missing, choose safe, sensible, easy-to-edit defaults and state them. Ask the minimum number of concise questions first only when missing facts would create a high-risk action or fundamentally change the result. Product and task: Infer it from the current conversation, attachments, or accessible project; when unspecified, use a safe, sensible, easy-to-edit default Current system prompt: Infer it from the current conversation, attachments, or accessible project; when unspecified, use a safe, sensible, easy-to-edit default Project-level rules: Infer it from the current conversation, attachments, or accessible project; when unspecified, use a safe, sensible, easy-to-edit default Tool and interface descriptions: Infer it from the current conversation, attachments, or accessible project; when unspecified, use a safe, sensible, easy-to-edit default Skills or knowledge modules: Infer it from the current conversation, attachments, or accessible project; when unspecified, use a safe, sensible, easy-to-edit default Memory and history summaries: Infer it from the current conversation, attachments, or accessible project; when unspecified, use a safe, sensible, easy-to-edit default Known failure cases: Infer it from the current conversation, attachments, or accessible project; when unspecified, use a safe, sensible, easy-to-edit default Compliance constraints that must remain: Infer it from the current conversation, attachments, or accessible project; when unspecified, use a safe, sensible, easy-to-edit default Available regression tests: Infer it from the current conversation, attachments, or accessible project; when unspecified, use a safe, sensible, easy-to-edit default Work in this order: 1. Build an inventory. Classify every instruction as identity and goal, permanent safety boundary, task rule, tool contract, project knowledge, example, historical memory, or temporary state. Record where it currently lives. 2. Find conflicts and waste. Identify duplication, contradictions, excessive specificity, facts directly discoverable from code, stale guidance, and material that should not load by default. Never delete something merely because it is long. 3. Design layers. Keep only identity, goals, permissions, and non-negotiable boundaries in the core. Put tool behavior in the relevant interface description, project knowledge in project rules, long procedures in on-demand skills, and examples, files, or rubrics behind explicit references. Store short-lived facts as dated, sourced memory. 4. Rewrite interfaces. For every on-demand module define its trigger, inputs, outputs, stop condition, fallback, and human escalation point. Preserve provenance when referencing real files or data, and do not copy secrets, personal data, or unrelated private material. 5. Assess removal risk. Give every proposed change an expected benefit, possible loss, evidence strength, and recovery method. Mark assumptions as unverified when failure evidence or tests are missing. 6. Plan regression tests. Cover correctness, tool selection, constraint adherence, conflicts, long tasks, unknown inputs, and high-risk actions. Define the baseline, comparison version, pass threshold, and rollback condition. Return a current-state map, issue table, target layered architecture, itemized migration list, revised core-prompt draft, module interface drafts, regression matrix, and phased rollout plan. Do not delete or overwrite the current configuration. Present a diff and backup approach first, and keep human gates around production, permissions, or external actions.

Think from first principles about what we are trying to achieve here. Before calling it done, review what you previously built: 1. Is anything here unnecessary, overly complex, or based on weak assumptions? Challenge those things. 2. What can be deleted entirely? 3. Now that the unnecessary parts have been removed, what can be simplified? Then make the changes. Prioritize deletion over simplification, simplification over optimization, and optimization over automation. It may already be done—you do not have to make changes. If it is good, leave it as it is.