# 640-skills: a rule and Skill source for evidence-driven agent work

> The repository is not an application but a configuration source, fourteen bundled and nineteen required external Skills, an Onboard package that installs them, and a set of natural language prompts that make the agent report what it wrote, and the discipline of the whole thing is in the vocabulary of the commands rather than in the code.

**KunoLu/640-skills** — Agent Skills for Solopreneurs & Teams.

- Repository: https://github.com/KunoLu/640-skills
- Stars: 550 · Forks: 13
- Language: Python
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/kunolu-640-skills

## A configuration source, not an application

The repository is described as reusable agent rules, skills and onboarding for evidence-driven development, and the description line calls it Agent Skills for Solopreneurs and Teams. The readme states the nature of the thing plainly: this repository is a configuration and Skill source, not a business application.

That distinction matters, because it tells you what you get and what you do not. You get rules that tell a coding agent how to work, a set of Skills that do particular jobs, an Onboard package that installs and initialises them, and prompts you paste into your agent. You do not get a service, a library to import, or a runtime that sits between you and your model.

The primary language is Python, but that is a detail of the Onboard tooling, which validates contracts, state and migrations, rather than a description of what the repository does for you day to day. The licence is Apache-2.0.

The main workflow targets Codex and Oh My Pi, and the installers also expose adapters for Claude Code and Kimi. The readme is careful about what that means, noting that adapter availability is not proof of identical host behaviour, which is a sensible warning for anyone about to assume the same prompt will behave the same way in a different agent host.

## The SBTD framing: specifications, behavior, tests, domain language

SBTD connects specifications, behavior, tests and domain language, and the readme summarises the division of labour in one line: your coding agent does the work, and the workflow makes scope, permissions and verification explicit.

Those four words are the actual content of the project. The idea is that a specification and the code that implements it, the tests that check the behaviour, and the vocabulary of the domain all refer to each other, and that an agent asked to change one of them should notice the others. A change to a behaviour that is not reflected in the specification, or a test that keeps asserting the old behaviour, is the kind of drift the workflow exists to prevent.

The second half of the sentence is what makes it usable rather than aspirational. Scope is explicit, so the agent knows what it is allowed to touch. Permissions are explicit, so the agent asks rather than assumes. Verification is explicit, so a claimed change is a change that was checked.

That is a design philosophy rather than a feature list, and it explains the shape of everything else in the repository. The prompts are not commands, they are requests written for a model, and the installation steps are instructions to an agent rather than a sequence of shell commands.

## Installing the Onboard skill from a pinned tag

The install path starts with a prompt you paste into your coding agent, and the prompt is written with the same discipline as the rest of the project. It asks you to install only the sbtd-workflow-onboard skill from the KunoLu/640-skills v2.0.1 tag, into the user level global Skills directory for Codex and not the current project, to resolve that revision and verify it exists, not to substitute main or a v1 package silently, to use the official skills CLI and copy the full directory, to show the resolved source and target, and not to run init or reset, install other tools, or change the AGENTS or MCP configuration yet.

The terminal route uses the official Skills CLI, with the skill name, the global flag, the agent and the copy flag.

```bash
npx --yes skills@latest add https://github.com/KunoLu/640-skills \
  --skill sbtd-workflow-onboard --global --agent codex --yes --copy
npx skills list --global --agent codex
```

Two warnings in the readme are worth repeating. The skills@latest selector picks the CLI version, not a Skill release, and an unpinned repository source reads the default branch rather than the latest tag. The pinning syntax is given as a repository, a reviewed ref and the skill name, with the reviewed ref replaced by an existing v2 tag or a reviewed commit, and the instruction is to follow that revision's documentation.

The other warning is about mixing generations. Do not combine a historical v1 package with the v2 setup prompts, because its initialization may install or invoke the retired Trellis or GitNexus workflow, and for v1 data the migration prompt is the route instead of init or reset.

## Bootstrap is not setup, and the readme is explicit about it

