Plugin repository
This repository gathers the Claude Code plugins I use on my projects and share with my team: for Spring, React and Flutter, they describe the roles of architect, developer, tester and release owner, as well as the way each one hands over to the next.
- Role
- Main author; a second contributor originated the Flutter plugin
- Period
- Since September 2026
- Status
- In service. Five plugins and nineteen skills, used on Sanu
- Technologies
- Claude Code, Markdown, JSON, bash
- Repositories
- One
Context
A Claude Code plugin groups skills, that is, written instructions that the assistant loads when a request concerns them. The repository contains five of them: one for product work, three for the Spring, React and Flutter stacks, and one specific to Sanu. It holds no application code, only Markdown files, JSON manifests and two scripts.
These instructions are addressed to an assistant, and most of them were written with it, as the co-author line carried by most of the repository’s commits shows.
Problem
A single instruction, which mixes structure, code, tests and delivery, leads the assistant to decide again, at each step, what had been decided at the previous one, so that two architectures end up coexisting in the same repository. A summary passed from one step to the next also turns an assumption into a fact, without anyone having checked it. Finally, a piece of work declared finished had to be so on evidence and not on an assertion.
Answer
Roles that do not overlap
Each stack has the same five roles. The architect sets the structure and the rules, the developer writes inside those rules, the tester writes the tests and gives the verdict, the release owner builds and ships, and the orchestrator classifies the request then drives the chain. A decision settled by one role is not reopened downstream, and the description of each skill also states what it does not cover, naming the skill that handles it.
A verifiable hand-off
A role ends with a block of fixed fields, which is copied as is into the context of the next role. Every fact about the repository or the contract cites its source there, namely a file and a line, failing which it is filed among the assumptions, phrased so that a reviewer can refute them in a word.
It travels verbatim. Copied into the next role's context, into the next subagent's
prompt, and into the final report. A paraphrased block is how an assumption written
carefully by one role becomes a fact in the next.
Every fact about the contract, the backend or the repository names its source, a file
and a line or a schema path, or it is listed under assumptions. Assumptions are phrased
so a reviewer can refute each in a word.
A field with nothing in it says `none`, so the next role knows it was considered and
not forgotten.A two-word verdict
Each stack has a single verification command, the same on the workstation and in the pipeline. The tester concludes with one of two words, GREEN or BLOCKED, accompanied by the output of that command, and a chain interrupted before reaching the tester declares itself built but not verified. Parallel work, for its part, requires a plan settled beforehand by the architect, which assigns each slice its files, names the owner of each shared file and sets the merge order.
Rules revised through use
The rules change when their cost becomes visible. The requirement of 100% coverage on all Flutter packages was thus brought down to two tiers, after one feature took about 1,700 lines of tests for 500 lines of code. These plugins have been used on Sanu, whose Flutter architecture document is written by the architect role and frozen before the code that depends on it.
Limits and outlook
Nothing checks that a skill triggers on the right request nor that it produces the expected behaviour: the repository has neither an evaluation set nor a pipeline, and its only evidence of effect lies in the Sanu repositories. The figures quoted in the instructions are moreover observations, and not recorded measurements.
A plugin’s version appears in three places that are kept in agreement by hand, and it has already drifted. The three stacks also repeat a large part of their text, since a skill never refers outside its own directory, so that a shared change has to be carried over three times. Finally, the repository is only one month old, and I am the author of nearly all its commits: sharing with the team is for the most part still to come.