Test Your Skill in a Clean Room

Build Your Software Factory — Article 2 of 20

Close every tab. Close the terminal. Close the IDE and reopen it. You need a session with no conversation history, no open files, no implicit context from the last hour of work. This is a clean room.

In the previous article, you captured a LINQ skill from a real correction session. It covers query syntax and separating IQueryable from execution. The assistant produced it with full context: it had just been corrected twice and knew exactly what you wanted. Now find out if the skill works without you in the room.

Invoke the skill with a new task

Open a fresh session and give the assistant a task the skill has never seen. Do not mention the skill by name. Do not set up context. The skill’s description says “use when writing LINQ queries.” If the description works, the assistant will load the skill on its own.

Add a repository method that returns total order amounts per customer for a given year, including the customer name. Return a CustomerOrderTotalDto with CustomerName and TotalAmount.

This task requires a join, a group by, and an aggregate. The skill from Article 1 covers none of these explicitly. That’s the point.

Watch without correcting

The assistant produces something like this:

public async Task<List<CustomerOrderTotalDto>> GetOrderTotalsByCustomerAsync(int year)
{
    var query =
        from o in _db.Orders
        where o.OrderDate.Year == year
        join c in _db.Customers
            on o.CustomerId equals c.Id
        group o by new { c.Id, c.Name } into g
        select new CustomerOrderTotalDto
        {
            CustomerName = g.Key.Name,
            TotalAmount = g.Sum(o => o.Amount)
        };

    return await query.ToListAsync();
}

Do not correct it. Read it. Score it against your team’s standards.

Score what you see

Walk through each standard the skill was supposed to enforce:

Query syntax. The output uses from, where, group, select. That’s correct. The skill’s first rule held.

Separated query from execution. The query is assigned to var query, then executed with ToListAsync() on a separate line. That’s correct too.

Navigation properties instead of explicit joins. This is wrong. Your team navigates relationships through EF Core’s navigation properties (o.Customer.Name), not explicit join clauses. The skill never mentioned this. The assistant defaulted to what LINQ tutorials teach: explicit joins.

Grouping pattern. The group by works, but the anonymous key type and the .Key.Name access are brittle. Your team uses a specific pattern for grouped projections. The skill says nothing about grouping.

Two rules passed. Two gaps surfaced. That’s a normal result for a first-draft skill tested in a clean room.

Classify each gap

Check whether the skill loaded

Before you analyze the output, find out whether the assistant even used the skill. Ask it directly:

What skills did you use to complete that task?

If the assistant lists your LINQ skill, the description triggered correctly. If it doesn’t, nothing else matters yet. A skill that never loads is invisible. The description needs to be rewritten before you fix any rules.

Classify each gap

Assuming the skill loaded, separate what you found into two categories:

Non-compliant but functional. The explicit join produces correct SQL. EF Core translates it fine. But it violates your team’s convention. The fix is a new rule in the skill: “Use navigation properties for related entities. Do not use explicit join unless no navigation property exists.”

Missing coverage. The skill has no guidance for group by, aggregates, or subqueries. The assistant improvised. The output happened to work, but it could just as easily have mixed method syntax into the grouping clause or inlined the execution. The fix is new content: examples and constraints for grouped queries.

Jot down the gaps

You don’t need a formal report. You need a short list you can work through one at a time with the assistant in the next article. A few bullets are enough:

• Used explicit join instead of navigation properties
• No guidance for group by or aggregates
• Skill loaded: yes / no

The skill is not broken

A first-draft skill that passes two checks and misses two is not a failure. It’s a baseline. You have a short list of gaps and you know the difference between a convention violation and missing coverage.

This is step two of the cycle:

Capture → Test → Retrospective → Refine → Optimize

In the next article, we run a retrospective to turn these gaps into specific improvements.

---

Next: Article 3 — The Retrospective: “Did You Use a Skill?”

For background on skill structure and the iterative creation process, see the Skills page. For the formal skill specification, see agentskills.io.