Enhance research documentation for UAV frame materials and reliability assessment. Update SKILL.md with new guidelines for internet search depth and multi-perspective analysis. Revise quality checklists to include comprehensive search criteria. Improve source tiering with emphasis on broad and cross-domain searches. Refine solution draft and reasoning chain to focus on reliability comparisons between VTOL and catapult+parachute systems.

2026-04-22 09:16:38 +00:00 · 2026-03-21 18:40:58 +02:00
parent f70d701979
commit 27febff23c
14 changed files with 2125 additions and 666 deletions
@@ -26,6 +26,9 @@ Transform vague topics raised by users into high-quality, deliverable research r
 - **Prioritize authoritative sources: L1 > L2 > L3 > L4**
 - **Intermediate results must be saved for traceability and reuse**
 - **Ask, don't assume** — when any aspect of the problem, criteria, or restrictions is unclear, STOP and ask the user before proceeding
+- **Internet-first investigation** — do not rely on training data for factual claims; search the web extensively for every sub-question, rephrase queries when results are thin, and keep searching until you have converging evidence from multiple independent sources
+- **Multi-perspective analysis** — examine every problem from at least 3 different viewpoints (e.g., end-user, implementer, business decision-maker, contrarian, domain expert, field practitioner); each perspective should generate its own search queries
+- **Question multiplication** — for each sub-question, generate multiple reformulated search queries (synonyms, related terms, negations, "what can go wrong" variants, practitioner-focused variants) to maximize coverage and uncover blind spots

 ## Context Resolution

@@ -152,18 +155,20 @@ A focused preliminary research pass **before** the main solution research. The g
   - Ambiguous acceptance criteria values → ask
   - Missing context (no `security_approach.md`, no `input_data/`) → ask what they have
   - Conflicting restrictions → ask which takes priority
-3. Research in internet:
-   - How realistic are the acceptance criteria for this specific domain?
-   - How critical is each criterion?
-   - What domain-specific acceptance criteria are we missing?
-   - Impact of each criterion value on the whole system quality
-   - Cost/budget implications of each criterion
-   - Timeline implications — how long would it take to meet each criterion
-4. Research restrictions:
-   - Are the restrictions realistic?
-   - Should any be tightened or relaxed?
-   - Are there additional restrictions we should add?
-5. Verify findings with authoritative sources (official docs, papers, benchmarks)
+3. Research in internet **extensively** — use multiple search queries per question, rephrase, and search from different angles:
+   - How realistic are the acceptance criteria for this specific domain? Search for industry benchmarks, standards, and typical values
+   - How critical is each criterion? Search for case studies where criteria were relaxed or tightened
+   - What domain-specific acceptance criteria are we missing? Search for industry standards, regulatory requirements, and best practices in the specific domain
+   - Impact of each criterion value on the whole system quality — search for research papers and engineering reports
+   - Cost/budget implications of each criterion — search for pricing, total cost of ownership analyses, and comparable project budgets
+   - Timeline implications — search for project timelines, development velocity reports, and comparable implementations
+   - What do practitioners in this domain consider the most important criteria? Search forums, conference talks, and experience reports
+4. Research restrictions from multiple perspectives:
+   - Are the restrictions realistic? Search for comparable projects that operated under similar constraints
+   - Should any be tightened or relaxed? Search for what constraints similar projects actually ended up with
+   - Are there additional restrictions we should add? Search for regulatory, compliance, and safety requirements in this domain
+   - What restrictions do practitioners wish they had defined earlier? Search for post-mortem reports and lessons learned
+5. Verify findings with authoritative sources (official docs, papers, benchmarks) — each key finding must have at least 2 independent sources

 **Uses Steps 0-3 of the 8-step engine** (question classification, decomposition, source tiering, fact extraction) scoped to AC and restrictions assessment.

