@openreachtech/hora
Advanced tools
Hora Kit: a package that distributes AI skills, agents, and docs for AI-driven application development.
Hora builds an application from its spec, one feature at a time, through an AI agent tool.
This package is the container that carries its core — the skills and agents that tool reads — to the repositories that build with it.
A new project does not install it by hand. It starts from a GitHub template, and which one depends on what it builds: hora-boilerplate for a web project, hora-boilerplate-mobile for a native Android or iOS one. Each declares this package and the skill libraries its stack needs, places them on npm install, and holds the documentation for the kit as a whole — what a project built with it contains, what each command does, and how to put it on a repository that already exists. The method is the same either way; what differs is the stack, the origin catalog, and which skill libraries a row equips. What follows here is for equipping the kit into a repository that came from neither template.
Everything it ships lives under a single directory, kit/, laid out the way an agent tool expects to find it:
kit/
├── agents/ subagent definitions
└── skills/ skill definitions
kit/ is named after what it holds rather than after any one tool, so the same payload can be delivered to whichever agent tool a repository uses. The target documented here is Claude Code, whose configuration directory is .claude/.
What npm publishes is dist/, built from kit/ on every pack. The two trees are identical, so the layout above is also the layout of the installed package.
Alongside it the package carries one executable, and its only job is to place that payload into a repository. There is nothing here to import.
How Hora itself works — the method this kit carries — is documented under docs/: the quickest route from an empty repository to a spec, what each command does, how the orchestrator runs, putting it on a repository that already exists, the emergency route, the parallel route, and the writing style these documents are held to.
Requires Node.js 20.0.0 or newer, the floor engines declares. The CI builds against the current LTS.
npm install -D @openreachtech/hora
This package ships no install script of its own, so adding it as a dependency installs the package and places nothing. Declare the command as your own project's postinstall, and npm install alone equips the repository:
{
"scripts": {
"postinstall": "hora-core install"
}
}
A project's own scripts are outside what npm holds back from v12 on, so this asks nothing of whoever clones the repository. npx is not needed here either: a lifecycle script runs with node_modules/.bin on its PATH.
The hook you just declared takes effect from the next npm install on, so run the command by hand for the first placement — and for a one-off, or a repository that is not yours to add a hook to:
npx --no hora-core install
--no stops npx before it downloads: the name is still resolved against the registry, but nothing is fetched, so neither the install script nor the bin of a stranger's package ever runs. Without it, a bin that is not installed becomes a fetch of whatever has been published under hora-core, an unscoped name this package does not hold.
Where the package is not a dependency at all — a one-off, or a repository that is not yours to add a hook to — name it in full instead: npx --package=@openreachtech/hora hora-core install. What is fetched is then a scoped name nobody else can publish under, which is the guarantee the unscoped bin name never carried.
The kit lands in your repository's .claude/, the directory an agent tool reads from — dist/agents/ at .claude/agents/, dist/skills/ at .claude/skills/. A package's own directory is never on that path, so this clone is what makes the kit visible. The skills are then invocable as slash commands, /hora, /hora-plan, /hora-build.
Every directory of dist/ is carried into the directory of the same name, and what that directory already holds is left in place. A skill your own repository authored sits beside the installed ones, untouched, as long as its name is not one this package distributes.
.claude/, and the payload directories inside it, have to be directories of your repository rather than symbolic links. An installation verifies every step it is reached through, and finding a link at any of them it writes nothing and removes nothing. .hora/equip-core.json, the record of what was installed, is verified the same way: a link there would send the write to whatever it stands for and overwrite it.
An installation that carries nothing says why and ends with a failing exit code. Where the command runs as your project's own postinstall, that is what npm install reports; run on its own, npx --no hora-core install tells you the same.
A link is content of the repository rather than an instruction of whoever runs the command, so following one would let the repository decide where entries are written and, worse, where the entries of the previous run are removed from.
Where .claude/ as a whole points at a directory shared between repositories, name that directory instead — npx --no hora-core install --dir <the directory it resolves to> reaches the same state, and the link still makes the kit visible at .claude/. Where a single payload directory is the link, no arrangement installs into it: --dir names the directory holding the payloads, never one of them. Replace it with a directory of its own.
The installed kit is this package's build output rather than source of your repository, so ignore it, and name your own back in:
.claude/agents/*
.claude/skills/*
!.claude/skills/my-own-skill/
.hora/*.json
.hora/wings/
.hora/addons/
Matching on the whole directory rather than on a name prefix is deliberate: what this package distributes changes with every release, and a pattern written against today's names goes stale without saying so.
Of .hora/, ignore only what the installers write: .hora/equip-core.json, this package's record of what it installed, the record every other installer keeps beside it, and the wings and definitions an add-on's installer places. Every install regenerates them. The rest of .hora/ — .hora/tasks/, .hora/addon/config.json and the other records the skills write — is the state of your project, and is committed.
An npm install with no arguments re-runs your project's postinstall, so the kit follows along. Naming the package on the command line — npm install @openreachtech/hora@latest — does not, and neither does a repository without a hook. Run the command again yourself:
npx --no hora-core install
install is repeatable: it removes what the previous run installed — recorded in .hora/equip-core.json — along with anything named after an entry this package distributes, before copying the current kit. A renamed or dropped skill therefore leaves nothing behind, and a repository that had copied dist/ by hand is tidied up on its first run.
| Command | What it does |
|---|---|
hora-core install | Install the kit, replacing what the previous run installed |
hora-core list | Print the entries the kit installs, installing nothing |
hora-core uninstall | Remove every entry this package installed, along with the manifest |
hora-core help | Print the usage text |
--dir <path> installs into a directory other than .claude.
Bug reports, feature requests, and code contributions are welcome.
Feel free to contact us through GitHub Issues.
git clone https://github.com/openreachtech/hora-core.git
cd hora-core
npm install
npm run lint
npm test
This project is released under the Apache License 2.0.
For more details, please see in the LICENSE file.
© 2026 Open Reach Tech Inc.
FAQs
Hora Kit: a package that distributes AI skills, agents, and docs for AI-driven application development.
The npm package @openreachtech/hora receives a total of 16 weekly downloads. As such, @openreachtech/hora popularity was classified as not popular.
We found that @openreachtech/hora demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 5 open source maintainers collaborating on the project.
Security News
GitHub is tightening GitHub Actions security with new restrictions on privileged pull request workflows. Here's what changes and how maintainers are affected.
Security News
/Application Security
A practical guide to securing GitHub Actions against supply chain attacks, covering malicious pull requests, credential theft, dependency risks, and release pipelines.
Security News
Composer 2.11 adds dependency cooldowns, joining package managers that delay new releases to reduce supply chain risks while allowing urgent security updates.