moxiedocs.com

Use Moxie Docs BEFORE writing code so any required documentation updates land in the same pull request as the change. Recommended flow: 1. Call `moxie.get_ai_context` to load repo status, verified commands, top conventions, and open gaps. 2. Before editing a file, call `moxie.get_doc_impact` with the file paths you intend to change. It returns the docs/gaps/conventions that apply AND flags paths that are net-new or undocumented (e.g. a new API surface) so you can document them in the same PR. 3. Use `moxie.get_documentation_patterns` to decide where new docs belong, and `moxie.get_conventions` for category-specific rules. 4. After you make the change and BEFORE you commit, call `moxie.review_change` with the new contents of the files you changed (and any deletedPaths). It flags convention breaches, docs your change makes false, undocumented new surface, and broken references. Fix every must-fix finding and re-run until the verdict is clean. 5. When you add or update a doc, call `moxie.propose_doc_update` with the title, markdown, and either a target path or the slug of an existing doc. It returns the exact repository-relative path and content to WRITE INTO YOUR OWN BRANCH and commit, so the docs land in this same PR. Moxie does not open a separate PR. 6. Whenever you edit an existing doc, read the whole file and fix anything else your change makes stale or wrong: correct statements your change contradicts, complete lists or tables it makes incomplete, and drop references to code that no longer exists. A doc you touch should be fully correct when you commit it - leaving a known-outdated section beside a fresh update is not acceptable. 7. Run the verified commands before opening or updating a PR. Tokens are organization-wide, so always pass `repository: "owner/name"` (case-insensitive) on every tool call unless your token is scoped to a single repository. Do not invent documentation: only create or expand human docs when behavior, API, workflow, architecture, or operational contract changed. This guardrail forbids fabricating new docs - it does not excuse leaving stale or contradicted content in a file you are already editing; correcting that is always in scope.