docs agent failed: committed generated docs to the wrong directory
Fixes a docs agent that commits generated docs outside the intended docs directory. Use when a docs-generation run lands files in the wrong folder, or a commit's file list does not match the docs output dir. Key trigger: generated pages appear in an unexpected path after the agent commits.
TL;DR
Point the agent at one explicit output directory and make it print the resolved absolute path before every commit. Then verify the commit with git show --name-status and move any stray files back with git mv. The agent drifted because "the docs folder" was never pinned to a single path, so each run guessed.
docs agent failed: committed generated docs to the wrong directorySteps
- See what actually landed: run
git show --name-status HEAD. Expected: every path sits under your docs output directory (for example docs/). Any path outside it is the bug. - Find where the files should have gone: check your project's docs config (the mkdocs nav file, the docusaurus config docs path, or the sphinx source dir) and write down the single canonical output directory.
- Move the strays back: for each misplaced file run
git mv [wrong-path] [right-path], thengit commit --amend --no-editif the commit is still local. Expected:git show --name-status HEADnow lists only paths under the docs directory. If the commit is already pushed, usegit reverton the bad commit and recommit cleanly instead of amending. - Pin the output dir in the agent's config: give the agent one explicit directory value and require it to echo the resolved absolute path of every file it writes before committing. Expected: the pre-commit file list shows only intended paths.
- Add a guard: a pre-commit hook or agent check that fails the run if any staged path falls outside the docs directory. Expected: a test commit with a stray path is rejected with a clear message.
Use this when
- generated docs appear in a folder you did not expect after an agent run
git show --name-statuslists doc files outside the docs directory- the docs site builds but new pages are missing because they landed elsewhere
- you run a docs agent that writes files and commits them itself
Not for this skill when
- the files are in the right place but the content is wrong (that is a generation or hallucination problem)
- the build fails on valid paths (that is a builder config problem, not a commit problem)
- a human misplaced the files by hand
Variant phrasings
- agent committed docs to the wrong folder
- generated docs landed in the wrong path
- docs agent wrote files outside docs/
- commit contains docs in unexpected directory
Why it happens
Agents resolve relative paths against whatever working directory they happen to be in, and "the docs folder" is ambiguous when a repo has docs/, doc/, website/docs, or generated output dirs. Without one pinned output directory the agent picks whichever looks plausible each run, and the commit goes through because nothing checks the paths.
Edge cases
- Amending a pushed commit rewrites history: if anyone already pulled the bad commit, revert instead of amend.
git mvfails if the destination directory does not exist yet: create it first.- Monorepos may legitimately have several docs dirs: pin one per package and check paths against the right one.
- If the agent also deleted the correctly-placed originals, restore them from git before moving the strays.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstwui-LTHP3vD8jhKgCkNMw