A tracker's intake form asks the business user to do product management: pick a component, guess a priority, write acceptance criteria. They cannot, and it is not their job, so the form gets a title and a hope and engineering does the rest in a meeting.
Intake in sleds goes the other way. The person says what they want, in Claude or Slack, in their words. The connector does the product work, out loud, and asks only what it cannot find.
It reads the repo first
Before it asks a single question, intake reads the product map: what the GitHub App built from each repo's tree, kept current. So it can say what the request touches (auth/sso, api › sessions) and, more usefully, what is already there. "The tenant switcher exists; this would add a second path through it" is a sentence a PM used to need an engineer for. Now it is in the first reply.
That matters for what it asks next. A request that fits an existing area gets a narrow question. One that touches four areas gets told so, gently, and asked whether the smallest version is the one that touches one.
It checks the backlog
Then it looks at the board. If something similar is already filed, sized or in flight, it says so and offers to attach the new context to it instead of filing a duplicate. Teams running alongside a tracker find this one quietly removes a third of their intake volume: not fewer requests, fewer copies of the same one.
It sets an expectation
Once the brief holds the why, the done line and the worth, the request is sized from the team's history and the band goes back to the filer in the same conversation: M · $4–11 · 20–55 min, and whether it waits on a yes. The business user leaves knowing what they asked for, roughly what it costs, and that it is real. That is the expectation-setting a good PM does in a hallway, done for every request, including the ones nobody would have had a hallway conversation about.
It helps draw it
For anything with a screen, intake offers once to make a clickable prototype in the workspace's design system, from the request and the product map. The business user tells it what is wrong with the prototype, which they can do, rather than writing a spec, which they cannot. The prototype goes on the item as a file and the engineer, or the agent, builds from the picture.
What the org controls
All of the above speaks in the org's voice, from AI Guidance: the questions that always get asked, the ones that never do, how to talk to support versus product, what to say when the request is too big. Intake is the same shape everywhere; what it says is yours.
The result is that the request arrives on the board the way a good PM would have filed it, and the PM did not have to be in the room.