القائمة
Use when starting ambiguous or high-stakes work, or when the user says "blind spot pass", "interview me", "what am I missing", or asks for an implementation plan.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Anthropic API rate limit handling - retry logic, backoff, throttling for batch workloads against Claude models
Use when building an automated test → issue → fix loop with Claude Code and GitHub issues — overnight auto-fixing, regression loops, self-healing CI.
Use when creating, editing, publishing, or deleting posts on Cyril's Workshop blog or the steponnopets.net devblog.
Use when writing or contributing a boofuzz network-protocol fuzzer in this repo — layout, formatting rules, and reading results.
Use when a task needs real-time control of a connected browser via the Browser Bridge Broker — submit JS jobs over HTTP that browsers eval and return.
Use when training a character LoRA (Chroma/Flux or Pony/SDXL) on a RunPod GPU and wiring it into the ComfyUI + pony_web render stack.
| name | Finding Unknowns |
| description | Use when starting ambiguous or high-stakes work, or when the user says "blind spot pass", "interview me", "what am I missing", or asks for an implementation plan. |
Work quality with Fable-class models is bottlenecked by how well the unknowns get articulated, not by prompt precision. Map the gaps instead of tuning specificity: over-specified instructions force suboptimal paths; under-specified ones silently fall back to industry defaults that may not fit. When a request is over-constrained, push back; when it's vague, surface the unknowns rather than guessing.
Four kinds of gap to probe for:
Offer or run these when they fit; the user may invoke them by name.
Blind spot pass (before starting): the user names an area they don't know; enumerate what they likely haven't considered — risks, existing patterns, standards, integration points. Deliverable is the list, not a fix.
Interview: ask clarifying questions one at a time, about genuine ambiguities only. Stop when the remaining unknowns wouldn't change the design.
Brainstorm / prototypes: when direction is undecided, produce several wildly different directions (the user may say "4 directions") or cheap throwaway prototypes before committing to one. Don't converge early.
References over descriptions: prefer being pointed at working code over screenshots or prose descriptions — and say so when the user is about to describe something that exists as code. Code carries structure that descriptions lose.
Implementation plan: foreground the decisions that are sticky or likely to be revisited — data models, interfaces, UX flows — over mechanical steps. The plan is for finding disagreements early, not for listing work.
Implementation notes (during): keep a running note of deviations from the plan and surprises hit along the way; unexpected edge cases are findings, not noise. Surface them at the end rather than silently absorbing them.
Pitch / explainer (after): package the change for stakeholders who have the same unknowns the user started with.
Quiz (after): offer to quiz the user on what changed and why — verifies their understanding survived the delegation.
Treat the exchange as thought partnership: it helps to know the user's experience level with the domain and where they are in their thinking (exploring vs committed). If that positioning is missing and it matters, ask for it — advice for a first-timer exploring differs from advice for an expert executing.
