Stats
Actions
Tags
From docflow
Discovers project documentation roots and routes questions to the right doc based on query shape. Activates for queries about specs, ADRs, roadmap, bugs, or shared links.
How this skill is triggered — by the user, by Claude, or both
Slash command
/docflow:routerThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Project-agnostic. No hardcoded tree — **discover, then route**. Works in any repo.
Project-agnostic. No hardcoded tree — discover, then route. Works in any repo.
Run a cheap scan to learn what this project has. Cache the result mentally for the session.
# docs roots + entry points
ls README* CONTRIBUTING* 2>/dev/null
fd -t d -d 2 -i 'docs?|spec|adr|decisions|wiki|reference' 2>/dev/null \
|| find . -maxdepth 3 -type d \( -iname 'docs' -o -iname 'spec*' -o -iname 'adr' -o -iname 'decisions' \) -not -path '*/node_modules/*'
# the markdown tree under the main docs dir (swap <DOCS> for what you found)
fd -e md . <DOCS> 2>/dev/null | head -80 || find <DOCS> -name '*.md' | head -80
If a hand-maintained index exists (<DOCS>/README.md, SUMMARY.md, mkdocs.yml, docusaurus.config.*), read that — it's the authoritative map. Don't rebuild what the maintainer already wrote.
Match the question's shape to a folder by its conventional name, then Read that one doc. Don't bulk-read the tree.
| Question shape | Look in (by conventional name) |
|---|---|
| "What does feature X do?" (user-facing) | product-spec/, docs/features/, top-level README |
| "How is X implemented / data flow / API contract?" | specs/, docs/architecture/, design/ |
| "Why did we choose X?" | decisions/, adr/, docs/adr/ (ADR files) |
| "How do I do X / convention for X?" | references/, docs/guides/, CONTRIBUTING.md |
| "What's planned / status of X?" | plans/, roadmap/, docs/roadmap/, project board |
| "Known issues / open bugs?" | reviews/bugs/, ISSUES.md, GitHub issues |
| "What shipped recently?" | CHANGELOG.md, changelog/, releases |
If names don't match these, fall back to the discovered index from step 1.
Three layers — do whichever the user asked for.
Project skills live at .claude/skills/<name>/SKILL.md and are checked into git — anyone who pulls + uses Claude Code gets them automatically, zero setup.
mkdir -p .claude/skills/router
cp ~/.claude/skills/router/SKILL.md .claude/skills/router/SKILL.md # or author a project-tuned copy
git add .claude/skills/router && git commit -m "docs: add docs router skill"
~/.claude/skills/) = only you, every project..claude/skills/ in repo) = whole team, this repo. Commit it to share.<DOCS>/README.md index with relative links to every doc — GitHub renders it; links are clickable in the web UI.README.md pointing at <DOCS>/.For a teammate who'll use Claude Code: create an ONBOARDING.md at repo root (point them at <DOCS>/ + the skills), then use the ShareOnboardingGuide tool to upload it and get a link they open in Claude Code. Generic and project-agnostic.
This skill is intentionally project-agnostic — it lives in ~/.claude/skills/ so it loads in every repo. To specialize it for one project, copy it into that repo's .claude/skills/ and replace step 1's discovery with the project's actual doc tree (like a hand-written router).
npx claudepluginhub medadembha/docflow --plugin docflowSurfaces the rules, ADRs, specs, and patterns for a code area before changing it. Also recaps project focus when picking up work or loading context for uncommitted changes.
Audits existing docs and generates full project documentation in docs/ including architecture.md, getting-started.md, development.md, API refs, and ADRs. For onboarding and context sharing.
Answers quick questions about codebase, git history, rules, docs, or skills with auto context gathering and source attribution.