A design skill suite that publishes what it has not yet verified

Turning one engineer's published design principles into agent skills

This repository reconstructs design judgment principles from a well-known Japanese engineer's publicly available materials, packaging them as skills an AI coding agent can invoke. The first line of the README states it is unofficial, and that it carries no supervision, approval or endorsement from that person or their organisation.

The stated goal is worth quoting because it rules out the obvious misreading. The aim is not to imitate anyone's tone or reproduce their conclusions. It is to make an agent consistently check the problem, the purpose, the context, the requirements, the contracts, the model, the quality attributes and the public boundaries, and to produce reasoned judgments and verifiable artifacts repeatedly.

The repository also separates three kinds of content explicitly: principles extracted directly from the public materials, the schemas, gates and workflows the suite added to make those principles repeatable, and repository policy such as versioning and validators. Keeping the borrowed ideas distinct from the scaffolding built around them is the right structure for a derivative work, and it lets a reader see which parts are interpretation.

The audience is developers using coding agents on design work who have noticed that the shape of the output varies every time the same request is made.

Seven skills, organised by development phase

The suite contains seven skills and the README maps them onto phases rather than leaving you to guess.

Four sit in the design phase. One frames the problem, separating observations, assumptions, purpose and success conditions before any solution is proposed. One audits domain model completeness, looking for missing concepts, states, constraints, failures and authority. One converts natural language requirements into preconditions, postconditions, invariants, failure guarantees and contract tests. One separates the interface a caller sees from the implementation behind it, finding caller-side branching and leaked technical detail.

A fifth covers architecture and quality strategy, for multiple modules, data ownership, system-wide trade-offs, migration and recovery. A sixth carries work end to end from requirements through implementation, review and verification, and is the one to use when two or more of the specialist outputs need integrating. The seventh is a shared core the others draw on and which the README says developers should not select directly.

Each skill produces a named artifact, and the naming is consistent enough to be useful: a framing package, a completeness package, a contract package, a boundary package, an architecture strategy package, and for the integrating skill an implementation specification, a verified change, a review result or a reproduction report.

The README also says when not to use any of it. A small rename, or a mechanical change where the problem and contracts are already recorded as an approved baseline, does not need the suite. Telling users when a tool is unnecessary is a good sign.

The status block is the most unusual thing here

Near the top of the README sits a status readout, and it is more candid than most projects manage anywhere.

Status: Experimental / Preview
Suite version: 0.12.0
Evaluation revision: 0.12.0-r6
Structural validation: 5 CI jobs pass for head d5be04a (merge fcd7e61); documentation correction not rerun in CI
Targeted behavioral evidence: 4 paired inputs against 0.8.0 (180ca1f) and 1 candidate-only negative (9 runs); effective model/settings unobserved
Comparison against PR base develop 0.9.0 (9a2af5e): not run
Behavioral release: not ready

Read what that says. Structural checks pass, and one documentation correction was not re-run through them. Behavioural evidence amounts to four paired inputs and one negative case, nine runs in total, with the effective model and settings unobserved. A comparison against the branch base was not run. And the project declares itself not ready as a behavioural release.

The README goes further, stating that the number of counted runs meeting the release criteria is currently zero, and that structural passes alone do not guarantee the design rules are useful or that behaviour holds across operating systems.

A project that publishes what it has not verified, names which commit each claim attaches to, and refuses to call itself ready is doing something almost nobody does. It also tells you exactly what you are getting: a well-organised set of prompts whose effect on agent output has not yet been demonstrated by its own standard.

Evaluation is versioned separately from the suite

The measurement apparatus is where most of the engineering attention has gone, and its structure is worth describing because it is the part other projects could borrow.

Evaluation inputs carry their own revision numbers, independent of the suite version, with the current revision holding sixty-two cases. Older revisions are retained rather than overwritten, and the README states the meaning of an input is never rewritten in place. Results are not reused across runs whose runtime fingerprint differs, even when the suite version matches.

A behavioural release is defined rather than asserted: an authorised evaluation owner freezes cases and isolated oracles, runs them repeatedly in fresh context, and the results must satisfy gates covering representative cases, negative cases, regressions and every required platform.

