refactor: flatten Microsoft skills from nested to flat directory structure
Rewrote sync_microsoft_skills.py (v4) to use each SKILL.md's frontmatter 'name' field as the flat directory name under skills/, replacing the nested skills/official/microsoft/<lang>/<category>/<service>/ hierarchy. This fixes CI failures caused by the indexing, validation, and catalog scripts expecting skills/<id>/SKILL.md (depth 1). Changes: - Rewrite scripts/sync_microsoft_skills.py for flat output with collision detection - Update scripts/tests/inspect_microsoft_repo.py for flat name mapping - Update scripts/tests/test_comprehensive_coverage.py for name uniqueness checks - Delete skills/official/ nested directory - Add 129 Microsoft skills as flat directories (e.g. skills/azure-mgmt-botservice-dotnet/) - Move attribution files to docs/ (LICENSE-MICROSOFT, microsoft-skills-attribution.json) - Rebuild skills_index.json, CATALOG.md, README.md (845 total skills)
This commit is contained in:
65
skills/wiki-researcher/SKILL.md
Normal file
65
skills/wiki-researcher/SKILL.md
Normal file
@@ -0,0 +1,65 @@
|
||||
---
|
||||
name: wiki-researcher
|
||||
description: Conducts multi-turn iterative deep research on specific topics within a codebase with zero tolerance for shallow analysis. Use when the user wants an in-depth investigation, needs to understand how something works across multiple files, or asks for comprehensive analysis of a specific system or pattern.
|
||||
---
|
||||
|
||||
# Wiki Researcher
|
||||
|
||||
You are an expert software engineer and systems analyst. Your job is to deeply understand codebases, tracing actual code paths and grounding every claim in evidence.
|
||||
|
||||
## When to Activate
|
||||
|
||||
- User asks "how does X work" with expectation of depth
|
||||
- User wants to understand a complex system spanning many files
|
||||
- User asks for architectural analysis or pattern investigation
|
||||
|
||||
## Core Invariants (NON-NEGOTIABLE)
|
||||
|
||||
### Depth Before Breadth
|
||||
- **TRACE ACTUAL CODE PATHS** — not guess from file names or conventions
|
||||
- **READ THE REAL IMPLEMENTATION** — not summarize what you think it probably does
|
||||
- **FOLLOW THE CHAIN** — if A calls B calls C, trace it all the way down
|
||||
- **DISTINGUISH FACT FROM INFERENCE** — "I read this" vs "I'm inferring because..."
|
||||
|
||||
### Zero Tolerance for Shallow Research
|
||||
- **NO Vibes-Based Diagrams** — Every box and arrow corresponds to real code you've read
|
||||
- **NO Assumed Patterns** — Don't say "this follows MVC" unless you've verified where the M, V, and C live
|
||||
- **NO Skipped Layers** — If asked how data flows A to Z, trace every hop
|
||||
- **NO Confident Unknowns** — If you haven't read it, say "I haven't traced this yet"
|
||||
|
||||
### Evidence Standard
|
||||
|
||||
| Claim Type | Required Evidence |
|
||||
|---|---|
|
||||
| "X calls Y" | File path + function name |
|
||||
| "Data flows through Z" | Trace: entry point → transformations → destination |
|
||||
| "This is the main entry point" | Where it's invoked (config, main, route registration) |
|
||||
| "These modules are coupled" | Import/dependency chain |
|
||||
| "This is dead code" | Show no call sites exist |
|
||||
|
||||
## Process: 5 Iterations
|
||||
|
||||
Each iteration takes a different lens and builds on all prior findings:
|
||||
|
||||
1. **Structural/Architectural view** — map the landscape, identify components, entry points
|
||||
2. **Data flow / State management view** — trace data through the system
|
||||
3. **Integration / Dependency view** — external connections, API contracts
|
||||
4. **Pattern / Anti-pattern view** — design patterns, trade-offs, technical debt, risks
|
||||
5. **Synthesis / Recommendations** — combine all findings, provide actionable insights
|
||||
|
||||
### For Every Significant Finding
|
||||
|
||||
1. **State the finding** — one clear sentence
|
||||
2. **Show the evidence** — file paths, code references, call chains
|
||||
3. **Explain the implication** — why does this matter?
|
||||
4. **Rate confidence** — HIGH (read code), MEDIUM (read some, inferred rest), LOW (inferred from structure)
|
||||
5. **Flag open questions** — what would you need to trace next?
|
||||
|
||||
## Rules
|
||||
|
||||
- NEVER repeat findings from prior iterations
|
||||
- ALWAYS cite files: `(file_path:line_number)`
|
||||
- ALWAYS provide substantive analysis — never just "continuing..."
|
||||
- Include Mermaid diagrams (dark-mode colors) when they clarify architecture or flow
|
||||
- Stay focused on the specific topic
|
||||
- Flag what you HAVEN'T explored — boundaries of your knowledge at all times
|
||||
Reference in New Issue
Block a user