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.
Source: forsonny/deep-discovery — distributed by TomeVault.
1---2name: deep-discovery3description: 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.4---56# Deep Discovery78A structured self-interrogation framework that exhaustively explores a topic through9100 sequential questions, each building on the previous answer. Designed to be10used in Codex as a skill for rigorous, sequential exploration before committing11to a design or decision.1213## Preflight14151. Identify the topic, available context, focus, and starting point. If any of16 those are too ambiguous to run a useful interrogation, ask at most three17 clarifying questions before starting.182. Choose the mode:19 - **Evaluation:** an existing design, architecture, strategy, or plan exists.20 - **Exploration:** the user is starting from scratch.21 - **Comparison:** the user is choosing between two or three options.223. Choose the closest domain pattern: software architecture, code review,23 Codex plugin/skill creation, business/product, trading/financial, or general.24 Use `references/question-patterns.md` as the index, then read only the relevant25 reference file when domain-specific prompts would improve the run.264. After enough context is available, run the process without further human27 input unless the user explicitly asks to participate.2829## How It Works3031The 100-question process is a **self-dialogue**: ask a question, answer it, then32ask the next question based on what the answer revealed. The questions naturally33progress through phases:3435### Question Progression3637| Phase | Questions | Focus |38|-------|-----------|-------|39| Foundation | Q1-Q10 | Goal, constraints, assumptions, what makes this unique |40| Mechanics | Q11-Q30 | How it works, components, data flow, dependencies |41| Stress Testing | Q31-Q50 | Edge cases, failure modes, what breaks first |42| Competitive Analysis | Q51-Q65 | What exists, what's different, what's the real edge |43| Feasibility | Q66-Q80 | Can this actually be built/done, what are the blockers |44| Refinement | Q81-Q90 | Improvements, optimizations, what was missed |45| Synthesis | Q91-Q100 | Final architecture, honest assessment, actionable output |4647### Rules for Questions48491. **Q1 is always:** "What is the goal, and how do we get there?"502. Each question MUST build on the previous answer; avoid random jumps.513. Be brutally honest; surface problems instead of hiding them.524. Challenge assumptions with questions like "Is that actually true?"535. Go concrete, not abstract: use specific numbers and scenarios.546. If an answer reveals a critical flaw, spend multiple questions exploring it.557. The final 10 questions must synthesize everything into actionable output.568. Do not abbreviate the run below 100 questions unless the user explicitly asks57 for a shorter version.5859## Running the Process6061Run the process in the current Codex conversation by default. If the user62explicitly asks to delegate the work to a sub-agent, use Codex's available63sub-agent mechanism and summarize the returned findings. Do not assume a64delegation tool is available, and do not refer to legacy tool names or custom65agent manifests from other harnesses.6667### Prompt Template6869Use this structure for the deep-discovery run:7071```72Topic: [what we're exploring]73Context: [relevant background - what's already been decided, constraints, goals]74Focus: [what specifically to evaluate - architecture? strategy? feasibility?]75Starting point: [any existing design or proposal to interrogate, or "from scratch"]76Mode: [evaluation | exploration | comparison]77Domain pattern: [software architecture | code review | codex plugin/skill creation | business/product | trading/financial | general]7879Do a rigorous 100-question self-brainstorm. Each question builds on the last.80Start with "What is the goal, and how do we get there?" and dig progressively81deeper through mechanics, stress testing, competitive analysis, feasibility,82and synthesis.8384Be brutally honest. Find every weakness, every edge case, every failure mode.85Also identify what's strong and worth keeping.8687At the end, provide:881. Questions asked: 100892. Domain pattern used903. A numbered list of the top 10 critical issues found914. A numbered list of the top 10 strengths925. Specific changes recommended, with rationale936. A revised proposal or architecture if the original needs significant changes947. The honest bottom line: one paragraph, no sugar-coating95```9697### Handling the Output9899After completing the run:1001011. **Extract the key findings** - summarize the top issues and strengths for the user.1022. **Present the revised architecture/proposal** if one was generated.1033. **Integrate findings** into the current design process.1044. Do NOT dump the full 100 Q&A into the conversation unless the user explicitly asks for it; summarize the insights.105106## Variations107108### Evaluation Mode109110When an existing design/architecture/plan exists, focus the 100 questions on111interrogating that specific proposal. Include the full design and focus on112finding flaws, edge cases, and missing constraints.113114### Exploration Mode115116When starting from scratch (no existing proposal), the 100 questions should117build toward a complete design. The output should be a fully-formed proposal118that emerged from the questioning process.119120### Comparison Mode121122When choosing between 2-3 options, run a separate 100-question process for each,123then compare the findings. If the user explicitly asks for delegated or parallel124work and Codex exposes a suitable mechanism, these runs may be delegated.125Synthesize a side-by-side comparison of their top issues, strengths, and revised126proposals to present a clear recommendation to the user.127128## Integration with Other Skills129130- **Before brainstorming:** Run discovery to deeply understand the problem space131- **After brainstorming:** Run discovery to stress-test the proposed design132- **Before writing plans:** Run discovery to validate the architecture133- **During debugging:** Run discovery to exhaustively explore root causes134135## Additional Resources136137### Reference Files138139- **`references/question-patterns.md`** - Index of available domain pattern files.140- **`references/software-architecture.md`** - Architecture and system design patterns.141- **`references/code-review.md`** - Patch, branch, and implementation review patterns.142- **`references/codex-plugin-creation.md`** - Codex plugin and skill planning/audit patterns.143- **`references/business-product.md`** - Business strategy and product patterns.144- **`references/trading-financial.md`** - Trading system and financial strategy patterns.145- **`references/general-pattern.md`** - Universal fallback pattern and discovery tips.146147---148> Source: [forsonny/deep-discovery](https://github.com/forsonny/deep-discovery) — distributed by [TomeVault](https://tomevault.io).149<!-- tomevault:4.0:skill_md:2026-06-23 -->