Create and revise specifications
Use Product Specs to agree on behavior before implementation.
Use a specification when the task needs decisions about users, behavior, scope, or acceptance before code changes begin. Product can help turn an objective into a structured document your team can review.
Start with the problem
Open the Product workspace and its Specs surface. Start a conversation or use the creation action offered there. Supply the problem, relevant repositories, affected users, constraints, and any existing task or brief.
Write a spec for saved filters in the activity list.
Users should save and rename a filter without changing the current URL behavior.
Use the web repository. Identify open decisions before proposing implementation tasks.An existing brief can supply source context. The separate Briefs surface is hidden in the current product, so use the visible Specs workflow rather than depending on an older brief tutorial.
Review the structure
Read the overview, detailed design, requirements, acceptance criteria, and proposed work. Check that each criterion describes an observable outcome. Supply repository or integration details that the draft cannot infer safely.
Keep the overview concise. Put consequential decisions in the structured fields instead of scattering them across repeated summaries. A conceptual diagram or explainer can clarify a relationship; it is not evidence that the proposed behavior already works.
Ask for a revision
Give targeted feedback in the Product conversation or use the specification's change-request controls. State which requirement changes and which constraints remain. Review the new revision against the earlier decision rather than assuming all feedback was applied.
An approved revision is immutable. Use follow-up work for a material change to an approved outcome.
When the draft is ready, read approve a specification and start work. For a small implementation with an agreed outcome, you can start a session directly.