Every skill in this collection states what it will not do

Every skill description ends with what it will not do

The pattern is consistent enough to be the design. Reading down the catalogue, each purpose line closes with a boundary. The product requirements builder edits product docs only. The interaction design builder designs flows and mockups and does not implement UI code. The system design baseline builder edits architecture docs only. The current architecture documenter documents from implementation evidence and does not propose a target or audit fitness. The system design proposal builder does not plan tasks or implement. The architecture decision recorder records one decision and does not design the whole system. The diagram builder produces architecture diagrams, not UI design. The migration planner plans migrations and does not execute them. The delivery plan builder is read-only.

This is the opposite of the usual skill description, which states capability and stops. Here the capability is half the sentence and the refusal is the other half, which makes two things true at once: an agent picking a skill knows what it will be asked to do, and a reviewer can see the scope the author intended.

It also makes the collection composable. The stages do not overlap, so asking for a design does not drag implementation along with it, and the page says as much: combine only the steps needed to resolve decisions and produce evidence.

The premise behind all of it is stated at the top in three sentences: you ask for a fix and get a new abstraction, a review lists generic advice, and the agent says done while you still have to work out what it checked.

The numbers in the name encode a position, not a rank

Skill directories are prefixed with an identifier that maps onto a numbered lifecycle. The product discovery family occupies 11, 12 and 13, for opportunity evaluation, requirements and interaction design. The architecture family runs 21 through 26, from baseline through migration. Delivery planning starts at 31 and 32. Implementation starts at 41, where the documented example lives: `/implementation-suite:ln-41-surgical-change-implementer`.

The lifecycle is drawn as seven stages with a feedback loop: product discovery, architecture, delivery planning, implementation, quality assurance, delivery, operations, with product feedback, architecture changes and operational remediation feeding back into the earlier stages. An eighth family, skill maintenance, supports the collection itself rather than any product work.

So the digits are coordinates. They tell you where in the sequence a skill expects to be invoked and roughly which family it belongs to, which makes a long directory listing navigable. What they do not do is rank quality: 41 is not better than 26, it comes later.

The `ln-` prefix itself is the author's, and it is consistent across every family, so a skill copied out of context into a chat session still carries its family and position.

Three commands in Claude Code, two in Codex, two invocation forms

Installation is a marketplace add plus a plugin install, and the syntax differs by client.

/plugin marketplace add levnikolaevich/claude-code-skills
/plugin install implementation-suite@levnikolaevich-skills-marketplace
/reload-plugins

codex plugin marketplace add levnikolaevich/claude-code-skills
codex plugin add implementation-suite@levnikolaevich-skills-marketplace

Note that the repository you add is `levnikolaevich/claude-code-skills` while the marketplace that gets created is named `levnikolaevich-skills-marketplace`, and the plugin is addressed as `implementation-suite@levnikolaevich-skills-marketplace`. Three names for one install, which is fine once and annoying while debugging.

Invocation is where the two clients diverge most. In Claude Code a skill is called by its plugin-qualified name, `/implementation-suite:ln-41-surgical-change-implementer`, and in Codex the same skill is called with a dollar sign and no plugin prefix, `$ln-41-surgical-change-implementer`. The page's example task is a behavioural one rather than a file location, fix the total calculation when an item has a discount and preserve the current rounding rules, which is a reminder that the skills are written around outcomes.

Claude Code also needs the extra reload step after installing; Codex does not.

The repository is a marketplace, not a folder of loose skills

The tree explains the packaging. `.claude-plugin/` holds the marketplace manifest, `plugins/` holds one directory per suite with a `skills/` folder inside, and `.agents/` sits alongside for agent configuration. There is also `SKILL_TEMPLATE.md` at the root, `scripts/`, `docs/`, `AGENTS.md` and `CLAUDE.md`, and both an `.editorconfig` and a `.gitattributes`.

That structure is what makes the per-suite negative scope clauses enforceable in principle: a skill's own `SKILL.md` is where its boundary sentence lives, and the paths in the catalogue point at those files directly, for example `plugins/architecture-suite/skills/ln-22-current-architecture-documenter/SKILL.md`.