@@ -204,12 +209,14 @@ Full 8-step research methodology. Produces the first solution draft.
 **Input**: All files from INPUT_DIR (possibly updated after Phase 1) + Phase 1 artifacts

 **Task** (drives the 8-step engine):
-1. Research existing/competitor solutions for similar problems
-2. Research the problem thoroughly — all possible ways to solve it, split into components
-3. For each component, research all possible solutions and find the most efficient state-of-the-art approaches
-4. Verify that suggested tools/libraries actually exist and work as described
-5. Include security considerations in each component analysis
-6. Provide rough cost estimates for proposed solutions
+1. Research existing/competitor solutions for similar problems — search broadly across industries and adjacent domains, not just the obvious competitors
+2. Research the problem thoroughly — all possible ways to solve it, split into components; search for how different fields approach analogous problems
+3. For each component, research all possible solutions and find the most efficient state-of-the-art approaches — use multiple query variants and perspectives from Step 1
+4. For each promising approach, search for real-world deployment experience: success stories, failure reports, lessons learned, and practitioner opinions
+5. Search for contrarian viewpoints — who argues against the common approaches and why? What failure modes exist?
+6. Verify that suggested tools/libraries actually exist and work as described — check official repos, latest releases, and community health (stars, recent commits, open issues)
+7. Include security considerations in each component analysis
+8. Provide rough cost estimates for proposed solutions

 Be concise in formulating. The fewer words, the better, but do not miss any important details.

@@ -271,11 +278,17 @@ Full 8-step research methodology applied to assessing and improving an existing

 **Task** (drives the 8-step engine):
 1. Read the existing solution draft thoroughly
-2. Research in internet — identify all potential weak points and problems
-3. Identify security weak points and vulnerabilities
-4. Identify performance bottlenecks
-5. Address these problems and find ways to solve them
-6. Based on findings, form a new solution draft in the same format
+2. Research in internet extensively — for each component/decision in the draft, search for:
+   - Known problems and limitations of the chosen approach
+   - What practitioners say about using it in production
+   - Better alternatives that may have emerged recently
+   - Common failure modes and edge cases
+   - How competitors/similar projects solve the same problem differently
+3. Search specifically for contrarian views: "why not [chosen approach]", "[chosen approach] criticism", "[chosen approach] failure"
+4. Identify security weak points and vulnerabilities — search for CVEs, security advisories, and known attack vectors for each technology in the draft
+5. Identify performance bottlenecks — search for benchmarks, load test results, and scalability reports
+6. For each identified weak point, search for multiple solution approaches and compare them
+7. Based on findings, form a new solution draft in the same format

 **📁 Save action**: Write `OUTPUT_DIR/solution_draft##.md` (incremented) using template: `templates/solution_draft_mode_b.md`

@@ -374,6 +387,35 @@ Key principle: Critical-sensitivity topics (AI/LLMs, blockchain) require sources
 - **Sub-question C**: "In what scenarios is X applicable/inapplicable?" (Boundary conditions)
 - **Sub-question D**: "What are X's development trends/best practices?" (Extended analysis)

