Most AI coding assistants are extremely good at one thing: making a confident-sounding first draft of whatever you ask.
That is also their failure mode.
If you let a single AI conversation handle "turn this idea into a tested, reviewed, merge-ready pull request," what you actually get is: a spec the model invented, an architecture the model chose silently, code written to pass tests the model also wrote, and no review because the author is the same entity as the reviewer. Shipping that is how AI-assisted engineering acquires its reputation for subtle bugs and unreadable modules.
Strong engineering teams have never worked that way. Even a two-person team informally splits the work: someone frames the problem, someone decides the approach, someone builds, someone else looks at the diff. The roles may compress onto one person, but the four moments are still there.
I made that structure explicit for Claude Code, as four slash-command skills, each with one job.
The four skills
Each /<skill> is a self-contained SKILL.md file with a strict output format. You invoke them in sequence (or individually), and each produces an artifact the next stage holds accountable.
/product-owner
Turns a raw idea into a testable spec. Output: PROBLEM, TASK SPEC, USER STORIES, ACCEPTANCE CRITERIA, EDGE CASES, OUT OF SCOPE, OPEN QUESTIONS, DEFINITION OF DONE.
The important part: if the request is missing something load-bearing, this skill is required to flag it under OPEN QUESTIONS rather than invent an answer. The thing that keeps AI coding from being safe is that models by default fill ambiguity with plausibility. Making "ask, don't guess" a hard rule at the spec stage is where most of the ROI lives.
/architect
Takes the spec and designs the minimal implementation approach. Output: APPROACH, COMPONENTS, DATA FLOW, INTERFACES, CONSTRAINTS, RISKS, TRADEOFFS, DEFINITION OF DONE.
First thing the architect skill does is a size check. If the diff would exceed ~400 lines of meaningful code, or touch more than 3-4 files across layers, it refuses to design the whole thing and instead splits it into sub-tasks. The downstream Dev/QA skill works much better on small, isolated changes.
/dev-qa
Implements the feature with tests. The core discipline: "Acceptance criteria are the contract. Every checked box must correspond to working code AND a test that would fail without it. If you cannot write the test, you do not understand the requirement."
Also: no drive-by refactors, no new dependencies without an architect note approving them, no commits to main, no bypassing failing tests. CI must be green before pushing.
/code-reviewer
Read-only. Reviews the diff against the spec and architect notes. Output: VERDICT (approve / request changes / needs human), CRITICAL issues, IMPORTANT issues, SUGGESTIONS, WHAT'S DONE WELL, VERIFICATION STORY.
Every Critical or Important issue must include affected area, risk, and recommended fix. "This feels bad" is not a valid finding; evidence is.
Why structuring it this way matters
Three things change when the roles are explicit:
Ambiguity surfaces at the cheapest stage. OPEN QUESTIONS at the spec step costs nothing to resolve. The same ambiguity caught at code review costs a rework round.
Drift becomes traceable. If the final PR doesn't match what the user asked for, the gap is attributable to a specific stage, with a specific output you can inspect.
Scope creep gets a hard stop. Dev/QA is explicitly banned from "while I'm here" cleanups. The architect refuses oversized tasks. The reviewer rejects PRs that exceed the spec.
None of this is theoretical. If you have ever reviewed a PR that quietly tripled in scope between the ticket and the diff, you know exactly what these guardrails prevent.
Install
git clone https://github.com/KumiQ/ai-engineering-skills.git
cd ai-engineering-skills
mkdir -p ~/.claude/skills
ln -s "$(pwd)/skills/product-owner" ~/.claude/skills/product-owner
ln -s "$(pwd)/skills/architect" ~/.claude/skills/architect
ln -s "$(pwd)/skills/dev-qa" ~/.claude/skills/dev-qa
ln -s "$(pwd)/skills/code-reviewer" ~/.claude/skills/code-reviewer
Restart Claude Code. /product-owner, /architect, /dev-qa, /code-reviewer are now available in every project.
Where this came from
I run KumiQ, where we work on making organizational engineering standards usable by AI coding agents, through a Model Context Protocol (MCP) server. These four role-based skills are the workflow layer that sits on top of that: once the agent has access to your organization's standards, these are the roles that actually use them to produce shipped work.
The skills are MIT-licensed, independent of KumiQ, and useful on their own. If your team is figuring out how to adopt AI coding tools without the output quality dropping, start here.
Repo: https://github.com/KumiQ/ai-engineering-skills
I would genuinely like to hear what breaks when you try these on your own stack. Issues and PRs welcome.
Top comments (16)
Your four artifacts line up almost exactly with where role boundaries become testable: product owner defines acceptance, architect defines scope, Dev/QA gets write authority, and the reviewer stays read-only. Would you be open to contributing one sanitized completed workflow as an interoperability fixture? No tool migration: map the existing skill outputs to role/task contracts, record a baseline PASS, add one deliberate contradiction (for example,
/code-revieweris asked to modify a file or Dev/QA touches an out-of-scope path), repair it, and publish setup time plus any false positives.ARC only validates the supplied declarations offline; it would not prove that Claude enforced the roles. Repo and evaluation template: github.com/suirindo/agent-role-con...
Would one of your shipped tasks be suitable?
This is an interesting direction. The distinction between defining role boundaries and actually enforcing them is important.
Our current approach focuses on making each role’s responsibilities, inputs and outputs explicit. I can see value in testing how those contracts hold up when deliberately challenged, particularly around write permissions and scope boundaries.
An interoperability fixture sounds like a useful way to explore this. I’ll take a closer look at ARC.
Thanks, Lital. I agree — the important test is whether role boundaries hold when challenged, not just whether they're clearly documented.
Your four skills provide a useful starting point. I'd suggest a small, fully synthetic interoperability fixture with three cases:
For each case, we could compare the declared contract, expected and observed ARC verdicts, and separate runtime evidence where available.
Importantly, an ARC declaration check wouldn't be treated as proof that Claude Code actually prevented a write.
We could also measure setup time and false positives, without requiring production code or changing your existing workflow.
Would a small synthetic example mapped to your four skills be a useful first step?
Interesting perspective. I particularly agree with the distinction between validating declared contracts and verifying actual runtime enforcement. That’s an important gap as we move from experimenting with agents to putting them into real organizational workflows.
At KumiQ, we’re looking at this from the broader organizational perspective: how to make AI capabilities reliable, governed and valuable in practice.
I don’t have capacity to explore an interoperability experiment right now, but I think we’re looking at complementary parts of an important problem. Definitely worth keeping the conversation going.
Thanks, Lital. I appreciate the thoughtful response, and completely understand the bandwidth constraint.
I think the complementary perspective is valuable. ARC focuses on making declared roles, authority, and task boundaries checkable before execution. But organizational trust also requires runtime enforcement, accountability, and evidence that the intended outcomes actually occurred.
One question we're exploring is how these layers can connect without creating another governance burden for the people using AI agents.
I'll keep sharing concrete findings as our experiments progress. Looking forward to following what you're building at KumiQ as well.
I think that last point is particularly important. Governance only works if it becomes part of how people work with AI, rather than another layer of complexity they have to manage.
There’s an interesting opportunity to connect technical assurance with organizational adoption. Looking forward to following your experiments with ARC as well.
Exactly, Lital. I think that connection between technical assurance and organizational adoption is where this becomes especially valuable.
One of the things we're exploring with ARC is how to make role boundaries, independent verification, and execution evidence part of the normal AI workflow — without requiring people to manage another governance system.
I'd love to take this a step further and explore a practical adoption scenario together.
For example, what if a team could introduce AI agents into an existing development workflow, with clear responsibilities and verifiable outcomes, while keeping the human experience almost unchanged?
We could examine both sides:
I think your perspective on organizational adoption would complement our ARC experiments really well.
Would you be interested in exploring a small, concrete use case together? I think we could turn this discussion into something genuinely useful for teams adopting AI agents.
I think there’s a valuable use case here, particularly around making reliable AI workflows practical for teams to adopt.
Our focus at KumiQ is on operationalizing AI across the SDLC, combining structured workflows, standards and specialized skills to make outcomes more consistent and measurable.
I can see interesting synergies between that approach and ARC. I’d be open to exploring the overlap and identifying a concrete scenario where both perspectives could add value.
Thanks, Lital. I think this is a promising intersection between KumiQ and ARC.
Your focus on making AI workflows consistent and measurable across the SDLC complements what we're investigating with ARC: whether declared roles, responsibilities, and task boundaries can be verified independently.
Here's one concrete scenario we could explore without requiring access to either team's production environment.
A synthetic AI-assisted pull request workflow:
We could introduce three deliberate failures: an unauthorized reviewer write, an out-of-scope implementation change, and a new commit arriving after review.
Then measure both dimensions:
ARC would handle declaration consistency; the host and workflow would remain responsible for runtime enforcement and outcome verification.
The interesting question is whether we can make those guarantees visible without making the team's workflow more complicated.
I'd be happy to put together a small, self-contained scenario outline for asynchronous feedback, keeping the initial commitment minimal.
Would this fit the kind of SDLC workflow KumiQ is building around?
I think even a lightweight comparison could produce useful findings for both approaches.
Thanks for sharing this. I think there’s an interesting intersection between KumiQ and ARC.
At KumiQ, we’re focused on making organizational engineering expertise actionable through AI coding agents. We guide agents through defined workflows, skills and standards, helping organizations scale AI adoption without requiring every developer to become an AI expert.
The work on independently verifiable roles, responsibilities and task boundaries addresses an important complementary challenge: ensuring agents actually operate within their declared boundaries.
I particularly like the idea of testing this through a synthetic PR workflow. It would be interesting to explore how ARC’s contract validation could complement KumiQ’s workflow orchestration, while keeping runtime enforcement independent and deterministic.
I think there’s potential for an interesting technical discussion here. Let’s take it offline.
Thanks, Lital. I'd be glad to take this offline.
I think a small synthetic PR workflow would be a good starting point. We can map KumiQ's four existing roles to ARC's contracts and examine the boundary cases we've discussed.
The key is to evaluate three things separately: declaration consistency, independent runtime enforcement, and evidence of the actual outcome.
I'd suggest starting with a one-page test matrix that we can review asynchronously. No production access or changes to KumiQ's existing workflow would be needed for this initial exploration.
If it looks useful to both sides, we could follow up with a short technical call.
What's the best way to connect privately — email or LinkedIn?
I agree with your point that scope creep gets a hard stop only when the boundaries are written down before implementation starts. In my own reviews, a generic "review this" prompt tends to praise the code and approve unrelated cleanups, because it has no standard for what counts as out of scope. A reviewer role with a fixed checklist changes that by forcing a separate answer for each item — whether each change maps to the spec, whether any new dependency appeared, and whether any unrelated file was touched — so an extra change cannot hide inside a generally good-looking diff. Non-English teams run into the same problem, and the curated Chinese collection at github.com/laolaoshiren/claude-cod... includes a Chinese-output code-review skill built around the same checklist idea. That explicit structure, rather than a smarter model, is what makes the "no" at review time feel repeatable instead of personal.
Exactly. A reviewer needs something concrete to evaluate against, otherwise it tends to become another model validating its own assumptions.
I particularly like your point about making every review item independently accountable. It makes the review much more reproducible and less dependent on the model’s interpretation of what good code looks like.
The multilingual angle is interesting too. The principles should remain consistent regardless of the language used by the team.
Tokenade is what I build, and I would check the reads before the roles. A role that loads only what its job needs costs less than one that reloads the whole repo.
Good point. Role separation shouldn’t mean every role reloads the entire context.
There’s an interesting balance between giving each role enough context to make sound decisions and keeping its working context focused on its actual responsibility.
This is also where separating organizational standards from task-specific context becomes important.
Open to pushback on the sub-task size threshold in /architect. I set it at ~400 LOC but honestly guessed.