The recorded primary language for the repository is PowerShell, which is worth noting because almost nothing in the visible material is PowerShell. The catalogue is Markdown, the installers are client commands, and the scripts directory is not described in the visible text, so whatever drives generation or release sits in a language the page does not cover.

The repository is MIT licensed and defaults to the `master` branch rather than `main`, and the project's own site lives on GitHub Pages with a separate project page linked from the header.

One suite exists to review the collection's own instructions

The routing table has eight rows, and seven of them map a kind of problem onto a suite. Is this idea worth building goes to the product discovery suite. How should this system change goes to architecture. Is this plan ready to implement goes to delivery planning. Fix, upgrade, simplify or speed up this code goes to implementation. What could go wrong with this delivery or codebase goes to quality assurance. Get this change published or deployed goes to delivery. Why did this fail, or did the feature help, goes to operations.

The eighth row is different: can I trust the instructions in this skill goes to the skill maintenance suite, whose stated result is a review of its boundaries, consistency and distribution readiness.

So the collection contains a reviewer for itself, and that reviewer's subject is exactly the property the rest of the catalogue relies on. If a skill's boundary clause is wrong or its packaging is inconsistent, that is what this family is for, which is a coherent answer to the failure mode most skill collections have, namely nobody re-reading the instructions after the first few hundred uses.

It is also the only family that is not part of the product lifecycle diagram's arrow sequence, which suggests it is treated as maintenance of the artifact rather than as a stage of delivery work.

Releases are dates, and the first one shipped a day after its name

The tags are calendar dates rather than semantic versions: v2026.04.21, v2026.05.06 and v2026.07.12. Two of the three were published on the date in their own name, v2026.04.21 on 2026-04-21 and v2026.05.06 on 2026-05-06, and the third was published on 2026-07-13, the day after the date in its tag.

For a collection of prompt-shaped files, a date tag is a defensible choice: there is no library API to break, and a date tells you how fresh the instructions are. The cost is that a date cannot express anything about the change itself, so the tag tells you when and not what, and the July release being a day late is invisible unless you cross-check the two timestamps.

The last push to the branch is dated 2026-09-16, roughly two months after the most recent tag, so the branch contains work that no release names.

That gap matters more than usual for this kind of repository, because a skill's value depends on its instructions being current for the tools it drives, and there is no published indication of which release the default branch corresponds to.

The bet is that a verdict should show the checks behind it

The stated change in workflow has four parts, and they are worth separating because only some of them are about prompts.

A clearer target means turning an idea, a bug report or an incident into an outcome the agent can check. Focused work means reusing existing capabilities, fixing the owning cause, and removing what the change makes obsolete, which is aimed at the new-abstraction failure in the opening line. A result you can assess means seeing the evidence, the checks that failed or were unavailable, and the remaining risks behind the verdict, which is aimed at the unassessable done. And control over consequential actions splits the verbs apart: reviews report findings, implementation stays inside the agreed scope, and publication and deployment follow their authorization boundaries.

That last split is the one that most affects a team. It makes publishing a distinct step from implementing, and it means the point where a human authorises something irreversible is a skill boundary rather than a habit.

Two supporting notes make the collection usable in pieces rather than as a pipeline. Supplied requirements, existing designs and current tests are stated to be valid starting points, so the skills do not demand a blank page. And implementation includes its own verification, with a separate test-building or review skill marked optional.

Editorial conclusion

Use it if your agents produce plausible work you cannot audit, since the value here is the negative scope each skill declares rather than the prompts themselves. Install one family rather than the lifecycle, because the collection says a small fix does not need a full pass. Two things to check first: the catalogue numbers skills by lifecycle position, so the numbering tells you where a skill expects to be used rather than how good it is, and the plugin names you type are `suite` names that resolve to a specific skill inside, which is worth doing once by hand before adopting the habit.

Frequently asked questions

Official sources

1. levnikolaevich/claude-code-skills on GitHub
2. License: MIT
3. Project website
4. README
5. Releases