+#### Perspective Rotation (MANDATORY)
+
+For each research problem, examine it from **at least 3 different perspectives**. Each perspective generates its own sub-questions and search queries.
+
+| Perspective | What it asks | Example queries |
+|-------------|-------------|-----------------|
+| **End-user / Consumer** | What problems do real users encounter? What do they wish were different? | "X problems", "X frustrations reddit", "X user complaints" |
+| **Implementer / Engineer** | What are the technical challenges, gotchas, hidden complexities? | "X implementation challenges", "X pitfalls", "X lessons learned" |
+| **Business / Decision-maker** | What are the costs, ROI, strategic implications? | "X total cost of ownership", "X ROI case study", "X vs Y business comparison" |
+| **Contrarian / Devil's advocate** | What could go wrong? Why might this fail? What are critics saying? | "X criticism", "why not X", "X failures", "X disadvantages real world" |
+| **Domain expert / Academic** | What does peer-reviewed research say? What are theoretical limits? | "X research paper", "X systematic review", "X benchmarks academic" |
+| **Practitioner / Field** | What do people who actually use this daily say? What works in practice vs theory? | "X in production", "X experience report", "X after 1 year" |
+
+Select at least 3 perspectives relevant to the problem. Document the chosen perspectives in `00_question_decomposition.md`.
+
+#### Question Explosion (MANDATORY)
+
+For **each sub-question**, generate **at least 3-5 search query variants** before searching. This ensures broad coverage and avoids missing relevant information due to terminology differences.
+
+**Query variant strategies**:
+- **Specificity ladder**: broad ("indoor navigation systems") → narrow ("UWB-based indoor drone navigation accuracy")
+- **Negation/failure**: "X limitations", "X failure modes", "when X doesn't work"
+- **Comparison framing**: "X vs Y for Z", "X alternative for Z", "X or Y which is better for Z"
+- **Practitioner voice**: "X in production experience", "X real-world results", "X lessons learned"
+- **Temporal**: "X 2025", "X latest developments", "X roadmap"
+- **Geographic/domain**: "X in Europe", "X for defense applications", "X in agriculture"
+
+Record all planned queries in `00_question_decomposition.md` alongside each sub-question.
+
 **⚠️ Research Subject Boundary Definition (BLOCKING - must be explicit)**:

 When decomposing questions, you must explicitly define the **boundaries of the research subject**:
@@ -397,9 +439,11 @@ When decomposing questions, you must explicitly define the **boundaries of the r
   - Classified question type and rationale
   - **Research subject boundary definition** (population, geography, timeframe, level)
   - List of decomposed sub-questions
+   - **Chosen perspectives** (at least 3 from the Perspective Rotation table) with rationale
+   - **Search query variants** for each sub-question (at least 3-5 per sub-question)
 4. Write TodoWrite to track progress

-### Step 2: Source Tiering & Authority Anchoring
+### Step 2: Source Tiering & Exhaustive Web Investigation

 Tier sources by authority, **prioritize primary sources** (L1 > L2 > L3 > L4). Conclusions must be traceable to L1/L2; L3/L4 serve as supplementary and validation.

@@ -411,6 +455,24 @@ Tier sources by authority, **prioritize primary sources** (L1 > L2 > L3 > L4). C
 - Always cross-verify training data claims against live sources for facts that may have changed (versions, APIs, deprecations, security advisories)
 - When citing web sources, include the URL and date accessed

+#### Exhaustive Search Requirements (MANDATORY)
+
+Do not stop at the first few results. The goal is to build a comprehensive evidence base.
+
+**Minimum search effort per sub-question**:
+- Execute **all** query variants generated in Step 1's Question Explosion (at least 3-5 per sub-question)
+- Consult at least **2 different source tiers** per sub-question (e.g., L1 official docs + L4 community discussion)
+- If initial searches yield fewer than 3 relevant sources for a sub-question, **broaden the search** with alternative terms, related domains, or analogous problems
+
+**Search broadening strategies** (use when results are thin):
+- Try adjacent fields: if researching "drone indoor navigation", also search "robot indoor navigation", "warehouse AGV navigation"
+- Try different communities: academic papers, industry whitepapers, military/defense publications, hobbyist forums
+- Try different geographies: search in English + search for European/Asian approaches if relevant
+- Try historical evolution: "history of X", "evolution of X approaches", "X state of the art 2024 2025"
+- Try failure analysis: "X project failure", "X post-mortem", "X recall", "X incident report"
+
+**Search saturation rule**: Continue searching until new queries stop producing substantially new information. If the last 3 searches only repeat previously found facts, the sub-question is saturated.
+
 **📁 Save action**:
 For each source consulted, **immediately** append to `01_source_registry.md` using the entry template from `references/source-tiering.md`.

