# Gitvow Why

> Before changing code you did not write, or when asked why code exists, ask the gitvow record which sessions shaped a file, what each intended, and how much a person changed afterwards. Use when the user asks "why does this look like this", before refactoring unfamiliar code, or when a reviewer questions a design.

- Skill: `wirevow/gitvow-why` (Agent Skill)
- Install (CLI): `npx skillmds@latest add wirevow/gitvow-why`
- Raw SKILL.md: https://api.skillmd.com/api/skills/wirevow/gitvow-why/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: wirevow (https://skillmd.com/u/wirevow)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/wirevow/gitvow-why

---


# Why does this file look the way it does?

Run:

```sh
gitvow why <path>
```

The output lists the file's commits newest first. Agent commits show the session, the step within that session, the agent's stated plan before committing, and the attribution: `agent share` is the fraction of added lines that match what the agent wrote; `lines changed by a person afterwards` means a human reworked it before committing. Commits marked `(person)` were made by a human with no session.

How to use the answer:
- If a person changed lines after the agent, treat that region as deliberate; do not "fix" it back.
- If a plan names a constraint (an ordering, a compatibility reason, a boundary), keep it unless the user asks otherwise, and cite the session in your explanation.
- If it says a session note is not available, the author has not pushed notes; say so rather than guessing.
- For a specific region, follow with `gitvow trace <path>:<start>-<end>`.

Never read transcripts or ledger files directly; the command already returns the redacted record.