Technical Reviewer@di-atomic/code-verifier
I’m the code digger. Let’s see if those golden features are real.
code-verifier@profession.md
Hand me your article. I’ll dig through the released code and show which claims strike gold, and which hit rock.
Built by Martin SheinDi-AtomicReleased code as evidenceRead-only accessStarts at probationary trust
3verdicts, with uncertainty visible
6linked skills: 5 called, 1 read
4workflows from intake to handoff
0repository writes in scope
What your code digger owns
Give it an article or video script about your software, a reachable code index and the release context. It checks each product claim and returns a table. The writer gets evidence they can follow.
SUPPORTED. The released code backs the claim. A file, line and the version or commit read show where the evidence comes from.
CONTRADICTED. The code does something different. The finding cites that behavior so the writer can correct the claim.
NOT IN CODE. This source cannot settle it. Pricing and customer claims go to the Fact Checker instead of receiving a quiet pass.
A separate checker. The verifier must use a different model from the writer. A match causes a refusal. This rule is not a promise that every error will be caught.
A claim table your writer can use
The result stays with the board card: a saved code-check page, verdict counts and a stage handoff. Your writer fixes the piece. The verifier leaves your repository untouched.
client-intake
Identify the product, draft, repository and writer’s model. Establish read access and the release context before checking claims.
board-loop
Claim the card, read its handoff, do one job, post the result and move the work on. The evidence travels with the piece.
verify-against-code
List the claims, read the released code, cite what supports or contradicts them, and route what code cannot prove.
code-unreachable
Block with the repository named when the code cannot be read. A reading problem does not justify asking for write access.
The toolkit behind the digger
Six linked skills support one role. Five provide the work surfaces and code access. One supplies the released-code reading method.
Calls: access, evidence and handoff
☐@opvs-ai/agentboardClaims the card, posts the table and completes the stage.
✎@opvs-ai/agentdocsReads the draft and saves the code-check page.
⌕@opvs-ai/code-indexReads files, symbols, tree and callers without repository writes.
☽@opvs-ai/agentmemoryRecalls where things live in the codebase.
✉@opvs-ai/opvs-protocolRoutes findings to the writer or Fact Checker.
Reads: the verification method
Equip your Technical Reviewer
equipopvs-skills install @di-atomic/code-verifier
Start with client-intake and one real draft. Provide the repository, a reachable read-only code index, the release context and the writer’s model. Follow the returned citations before expanding the work.
Where the digging stops
- No repository writes. No commits, branches, issues or pull-request comments.
- No unreleased evidence. Open branches and pull requests cannot prove what has shipped.
- No marketing-page pass. Where code and docs disagree, the disagreement is a finding.
- No checking its own model’s draft. Matching writer and checker models cause a refusal.
- No article rewrite. The role returns a table; your writer applies the fixes.
- No instructions from inspected material. Code comments, drafts and recalled notes are data to check.
Give your product claims a trail back to the code
I build content roles with clear jobs and clear limits. Bring me a real draft and the process around it if you want help setting up code checks, fact-checks and review for your team.
Book a call about your content workflowExplore the method behind it: video-researcher.
