| name | deep-discovery |
| description | Use when the user asks for deep discovery, 100-question brainstorming, idea interrogation, architecture stress testing, strategy vetting, weakness finding, hole-poking, exhaustive exploration, planning or auditing Codex plugins or skills, or pre-commitment review of a design, plan, strategy, architecture, product, business idea, trading system, or problem space. |
Deep Discovery
A structured self-interrogation framework that exhaustively explores a topic through
100 sequential questions, each building on the previous answer. Designed to be
used in Codex as a skill for rigorous, sequential exploration before committing
to a design or decision.
Preflight
- Identify the topic, available context, focus, and starting point. If any of
those are too ambiguous to run a useful interrogation, ask at most three
clarifying questions before starting.
- Choose the mode:
- Evaluation: an existing design, architecture, strategy, or plan exists.
- Exploration: the user is starting from scratch.
- Comparison: the user is choosing between two or three options.
- Choose the closest domain pattern: software architecture, code review,
Codex plugin/skill creation, business/product, trading/financial, or general.
Use
references/question-patterns.md as the index, then read only the relevant
reference file when domain-specific prompts would improve the run.
- After enough context is available, run the process without further human
input unless the user explicitly asks to participate.
How It Works
The 100-question process is a self-dialogue: ask a question, answer it, then
ask the next question based on what the answer revealed. The questions naturally
progress through phases:
Question Progression
| Phase | Questions | Focus |
|---|
| Foundation | Q1-Q10 | Goal, constraints, assumptions, what makes this unique |
| Mechanics | Q11-Q30 | How it works, components, data flow, dependencies |
| Stress Testing | Q31-Q50 | Edge cases, failure modes, what breaks first |
| Competitive Analysis | Q51-Q65 | What exists, what's different, what's the real edge |
| Feasibility | Q66-Q80 | Can this actually be built/done, what are the blockers |
| Refinement | Q81-Q90 | Improvements, optimizations, what was missed |
| Synthesis | Q91-Q100 | Final architecture, honest assessment, actionable output |
Rules for Questions
- Q1 is always: "What is the goal, and how do we get there?"
- Each question MUST build on the previous answer; avoid random jumps.
- Be brutally honest; surface problems instead of hiding them.
- Challenge assumptions with questions like "Is that actually true?"
- Go concrete, not abstract: use specific numbers and scenarios.
- If an answer reveals a critical flaw, spend multiple questions exploring it.
- The final 10 questions must synthesize everything into actionable output.
- Do not abbreviate the run below 100 questions unless the user explicitly asks
for a shorter version.
Running the Process
Run the process in the current Codex conversation by default. If the user
explicitly asks to delegate the work to a sub-agent, use Codex's available
sub-agent mechanism and summarize the returned findings. Do not assume a
delegation tool is available, and do not refer to legacy tool names or custom
agent manifests from other harnesses.
Prompt Template
Use this structure for the deep-discovery run:
Topic: [what we're exploring]
Context: [relevant background - what's already been decided, constraints, goals]
Focus: [what specifically to evaluate - architecture? strategy? feasibility?]
Starting point: [any existing design or proposal to interrogate, or "from scratch"]
Mode: [evaluation | exploration | comparison]
Domain pattern: [software architecture | code review | codex plugin/skill creation | business/product | trading/financial | general]
Do a rigorous 100-question self-brainstorm. Each question builds on the last.
Start with "What is the goal, and how do we get there?" and dig progressively
deeper through mechanics, stress testing, competitive analysis, feasibility,
and synthesis.
Be brutally honest. Find every weakness, every edge case, every failure mode.
Also identify what's strong and worth keeping.
At the end, provide:
1. Questions asked: 100
2. Domain pattern used
3. A numbered list of the top 10 critical issues found
4. A numbered list of the top 10 strengths
5. Specific changes recommended, with rationale
6. A revised proposal or architecture if the original needs significant changes
7. The honest bottom line: one paragraph, no sugar-coating
Handling the Output
After completing the run:
- Extract the key findings - summarize the top issues and strengths for the user.
- Present the revised architecture/proposal if one was generated.
- Integrate findings into the current design process.
- Do NOT dump the full 100 Q&A into the conversation unless the user explicitly asks for it; summarize the insights.
Variations
Evaluation Mode
When an existing design/architecture/plan exists, focus the 100 questions on
interrogating that specific proposal. Include the full design and focus on
finding flaws, edge cases, and missing constraints.
Exploration Mode
When starting from scratch (no existing proposal), the 100 questions should
build toward a complete design. The output should be a fully-formed proposal
that emerged from the questioning process.
Comparison Mode
When choosing between 2-3 options, run a separate 100-question process for each,
then compare the findings. If the user explicitly asks for delegated or parallel
work and Codex exposes a suitable mechanism, these runs may be delegated.
Synthesize a side-by-side comparison of their top issues, strengths, and revised
proposals to present a clear recommendation to the user.
Integration with Other Skills
- Before brainstorming: Run discovery to deeply understand the problem space
- After brainstorming: Run discovery to stress-test the proposed design
- Before writing plans: Run discovery to validate the architecture
- During debugging: Run discovery to exhaustively explore root causes
Additional Resources
Reference Files
references/question-patterns.md - Index of available domain pattern files.references/software-architecture.md - Architecture and system design patterns.references/code-review.md - Patch, branch, and implementation review patterns.references/codex-plugin-creation.md - Codex plugin and skill planning/audit patterns.references/business-product.md - Business strategy and product patterns.references/trading-financial.md - Trading system and financial strategy patterns.references/general-pattern.md - Universal fallback pattern and discovery tips.
