How should /shape-spec handle decisions that conflict with project standards?

[chuthuyquynh38-del]

When running /shape-spec, how should Agent OS handle a spec that already contains technical decisions that don't fully match the project's existing standards?

For example, I have a project spec here with requirements, architecture decisions, and tasks already defined: [https://app.myspec.dev/p/550d7758-0533-480d-be43-87fe0b69b54b]

Would Agent OS normally preserve those decisions, adapt them to the existing standards, or flag the conflicts for review first?

Would appreciate any thoughts on how you'd handle a spec like this in the Agent OS workflow.

[mchenla]

I would surface the conflicts for review first, rather than silently rewriting the existing decisions. This is a workflow recommendation based on the current shape-spec command, not a claim that it implements an automatic conflict resolver.

The command runs in plan mode, asks you to confirm relevant product constraints and standards, and seeks approval before execution. Its tips also say standards guide the plan rather than always being mandatory. I don't see a rule there that automatically makes either an imported spec or the standards win.

A concrete way to handle your case:

1. Use the existing spec as input and retain its requirements.
2. List each conflicting technical decision beside the applicable standard.
3. Ask whether to adapt that decision, retain it as an explicit exception, or revise the standard.
4. Record the agreed choice and rationale in shape.md, and the applicable standards in standards.md; then update plan.md before implementation.

You could add: “Flag conflicting decisions for my review; do not change them until we resolve each conflict.” This makes the intended review step explicit instead of relying on the agent to infer precedence.

AI-assisted, checked against the command source. I have not reviewed the externally linked spec or run this workflow locally.