The phrase bootstrap is not setup appears as a heading level warning, and the list of what the Onboard package does not do is the most useful paragraph in the install section.

It copies the self-contained Onboard package. It does not execute onboard.py, it does not install the remaining Skills, it does not install the Python dependencies, it does not configure MCP, and it does not initialise projects. In other words, the first step gives you the tool that performs setup, not setup itself.

Two details follow from that. The readme tells you to find the actual installed directory rather than assuming a path under HOME, which is the sort of instruction that saves an hour when the installer decides where things go. And for OMP or another host it tells you to confirm the supported Skills CLI agent identifier and the discovery path instead of assuming that Onboard's platform name is the identifier the CLI expects.

The Onboard package also needs Python 3.10 or newer and its declared dependencies, because it uses them for contract, state and migration validation, and the dependency install is its own step with its own review gate.

```bash
python -m pip install -r /path/to/installed/sbtd-workflow-onboard/requirements.txt
```

The second stage is the review and initialise step, and it is again a prompt rather than a command. You give it the absolute project roots separated by English commas, the target platform, and it checks the installed package's Python dependencies and shows a plan as JSON covering global Skills, global AGENTS and host or MCP targets, asks before installing missing prerequisites or applying the plan, and after approval runs init and reports each project's writes, backups, skipped checks and remaining actions.

For OMP you use omp instead of codex, and a normal setup installs the fourteen bundled and nineteen required external Skills globally, while optional tools keep their own confirmation gates.

## Eight management paths, and they are not interchangeable

The usage section presents a table of goals and the command that serves each, and the descriptions are careful to say what a command does not do.

Check and plan are for inspecting without installing, giving a read only inventory and the proposed work, and the table notes that this is not proof that setup ran. Init is the first full setup, installing missing or invalid Skills and preserving valid Skill shells, though not necessarily their current content. Init-projects adds a project only, writing project AGENTS and ignore files and applicable local assets, with no global installation and no user MCP or hooks.

Upgrade aligns an existing environment with a fixed baseline through a plan, apply and verify cycle, with explicit drift decisions, backups and recovery. Reset deliberately reinstalls, overwriting the bundled Skills without a backup and reinstalling the required externals, and the table is explicit that it is not an upgrade recovery protocol. Migration moves legacy data with approved projections, retained originals and verified receipts, under a separate deployment authorization, and an interrupted deployment is reconciled from the current state and never backfilled. Cleanup-legacy retires detected legacy assets, displaying the actual candidates and then obtaining separate execution consent. Recovery restores an authorised batch from trusted batch evidence, and it is not a general undo command.

That taxonomy is the clearest statement of the project's philosophy. There is a read only path, a dry run, a first setup, an upgrade path with backups, a destructive reinstall that is explicitly not a recovery, a migration path, a cleanup path with its own consent, and a recovery path restricted to trusted evidence. A tool that names its destructive operation and says what it is not for is unusual, and it is why the readme spends more space on the semantics of the commands than on the contents of the Skills.

One thing to note about usage in general: the prompts are natural language requests to your agent, not new CLI commands, with bracketed inputs and absolute paths to be replaced, and the agent is instructed to read local facts first and ask only for missing choices or required authorisation.

## The write scope is the part to read before running init

The most operationally important paragraph in the readme is the one about write scope, and it is easy to skip because it sits in a callout rather than in the install steps.

A normal init or reset writes global Codex rules by default. It also backs up and overwrites the file at ~/.omp/agent/AGENTS.md when the ~/.omp directory already exists. Selecting a platform does not select the global AGENTS destination, which is a confusing sentence until you notice that the platform choice and the destination choice are two separate decisions that the tool does not tie together.

The mitigation is documented. The --global-agents-path option changes only the Codex target, and there is a project only mode for the case where global writes are not wanted.

That is the whole point of the checks and the reporting. The agent is asked to show a plan as JSON before it acts, to ask before installing prerequisites, and to report afterwards what it wrote, what it backed up, which checks it skipped and what remains. For a workflow that edits files inside your home directory and inside your projects, that reporting is the feature, and the permission model is deliberately conservative rather than convenient.

