In the past, I’ve encountered agents repeatedly falling into the same old pitfalls while writing code—pitfalls that might be difficult to include in the spec documentation.These days, developers rarely review code line by line, but when agents do review it, they often focus only on code quality.Additionally, in some cases, agents from different developers make changes to the same product logic (not just within the same code file), but issues often aren’t discovered until the branch merge phase, requiring rework.To solve these problems, I created Mainline.Mainline uses CLI, skills, and coding agent hooks to store the intent that humans express through agents in Git.Before editing, agents can read historical intents, decisions, and risks; after making changes, they can record the rationale, trade-offs, and review notes. You can also export a static Hub for others to view historical intents, risks, and hotspotsRepo: https://github.com/mainline-org/mainlineHow to use: curl -fsSL https://raw.githubusercontent.com/mainline-org/mainline/main... | bashmainline doctor --setupmainline init --actor-name alice I’d like to know if you think the granularity of intent records is useful. Does reviewing intent before a code review actually reduce the reviewer’s burden?