Code-Review on Lessons learned

Adapt security skills to your project's risks: from Go to OWASP LLM and iOS

Sun, 25 Oct 2026 21:50:00 +0100

A security skill written for Go covers different questions than one written for an LLM application or an iOS app. I started with golang-security from samber/cc-skills-golang , asked Claude to adapt it using the OWASP Top 10 for LLM Applications, and later carried that approach into production iOS development.

The most useful part of the adaptation was aligning the review questions with the project’s risks and the company’s values.

Start with a review method

I was working in Go, a language I was unfamiliar with. I used my security skills alongside other Go skills to keep the implementation in check.

The security skill provided a repeatable method: separate modes for coding, reviewing changes, and auditing a codebase; questions about trust boundaries and attacker-controlled input; and instructions to trace data through surrounding code before reporting a finding. Its references and checklist gave the agent somewhere to look beyond the main instructions.

Adapt OWASP categories to the application

I asked Claude to create a new skill using the OWASP Top 10 for LLM Applications (2025) , adapted to the project’s LLM and Model Context Protocol (MCP) surfaces.

The resulting llm-security skill kept the review modes and evidence requirements. It mapped the categories to tools, resources, prompts, and content returned to the model. The Go checklist stayed active for the code underneath.

For prompt injection , the reviewer needs to identify whose text reaches the model and what an attacker can control. A returned document body or filename can carry instructions. For excessive agency , the questions concern tool permissions, reachable side effects, and authorization enforced outside the model.

Those questions give the agent a path through the repository. It can follow a tool result back to its data source, then follow a tool call forward to the operation it performs. The skill also asks it to account for existing protections when assessing impact.

Repeat the adaptation for iOS

Later, I applied the same approach to an iOS app using the OWASP Mobile Top 10 (2024) . That mobile security skill became part of production development.

The review method carried over. The mapping changed to platform APIs and the code responsible for them:

Mobile risk	Concrete review question
Improper credential usage	Where are tokens stored, and which Keychain access settings apply?
Insufficient input/output validation	What can a deep link or share-extension input cause the app to do?
Insecure data storage	Which protection classes apply to cached and temporary user files?
Inadequate privacy controls	Where can sensitive data appear outside its intended screen, including logs and notifications?

Repository context matters here. If a shared SDK owns authentication or networking, the skill needs to direct the reviewer into that SDK. Stopping at the changed Swift view would leave the relevant behavior unexamined.

For a mobile adaptation, MASVS supplies verification controls, and MASTG provides testing guidance for checking them.

Turn company values into review rules

Company values need concrete instructions too. For example, a company that prioritizes privacy can require reviewers to trace user data into logging, analytics, and crash reporting. That turns a broad preference into something an agent can inspect.

The mobile skill also records settled product decisions. An intentional tradeoff needs a rationale and the protections that still apply so that each review can assess the implementation against that decision. New evidence or changed assumptions can justify reopening it.

Severity needs the same local reasoning. OWASP provides risk categories; the product’s data, attacker access, and existing controls determine a finding’s impact.

A fresh adaptation request could be:

Use the existing security skill as a template. Keep its review workflow
and evidence requirements. Adapt the relevant OWASP categories to this
repository's entry points, data flows, and platform APIs. Link each check
to the responsible code and a primary reference. Record product decisions
with their rationale. Preserve the language-level checks alongside it.

Tailoring a security skill gives the agent concrete questions about the product it is building. Take one OWASP category in your current skill and map it to the code, data, and product decision the reviewer should examine.

A repeatable agentic development workflow: context, tickets, implementation, review

Sun, 25 Oct 2026 18:25:00 +0100

Giving a coding agent a feature request and accepting the first working diff is easy. Repeating that across projects is where things get messy: the agent has to rediscover the domain, invent missing requirements, decide what “done” means, and review its own assumptions.

Here is the setup I now reuse across stacks. It has supported ten iOS app releases this year, helped clean up an existing app built with loose agent guidance, and helped a Go implementation recover after its first approach fell apart - to name a few examples. The Go work also involved a language stack and MCP technology I had not used before. The process didn’t provide that expertise on its own; it made the gaps visible early enough to address them.

Give the agent durable context

Start with mattpocock/skills and run its repository setup. Keep a short domain vocabulary in CONTEXT.md (or the current upstream convention, GLOSSARY.md). Record consequential design choices as ADRs. The agent can then use the same terms in discussions, tickets, code, and reviews.

For a change whose shape is uncertain, use /grill-with-docs to work through the decisions and write them down. Run /to-spec once the conversation has enough detail. Break the spec into small, ordered tickets with /to-issues in older installations or /to-tickets in the current upstream skills. Then use /implement against those tickets.

The sequence is:

shared vocabulary + ADRs → grill → spec → tickets → implement → review

You can enter the sequence at whichever step the work needs. A small, well-specified fix may already have a ticket. An uncertain feature should be grilled before an agent starts writing code.

Put tickets where the project works

The tracker is an adapter for the process. One project keeps issues in a local docs/TODO.txt; others use Vikunja or Taiga. What matters is that the agent knows where the authoritative spec and tickets live, how to record blockers, and how to update their status. Write those rules into the repository’s agent documentation. A tracker integration skill can handle the API details without changing the development sequence.

This also makes the setup portable. Moving to a new project means teaching the agent that project’s domain, tracker, and checks, rather than rebuilding the workflow.

Make implementation answer to the spec

