docs-setup
Lay out a repository's docs to the documentation standard (DOCSPEC), or move an existing repo to it. Use when the user wants to set up, standardise, restructure or migrate docs, move docs/specs or doc
SKILL.mdclaude/plugins/docs/skills/docs-setup/SKILL.md
GitHubDocs — setup
Runs scripts/docs_setup.py from the luismc-docs plugin (DOCSPEC §9). The layout rules are in references/docspec.md. Read §2 and §9 first.
How this setup talks to you (setup pattern)
This setup follows section 13 of docs/features/delivery/shared-self-hosted-runners.md.
- Plan first. Before any change, show one plan: the folders and files it will create or move (with paths), that nothing is deleted, what lands outside the repository (nothing), what needs the owner (a yes, the app and topic names, the guesses to confirm) and about how long it takes (a minute for
init, a few minutes formigrate). For an existing repo the plan is themigratedry run. Ask for one yes. - Do the heavy lifting. After the yes, run every command yourself:
initormigrate --apply, thedocs.jsonedit (apps,topics),docs_index.py buildanddocs_check.py. Leave to the owner only what you cannot do: the guesses only they can judge, and the commit and push. Give each an exact step and check it afterwards. - One line per step. While it runs, print one line per step: what you are doing, then done, or failed with the reason and the fix.
- Finish with three parts. Done (what changed, with paths). Left for you (numbered, exact steps). What you can do now:
/luismc-docs:docs-check(check links and freshness),/luismc-docs:docs-index(build the offline site; opendocs/index.html),/luismc-docs:feature-spec-new(write a feature spec),/luismc-docs:docs-note(add a change note for your task),/luismc-docs:design-system-setup(start the design system). Give each one line with an example. - Safe to run again. A second run says what is already set (the layout,
docs.json) and changes only what is missing.
S="${CLAUDE_PLUGIN_ROOT}/scripts/docs_setup.py"
python3 "$S" init --apply --app web --topic library # new repo: layout, docs.json, overview stubs, AGENTS.md
python3 "$S" migrate # existing repo: print the plan, change nothing
python3 "$S" migrate --map docs/specs/x.md=docs/architecture/x.md # override a guessed target
python3 "$S" migrate --apply # git mv, rewrite links, front matter stubs, layout
python3 "$S" move-record --apply # artifacts record to record_dir (docs/project)
Steps for an existing repo
- Confirm no branch is in flight (run between trains, R9.8).
- Run
migrateand read the plan. Lines markedguesscome from the file name. The owner decides which guesses are wrong, and you pass--map. - Run
migrate --applyon its own branch. Exit 2 means a target already existed. The file was kept; decide by hand. - Ask the owner for the app names and topics, write them into
docs/docs.jsonyourself, then rundocs_index.py buildanddocs_check.py. - Report the gaps list (
docs/features/index.md, Gaps). Content gaps become tasks. This skill does not rewrite docs (R9.5).
docs/work/ is never moved. If it holds files, say so in the report. Do not commit generated files by hand: docs_index.py build writes them.