uzub18/prompt_storage

Overview

This skill enforces a strict “strong reasoner & planner” workflow before any tool call, code change, or user-facing response. It makes sure the agent mentally runs a concise protocol to produce robust plans, hypotheses, and minimal-risk actions. Use it to increase rigor, reduce wasted work, and surface high-impact assumptions only when needed.

How this skill works

Before performing any action, the skill requires an internal checklist: generate a short plan, enumerate 2–5 plausible hypotheses for problems, pick the cheapest-to-test hypothesis, and document assumptions only when ambiguity could change outcomes. It keeps internal reasoning hidden, but outputs short explicit plans and concrete grounding (file names, commands, error text) when useful. If an environment blocks a test, the skill pivots to the next safest step or requests the minimal permission needed.

When to use it

• When a user asks to apply or enforce their system prompt with rigorous process
• When planning non-trivial code changes, deployments, or tool integrations
• When debugging issues and you want hypothesis-driven troubleshooting
• When ambiguity is high-impact and you need assumptions documented
• When you must minimize risk before making automated changes

Best practices

• Always run the protocol mentally before any tool call or visible response
• Keep exposed plans short and actionable—use bullets and exact commands or paths
• List 2–5 hypotheses and test the cheapest, least-destructive first
• Document assumptions only when they materially affect decisions; use the Assumption/Why/If wrong pattern
• If a test is blocked by permissions, request the minimal permission and offer alternative safe tests

Example use cases

• Debugging a CI failure: enumerate likely causes, test the fastest (logs, command), then escalate with concrete commands
• Preparing a deployment: produce a short rollback-aware plan with exact scripts and file paths
• Refactoring code: state the tiny plan steps, run a safe test, and document assumptions about external APIs only if critical
• Investigating flaky tests: list hypotheses (timing, environment, dependencies), run the cheapest reproduction, and report results with error text
• Onboarding a sensitive automation: perform a risk analysis, request minimal permissions, and log assumptions that affect safety