Install DocsPress

Connect an existing Markdown documentation directory to WordPress without overwriting manual pages or exposing credentials. Treat repository changes, GitHub writes, and WordPress writes as separate approval boundaries.

1. Inspect before changing anything

1. Resolve the repository root, active branch, remote, default branch, and working-tree state.
2. Find documentation directories and existing workflows. Prefer rg --files and inspect .github/workflows/ before creating files.
3. Reuse an existing docs directory. Default to docs/ only when there is no stronger repository convention. Detect whether it contains multiple maintained API releases, a version registry, version directories, or filename suffixes; do not infer versioning from a changelog alone.
4. If no usable Markdown documentation exists, invoke $generate-docs-from-source, complete its verified docs workflow, then return here.
5. Inspect an existing DocsPress workflow and update it in place. Never create a second competing sync workflow.
6. Determine the WordPress target:
   • WordPress.com: use https://public-api.wordpress.com and a global-scope OAuth token.
   • Self-hosted WordPress: use the site origin as wordpress-url; proceed only if that site already accepts the supplied Bearer token for /wp-json/wp/v2/pages.
7. Minimize configuration questions to values that cannot be inferred: target site/domain, nonstandard docs directory, or whether the companion theme and plugin are wanted. Always request separate approval before repository writes, GitHub writes, WordPress Page writes, plugin activation, theme activation, or public publication.

Do not ask the user to paste access tokens, OAuth client secrets, passwords, or cookies into chat. Do not print secret values during verification.

2. Confirm the documentation contract