# skills packages agent instructions as installable markdown files

> The suleimanodetoro/skills repository collects eight agent skills covering interface design, React, React Native and software security, split into four build skills that may change code and four read-only review skills. It suits developers who want a reviewable checklist for agents working in their own codebase, and it is a set of prompts rather than a tool.

**suleimanodetoro/skills** — Agent skills for interface design, React, React Native, and software security.

- Repository: https://github.com/suleimanodetoro/skills
- Stars: 770 · Forks: 10
- Language: Python
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/suleimanodetoro-skills

## A repository of prompts, not a library

The suleimanodetoro/skills repository describes itself as a collection of agent skills used to design and ship software, covering interface design, React, React Native and security. What that means concretely is visible in the tree. The top level holds a .gitignore, an AGENTS.md, a LICENSE, the README, an old-notes/ directory and a scripts/ directory, and the bulk of the content sits under skills/. Inside skills/ there is one directory per skill, and each one contains a file called SKILL.md. So the unit of this project is a markdown document that an agent reads as instructions, not a package with an API, no build output and no runtime dependency. The primary language listed for the repository is Python, which reflects the scripts and tooling around the collection rather than any library API. For a reader deciding whether to adopt this, the right question is not whether it is technically sound but whether the author writes prompts that match how you want work done.

## Each domain gets one build skill and one review skill

The collection is deliberately paired, and the README states the design directly: each area has one skill for making the work and another for reviewing it. The eight entries are named so the pairing is obvious. The design area has $design-interface for building product interfaces and $review-interface for reviewing the rendered experience. React has $engineer-react and $review-react. React Native has $engineer-react-native and $review-react-native. Security has $secure-software for threat modeling features and building security in, and $review-security. The naming convention is part of the interface. A skill is referenced by its dollar-prefixed name, and each README entry links to the file that defines it, for example skills/review-react/SKILL.md. That gives you a link to read before installing, which is the single most useful thing about the layout. The eight descriptions are short enough to read in a minute, and they already tell you the intent of each one, which is enough to decide whether the collection is relevant to your work before you go deeper.

## The review skills are read-only on purpose

The README draws a line that the whole design depends on. The build skills can change code, and the review skills investigate, verify, and return findings without quietly fixing anything. The review skills are described as deliberately read-only. Each review description reinforces that. $review-interface is to review the rendered experience with evidence, not taste alone. $review-react covers React correctness, architecture and runtime behavior. $review-react-native covers JavaScript and native behavior across both platforms. $review-security reports only reachable risks that matter, and only with concrete evidence. The wording matters for how you use these. A review skill that edited files would be a safety hazard, because an agent that changes code while claiming only to review it produces changes nobody approved. Here the expected output is a set of findings, and the fix is a separate decision that a human takes. If you use a build skill and a review skill in the same session, the separation is what stops the review from becoming an unreviewed rewrite.

## Installing the collection

The installation path is a single command through a package runner, and the README gives it under Install:

```bash
npx skills@latest add suleimanodetoro/skills
```

That is the whole instruction. The npx invocation pulls the latest published version of the skills tooling and passes it the repository reference, so the collection is installed from GitHub rather than from a registry package with its own release history. Two things follow from that. First, you are installing a moving reference rather than a pinned artifact, since the repository has no GitHub releases and no version numbers to lock onto. Second, the agent runtime has to know how to find the installed skills, which is a property of the tooling and your agent setup rather than of this repository. The repository does not document the target directory, the discovery mechanism or an update command, so if your runtime expects skills in a particular location, confirm that before you assume the install landed where your agent will look.

## What is in the tree beyond the skills

Three things sit outside skills/ and are worth a look before you adopt the collection. The first is AGENTS.md at the repository root, which is the conventional place for instructions that apply to an agent working in a repository. That tells you the author is working in the same ecosystem where such files are read, and it may explain how the skills are expected to be invoked. The second is scripts/, which suggests there is tooling around the collection rather than only prose. The third is old-notes/, which the README describes as notes that used to live in this repository, specifically interview-study notes, now moved there and outside the skill collection. The archived notes section is a small honesty signal. It tells you the repository was repurpose rather than purpose-built, and it names exactly what was moved out, so you know what you are not getting. The skill collection also keeps its own boundaries narrow on purpose, and the removal was made visible rather than left as an unexplained directory of unrelated text.