The canonical suite version lives in a manifest file rather than being duplicated across documents, and separate evaluation records are kept per revision, with an explicit statement that an older revision's successes are not inherited by the current runtime.

Platform coverage is handled with the same care. Windows, Linux, macOS and a Linux compatibility layer are each described with the shell and filesystem differences that matter, and the README states parity is not treated as verified until every required platform has produced results. Design problems, requirements, contracts and test oracles are shared across systems, with only path separators, shells, line endings, permissions and file locking separated out.

What this means for someone thinking of using it

The honesty is admirable and it does not remove the limitations, which are substantial.

There is no licence file. For a work derived from another person's published materials, that is the most consequential gap, because it leaves both the derivation and the reuse unresolved. Without a licence no permission to use, modify or redistribute has been granted, and the underlying materials carry whatever terms their author set. Anyone considering this at an organisation should stop at that point. This is not legal advice.

The documentation is in Japanese. The skills themselves target technology-agnostic design principles and one embedded composition example is in English, but the README, the phase guidance and the evaluation records assume a Japanese reader.

The effectiveness question is open by the project's own account. Nine behavioural runs with unobserved model settings is not evidence that an agent produces better design work with these skills than without them, and the README says so more plainly than this review could.

Finally, the suite is at 0.12.0 with two releases visible, the most recent on 2026-09-17, and the interface between skills, schemas and gates is exactly the sort of thing that moves before a first stable version.

Writing your own agent instructions is the alternative

Nearly every team using coding agents has already written the alternative: a project instruction file containing the conventions they want followed.

The difference in approach is structure against immediacy. A hand-written instruction file is quick, fits your codebase exactly, and can be changed the moment something annoys you. It is also unversioned prose with no gates, no defined artifacts and no way to tell whether a change to it improved anything, so it accumulates rules nobody has tested and drifts as people add lines.

This suite is the opposite proposition. Skills have entry conditions, produce named artifacts, and are measured against versioned evaluation cases with defined release gates. That machinery is the point, and it is also most of the cost, since adopting it means accepting someone else's decomposition of design work.

For a small team with settled conventions, an instruction file remains the sensible choice and this would be overhead. For anyone who has found that their agent's design output varies unpredictably between sessions, the useful move may be to read how this project structures and measures its skills rather than to adopt the skills themselves, since the evaluation discipline is transferable in a way the Japanese-language design principles may not be.

What the repository actually contains

The tree is small: a skills directory holding the seven skills, a maintenance directory with scripts, the version manifest and per-revision evaluation records, a documents directory holding the source material mapping, an instruction file for agents, editor and attribute configuration, and workflow definitions.

The mapping document deserves a mention because it addresses an obvious question. The README states that source documents were not converted one-to-one into skills. Rules sharing a primary artifact and a reason for change were grouped, and those differing were separated, with a table showing which source themes landed in which runtime skill and why. That is a considered editorial decision rather than a mechanical import, and it is the kind of thing that makes a derivative work defensible on its merits.

The release notes are terse, with the most recent describing an update using a particular tool and the earlier one recording a fix so that checks target only the suite's own skills, plus a correction for scripts that failed on one operating system.

Before doing anything with this, resolve the licence question, since there is no file granting anything, and read the status block rather than the feature list, because the project states its own behavioural readiness better than any summary can.

Editorial conclusion

This suite is worth reading by anyone whose coding agent produces design work of inconsistent shape between sessions, though what transfers most readily is its evaluation structure: versioned input revisions, frozen cases, isolated oracles and per-platform gates. Do not bring it into an organisation as it stands, because the repository has no licence file and the work derives from another author's published materials, leaving both the derivation and your reuse ungranted. Read the status block before the feature list, since the project states its behavioural release is not ready, its counted qualifying runs stand at zero, and its behavioural evidence amounts to nine runs with the effective model settings unobserved.

Frequently asked questions

Official sources

1. Issues
2. my-take-dev/inspired-mino-design-skills on GitHub
3. README
4. Releases