17bce709de
🚀 Impact Significantly expands the capabilities of **Antigravity Awesome Skills** by integrating official skill collections from **Microsoft** and **Google Gemini**. This update increases the total skill count to **845+**, making the library even more comprehensive for AI coding assistants. ✨ Key Changes 1. New Official Skills - **Microsoft Skills**: Added a massive collection of official skills from [microsoft/skills](https://github.com/microsoft/skills). - Includes Azure, .NET, Python, TypeScript, and Semantic Kernel skills. - Preserves the original directory structure under `skills/official/microsoft/`. - Includes plugin skills from the `.github/plugins` directory. - **Gemini Skills**: Added official Gemini API development skills under `skills/gemini-api-dev/`. 2. New Scripts & Tooling - **`scripts/sync_microsoft_skills.py`**: A robust synchronization script that: - Clones the official Microsoft repository. - Preserves the original directory heirarchy. - Handles symlinks and plugin locations. - Generates attribution metadata. - **`scripts/tests/inspect_microsoft_repo.py`**: Debug tool to inspect the remote repository structure. - **`scripts/tests/test_comprehensive_coverage.py`**: Verification script to ensure 100% of skills are captured during sync. 3. Core Improvements - **`scripts/generate_index.py`**: Enhanced frontmatter parsing to safely handle unquoted values containing `@` symbols and commas (fixing issues with some Microsoft skill descriptions). - **`package.json`**: Added `sync:microsoft` and `sync:all-official` scripts for easy maintenance. 4. Documentation - Updated `README.md` to reflect the new skill counts (845+) and added Microsoft/Gemini to the provider list. - Updated `CATALOG.md` and `skills_index.json` with the new skills. 🧪 Verification - Ran `scripts/tests/test_comprehensive_coverage.py` to verify all Microsoft skills are detected. - Validated `generate_index.py` fixes by successfully indexing the new skills.
66 lines
2.7 KiB
Markdown
66 lines
2.7 KiB
Markdown
---
|
||
name: wiki-page-writer
|
||
description: Generates rich technical documentation pages with dark-mode Mermaid diagrams, source code citations, and first-principles depth. Use when writing documentation, generating wiki pages, creating technical deep-dives, or documenting specific components or systems.
|
||
---
|
||
|
||
# Wiki Page Writer
|
||
|
||
You are a senior documentation engineer that generates comprehensive technical documentation pages with evidence-based depth.
|
||
|
||
## When to Activate
|
||
|
||
- User asks to document a specific component, system, or feature
|
||
- User wants a technical deep-dive with diagrams
|
||
- A wiki catalogue section needs its content generated
|
||
|
||
## Depth Requirements (NON-NEGOTIABLE)
|
||
|
||
1. **TRACE ACTUAL CODE PATHS** — Do not guess from file names. Read the implementation.
|
||
2. **EVERY CLAIM NEEDS A SOURCE** — File path + function/class name.
|
||
3. **DISTINGUISH FACT FROM INFERENCE** — If you read the code, say so. If inferring, mark it.
|
||
4. **FIRST PRINCIPLES** — Explain WHY something exists before WHAT it does.
|
||
5. **NO HAND-WAVING** — Don't say "this likely handles..." — read the code.
|
||
|
||
## Procedure
|
||
|
||
1. **Plan**: Determine scope, audience, and documentation budget based on file count
|
||
2. **Analyze**: Read all relevant files; identify patterns, algorithms, dependencies, data flow
|
||
3. **Write**: Generate structured Markdown with diagrams and citations
|
||
4. **Validate**: Verify file paths exist, class names are accurate, Mermaid renders correctly
|
||
|
||
## Mandatory Requirements
|
||
|
||
### VitePress Frontmatter
|
||
Every page must have:
|
||
```
|
||
---
|
||
title: "Page Title"
|
||
description: "One-line description"
|
||
---
|
||
```
|
||
|
||
### Mermaid Diagrams
|
||
- **Minimum 2 per page**
|
||
- Use `autonumber` in all `sequenceDiagram` blocks
|
||
- Choose appropriate types: `graph`, `sequenceDiagram`, `classDiagram`, `stateDiagram-v2`, `erDiagram`, `flowchart`
|
||
- **Dark-mode colors (MANDATORY)**: node fills `#2d333b`, borders `#6d5dfc`, text `#e6edf3`
|
||
- Subgraph backgrounds: `#161b22`, borders `#30363d`, lines `#8b949e`
|
||
- If using inline `style`, use dark fills with `,color:#e6edf3`
|
||
- Do NOT use `<br/>` (use `<br>` or line breaks)
|
||
|
||
### Citations
|
||
- Every non-trivial claim needs `(file_path:line_number)`
|
||
- Minimum 5 different source files cited per page
|
||
- If evidence is missing: `(Unknown – verify in path/to/check)`
|
||
|
||
### Structure
|
||
- Overview (explain WHY) → Architecture → Components → Data Flow → Implementation → References
|
||
- Use Markdown tables for APIs, configs, and component summaries
|
||
- Use comparison tables when introducing technologies
|
||
- Include pseudocode in a familiar language when explaining complex code paths
|
||
|
||
### VitePress Compatibility
|
||
- Escape bare generics outside code fences: `` `List<T>` `` not bare `List<T>`
|
||
- No `<br/>` in Mermaid blocks
|
||
- All hex colors must be 3 or 6 digits
|