Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →mohitagw15856/agent-design-review
Review an LLM agent design and find where it will be unreliable, expensive, or unsafe.
Passed 20 of 22 test cases with the skill, and 16 of 22 without it.
and 3 more in the full report
5 fixed15 passed either way1 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
I am designing an automated customer support bot that reads incoming user tickets, retrieves order details from a database, computes refund amounts, and directly issues payments via a payment gateway API. The workflow uses a basic ReAct loop where the model receives full conversation history at each step until it decides it is finished. Could you perform an architectural review on this proposed system? Please structure your evaluation to include a high-level summary highlighting major production risks, a detailed tabular breakdown of design flaws categorised with severity levels and concrete remedies, a reliability verification checklist, cost and latency optimization strategies, safety analysis regarding side-effecting actions, and a prioritized refactoring plan based on impact versus effort.
| Checked | Without skill | With skill |
|---|---|---|
| The review summary specifies a single primary recommended modification alongside the top risks | Missed | Passed |
| The analysis includes a table with columns for Dimension, Finding, Severity, and Fix | Missed | Passed |
| The output flags the financial payment action as requiring a human confirmation gate | Passed | Passed |
The instructions your model reads when the skill loads.
Most agents don't fail because the model is weak — they fail because the design lets them loop, call the
wrong tool, lose the thread across steps, or burn tokens with no stopping rule. This skill reviews an agent's
architecture against the decisions that actually determine reliability, and ranks the fixes — so "it works in
the demo but not in prod" becomes a specific list of changes. (Writing a new agent spec? Use
agent-spec.)
Given a sketch ("a research agent that searches, reads, and writes a report"), deliver the full review anyway — infer the likely control flow and tools, label the inference, and flag what to confirm. Never withhold the review for missing detail.
Ask for these only if they aren't already provided (else infer and label):
1. Summary — will this be reliable in production? The top 3 risks and the single change that helps most.
2. Findings by dimension — for each, what's sound and what's fragile:
| Dimension | Finding | Severity | Fix |
|---|---|---|---|
| Control flow | no max-steps / no progress check → loops | High | step budget + "am I making progress?" check + halt |
| Tool use | overlapping tools confuse selection | Med | fewer, sharply-described tools; allowlist |
| Context | full history re-sent each step → cost + drift | High | summarise/scope memory per step |
| Failure handling | one tool error aborts the run | Med | retry/backoff + graceful degradation |
| Safety | acts without confirmation on writes | High | human/confirm gate on side-effecting actions |
test cases passed, vs 16 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.