@@ -456,6 +518,40 @@ For each extracted fact, **immediately** append to `02_fact_cards.md`:
 - Wrong: "The Ministry of Education banned phones in classrooms" (doesn't specify who)
 - Correct: "The Ministry of Education banned K-12 students from bringing phones into classrooms (does not apply to university students)"

+### Step 3.5: Iterative Deepening — Follow-Up Investigation
+
+After initial fact extraction, review what you have found and identify **knowledge gaps and new questions** that emerged from the initial research. This step ensures the research doesn't stop at surface-level findings.
+
+**Process**:
+
+1. **Gap analysis**: Review fact cards and identify:
+   - Sub-questions with fewer than 3 high-confidence facts → need more searching
+   - Contradictions between sources → need tie-breaking evidence
+   - Perspectives (from Step 1) that have no or weak coverage → need targeted search
+   - Claims that rely only on L3/L4 sources → need L1/L2 verification
+
+2. **Follow-up question generation**: Based on initial findings, generate new questions:
+   - "Source X claims [fact] — is this consistent with other evidence?"
+   - "If [approach A] has [limitation], how do practitioners work around it?"
+   - "What are the second-order effects of [finding]?"
+   - "Who disagrees with [common finding] and why?"
+   - "What happened when [solution] was deployed at scale?"
+
+3. **Targeted deep-dive searches**: Execute follow-up searches focusing on:
+   - Specific claims that need verification
+   - Alternative viewpoints not yet represented
+   - Real-world case studies and experience reports
+   - Failure cases and edge conditions
+   - Recent developments that may change the picture
+
+4. **Update artifacts**: Append new sources to `01_source_registry.md`, new facts to `02_fact_cards.md`
+
+**Exit criteria**: Proceed to Step 4 when:
+- Every sub-question has at least 3 facts with at least one from L1/L2
+- At least 3 perspectives from Step 1 have supporting evidence
+- No unresolved contradictions remain (or they are explicitly documented as open questions)
+- Follow-up searches are no longer producing new substantive information
+
 ### Step 4: Build Comparison/Analysis Framework

 Based on the question type, select fixed analysis dimensions. **For dimension lists** (General, Concept Comparison, Decision Support): Read `references/comparison-frameworks.md`
@@ -657,9 +753,15 @@ Default intermediate artifacts location: `RESEARCH_DIR/`
 │                                                                  │
 │ 8-STEP ENGINE:                                                   │
 │  0. Classify question type → Select framework template           │
-│  1. Decompose question → mode-specific sub-questions             │
-│  2. Tier sources → L1 Official > L2 Blog > L3 Media > L4         │
+│  0.5 Novelty sensitivity → Time windows for sources              │
+│  1. Decompose question → sub-questions + perspectives + queries  │
+│     → Perspective Rotation (3+ viewpoints, MANDATORY)            │
+│     → Question Explosion (3-5 query variants per sub-Q)          │
+│  2. Exhaustive web search → L1 > L2 > L3 > L4, broad coverage   │
+│     → Execute ALL query variants, search until saturation        │
 │  3. Extract facts → Each with source, confidence level           │
+│  3.5 Iterative deepening → gaps, contradictions, follow-ups     │
+│     → Keep searching until exit criteria met                     │
 │  4. Build framework → Fixed dimensions, structured compare       │
 │  5. Align references → Ensure unified definitions                │
 │  6. Reasoning chain → Fact→Compare→Conclude, explicit            │
@@ -667,7 +769,8 @@ Default intermediate artifacts location: `RESEARCH_DIR/`
 │  8. Deliverable → solution_draft##.md (mode-specific format)     │
 ├──────────────────────────────────────────────────────────────────┤
 │ Key discipline: Ask don't assume · Facts before reasoning        │
-│                 Conclusions from mechanism, not gut feelings     │
+│   Conclusions from mechanism, not gut feelings                   │
+│   Search broadly, from multiple perspectives, until saturation   │
 └──────────────────────────────────────────────────────────────────┘
 ```