An AI developer can finish the task it understood while leaving the task you intended unfinished. A cache exists, but it downloads the same image again. Checkout works on the happy path, but a restart loses the user’s progress. The report says “done,” while the physical-device cases remain untested.
I wanted a repeatable way to make those gaps visible before accepting a handoff. Ironclad-mudrae is the Agent Skill I use for that planning and review role. It makes the technical lead’s decisions explicit, gives the implementing developer a bounded assignment and defines what evidence is needed to accept the result.
The source package includes lifecycle playbooks, developer and reviewer contracts, progress rules and an optional Python handback checker. It follows the Agent Skills format and is licensed under MIT. You can also download the versioned skill package.
Keep the planning role explicit
The default mode is PLAN. The agent can read the repository and write the work order, but it does not start implementing the application just because it has enough tools to do so.
When a developer returns a report, REVIEW inspects the agreed scope, source changes and actual evidence. It returns ACCEPTED, CHANGES_REQUIRED or BLOCKED, with a precise correction and the proof needed to close it.
EXECUTOR is available when a human explicitly assigns implementation. That implementing agent follows the work order and its action boundaries. Loading the skill alone does not grant deployment, messaging or provider permissions.
This separation lets me ask for a release plan without accidentally starting a release. It also keeps the reviewer from quietly fixing the submission and losing track of what the original developer actually delivered.
Give the developer decisions they can implement
“Add caching and make the app fast” leaves too many decisions open. The developer still has to decide what is cached, which identity is used, how updates are detected, what survives a restart and which data must remain live.
For an image-caching assignment, a useful work order might require:
| Decision | Required behavior |
|---|---|
| Image identity | Stable asset ID plus content revision; editing a price does not change an unchanged photo’s identity |
| Local reuse | List, detail and cart share retained canonical bytes instead of downloading their own copies |
| Refresh | Check small revision metadata and download only changed media |
| Recovery | A truncated file is repaired safely; an old download cannot overwrite a newer revision |
| Authority | Cached browsing prices never replace a current server quote at payment |
Those are example requirements, not claims that a particular application already meets them. The order must also define the relevant environment, storage and freshness budgets, failure cases and proof.
The manager makes the consequential decisions. Routine implementation choices can remain with the developer when they preserve the contract. For a small reversible copy change, a short assignment and rendered proof are enough; the skill should not invent a migration program or a full release audit.
Require evidence for the actual claim
A screenshot can show that a populated cart renders correctly. It cannot prove that the cart survives process death. A unit test can exercise retry logic. It cannot prove that a payment provider settled a refund.
Ironclad-mudrae separates implementation, automated checks, rendered UI, physical-device behavior, provider readback, deployment and public availability. Each claim needs evidence suited to it.
For the caching example, the developer should capture the first download, reopen the same content across screens and restart the app, then show that unchanged retained images make no repeat requests. Replacing one dashboard image should produce one new revision download without refetching every other image. A recording and network trace answer that question more directly than a dependency called a cache manager.
The handback links each requirement to changed source, relevant cases and actual evidence. It records candidate and environment identity, exact commands, exit codes, failures, skips and unresolved boundaries. Material changes invalidate the affected evidence so an old screenshot cannot quietly prove a new build.
What the checker can establish
For substantial assignments, the manager issues a machine-readable acceptance contract and pins its SHA-256 before implementation. The developer returns a manifest describing the reports and evidence.
The local checker checks required IDs and reports, candidate/environment consistency, file hashes, evidence kinds and named automated case claims. It also checks failure conditions such as missing cases, unsafe paths and nonzero command exits. It reads files only and does not execute commands found in a report.
The bundled synthetic example produces:
{
"verdict": "STRUCTURALLY_COMPLETE_PENDING_REVIEW",
"release_authorized": false,
"semantic_review_required": true
}That is deliberately a limited result. Matching hashes cannot establish that a screenshot depicts the intended state or that a provider receipt is genuine. The checker does not compute accepted completion or authenticate owner approval. Someone still has to inspect the source and proof.
Version 2.1.0’s checker passed its 29 local regression tests during release preparation. Those tests cover the checker; they are not a benchmark of agent capability or a claim about an application’s quality. The repository includes the test suite and the clearly labeled synthetic example so readers can inspect the boundary themselves.
Report completion against a fixed scope
For a large assignment, define criterion weights before the developer starts. Keep the denominator fixed when access, hardware or a provider gate becomes blocked.
Suppose a 100-point order has 72 points accepted, eight explicitly waived by the owner, 12 blocked and eight failed. Report 72% verified completion, eight waived points and 20 unresolved points. Do not report 80% verified or remove blocked work from the denominator.
Developer-claimed implementation, evidence packaging and reviewer-accepted completion remain separate. A high percentage cannot bypass a mandatory financial or privacy gate. Even 100% accepted readiness does not grant permission to deploy.
Similar published tools already exist
This is not the first workflow to make AI development more structured. The following descriptions come from the projects’ primary documentation reviewed on 2 November 2026, not a head-to-head benchmark.
| Project | Documented focus | How I would evaluate the fit |
|---|---|---|
| Superpowers | Composable development skills covering planning, execution, debugging and verification | Evaluate it when you want a broader development workflow for the implementing agent |
| Planning with Files | Persistent planning records and context continuity | Evaluate it when preserving the plan across long sessions is the main problem |
| Compound Engineering | Plan, build, review and capture lessons for later work | Evaluate it when reusable team knowledge is central to the workflow |
| BMAD | Product, architecture and implementation workflows with specialized perspectives | Evaluate it when you want a broader project-development method |
| BMAD-Speckit-SDD-Flow | Requirement contracts, bounded execution, evidence chains and human closeout gates | Compare it directly if formal delivery contracts and closeout are your main requirement |
Ironclad-mudrae packages my manager-first work-order and acceptance process into a portable skill with a small local checker. There is substantial overlap with the ideas above. I make no claim that it outperforms them or that using all of them together produces a better result. If you combine workflows, establish which one owns the plan, execution authority and acceptance rules.
Install and try one bounded assignment
Using the Skills CLI:
pnpm dlx skills add yasircs4/ironclad-mudrae --skill ironclad-mudrae -gActual discovery depends on your agent host. Keep the complete skill folder, including references and scripts, and follow the host’s installation rules. The optional checker needs Python 3.9 or later and the standard library; the planning instructions do not require Python or a hosted account.
Start with a specific request:
Use $ironclad-mudrae in PLAN mode.
Read this repository and its existing specification without implementing it.
Make the technical decisions for the requested change.
Write a developer work order with failure cases, measurable acceptance,
required proof and an explicit handback location.Give it the real repository and constraints. Then review the resulting decisions before assigning implementation. A skill can make omissions harder to hide, but it cannot supply missing model competence, tools or access. The useful result is a clearer assignment and an acceptance decision you can trace back to actual evidence.