## Where a prompt collection stops and engineering starts

The limitation is the nature of the artifact. These skills are instructions for an agent, so their quality is judged by whether they change behaviour, and the repository gives you no way to measure that. There is no test suite, no benchmark, no list of the errors the review skills are known to catch, and no record of the ones they miss. The security pair in particular needs care. A $secure-software skill is described as threat-modeling features and building security into them, and $review-security as reporting only reachable risks that matter, with concrete evidence. That is a good discipline to ask for in a reviewer, but a review skill can still miss what it does not look for, and nothing in the repository enumerates what it looks for. Treat the findings as a second pass over your own review, not as a substitute for one. The same applies to $review-interface, which asks for evidence rather than taste, since whether the evidence is the right evidence is a judgement the reader still has to make.

## The alternative is writing your own review checklist

There is a reasonable alternative that many teams already have, and it is worth comparing honestly. Instead of installing eight skills, you write your own review instructions into an AGENTS.md or a similar file in the repository, listing the checks you care about for that codebase. The difference in approach is specific. A local checklist is written against your code, your conventions and your past incidents, so it can name the pattern that bit you last quarter. A shared skill collection is written against the author habits, and the value in it is a second perspective that is not your own, which is exactly what a review skill is for. The two are not exclusive and there is no reason they cannot coexist, since a review skill that disagrees with your checklist is a useful signal rather than a conflict. The decision comes down to where your review burden lies. If your team keeps finding the same class of problem in review, encode it locally. If the problem is that reviews are inconsistent or skipped, a written skill from someone else is more likely to be followed because it is not yours to remember.

## Maintenance state and licence

The repository is not archived, and the last push was on 2026-07-30, so the collection has been touched within the last few months. There are no GitHub releases, which means no changelog to read before an update and no version to pin in a script. That is the main upgrade risk. Because installation is by repository reference, a reinstall or a refresh can pick up rewording in a skill you had already tuned, and there is no way to see what changed short of reading the diffs yourself. That is manageable when the skills are markdown, and it is exactly why the README links each skill to its file. The licence is MIT, referenced from the LICENSE file, which means you can read the collection, adapt a skill to your own conventions, keep those changes, and use the modified version internally without asking. For prompts rather than code, that permission matters less than it would for a library, but it removes one reason not to fork a single skill out into your own repository.

## Conclusion

Adopt skills when you want a second opinion on interface, React, React Native or security work inside an agent session, and when you are comfortable reviewing the markdown yourself before letting a review skill read your source. Do not adopt it as a security tool, since it reports findings rather than proving them, and do not expect a versioned dependency you can pin. Verify first that the review skills match the way your team wants findings reported, that your agent runtime reads skills from the directory layout the installer expects, and that nothing in the collection replaces your own threat model before you merge a change.

## FAQ

### How do I install the skills in the suleimanodetoro/skills collection?

The README gives one command: npx skills@latest add suleimanodetoro/skills. The collection is installed from the GitHub repository rather than from a released package, and the repository publishes no GitHub releases to pin a specific version to.

### What is the difference between the build skills and the review skills?

The build skills, such as $design-interface, $engineer-react, $engineer-react-native and $secure-software, can change code. The review skills are deliberately read-only, investigating and returning findings without quietly fixing anything.

### Which areas do the skills in this collection cover?

Four areas: interface design, React, React Native and software security. Each area has one skill for making the work and one for reviewing it, for eight skills in total.

### Can I modify a skill from the collection for my own team?

The repository is published under the MIT licence, and each skill is a markdown file such as skills/review-react/SKILL.md, so you can read it, adapt it and keep your changes internally.

## Sources

- [Issues](https://github.com/suleimanodetoro/skills/issues)
- [License: MIT](https://github.com/suleimanodetoro/skills/blob/main/LICENSE)
- [README](https://github.com/suleimanodetoro/skills/blob/main/README.md)
- [suleimanodetoro/skills on GitHub](https://github.com/suleimanodetoro/skills)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/suleimanodetoro-skills