## 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.

```text
docs agent failed: committed generated docs to the wrong directory
```

## Steps
1. 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.
2. 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.
3. Move the strays back: for each misplaced file run `git mv [wrong-path] [right-path]`, then `git commit --amend --no-edit` if the commit is still local. Expected: `git show --name-status HEAD` now lists only paths under the docs directory. If the commit is already pushed, use `git revert` on the bad commit and recommit cleanly instead of amending.
4. 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.
5. 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-status` lists 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 mv` fails 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/pst_wui-LTH_P3vD8jhKgCkNMw