Enable optional DeepWiki integration for advanced repository analysis and UI library research.#1072
Conversation
… and UI library research.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the ✨ Finishing touches🧪 Generate unit tests (beta)
Comment |
|
🔍 What's New DeepWiki MCP Integration enables authoritative GitHub repository documentation queries directly within research workflows. ⭐ Phase 1: Cross-Repository Reasoning The Challenge: DeepWiki only supports single-repo queries - no native cross-repo analysis. The Solution: A 4-phase query protocol that enables intelligent cross-repository synthesis:
Confidence Labeling System:
Additional Features:
⭐ Phase 2: UI Library Support for UX Designers Repository Type Classification:
Phase 3.5: UI Component Analysis (5 specialized queries):
"For UX Designer" Section Output:
🧪 Tested With
Both passed validation with 100% compliance score. 📁 Files Changed
~700 lines added across 3 files.The workflow edit: Tested files:
|
|
It uses DeepWiki MCP for public repo and Devin MCP for private repo: Note: The service is totally free for public and private repo. |
|
is this the same or similar MCP to context-7 mcp? I like the idea here, but I think a few changes are needed. Workflow step files are meant to be small, I think the research steps already need some reduction. but to keep them smaller when this is used vs not used, this would be better split into distinct step files if used vs not used. re use distinction, this could be a bmad installer question instead of configuring during research. init step 1 possibly. Thinking about it... |
|
You’re completely right @bmadcode . I just wanted to share an idea. Honestly, I don’t yet know the best way to integrate it into the existing BMM workflows. However, I manually reviewed my PRD and architecture documents using DeepWiki + Otocode, and they caught some very useful missing information. Here are screenshots. 1- Example of a DeepWiki MCP enhancement: 2- Final review with Octocode MCP: I also attached a terminal output for more details. Overall, before jumping into the solutioning phase, I now feel confident about my PRD and architecture document. Context7 MCP vs DeepWiki MCP vs Octocode MCP (Comparative Scenarios)Here’s how they typically stack up in real usage: Scenario: Generate current REST API code Scenario: Understand entire repository architecture Scenario: Find semantic code patterns across repos Scenario: Cross-repo analysis and pattern synthesis Summary Highlights
|
|
@bmadcode new validation summary for the UX-Spec 
New validation summary for the UX-Spec. Deepwiki + Octocode make me feel so confident in every step. Here is the prompt:
|
There was a problem hiding this comment.
Pull request overview
This PR adds optional DeepWiki MCP integration to the Technical Research workflow, enabling authoritative repository documentation extraction for framework integration research and UI library analysis. The enhancement introduces a structured multi-phase query system with confidence labeling to distinguish repository-verified facts from LLM-synthesized integration patterns.
Key changes:
- Three-phase opt-in workflow with repository validation, structured extraction (5 queries per repo), and LLM synthesis with mandatory confidence labels
- Specialized UI library analysis (Phase 3.5) with component capability matrices, theming compatibility, and accessibility documentation for UX Designer downstream use
- POC validation checklists for synthesized patterns with clear warnings to Architect and DEV agents about validation requirements
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 7 comments.
| File | Description |
|---|---|
| step-01-init.md | Adds DeepWiki opt-in prompt, repository type classification (ui-library, ui-primitive, framework, auth-library, general), validation via read_wiki_structure(), and frontmatter configuration with query budget tracking |
| step-03-integration-patterns.md | Implements 4-phase DeepWiki query protocol: cross-reference detection, structured per-repo extraction (5 queries), LLM synthesis with [LLM-SYNTHESIZED] labels, and conditional UI Component Analysis (Phase 3.5) with capability matrices |
| step-06-research-synthesis.md | Adds conditional Integration Research Findings section with data source summary, confidence legend, framework compatibility matrix, downstream agent guidance (Architect/DEV/UX Designer), POC validation summary, and DeepWiki query audit trail |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| {Repo A} → {mechanism} → {Repo B} | ||
| {Repo B} → {mechanism} → {Repo A} (if bidirectional) | ||
|
|
||
| ```` |
There was a problem hiding this comment.
Mismatched code fence delimiters. The code block opens with three backticks on line 470, but closes with four backticks on line 475. This creates an unclosed code block, and the subsequent code fence on line 478 won't work as expected.
| ```` |
| ```{language} | ||
| // Integration pattern - REQUIRES VALIDATION | ||
| {conceptual code based on extracted APIs} | ||
| ```` |
There was a problem hiding this comment.
Inconsistent code fence delimiter usage. This code block closes with four backticks, but markdown code blocks should use three backticks consistently for opening and closing delimiters.
| After user selects 'C', load `./step-04-architectural-patterns.md` to analyze architectural patterns, design decisions, and system structures for {{research_topic}}. | ||
|
|
||
| Remember: Always write research content to document immediately and emphasize current integration data with rigorous source verification! | ||
| ``` |
There was a problem hiding this comment.
Extraneous closing code fence delimiter. There is an extra closing code fence (```) at line 616 that doesn't have a corresponding opening delimiter. This appears at the end of the file and will cause markdown rendering issues.
| ``` |
| | `shadcn/*`, `shadcn-ui/*`, `radix-ui/*` | `ui-primitive` | Primitives, composition, accessibility | | ||
| | `chakra-ui/*`, `mui/*`, `ant-design/*` | `ui-library` | Components, theming, variants | | ||
| | `*-ui/*`, `*ui/*` (general) | `ui-library` | Components, props, customization | | ||
| | `tauri-apps/*`, `vercel/*`, `electron/*` | `framework` | APIs, protocols, extensions | | ||
| | `*auth*`, `*-auth/*` | `auth-library` | Sessions, providers, security | | ||
| | Other | `general` | Standard technical queries | | ||
|
|
There was a problem hiding this comment.
The pattern match for shadcn repositories uses shadcn/* and shadcn-ui/*, but the actual shadcn/ui repository is typically referenced as shadcn-ui/ui or shadcn/ui. The pattern should include consideration for the exact repository naming convention. Consider adding documentation or examples that clarify which specific repositories match these patterns, as shadcn/ui is not an organization but a design system where the actual repository might be structured differently.
| | `shadcn/*`, `shadcn-ui/*`, `radix-ui/*` | `ui-primitive` | Primitives, composition, accessibility | | |
| | `chakra-ui/*`, `mui/*`, `ant-design/*` | `ui-library` | Components, theming, variants | | |
| | `*-ui/*`, `*ui/*` (general) | `ui-library` | Components, props, customization | | |
| | `tauri-apps/*`, `vercel/*`, `electron/*` | `framework` | APIs, protocols, extensions | | |
| | `*auth*`, `*-auth/*` | `auth-library` | Sessions, providers, security | | |
| | Other | `general` | Standard technical queries | | |
| | `shadcn-ui/ui`, `shadcn-ui/*`, `radix-ui/*` | `ui-primitive` | Primitives, composition, accessibility | | |
| | `chakra-ui/*`, `mui/*`, `ant-design/*` | `ui-library` | Components, theming, variants | | |
| | `*-ui/*`, `*ui/*` (general) | `ui-library` | Components, props, customization | | |
| | `tauri-apps/*`, `vercel/*`, `electron/*` | `framework` | APIs, protocols, extensions | | |
| | `*auth*`, `*-auth/*` | `auth-library` | Sessions, providers, security | | |
| | Other | `general` | Standard technical queries | | |
| > **Note:** The canonical shadcn repository is [`shadcn-ui/ui`](https://github.com/shadcn-ui/ui). There is no `shadcn/ui` repository or `shadcn` organization. Use `shadcn-ui/ui` or other repositories under `shadcn-ui/*` for shadcn-related queries. |
| **Query Budget:** This session will use approximately {estimated} queries. Maximum recommended: 15 queries." | ||
|
|
There was a problem hiding this comment.
The query budget estimation is mentioned as "{estimated} queries" but there's no clear guidance on how to calculate this estimation. Based on the Phase 2 logic (5 queries per repo) and Phase 3.5 logic (5 queries per UI library repo), the estimation formula should be documented. For example, if all 3 repos are queried in Phase 2, that's 15 queries. If cross-reference detection is performed for repo pairs, that could be up to 3 additional queries. If any repos are UI libraries, that's another 5 queries each. The maximum could easily exceed 15 queries, which contradicts the stated maximum.
| **Query Budget:** This session will use approximately {estimated} queries. Maximum recommended: 15 queries." | |
| **Query Budget:** This session will use approximately {estimated} queries. | |
| _Query budget estimation formula:_ | |
| - 5 queries per repository (Phase 2) | |
| - Plus 5 additional queries for each UI library or UI primitive repository (Phase 3.5) | |
| - Plus up to 1 query per unique pair of repositories for cross-reference detection | |
| _Example:_ For 3 repositories (including 1 UI library), the maximum could be: (3 × 5) + (1 × 5) + (3 pairs × 1) = 23 queries. | |
| **Maximum recommended:** 25 queries per session (soft limit; adjust as needed based on actual repo count and types). |
| | Library | Components | Theming | Dark Mode | Accessibility | | ||
| | ---------- | ---------- | ---------- | ----------- | ------------- | | ||
| | {{repo_1}} | {{count}} | {{method}} | {{support}} | {{level}} | | ||
| | {{repo_2}} | {{count}} | {{method}} | {{support}} | {{level}} | | ||
|
|
||
| ##### Component Availability Quick Reference | ||
|
|
||
| | Component Type | {{repo_1}} | {{repo_2}} | Notes | | ||
| | --------------- | ---------- | ---------- | --------- | | ||
| | Buttons | ✅/❌ | ✅/❌ | {{notes}} | | ||
| | Forms/Inputs | ✅/❌ | ✅/❌ | {{notes}} | | ||
| | Navigation | ✅/❌ | ✅/❌ | {{notes}} | | ||
| | Data Display | ✅/❌ | ✅/❌ | {{notes}} | | ||
| | Feedback/Alerts | ✅/❌ | ✅/❌ | {{notes}} | | ||
| | Layout | ✅/❌ | ✅/❌ | {{notes}} | | ||
| | Overlay/Modal | ✅/❌ | ✅/❌ | {{notes}} | |
There was a problem hiding this comment.
The table templates assume exactly 2 UI library repositories ({{repo_1}} and {{repo_2}}), but the system allows up to 3 repositories total. If only 1 UI library is provided or if all 3 repositories are UI libraries, these tables won't render correctly. The template should either be flexible to handle variable numbers of repositories (1-3), or there should be guidance on how to handle different scenarios.
| **Q5 - Variant & State System:** | ||
|
|
||
| ``` | ||
| ask_question(repo, "How does {repo} handle component variants and states? What props control visual variations (size, color, disabled, etc.)?" |
There was a problem hiding this comment.
Missing closing double quote in the query string. The query string starts with a double quote but ends without one, which will cause a syntax error when this template is used.
| ask_question(repo, "How does {repo} handle component variants and states? What props control visual variations (size, color, disabled, etc.)?" | |
| ask_question(repo, "How does {repo} handle component variants and states? What props control visual variations (size, color, disabled, etc.)?") |
|
Hi @muratkeremozcan . This PR needs to be reworked completely. Maybe I should close it. |
Idea: Add DeepWiki MCP integration to Technical Research workflow for authoritative repository documentation
PASS Framework
Problem:
Audience:
Solution: