Why we built Lusona Skills
Why our team built Lusona Skills to support design decisions through investigation, experimentation, and measurement, with execution that adapts as we learn.
TL;DR: We built Lusona Skills to help our team make design decisions through investigation, experiments, and measurement, and to give agents more responsibility for execution and verification. We wanted to test assumptions before committing, check whether changes delivered the intended improvements, and use what we learned to revise decisions and choose further work. Find Lusona Skills on GitHub.
What we wanted from working with agents
Our team wanted coding agents to help us develop a product through changing requirements, architectural questions, and findings we couldn’t anticipate at the start of an assignment. That included examining design alternatives, testing assumptions, and measuring whether a change achieved its intended effect.
We had been using Superpowers, gstack, and Matt Pocock’s skills. We value the attention they give to engineering practice: Superpowers connects design, testing, and review; gstack gives product thinking and QA dedicated tools; and Pocock’s skills make practices such as clarifying intent and getting feedback from tests easy to reuse. They helped bring consistency to our work.
Lusona grew from a particular set of needs in our own projects: evidence to guide design decisions, more autonomy during execution, and continuity between what an assignment establishes and what the team does next.
Making design decisions through investigation, experiments, and measurement
Design involves choices about boundaries, responsibilities, and tradeoffs whose consequences may need investigation before we can judge them. We wanted agents to help us compare alternatives and identify the assumptions behind them. Understanding the outcome we want doesn’t always tell us which design will serve it best.
Investigation helps establish what we know about a question: how the current system behaves, what causes a problem, or whether an approach is feasible. That can resolve a design choice or identify an assumption worth testing. We wanted room for this work before committing to a spec, and whenever implementation raised a new question.
Experimentation lets us test an intervention or compare approaches through a bounded trial. A prototype can help, provided we know which question it should answer and what result would support adopting, rejecting, or refining the approach. We wanted agents to make those criteria explicit before running the trial, including when to stop. An inconclusive result should remain inconclusive.
Measurement gives us a basis for judging the size and value of a change. We wanted agents to establish a baseline, compare results under suitable conditions, and report uncertainty and costs alongside any improvement. This matters both when choosing between designs and after implementation, when we need to know whether the expected benefit was realized.
These needs shaped Lusona’s architecture, investigation, experiment, and measurement skills. They can inform a decision independently or together, and we can return to them as evidence changes the design. Their purpose is to give the team a defensible basis for committing engineering time.
Giving the agent responsibility for execution
In our work, newer models were increasingly able to investigate an uncertainty, try an approach, check the result, and adjust. We wanted to give them responsibility for that execution while keeping consequential product and engineering decisions with the team.
Improvements in reasoning, planning, tool use, and error recovery make this delegation more practical. Anthropic identifies these capabilities as the basis for agents that plan and act independently, using results to guide subsequent steps. OpenAI’s guidance for GPT-6 Astra describes a related change: detailed procedural instructions that helped earlier models can constrain more capable ones. For us, this supported giving the agent more responsibility for deciding how to carry out the work, with clear outcomes, decision boundaries, and completion criteria.
We stopped requiring a separate planning document for every change. We still agree on outcomes, constraints, and acceptance criteria, and retain a spec when the change needs one. Planning can then develop with the implementation, with more detail where dependencies or coordination require it.
Lusona organizes this around a shared loop: choose an action, carry it out, check the result, and use what was learned to choose the next action. Skills supply the relevant guidance without requiring us to direct every transition between them.
This gives us a practical division of responsibility. The agent continues through useful authorized work and verifies the result. The team addresses choices that exceed the agreed authority. If progress is blocked, we need a clear account of what remains and what would allow the work to continue.
Keeping the project’s decisions current
A decision can be reasonable when we make it and need revision after an experiment or implementation reveals more. We wanted those revisions to carry through to subsequent work.
Our team had encountered cases where we agreed on a new approach but the agent continued following earlier instructions. That made keeping the records consistent an additional responsibility for us.
In Lusona, revisiting a decision includes identifying what the new evidence changes and updating the affected records after the revision is agreed. The supporting rationale remains available. This matters as dependencies grow: a change in one area can affect assumptions elsewhere, and later assignments need to start from the current understanding.
Using findings to decide what comes next
Completing an assignment can reveal work the original scope didn’t include. We wanted the agent to investigate those findings and retain enough context for us to judge their value.
One evaluation exposed gaps we hadn’t anticipated. Investigation showed that one apparent problem required two distinct changes. A later check also reduced the expected benefit: some cases we had counted as potential improvements were already covered by our existing measurement.
We kept the finding, corrected the claim, and recorded that correction with the proposed work. That gave us a basis for deciding what to authorize without reconstructing the investigation. It also demonstrated why an agent’s proposal still needs scrutiny.
As the project grew more complex, having observations, uncertainty, and possible next actions available together became more valuable. We could assess a proposal, defer it with a reason, or use it to shape another assignment. Finishing one piece of work contributed to our understanding of what the product still needed.
Keeping engineering judgment in the loop
An agent’s proposal can be plausible and still overstate the benefit. The correction in our evaluation shows why examining the assumptions and measurements is part of the work. We remain responsible for the acceptance criteria, consequential tradeoffs, and decisions about which work to pursue.
We apply the same scrutiny to Lusona Skills. Each requirement should help the agent make progress, preserve a necessary boundary, or provide evidence we need to judge the result. We need to revisit instructions that add coordination work without serving those purposes.
We’ve been developing and using Lusona Skills for several months. Our aim is to help the team devote more attention to design and product decisions, supported by agents that carry out the agreed work and produce evidence we can evaluate. We welcome feedback from teams with similar needs, including where the skills introduce coordination work of their own.