The readme also separates the evidence layers, noting that code, CI, installation, native checks and actual host acceptance are separate things, and that publishing a tag does not upgrade your environment. The stable v2.0.1 release is called out as released, with the catalog holding fourteen bundled and nineteen required external Skills, and the delivery plan and acceptance boundaries are set out in a document under docs/prd.

## Licence, releases and the shape of the repository

The licence is Apache-2.0, stated in the badge row and carried in the LICENSE file, so the rules, the Skills and the installers can be used and modified with the notice kept. This is not legal advice.

The release history is recent and quick. Version 2.0.1 was published on 2026-10-14, 2.0.2 on 2026-10-15 and 2.1.0-rc.1 on 2026-10-17, and the last push to the default branch was on 2026-10-20. The repository is not archived, and the presence of a release candidate so soon after two patch releases says the 2.1 line is still moving.

The repository layout is the interesting part for an adopter. There is an ai directory, an archive directory, a docs directory, a prompts directory, an sbtd-runtime directory, the sbtd-workflow-onboard package itself, and a tests directory, alongside install.sh and install.ps1 for the two platforms, an ENTRYPOINT.md, and a CHANGELOG.md with a Chinese counterpart, mirrored by a Chinese README. The archive directory is what the migration and cleanup-legacy commands exist to move away from, which is consistent with the readme's warning about the retired Trellis and GitNexus workflow in v1 packages.

The bilingual documentation is a real feature rather than a courtesy. The readme and the changelog both exist in English and Simplified Chinese, and the install prompts themselves are written in English, which tells you the intended agent interaction language.

For a team evaluating this, the reading order is the readme's own: the install prompts, the write scope paragraph, and then the management table. The rest is in the linked reference documents, and the acceptance boundaries document is where the project is most honest about what it does and does not guarantee.

## Conclusion

640-skills is worth reading for anyone building an agent workflow where the instructions, the tests and the domain language are supposed to stay connected, and it is a usable starting point for a team that wants its coding agent to be explicit about scope, permissions and verification. It is the wrong tool for a project that wants one prompt and a finished setup, because the Onboard package deliberately does not install everything. Before adopting, pin a reviewed tag rather than a branch, read the write scope section before you run init, and treat the eight management paths as distinct operations rather than as a single setup command.

## FAQ

### What is the 640-skills repository?

It is a configuration and Skill source rather than a business application, providing reusable agent rules, skills and onboarding for evidence-driven development. The SBTD workflow connects specifications, behavior, tests and domain language, and the catalog holds 14 bundled and 19 required external Skills.

### How do I install the Onboard skill from 640-skills?

The documented path uses the official Skills CLI, adding the repository with the sbtd-workflow-onboard skill, the global flag, the agent and the copy flag. The readme stresses that the source must be pinned to a reviewed tag or commit, because an unpinned repository source reads the default branch rather than the latest tag.

### Does bootstrapping the Onboard skill complete the setup?

No. The readme states that bootstrap is not setup: it copies the self-contained Onboard package and does not execute onboard.py, install the remaining Skills or Python dependencies, configure MCP, or initialise projects. Reviewing and initialising selected projects is a separate step.

### What files does a normal init or reset write?

A normal init or reset writes global Codex rules by default and also backs up and overwrites ~/.omp/agent/AGENTS.md when the ~/.omp directory already exists. The --global-agents-path option changes only the Codex target, and a project only mode exists for setups where global writes are not wanted.

## Sources

- [Issues](https://github.com/KunoLu/640-skills/issues)
- [KunoLu/640-skills on GitHub](https://github.com/KunoLu/640-skills)
- [License: Apache-2.0](https://github.com/KunoLu/640-skills/blob/main/LICENSE)
- [README](https://github.com/KunoLu/640-skills/blob/main/README.md)
- [Releases](https://github.com/KunoLu/640-skills/releases)

---

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