solid-skills ships one skill in ten Markdown files, with the word MIT and no LICENSE

One skill in ten Markdown files, with nothing executable in the tree

The repository top level is `CODEOWNERS`, `README.md` and `skills/`. Inside, the layout is a skill directory and nothing else:

skills/
└── solid/
    ├── SKILL.md           # Main skill instructions
    └── references/        # Supporting documentation
        ├── solid-principles.md
        ├── tdd.md
        ├── testing.md
        ├── clean-code.md
        ├── code-smells.md
        ├── design-patterns.md
        ├── architecture.md
        ├── object-design.md
        └── complexity.md

That is one instruction file and nine reference documents, all Markdown. It matters for reading the feature list, which says the skill enforces the TDD workflow with the failing test written first, detects and fixes code smells automatically, and applies SOLID principles to every class and function. Nothing in that package can detect anything. Those are claims about what the model will do after reading, and the vocabulary of enforcement and automation is doing work the repository structure cannot support.

Methods under ten lines and classes under fifty are the only numbers

Among the key features, exactly two are checkable: keep methods under ten lines and classes under fifty. The rest are qualitative, from using value objects for domain primitives such as IDs, emails and money, to following the Law of Demeter and Tell Don't Ask, to applying SOLID to every class and function. The numeric pair is genuinely useful because it gives a reviewer something to point at in a diff, and it is the sort of rule an agent can be asked to respect while writing. What the documentation does not say is how either number would be enforced or checked. There is no linter configuration, no test directory and no CI configuration in the tree, so whether a ten-line method limit holds is a matter of the model remembering it, and the only signal you would get is reading the result. The principles table above them is mostly prose as well, with TDD named as the red-green-refactor cycle with tests before code, SOLID spelled out in full from Single Responsibility to Dependency Inversion, clean code summarised as meaningful names, small functions and no comments needed, the three families of design patterns, and architecture defined as vertical slicing with a dependency rule. The no-comments-needed line sits oddly in a package whose value is nine documentation files, though it plainly refers to code the agent writes rather than to these.

The trigger list includes writing any code, so there is no off switch

The use-when list has seven entries: writing any code covering features, fixes and utilities, refactoring existing code, planning or designing architecture, reviewing code quality, debugging issues, creating tests, and making design decisions. Read as a whole, that is every engineering task an agent might be handed, and one of them is stated without qualification. Installation is a single line, `npx skills add ramziddin/solid-skills`, after which the documentation says the skills are automatically available and the agent will use them when relevant tasks are detected. So the gating is a detection judgement made by the model itself, and the scope claim starts at writing any code. If you want the skill active on reviews but not on every keystroke, that preference has to live in your own agent configuration rather than in this package.

TypeScript examples, a NestJS mention, and a claim of language independence

The positioning sentence says the skill transforms junior-level code into senior-engineer quality software, primarily designed for TypeScript and NestJS projects, but applicable to any object-oriented codebase. The reference list backs up the first half and not the second. `solid-principles.md` is described as SOLID principles with TypeScript examples, `design-patterns.md` as GoF patterns, and the others as general practice documents with no language named. So the worked examples are TypeScript while the stated applicability is any object-oriented code, and a reader in a Python, Go or Rust codebase is being asked to translate the examples rather than follow them. NestJS is named once, in that positioning sentence, and does not appear in any of the nine reference filenames, which is thin support for naming a specific framework.

The README says MIT and the tree carries no licence file

The licensing position needs two sources that do not agree. A License section at the end of the README says MIT, in one word. The repository's own licence field records nothing, and there is no LICENSE file among the three top-level entries, so nothing corroborates the claim inside the tree. That is a different situation from a repository with a licence file and an unset metadata field, because here the only evidence is prose. It also sits next to a provenance credit that raises a second question, which is the subject of the next section. For anyone intending to copy these reference documents into an internal standard or a commercial codebase, the practical step is to ask the author for the licence text rather than treating a heading as a grant.

clean-code.md credits an external course summary by name, year and company

The credits section says that clean code practices in `clean-code.md` include concepts from a Clean Code course summary by Academind GmbH and Maximilian Schwarzmuller, copyright 2020. The attribution is precise about the source and careful about the scope, limiting the credit to one of the nine reference files rather than the whole package. What it does not attach is any terms. A named commercial course summary is a work with its own copyright, and the credit gives no licence, no link to terms and no indication of what was reused, whether it was paraphrased or copied. Combined with the missing LICENSE file, this means a reader has one unverified licence claim and one acknowledged third-party source with no stated basis, in a package whose selling point is that it codifies somebody else's professional standards.

A repository named plural, one skill, and an unpinned install

The repository is called solid-skills and the documentation heading says Available Skills, but exactly one entry appears under it, a skill named `solid`. SOLID, TDD and clean architecture are reference documents inside that single skill rather than separate installable units, which is a reasonable design and a slightly misleading name. Installation is one command with no version pin, so an install pulls whatever the repository's default branch holds, and there is no GitHub release to pin against. The last push on the default branch is dated 2026-09-03. `CODEOWNERS` is the only file besides the README, and the tree holds no licence file, no tests and no CI configuration, so review ownership is declared but nothing about it is visible in what was retrieved here.

Editorial conclusion

Use solid-skills when you want an agent to be reminded of TDD and SOLID while working in TypeScript, since the reference material is organised and the ten-file layout makes it easy to read the parts you care about and skip the rest. Set expectations about what it is before you install it: this is prose, not a checker, so the line limits and the TDD ordering will only hold as far as the model chooses to follow them. Two things to settle first. The README says MIT while the repository carries no LICENSE file and the licence field records nothing, and `clean-code.md` credits an external course summary by name and year with no terms attached, so both need your own review before the files go into a commercial codebase.

Frequently asked questions

Official sources

1. Issues
2. ramziddin/solid-skills on GitHub
3. README