Implementation includes tests and a diff review. Review the result against two different questions: does the code follow the project’s standards, and does it actually satisfy the originating spec? The latter catches plausible code that solves the wrong problem. A previous review found duplicate-write paths after a large test suite passed because it checked a safety claim against the call path.

Where the project’s rules allow it, use a different model family for review. A typical split is Claude writing the code and GPT reviewing it, since a different family brings different blind spots. Claude reviewing Claude has also proven decent, so one family is still a workable setup when you can only use one provider. For larger changes, a multi-review skill can run distinct axes such as correctness, quality, tests and performance, security, and, for frontend, accessibility. Give each reviewer the same bounded diff and the actual spec; collect actionable findings back into the tracker.

Attach stack-specific skills where they help. Go work can load guidance for concurrency, error handling, testing, and security. iOS work can use Swift and mobile guidance. For exposed web APIs, mobile clients, or MCP tools, apply relevant OWASP-based web, mobile, and LLM security skills during implementation and review. A checklist gives the agent concrete questions to ask; it does not turn a code review into a security certification.

Start with one change: write down the vocabulary and decision, turn the request into a spec and tickets, implement one ticket, and review the diff against the spec and its security boundaries. Adjust the tracker, skills, and review axes to fit the next project.

Standards vs Spec review: a second agent found duplicate writes past 1,572 green tests

Wed, 22 Jul 2026 21:58:00 +0200

This is what the review agent reported, just before it listed its findings:

The test evidence is clean: Ruff passes, Python reports 1,572 passed / 56 skipped /
1 expected failure, and the GUI reports 418 passed / 4 skipped. The review nevertheless
found safety gaps the tests do not exercise — most importantly, two write clients retry
"500-after-commit" before their advertised idempotency/verification guard can run.

A coding agent had built the branch: 53 commits, 147 files. A different model reviewed it and found two paths that could put the same invoice in the ERP twice and report plain success. No test covered them, and no linter could. They came from a reviewer with one job: check the code against what the branch said it does.

The setup

The repository vendors the two-axis code-review skill from mattpocock/skills . It pins a fixed point and diffs against the merge base, git diff master...HEAD, then forks two subagents in parallel:

Standards: does the diff follow the repo’s documented rules (glossary, ADRs, a baseline of Fowler code smells)?
Spec: does the diff do what the originating issue or PRD asked for?

The parent agent runs lint and tests meanwhile, “as supporting evidence, not as a substitute for the diff review”. It then reports the two axes under separate headings and doesn’t rerank them, so a pile of naming nits can’t bury a P1.

The Spec brief is short:

Report: (a) requirements the spec asked for that are missing or partial;
(b) behavior in the diff that wasn't asked for (scope creep);
(c) requirements that look implemented but where the implementation looks wrong.
Quote the spec line for each finding, under 400 words.

What each axis found

There was no PRD for the branch, so the Spec reviewer used the commit messages and the ADRs. One commit claimed that the MCP server’s idempotency check made it safe to retry a write that got a 5xx. The reviewer traced the call: the check ran before _request(), the key was recorded after success, and the retry happened inside _request(), in between. A webhook worker had the same shape, with a verify-by-GET that ran only if the request finally raised. A retry that succeeds never raises. (The full HTTP 500 story is here .)

The Standards reviewer found something else. Two functions called urlopen() directly, past the shared transport that an ADR says owns all retries. It also found an import that went through a module the ADRs forbid as a re-export facade, and an unfinished vocabulary migration.

None of the Standards findings overlapped with the Spec ones. All six were fixed the same evening, in one commit.

Why the tests stayed green

The tests came from the same author as the claim. No test let a 500 commit the write, let the retry succeed, and counted the writes, because the commit said the idempotency check covered that case. A suite tests what its author thought could break.

The Spec reviewer starts from the claim instead. A commit message says the code is safe, so it goes looking for the line that makes it safe, and here that line ran on the wrong side of the retry.

Two more runs, same pattern

In the next review, a few hours later on a six-commit range, a guard was undone downstream. Every write had to carry exactly one confidence label, and create_* checked that. But when label setup had failed, a fallback further down stripped all labels from the payload. The reviewer reproduced a labeled invoice leaving without its label. It also found a write that went through a raw put() and skipped the scope check that limits which record types may be written at all.

The third review had nothing to go on but commit messages. The branch added a gate: if an invoice is addressed to another company, warn and refuse to post it. The reviewer said it was inferring the spec from the commits, so I pasted the original request and the Spec subagent re-checked against that. The request held a second requirement the commit summary had left out, which turned out to be implemented. The review also found that a replay of staged payloads called the push function directly and skipped the new gate. And while company registration numbers were checksum-validated, VAT IDs relied on regex alone, so one misread digit could block a legitimate invoice. Both failed the first test, then got fixed.

How to use it

Run Standards and Spec as separate subagents, so neither sees the other’s findings, and report them under separate headings.
Give the Spec reviewer the authoritative spec. If you only have commit messages, say so, and swap in the real request the moment you have it.
Treat claims in commit messages and ADRs (“X makes this safe”, “Y owns all retries”) as requirements. They are the cheapest spec you have, and the author’s tests already agree with them.
If you can, review with a different model than the one that wrote the code. It is less likely to share the writer’s blind spots.

Takeaway

A green suite tells you the code does what its author expected. A Spec review by a second agent tells you whether that matches what the author promised. The duplicate writes were in the gap between the two.

Take the last branch your agent wrote, and have a second agent check each “this makes X safe” in its commit messages against the code.