← back to Cli Printing Press

feat(skills): add DeepWiki codebase analysis to research phase (#156)

6cc5a5f6d2d204714c478e404ec97e34659c6657 · 2026-04-12 09:11:06 -0400 · Matt Van Horn

Query DeepWiki for GitHub repos discovered during Phase 1/1.5a research
to get semantic understanding of API architecture, auth flows, data
models, and error handling. Complements crowd-sniff (endpoints) and MCP
source reading (auth headers) with "how things work" context.

- Add Step 1.5a.6 to SKILL.md for DeepWiki queries (parallel, 2min budget)
- Add references/deepwiki-research.md with full query procedure
- Add Codebase Intelligence section to Phase 1 brief template
- Update absorb-scoring.md: DeepWiki counts as evidence source
- Add 5th self-brainstorm question for DeepWiki-informed features

Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Files touched

• A docs/plans/2026-04-09-002-feat-deepwiki-research-enrichment-plan.md
• M skills/printing-press/SKILL.md
• M skills/printing-press/references/absorb-scoring.md
• A skills/printing-press/references/deepwiki-research.md

Diff

commit 6cc5a5f6d2d204714c478e404ec97e34659c6657
Author: Matt Van Horn <mvanhorn@users.noreply.github.com>
Date:   Sun Apr 12 09:11:06 2026 -0400

    feat(skills): add DeepWiki codebase analysis to research phase (#156)
    
    Query DeepWiki for GitHub repos discovered during Phase 1/1.5a research
    to get semantic understanding of API architecture, auth flows, data
    models, and error handling. Complements crowd-sniff (endpoints) and MCP
    source reading (auth headers) with "how things work" context.
    
    - Add Step 1.5a.6 to SKILL.md for DeepWiki queries (parallel, 2min budget)
    - Add references/deepwiki-research.md with full query procedure
    - Add Codebase Intelligence section to Phase 1 brief template
    - Update absorb-scoring.md: DeepWiki counts as evidence source
    - Add 5th self-brainstorm question for DeepWiki-informed features
    
    Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
    Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
---
 ...9-002-feat-deepwiki-research-enrichment-plan.md | 178 +++++++++++++++++++++
 skills/printing-press/SKILL.md                     |  22 +++
 skills/printing-press/references/absorb-scoring.md |  13 +-
 .../printing-press/references/deepwiki-research.md | 134 ++++++++++++++++
 4 files changed, 341 insertions(+), 6 deletions(-)

diff --git a/docs/plans/2026-04-09-002-feat-deepwiki-research-enrichment-plan.md b/docs/plans/2026-04-09-002-feat-deepwiki-research-enrichment-plan.md
new file mode 100644
index 00000000..43535c72
--- /dev/null
+++ b/docs/plans/2026-04-09-002-feat-deepwiki-research-enrichment-plan.md
@@ -0,0 +1,178 @@
+---
+title: "feat: Add DeepWiki analysis to Phase 1 research"
+type: feat
+status: completed
+date: 2026-04-09
+---
+
+# feat: Add DeepWiki analysis to Phase 1 research
+
+## Overview
+
+Add DeepWiki as a research source during Phase 1 (Research Brief) and Phase 1.5a (MCP Source Code Analysis). When the research phase discovers a GitHub repo for an API or its SDK, query DeepWiki's MCP server to get a structured understanding of how the API works - auth patterns, data models, architecture, and internal design. This complements crowd-sniff (which finds endpoints) and MCP source reading (which finds auth headers) with "how things actually work" context.
+
+## Problem Frame
+
+The Printing Press research phase currently gathers API intelligence from: web search, npm/PyPI package listings, MCP server READMEs, GitHub issues, and (via crowd-sniff) SDK source code grepping. What it lacks is a semantic understanding of how an API is designed - its data model relationships, authentication flows, rate limiting behavior, error handling patterns, and architectural decisions.
+
+DeepWiki generates AI-analyzed documentation for any GitHub repo. It explains how the codebase works, not just what endpoints exist. For the Printing Press, this means: given an API's SDK repo or server repo, DeepWiki can explain the auth flow, data model, and internal design in a way that directly improves the Phase 1 brief's "API Identity," "Data Layer," and "Product Thesis" sections.
+
+**User's observation:** "they say how things work really well" - this is exactly the gap in current research.
+
+## Requirements Trace
+
+- R1. Query DeepWiki for repos discovered during Phase 1/1.5a research (SDK repos, API server repos, MCP server repos)
+- R2. Extract actionable intelligence: auth patterns, data models, entity relationships, rate limiting, error handling
+- R3. Feed DeepWiki findings into the Research Brief and Absorb Manifest
+- R4. Run in parallel with existing research (no additional latency on the critical path)
+- R5. Graceful degradation - if DeepWiki is unavailable or returns poor results, research continues without it
+
+## Scope Boundaries
+
+- This is a skill-level change only (SKILL.md and possibly a new reference file). No Go binary changes.
+- DeepWiki is queried via its HTTP API (`/api/wiki_cache`), not via MCP server connection (the skill runs in a context where MCP tools are available but adding a new MCP server mid-session is not practical)
+- No changes to spec resolution (DeepWiki does not produce OpenAPI specs)
+- No changes to the generator, scorer, or verifier
+
+## Context & Research
+
+### Relevant Code and Patterns
+
+- `skills/printing-press/SKILL.md` - Phase 1 research, Phase 1.5a ecosystem search, Phase 1.5a.5 MCP source reading
+- `skills/printing-press/references/absorb-scoring.md` - Gap analysis uses research findings
+- `skills/printing-press/references/crowd-sniff.md` - Crowd sniff discovers repos, these are the same repos DeepWiki would analyze
+- `internal/crowdsniff/npm.go` - npm search discovers SDK repo URLs (GitHub URLs extracted from package metadata)
+- `internal/pipeline/research.go` - Go-side research discovers GitHub repos via search API
+
+### Institutional Learnings
+
+- **Pagliacci retro**: Sniff quality is fragile, especially for auth discovery and SPA navigation. DeepWiki could pre-identify auth patterns before sniffing, reducing the sniff's burden.
+- **Postman retro**: Reverse-engineered specs include wrong enum values from client-side code. Server-side repo analysis via DeepWiki could provide accurate server-validated values.
+- **Crowd-sniff gives structure, not meaning**: Crowd-sniff discovers endpoint paths and auth header patterns. DeepWiki would explain what those endpoints do and how data flows between them. These are complementary, not overlapping.
+
+### External References
+
+- DeepWiki MCP server: `https://mcp.deepwiki.com/` (no auth, 3 tools: `ask_question`, `read_wiki_structure`, `read_wiki_contents`)
+- DeepWiki HTTP API: `https://deepwiki.com/api/wiki_cache/{owner}/{repo}` (cached wiki data)
+- URL pattern: `https://deepwiki.com/{owner}/{repo}`
+
+## Key Technical Decisions
+
+- **HTTP API over MCP connection**: Use `WebFetch` against DeepWiki's HTTP endpoints rather than connecting an MCP server mid-session. Simpler, no session config changes, and the skill already has `WebFetch` in its allowed tools. The MCP tools (`ask_question`, `read_wiki_contents`) are richer but require MCP server connection setup that would complicate the skill.
+
+- **Query with targeted questions, not raw wiki dump**: Rather than fetching the entire wiki and parsing it, use DeepWiki's page structure to fetch specific sections relevant to CLI generation: authentication, data models, rate limiting, error handling. This keeps the context window lean.
+
+- **Parallel execution with existing Phase 1.5a searches**: DeepWiki queries run alongside the 10 existing web searches in Phase 1.5a, not after them. This adds zero latency to the research phase.
+
+- **Skill-level integration only**: The Go binary does not need to know about DeepWiki. The skill agent fetches and synthesizes DeepWiki content the same way it does MCP README reading and web search results.
+
+## Open Questions
+
+### Resolved During Planning
+
+- **Q: Where does DeepWiki fit in the pipeline?** After Phase 1 discovers the API's GitHub repos (SDK repos, server repos) and during Phase 1.5a when the agent is reading MCP source code. The repos are already known at this point.
+
+- **Q: What if the API has no GitHub repo?** DeepWiki only works for GitHub repos. For APIs without public repos (e.g., Stripe's server is closed-source), DeepWiki would analyze the SDK repo (e.g., `stripe/stripe-node`), which still provides valuable insight into how the API is designed from the client perspective.
+
+- **Q: Will this slow down the research phase?** No. The queries run in parallel with existing Phase 1.5a web searches. DeepWiki responses are typically fast (cached wiki data).
+
+### Deferred to Implementation
+
+- **Q: What's the optimal set of questions to ask DeepWiki?** Needs experimentation. Start with: auth flow, data model, rate limiting, error handling. Adjust based on which questions produce the most actionable intelligence for the brief.
+
+- **Q: Should DeepWiki analysis feed into the auto-suggest novel features (Step 1.5c.5)?** Likely yes, as a 7th gap analysis category. But the exact scoring dimensions need to be determined during implementation.
+
+## Implementation Units
+
+- [ ] **Unit 1: Add DeepWiki research step to SKILL.md**
+
+**Goal:** Add a new sub-step in Phase 1.5a that queries DeepWiki for repos discovered during research
+
+**Requirements:** R1, R2, R4, R5
+
+**Dependencies:** None
+
+**Files:**
+- Modify: `skills/printing-press/SKILL.md` (Phase 1.5a section)
+- Create: `skills/printing-press/references/deepwiki-research.md` (extracted reference for the DeepWiki query procedure)
+
+**Approach:**
+- Add a new step 1.5a.6 (after MCP source reading in 1.5a.5) titled "DeepWiki Codebase Analysis"
+- When Phase 1 or Phase 1.5a discovers a GitHub repo URL (from npm package metadata, GitHub search, MCP server discovery), extract the `owner/repo` path
+- Use `WebFetch` against `https://deepwiki.com/{owner}/{repo}` to get the wiki structure
+- Then fetch 2-3 targeted pages: authentication, data model/schema, and architecture/overview
+- Extract: auth flow description, entity relationships, rate limit behavior, error patterns
+- The reference file contains the detailed procedure (which pages to fetch, what to extract, how to handle failures)
+- Time budget: 2 minutes max. If DeepWiki is slow or unavailable, skip silently with a log note
+- Run in parallel with existing 1.5a searches (not sequentially after them)
+
+**Patterns to follow:**
+- Phase 1.5a.5 (MCP source code reading) - same pattern: discover repo, read specific parts, extract structured intelligence, feed into absorb manifest
+- Time budget pattern from sniff gate (3 min) and crowd sniff gate (5 min)
+
+**Test scenarios:**
+- Happy path: API has a popular SDK repo on GitHub (e.g., `stripe/stripe-node`), DeepWiki returns wiki with auth and data model sections, findings enrich the brief
+- Edge case: API has no GitHub repo (closed-source) - step is skipped silently
+- Edge case: DeepWiki returns empty wiki or 404 - step is skipped silently, research continues
+- Edge case: DeepWiki returns a wiki but the targeted sections don't exist - extract what's available, skip missing sections
+- Error path: WebFetch times out or fails - step is skipped, logged as "DeepWiki unavailable"
+
+**Verification:**
+- Running `/printing-press` on an API with a popular GitHub repo (e.g., Discord) produces a brief that references DeepWiki findings
+- Running `/printing-press` on an API without a repo still completes normally
+- No additional latency observed (parallel execution)
+
+- [ ] **Unit 2: Feed DeepWiki findings into Brief and Absorb Manifest**
+
+**Goal:** Integrate DeepWiki intelligence into the Research Brief template and Absorb Manifest scoring
+
+**Requirements:** R3
+
+**Dependencies:** Unit 1
+
+**Files:**
+- Modify: `skills/printing-press/SKILL.md` (Phase 1 brief template, Phase 1.5c.5 gap analysis)
+- Modify: `skills/printing-press/references/absorb-scoring.md` (add DeepWiki as evidence source)
+
+**Approach:**
+- Add a `## Codebase Intelligence` section to the Phase 1 brief template (after "Data Layer", before "User Vision") - only populated when DeepWiki returned useful findings
+- In absorb-scoring.md, add DeepWiki findings as a valid evidence source for the "Research Backing" scoring dimension (0-2 points). DeepWiki architectural analysis counts as 1 source for the "2+ sources" threshold
+- In Phase 1.5c.5 self-brainstorm, add a 5th question (when DeepWiki data is available): "Based on the codebase architecture DeepWiki revealed, what compound use cases become possible that the public API docs don't suggest?"
+
+**Patterns to follow:**
+- "User Vision" section pattern - optional, only populated when context is available
+- Absorb scoring's existing evidence attribution pattern ("ESPN community requests, espn_scraper lacks X")
+
+**Test scenarios:**
+- Happy path: DeepWiki findings appear in the brief under "Codebase Intelligence" and are cited as evidence in absorb manifest transcendence features
+- Edge case: No DeepWiki data available - "Codebase Intelligence" section is omitted from the brief, scoring proceeds without it
+- Integration: A novel feature scores higher because DeepWiki provided a second evidence source (pushing Research Backing from 1 to 2)
+
+**Verification:**
+- Brief template renders correctly with and without the Codebase Intelligence section
+- Absorb scoring correctly counts DeepWiki as an evidence source
+
+## System-Wide Impact
+
+- **Interaction graph:** DeepWiki queries happen inside the Phase 1.5a agent parallel fan-out. No new callbacks, middleware, or observers.
+- **Error propagation:** DeepWiki failures are swallowed at the step level (graceful skip). They do not propagate to Phase 1.5 or block the absorb gate.
+- **State lifecycle risks:** None. DeepWiki data is ephemeral - it's synthesized into the brief and manifest, not persisted separately.
+- **API surface parity:** No changes to any CLI, binary, or published interface.
+- **Unchanged invariants:** The spec resolution chain, generator, scorer, verifier, and publisher are all unchanged. DeepWiki enriches research quality; it does not change the pipeline structure.
+
+## Risks & Dependencies
+
+| Risk | Mitigation |
+|------|------------|
+| DeepWiki service unavailable or slow | 2-minute time budget + graceful skip. Research continues without it. |
+| DeepWiki returns hallucinated/inaccurate information | DeepWiki findings are evidence for scoring, not ground truth. They enrich the brief but don't override spec-derived endpoints or crowd-sniff-discovered auth patterns. |
+| Context window pressure from large wiki pages | Fetch only 2-3 targeted sections, not the full wiki. Extract structured intelligence, not raw text. |
+| DeepWiki API changes or rate limits | No auth required currently. If they add rate limits, the 2-minute timeout handles it. If the API changes, the reference file is easy to update. |
+
+## Sources & References
+
+- DeepWiki: `https://deepwiki.com`
+- DeepWiki MCP: `https://mcp.deepwiki.com/`
+- Related skill sections: Phase 1.5a.5 (MCP source reading), Phase 1.5c.5 (auto-suggest features)
+- Pagliacci retro: auth discovery gaps that DeepWiki could help fill
+- Postman retro: server-side validation accuracy from codebase analysis
diff --git a/skills/printing-press/SKILL.md b/skills/printing-press/SKILL.md
index 5d2e7277..aa315de2 100644
--- a/skills/printing-press/SKILL.md
+++ b/skills/printing-press/SKILL.md
@@ -593,6 +593,14 @@ Suggested shape:
 - Sync cursor:
 - FTS/search:
 
+## Codebase Intelligence
+- [DeepWiki findings if available, otherwise omit this section]
+- Source: DeepWiki analysis of {owner}/{repo}
+- Auth: [token type, header, env var pattern]
+- Data model: [primary entities and relationships]
+- Rate limiting: [limits and behavior]
+- Architecture: [key insight about internal design]
+
 ## User Vision
 - [USER_BRIEFING_CONTEXT if provided, otherwise omit this section]
 
@@ -964,6 +972,20 @@ If step 1.5a discovered MCP server repos with public source code on GitHub, read
 - MCP repos are private or archived
 - The MCP is a monorepo where the relevant server is hard to locate within 3 minutes
 
+### Step 1.5a.6: DeepWiki Codebase Analysis (if GitHub repos found)
+
+If Phase 1 or Step 1.5a discovered GitHub repos for the API (SDK repos, server repos, MCP server repos), query DeepWiki for a semantic understanding of how the API works - architecture, auth flows, data models, error handling. This complements crowd-sniff (endpoints) and MCP source reading (auth headers) with "how things actually work" context.
+
+**Time budget:** 2 minutes max. If DeepWiki is slow or unavailable, skip silently.
+
+**Run in parallel** with Steps 1.5a through 1.5a.5 when possible. DeepWiki queries do not depend on MCP source reading results.
+
+Read and follow [references/deepwiki-research.md](references/deepwiki-research.md) for the query procedure: wiki structure fetch, targeted section extraction (auth, data model, architecture), and synthesis into the research brief and absorb manifest.
+
+**Skip this step when:**
+- No GitHub repos were discovered during Phase 1 or Step 1.5a
+- The API is trivially simple (1-2 endpoints, no auth)
+
 ### Step 1.5b: Catalog every feature into the absorb manifest
 
 For EACH tool found, list EVERY feature/tool/command it provides. Then define how our CLI matches AND beats it:
diff --git a/skills/printing-press/references/absorb-scoring.md b/skills/printing-press/references/absorb-scoring.md
index d5b055c3..7cb74771 100644
--- a/skills/printing-press/references/absorb-scoring.md
+++ b/skills/printing-press/references/absorb-scoring.md
@@ -85,11 +85,12 @@ the persona work missed:
 
 4. **Agent workflow gaps** — What would an AI agent using this CLI wish it could do in one command instead of multiple?
 
-5. **Self-brainstorm** — Answer using research context:
-   - What workflows do power users do that aren't covered in the absorbed features?
-   - What are the most annoying limitations that a CLI with local data could fix?
-   - What single "killer feature" would make a power user install this over any alternative?
-   - (Only when `USER_BRIEFING_CONTEXT` is non-empty) What features directly serve the user's stated goals?
+5. **Self-brainstorm** — Answer these questions using the research context gathered so far. Do NOT ask the user — answer them yourself from the research brief, absorb manifest, and ecosystem findings:
+   - Based on the research brief's top workflows and user profiles, what workflows does the typical power user of this API do that aren't covered in the absorbed features?
+   - Based on competitor repo issues, community pain points, and ecosystem gaps found in Phase 1/1.5, what are the most annoying limitations that a CLI with SQLite could fix?
+   - Based on the NOI and domain archetype, what single "killer feature" would make a power user install this CLI over any alternative?
+   - (Only when `USER_BRIEFING_CONTEXT` is non-empty) Based on the user's stated vision, what features directly serve their stated goals that the absorbed features don't already cover?
+   - (Only when DeepWiki codebase analysis is available) Based on the codebase architecture DeepWiki revealed, what compound use cases become possible that the public API docs don't suggest? Look for internal data relationships, queue/worker patterns, or event systems that could power novel CLI features.
 
 #### Generate, Vet, and Score
 
@@ -102,7 +103,7 @@ the persona work missed:
 | **Domain Fit** | 0-3 | 3=core to this API's power users, 2=useful but niche, 1=tangential, 0=wrong domain |
 | **User Pain** | 0-3 | 3=research surfaced explicit demand (community complaints, competitor gap), 2=implied need, 1=speculative, 0=no evidence |
 | **Build Feasibility** | 0-2 | 2=API endpoint + local data covers it, 1=needs minor data model additions, 0=requires new infrastructure |
-| **Research Backing** | 0-2 | 2=evidence from 2+ sources in Phase 1/1.5 research, 1=evidence from 1 source, 0=invented |
+| **Research Backing** | 0-2 | 2=evidence from 2+ sources in Phase 1/1.5 research (web search, community issues, MCP source, DeepWiki analysis each count as 1 source), 1=evidence from 1 source, 0=invented |
 
 **Normalize:** `score_10 = round(raw / 10 * 10)`. Include features scoring >= 5/10.
 
diff --git a/skills/printing-press/references/deepwiki-research.md b/skills/printing-press/references/deepwiki-research.md
new file mode 100644
index 00000000..d7727fcd
--- /dev/null
+++ b/skills/printing-press/references/deepwiki-research.md
@@ -0,0 +1,134 @@
+# DeepWiki Codebase Analysis
+
+> **When to read:** This file is referenced by Phase 1.5a.6 of the printing-press skill.
+> Read it when GitHub repos have been discovered during Phase 1/1.5a research.
+
+## What DeepWiki Provides
+
+DeepWiki generates AI-analyzed documentation for any public GitHub repo. It explains
+how a codebase works - architecture, data models, auth flows, error handling - not
+just what endpoints exist. This complements crowd-sniff (which finds endpoints) and
+MCP source reading (which finds auth headers) with semantic understanding.
+
+URL pattern: `https://deepwiki.com/{owner}/{repo}`
+
+## When to Query
+
+Query DeepWiki when Phase 1 or Phase 1.5a discovers a GitHub repo URL for:
+- The API's official SDK repo (e.g., `stripe/stripe-node`, `triggerdotdev/trigger.dev`)
+- The API's server repo (if open source)
+- A popular community wrapper or MCP server repo
+
+**Repo URL sources:** npm package metadata (`repository` field), GitHub search results,
+MCP server discovery (Step 1.5a searches), WebSearch results linking to GitHub repos.
+
+**Skip when:**
+- No GitHub repos were discovered
+- The repo is private (DeepWiki only indexes public repos)
+- The API is trivially simple (1-2 endpoints, no auth)
+
+## How to Query
+
+**Time budget:** 2 minutes max. If DeepWiki is slow or returns errors, skip silently.
+
+### Step 1: Fetch the wiki structure
+
+```
+WebFetch: https://deepwiki.com/{owner}/{repo}
+Prompt: "List all wiki section titles and their numeric path identifiers"
+```
+
+This returns the wiki's table of contents with section IDs like `1-overview`,
+`3.1-task-definition-api`, `5.8-authentication-and-authorization`.
+
+### Step 2: Fetch targeted sections
+
+From the wiki structure, identify and fetch **up to 3** of these high-value sections
+(in priority order):
+
+1. **Authentication/Authorization** - look for sections with "auth", "authentication",
+   "authorization", "security", "api key", "token" in the title. This reveals token
+   formats, auth flows, required scopes, and session handling.
+
+2. **Data Model/Schema** - look for sections with "model", "schema", "database",
+   "data", "entity" in the title. This reveals entity relationships, primary keys,
+   and data flow patterns.
+
+3. **Architecture/Overview** - look for sections with "architecture", "overview",
+   "system", "design" in the title. This reveals how components interact, what the
+   main abstractions are, and how the API is structured internally.
+
+4. **API/SDK surface** - look for sections with "api", "sdk", "client", "endpoint",
+   "rest" in the title. This reveals the intended API surface from the maintainer's
+   perspective.
+
+For each section, use WebFetch with a targeted extraction prompt:
+
+```
+WebFetch: https://deepwiki.com/{owner}/{repo}/{section-path}
+Prompt: "Extract: (1) authentication method and token format, (2) primary data
+entities and their relationships, (3) rate limiting or throttling behavior,
+(4) error handling patterns, (5) key architectural decisions. Be specific -
+include field names, header names, status codes, and entity names."
+```
+
+### Step 3: Synthesize findings
+
+Organize extracted intelligence into these categories:
+
+- **Auth flow**: Token type (Bearer, API key, session cookie, OAuth), header name,
+  env var convention, required scopes or permissions
+- **Data model**: Primary entities, their relationships (1:many, many:many),
+  key fields, pagination approach
+- **Rate limiting**: Limits per endpoint or global, retry-after behavior,
+  backoff strategy
+- **Error patterns**: Error response format, common error codes, retry guidance
+- **Architecture insights**: Key abstractions, service boundaries, queue/worker
+  patterns, event systems
+
+## How to Use Findings
+
+### In the Research Brief (Phase 1)
+
+Add findings to the `## Codebase Intelligence` section (between Data Layer and
+User Vision). Only populate when DeepWiki returned useful findings:
+
+```markdown
+## Codebase Intelligence
+- Source: DeepWiki analysis of {owner}/{repo}
+- Auth: [token type, header, env var pattern]
+- Data model: [primary entities and relationships]
+- Rate limiting: [limits and behavior]
+- Architecture: [key insight about how the API works internally]
+```
+
+### In the Absorb Manifest (Phase 1.5b)
+
+When attributing features in the absorb manifest's "Best Source" column, use
+`DeepWiki ({owner}/{repo})` to distinguish DeepWiki-sourced intelligence from
+other sources.
+
+### In Novel Feature Scoring (Phase 1.5c.5)
+
+DeepWiki architectural analysis counts as 1 evidence source for the "Research
+Backing" scoring dimension (0-2 points). Combined with another source (e.g.,
+community issues, competitor tool analysis), it can push a feature to the
+maximum 2/2 Research Backing score.
+
+### Pre-Sniff Auth Intelligence (Phase 1.6)
+
+DeepWiki auth findings directly feed into Phase 1.6's auth profile classification.
+If DeepWiki reveals the token format (e.g., `tr_dev_` prefix for Trigger.dev,
+`sk_live_` for Stripe), credential setup steps, or required scopes, use these
+to ask the user more specific auth questions.
+
+## Failure Handling
+
+- **DeepWiki returns 404 or error:** Skip silently. Log: "DeepWiki: no wiki
+  available for {owner}/{repo}"
+- **WebFetch times out:** Skip silently. Log: "DeepWiki: timeout fetching
+  {owner}/{repo}"
+- **Wiki exists but targeted sections not found:** Extract what is available.
+  Even the overview section provides useful architectural context.
+- **Wiki content is thin or unhelpful:** Use only findings that are specific
+  and actionable. Do not pad the brief with generic DeepWiki output.

← 575a3f4f chore(main): release 2.0.0 (#170)  ·  back to Cli Printing Press  ·  fix(ci): make validate-catalog fail loud on missing base ref 8239f28b →