A competitive finding reopened a decision I had already closed, and about six hours of pipeline later the feature was built and running. Two things came back with it. One is a defect: an invited user showed a question mark where it should have said pending. The other is a judgement: the public view came out thinner than I want. A run leaving work like that behind is normal, which is why the quality pass sits after the pipeline rather than inside it. How thin the public view came out is the part I did not see coming.
Arcs one and two covered building a feature end to end. This arc moves the decision earlier, to what gets built at all, and this is its second article: the previous one covered where research sits in my pipeline and how a weekly report became Linear projects.
The decision the research changed
Insights is the analysis the AI writes from the results of a study, the test you put in front of respondents. You could already share a study, and you could share a launch, which is one run of a study and the results it came back with. You could not share the insight. I had decided that was fine for alpha, the release I was building towards at the time. Sharing adds complexity to the app, and I probably did not need it.
Then I looked at the competitive landscape and decided I would probably just do it. The components already existed, built earlier for studies and launches, so the cost was lower than I had priced it.
Two sets of projects, and what that split is based on
The agent broke the research into projects rather than one, or we did between us. Pre-alpha projects, and a set that could follow after alpha. At that point the ordering rested on competitive research alone, and I planned to validate it later. I would rather say that than present it as user evidence.
Handing one project to a build agent
A skill is a named set of instructions I hand to a fresh agent, so it starts with the process already in its head instead of me re-explaining it. /build is the delivery one. I open a fresh agent, give it the Linear project, and ask for the full sequence: brief, review, lock the brief, research, plan, review the plan again, then implement and run a series of checks before shipping.
The ship step targets a staging environment, not production. At the time of this run I did not mind shipping straight into the app: there were no users, signups were closed, the app was locked down. The app has soft launched since, so that period is over. Testing the staging path was worth doing while getting it wrong cost nothing.
Phases, tickets, and companions
The project comes back decomposed into phases, and each phase into tickets. Some tickets carry companions, which are small sibling tickets attached to a phase and blocking it.
A UX companion attaches when a phase touches the component library. This project had some, because the work either adds new components or updates existing ones. The phase does not get implemented until a design pass has produced a spec for it.
A QA companion attaches when a phase introduces a feature that could break something around it, which for a new feature is most of the time. It carries acceptance criteria and gets executed against the built phase.
Ideate, then translate
/ux is the design skill. Two of its steps matter here.
Ideate generates a set of variants for the surface. I review them with the agent and agree on one. This one was quick. The variant I picked is close to what studies and launches already do, and because an analysis has no roles, the only thing it adds is the option to remove a user from it.
Ideation does not use real components. It is markup that looks like the product. Translate is the step that takes the picked variant and rebuilds it out of the actual component library, as a story in Ladle, the component workbench this repo uses. That gives me a screenshot and a live render I can open and click.
The render came out close to the ideation output, and close to what studies and launches already look like. That is fine by me.
What came out
The run was intense and it took a long time. Beginning to end, about six hours. At the end the sharing features were built and running, and everything below is that staging build as it stood on the day.
The insight lists who it is shared with. Two users on this one: me, and one with a question mark next to them, because that user has not accepted the invite yet. That is the defect. It should say pending, and it does not.
The share panel handles the rest. The link can be private or public.
The public view is the first version and it is not perfect. I was expecting better than this, so it needs a separate UX pass of its own. As a starting point it is fine.
The pipeline gets a feature to the point where it works and does not break what sits around it. Making it good is a separate pass, and I run it afterwards. One research driven feature, from Linear project to built and running, in pretty much a day.
Running this with your own agent
None of this depends on my repo.
- Write the research outcome into your tracker as a project with its own scope and release target, before you hand it to anything.
- Split the work by release: what has to land before your release date, and what can follow it. Say which side of that split is evidence and which is a guess.
- Give one agent the project and the whole process at once, not one step at a time. Brief, lock the brief, research, plan, review the plan, then implement.
- Point the ship step at a staging target while your app has no users, and spend that period testing the ship path rather than skipping it.
- Attach companions to phases. A design companion on any phase that touches the component library, blocking implementation until there is a spec. A QA companion with acceptance criteria on any phase that could break an existing surface.
- Keep ideation and implementation apart. Pick a direction from throwaway mockups, then have a second step rebuild the picked one from your real components and render it somewhere you can click.
- Open the feature yourself the moment it lands, and check the states that did not get designed: pending, empty, invited but not accepted.
- Book the quality pass as its own piece of work, with its own ticket, after the run rather than during it.
The next article covers automated prototyping for complex user journeys.
