What happened
On PR #7066, the code agent was asked to bring repos install to parity with github setup for vendor flags (issue #7065). The issue listed 4 specific changes: add config fields, replace standalone flag with addVendorFlags(), add validateVendorFlags call, and pass fields through to appendVendorTreeFiles. The code agent implemented all four correctly but also added a call to applyDeprecatedVendorBinaryFlag(cmd, &opts.vendor) — copying it from github setup's RunE. This function is a deprecation shim for --vendor-fullsend-binary, a flag that was historically offered on github setup but never on repos install. The shim is a no-op in the new context. The human reviewer (comment) caught this and triggered a fix cycle to remove it. The initial commit message even listed it as an intentional change.
What could go better
The code agent's existing guidance says to implement 'the smallest correct change' and AGENTS.md says 'Only code required by the issue.' The code agent violated both principles by adding unrequested code. The root cause is that the code agent treated github setup's RunE as a template to copy wholesale, rather than evaluating whether each component of the pattern applies to repos install. Deprecation shims and backwards-compatibility wrappers are inherently context-dependent — they exist because of the history of a specific command (callers who used a prior interface), not because of the pattern itself. When copying a pattern to a new command that has no such history, the shim is dead code. Confidence: high — the issue spec was precise, the code agent went beyond it, and the function name literally contains 'Deprecated' which should have been a signal to evaluate applicability.
Proposed change
Add guidance to the code-implementation skill (skills/code-implementation/SKILL.md) in fullsend-ai/agents. In the planning or implementation phase, add a check: 'When adapting a pattern from command A to command B (e.g., bringing B to parity with A), evaluate each component of A's implementation independently. Deprecation shims, backwards-compatibility wrappers, and migration code are tied to the history of command A — they exist to support callers who used a prior interface. If command B never offered that interface, these components are dead code and must not be included. The function name or documentation will typically contain signals like Deprecated, Legacy, Compat, or Migration.' This is a targeted addition to existing minimality guidance, not a new principle.
Validation criteria
On the next 5 code agent runs where the issue asks to bring one command to parity with another, the code agent should not include deprecation shims, backwards-compatibility wrappers, or migration code that only applies to the source command's history. Specifically, any call to a function with 'Deprecated', 'Legacy', or 'Compat' in its name should be evaluated for applicability rather than copied wholesale.
Generated by retro agent from fullsend-ai/fullsend#7066
What happened
On PR #7066, the code agent was asked to bring
repos installto parity withgithub setupfor vendor flags (issue #7065). The issue listed 4 specific changes: add config fields, replace standalone flag withaddVendorFlags(), addvalidateVendorFlagscall, and pass fields through toappendVendorTreeFiles. The code agent implemented all four correctly but also added a call toapplyDeprecatedVendorBinaryFlag(cmd, &opts.vendor)— copying it fromgithub setup's RunE. This function is a deprecation shim for--vendor-fullsend-binary, a flag that was historically offered ongithub setupbut never onrepos install. The shim is a no-op in the new context. The human reviewer (comment) caught this and triggered a fix cycle to remove it. The initial commit message even listed it as an intentional change.What could go better
The code agent's existing guidance says to implement 'the smallest correct change' and AGENTS.md says 'Only code required by the issue.' The code agent violated both principles by adding unrequested code. The root cause is that the code agent treated
github setup's RunE as a template to copy wholesale, rather than evaluating whether each component of the pattern applies torepos install. Deprecation shims and backwards-compatibility wrappers are inherently context-dependent — they exist because of the history of a specific command (callers who used a prior interface), not because of the pattern itself. When copying a pattern to a new command that has no such history, the shim is dead code. Confidence: high — the issue spec was precise, the code agent went beyond it, and the function name literally contains 'Deprecated' which should have been a signal to evaluate applicability.Proposed change
Add guidance to the code-implementation skill (
skills/code-implementation/SKILL.md) infullsend-ai/agents. In the planning or implementation phase, add a check: 'When adapting a pattern from command A to command B (e.g., bringing B to parity with A), evaluate each component of A's implementation independently. Deprecation shims, backwards-compatibility wrappers, and migration code are tied to the history of command A — they exist to support callers who used a prior interface. If command B never offered that interface, these components are dead code and must not be included. The function name or documentation will typically contain signals like Deprecated, Legacy, Compat, or Migration.' This is a targeted addition to existing minimality guidance, not a new principle.Validation criteria
On the next 5 code agent runs where the issue asks to bring one command to parity with another, the code agent should not include deprecation shims, backwards-compatibility wrappers, or migration code that only applies to the source command's history. Specifically, any call to a function with 'Deprecated', 'Legacy', or 'Compat' in its name should be evaluated for applicability rather than copied wholesale.
Generated by retro agent from fullsend-ai/fullsend#7066