菜单
Add or update a markdown file's table of contents (TOC) based on its header structure. Use when creating new documentation, updating existing files, or ensuring TOC accuracy. Supports GitHub-style TOC with configurable header levels.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Deterministic, offline image post-processing in two layers: fixed commands (background removal, multi-signal alpha matting, a 'steps' visual debugger, wordmark composition) and a DECLARATIVE PIPELINE that chains any number of transforms in any order — compositing layers, recolouring, healing regions with inpaint, Poisson seamless-clone, feathered face cut-outs, plus escape hatches that call ANY OpenCV 5 function or ANY HuggingFace pipeline by name. Every output gets a JSON sidecar and every pipeline can emit numbered intermediates, so edits are reproducible and their working-out is inspectable. Use when the user wants to composite logos or faces onto an image, remove or recolour part of it, build a matte, debug a transform chain, or otherwise edit without paying for a fresh AI generation. Runs offline (no API key).
Generate images from curated prompt files via Google's GenAI image models (Gemini 'Nano Banana' + Imagen 4). Each image is written with a JSON sidecar recording the exact prompt and settings, so runs are reproducible and the next prompt can be curated from prior ones. Supports fan-out across multiple prompt files in one invocation. Use when the user wants to generate, explore, or iterate on logos, icons, illustrations, or other AI imagery from text prompts. Requires either a non-empty GOOGLE_API_KEY or gcloud application-default credentials (Vertex AI).
Repo documentation organisation: ensures the canonical document set exists (README.md, CONTRIBUTING.md, CLAUDE.md/AGENTS.md, an ADR surface, GLOSSARY.md ubiquitous language) with required cross-links, and that every doc — and every section within a doc — lives where its content says it belongs. Modes: (1) AUDIT (default) — resolve the repo's dialect (docs/CONVENTIONS.md, else observed conventions, else researched baseline), then report missing/misfiled/misnamed docs and sections as a shelving plan, plus graduation advice when the repo outgrows its flavour; (2) APPLY — execute an approved plan with history-preserving moves and link rewrites; (3) INIT — bootstrap docs/CONVENTIONS.md from the observed dialect or a named flavour (minimal/standard/rigorous). Use when asked to organise repo docs, check doc layout/placement, add missing canonical docs, relocate/rename docs, or on 'librarian'. Skip when the ask is prose quality, staleness/drift, or within-one-file readability — content-quality skills own those.
Generate and serve rich HTML companions to markdown discovery documents: paired markdown→HTML rendering (marked + mermaid + data-driven cytoscape/plotly fenced blocks), a vendored draw.io stencil library (~AWS/GCP/Azure/K8s SVG icons) for composing custom architecture diagrams, an injectable design-tokens brandpack, and a reliable localhost server for HTML that pulls pinned CDN libraries. Use when turning a review/architecture/cost markdown doc into an interactive HTML view, when a diagram needs real cloud provider icons, when serving local HTML that file:// breaks, or when building a data-driven graph/chart view. Skip when the deliverable is plain mermaid-in-markdown authoring with no HTML companion, or a Python-rendered architecture diagram image.
Documentation quality skill with three modes: (1) AUDIT — fan out parallel subagents to corroborate that docs still reflect the reality of the code (commands run, paths exist, signatures match, claims hold) and produce a drift report; (2) WRITE/IMPROVE — author or rewrite docs using the researched lens taxonomy (Diátaxis + distilled style principles from great OSS docs), optionally in the maintainer's personal voice; (3) RESTRUCTURE — reorganize an existing doc, spec, or plan file for structural readability (heading hierarchy, list/table discipline, whitespace rhythm, frontloaded summaries) without changing its claims. Use when the user asks to check/audit docs, fix stale docs, write or improve documentation, restructure a doc/spec/plan for readability, or says 'gooddocs'. Add 'voice' to the invocation to write in the maintainer's voice; default is the neutral researched style.
Build and maintain presentation decks as version-controlled Markdown (Marp), rendered to HTML/PDF/PPTX and to self-running mp4/GIF whose per-slide timing is computed from each slide's word count. Use when asked to create a slide deck, pitch deck or presentation from a repo; add slides to an existing deck; render a deck to PDF/PowerPoint/GIF/video; build an audience-tiered deck (executives through to engineers) with a progress bar; or theme a deck from a project's design tokens. Also use when a deck's timing, progress bar or prose gate needs fixing. Skip for one-off diagrams (no deck), for a document that is prose rather than slides, and for editing an existing PowerPoint binary (this authors decks as Markdown, it does not parse .pptx).
| name | mdtoc |
| description | Add or update a markdown file's table of contents (TOC) based on its header structure. Use when creating new documentation, updating existing files, or ensuring TOC accuracy. Supports GitHub-style TOC with configurable header levels. |
| argument-hint | [markdown-file] |
| user-invocable | true |
This skill generates a table of contents (TOC) for a markdown file by analyzing its header structure. It is designed to be used when creating new documentation, updating existing files, or ensuring that the TOC is accurate and up-to-date. The generated TOC follows GitHub-style formatting and can be configured to include specific header levels.
<!--TOC-->).<!--TOC--> markers where the TOC will be injected.md-toc tool bash snippet below to analyze the markdown file's header structure and generate a new TOC.Add this snippet to the top of the markdown file to enable TOC generation:
---
<details>
<summary><b>Table of Contents</b></summary>
<!--TOC-->
<!--TOC-->
</details>
---
NOTES:
<!--TOC--> markers denote where the TOC will be injected. Do not remove or alter these markers. The python md-toc tool looks for these exact markers to know where to insert the generated TOC.md-toc ToolingRun the following command to add or update the TOC in-place:
uvx --from md-toc md_toc --in-place --no-list-coherence github --header-levels 4 $ARGUMENTS
Before (no TOC):
# My Documentation
Overview of the project...
## Installation
...
## User Guide
...
After (with TOC base snippet):
# My Documentation
Overview of the project...
---
<details>
<summary><b>Table of Contents</b></summary>
<!--TOC-->
<!--TOC-->
</details>
---
## Installation
...
## User Guide
...
NOTE:
<!--TOC--> markers, then the user has chosen custom placement and we simply update the TOC in-place without adding the base template snippet.After (with TOC updated):
# My Documentation
Overview of the project...
---
<details>
<summary><b>Table of Contents</b></summary>
<!--TOC-->
1. [My Documentation](#my-documentation)
1. [Installation](#installation)
1. [User Guide](#user-guide)
<!--TOC-->
</details>
---
## Installation
...
## User Guide
...
The md-toc documents that it has the following exit codes:
Return values: 0 ok, 1 error, 2 invalid command, 128 TOC differs from the one in the file (see --diff option)
You can self discover the documentation via:
uvx --from md-toc md_toc --help