HIVEM1ND

One mind for every coding agent.

Download · Quick start · Commands · Docs · Links · Support

What it is

HIVEM1ND is a folder of plain markdown that any coding agent can read and write. Context, memory, preferences and work in progress carry over across projects and machines instead of resetting with every chat. Roles, commands, features and knowledge modules are files, so there is no database and no lock, and any agent or app can read the folder directly. The only index is a markdown file inside each knowledge module, listing its protocols so an agent loads the ones the work needs instead of the whole module. Every supported agent attaches to the same mind through its own adapter, and an agent without one gets a generic attach prompt.

Quick start

| Method | Steps | | --- | --- | | Windows | Download HIVEM1ND-<version>-x64.zip from Releases, extract it, run HIVEM1ND\HIVEM1ND.exe. | | npx | npx hivem1nd init opens the terminal wizard; add --gui for the browser wizard. | | Clone | Clone this repository into the folder that will hold the mind. That is the install, with no setup step. | | Genesis | Paste the setup prompt into any agent chat and it runs the setup in plain language. |

All four ask the same questions in the same order and resume where a previous attempt stopped.

The Windows build is unsigned, so SmartScreen may warn before the first run, and Smart App Control blocks it outright. The npx hivem1nd path requires Node.js 22 or later.

How it works

HIVEM1ND is organized in nodes, an inverted tree with the mind at the top.

mind (one per user)
 └─ environment (optional, groups repos of one kind)
     └─ repo (an executor works here)

The hive is the mind itself: one per user, holding roles, commands, features and knowledge modules, plus everything its agents learn. An environment groups repos of one kind, such as a game engine or a web stack, and its coordinator runs at that level. A repo is the leaf, where an executor works, with a brief describing what it is and where its design document is located. A repo or an environment can hold a local instance too, a committed folder with overrides for that node.

Any agent attaches in one of two modes. In on-demand mode nothing loads by itself; a command starts a chat in a role, and from there the agent works with the mind's context. In auto mode every new chat has HIVEM1ND loaded without running anything, through one line added to the agent's own rules file.

Knowledge packs and protocols

Knowledge packs hold what an agent should know before it builds, one per discipline: security, design, copy and product ship with the kit; the first three each install a command (/cyberattack, /uify, /humanize), and product holds the protocol that writes the product document of a product. A pack is organized as a two-level index. INDEX.md lists the categories in one line each; a category file lists its subcategories, when each one applies, a Build: line with how to get it right the first time, the options to choose from, and which protocols to open.

Packs are read while planning. Asked for a contact page with a form, the executor reads each index, opens only the categories the work touches, such as forms, interface copy and API security, and writes their Build: lines into the plan as requirements, each naming the file it came from. A large pack costs a few hundred words to consult instead of all of it, and a task that touches no category reads nothing more.

A protocol is a checklist an agent can actually run: a strict sequence of steps, each with a task, a time limit and a result that proves it happened, such as a measured contrast ratio, a status code or a search that returns nothing. A step without its result is not done, and a run stops at the first step that fails.

Protocols are offered, not imposed. While a task is planned, the protocols that cover something the plan actually builds are listed next to it, and before the report the agent asks which ones to run; only the confirmed ones run. A pack can be left out at setup, and a user adds private protocols and packs the same way under user/: global protocols in user/protocols/, and local ones for a single project in user/projects/<project>/protocols/.

Setup steps

| # | Step | What it asks | | --- | --- | --- | | 1 | Install mode | Simple accepts every detected default and installs immediately; Custom opens every setting first. | | 2 | Mind location | The root folder for the mind: local, a cloud drive, a pendrive or a network location. A mind already in that folder is attached instead of reinstalled, and the step says so before it asks. | | 3 | Agents | Scans the machine and sets how each agent loads HIVEM1ND, on-demand or auto. | | 4 | Content | Which features and knowledge modules to include. | | 5 | Projects | Confirms roots, optional environments and repositories. | | 6 | Confirm | Optional preferences and whether to check for updates automatically. | | 7 | Install | Reviews every change and resolves conflicts before anything is written. | | 8 | Done | Prints what was written, the report of the run, one Relay line per client and the first command to run. |

Attaching a second machine to a mind that already exists writes that machine's record and its agent files, and leaves the mind's content, its preferences and its version untouched. Simple mode attaches by itself when it finds a mind on the machine; custom mode asks at step 2.

No install is left half done. A destination that cannot be written stops on that item and asks: a symbolic link or a Windows junction standing where files belong is replaced by default, removing the link and keeping the folder it points at, and omitting it is an explicit choice. What the run wrote, omitted or replaced goes to user/machines/<host>.report.md, and an install that leaves assets unwritten is never recorded as done.

Reference

Roles

A role is a markdown file in roles/, and that file is also the command that starts a chat in that role. A role added inside the mind is installed the same way, so it becomes a command on every machine. See roles/README.md.

| Role | Group | Description | | --- | --- | --- | | Genesis | Executive | Installs the mind on a machine and maintains it afterward. | | Overlord | Operative | Leads a squad as a mini overseer: one environment, or the chats of one repository. | | Executor | Operative | Executes tasks inside one repo, one at a time. The default seat for a repo. | | Overseer | Executive | Manages the whole mind: knows where every project stands, defines scope with the user and hands work to the executors. | | Adjutant | Executive | Takes the user's requests and solves them end to end: documents and manuals, research, reports, texts and analysis. Leaves the Overseer with coordination. | | Incubator | Operative | Develops ideas into products inside one folder: brainstorms them, prototypes them fast and sends each one to the product it belongs in. |

Commands

Every role is a command, and a few more operate the system. Every command also works in plain language: telling an agent to start as an executor does the same as /executor. See commands/README.md.

| Command | Description | | --- | --- | | /relay | Starts and ends a role's session. On entry it fetches, aligns the repos with the recorded branches and reads the state and the inbox; on exit it commits and pushes everything, writes the state and the log, and clears the conversation. | | /evolve | Updates the mind base, applies private migrations in order and reinstalls the included commands for this machine. | | /task | Creates a task file with the next id for a unit and leaves it a message that the task is ready. | | /msg | Writes a message into a unit's inbox and, when its agent has a CLI and the unit is in, tells it to read the inbox. | | /absorb | Stores a piece of feedback as a preference, for the current project or globally, with the date and the reason. | | /migrate | Absorbs a structure a person already has, the rules and memories of their agents and repositories, into the mind, without touching the original. | | /pylon | Adds shared team state to a repository without switching or changing its code branch. | | /swarm | Lists every active unit, open or delivered task, and unread inbox in the mind. | | /uninstall | Removes what was installed on this machine: commands, skills and the auto rule line for each attached agent. | | /protocol | Creates or runs a protocol: a strict sequence of steps, each with a task, a time and a result. A task whose work matches a protocol's scope lists it in its plan and runs it before the report once the user confirms. |

Features

A feature is a workflow that runs on a repo, with a start and an end, one markdown file in features/, or a folder with its scripts when the feature has any. Most are included in the base; the rest are installed with a knowledge module and require it.

| Feature | Category | Description | | --- | --- | --- | | /report | Planning | Investigates a defect or request and writes an evidence-backed task for the project executor without changing code. | | /plan | Planning | Splits a request into ordered task files for the owning units and sends each unit a message without implementing it. | | /brainstorm | Planning | Develops a topic one approved decision at a time and records agreed text separately from open questions. | | /blueprint | Planning | Serves the screen-flow boards of every project on the machine in one local viewer and writes the comments left on them into each repo. This is Blueprint Lite; the full editor is Blueprint. | | /void | Planning | Opens a long text in a quiet reader where the person corrects it in place, and saves every edit into the file on disk, keeping the original and each version, where agents read it. | | /qa | Quality | Runs every open project task in non-overlapping groups, verifies the results and records what passed or failed. | | /tribunal | Quality | Convenes three judges, cross-examines their findings and records an evidence-backed verdict without editing code. | | /corpo | Quality | Stress-tests delivered work with three deliberately difficult reviewers and records every finding for the user. | | /observer | Quality | Tests a project under adverse conditions and writes reproducible weakness reports as open tasks. | | /conflicts | Quality | Resolves compatible merge or rebase conflicts, asks about incompatible hunks and verifies the build before completion. | | /catchup | Continuity | Summarizes changes, authors, open work and unread messages since the unit's recorded state without changing files. | | /cleaner | Continuity | Measures how bloated the mind is, proposes every cleanup in one list for a single yes, applies it and verifies that nothing was lost. The startup check offers it when a threshold is crossed. | | /docs | Continuity | Updates only the documentation affected by the current diff or a supplied commit range. | | /release | Continuity | Prepares a local release from commits since the last tag and reports the commands needed to publish it. | | /cyberattack | Quality | Audits security, the whole project or one feature, and warns before the full pass. Installed with the security module. | | /uify | Quality | Reviews design and interface, the whole project or one feature, and applies the pass. Installed with the design module. | | /humanize | Quality | Rewrites copy that reads as written by an AI, the whole project or one feature. Installed with the copy module. |

Files

Everything in the mind is stored as files, one record per file: a brief per project, a product document per product, a state file per unit, a message per inbox entry, a task per request, a log per repo, environment and mind, plus preferences and knowledge modules. The full layout and every record format are in files.md.

Working together

Several people can share a repo, each with their own mind. The team's shared state, presence, messages, tasks and log, is stored on a dedicated branch of the same repo, mounted in a folder the code branches ignore. Work happens on branches, and main changes through pull requests that a person merges; an agent commits and pushes on its own task branch and nowhere else. AI presence, whether commits carry AI trailers and whether shared files are allowed, is decided by the team once per repo.

Updating and uninstalling

/evolve pulls the new version into the mind, joins to Relay any available client that has no Relay entry yet, translates roles and features into the format of each attached agent, and migrates user/ when the structure changed. Roles, commands and features written inside the mind are installed alongside the ones the kit ships, from the mind folder for what is shared and from user/roles, user/commands and user/features for what stays private to that mind. A name the kit already ships keeps the kit file and reports it. Anything left out at setup stays out on later updates.

To remove what was installed on a machine, run uninstall.cmd in the mind folder, hivem1nd uninstall [--dry-run] [--remove-mind] from a terminal, or /uninstall from an attached agent. A dry run reports the plan before anything is removed.

Troubleshooting

Windows warns about an unknown publisher, or blocks the app outright. The build is unsigned. SmartScreen shows a warning that can be dismissed with "Run anyway"; Smart App Control blocks unsigned software entirely and has no per-app exception, so it must stay off to run the packaged app.

Node.js version errors. HIVEM1ND requires Node.js 22 or later. Check the installed version with node --version before running npx hivem1nd init.

Where is the mind. In auto mode, the HIVEM1ND line in each agent's rules file names its path. Inside the mind, user/machines/<host>.md records it under the mind field, one file per machine.

Starting over. Run the setup again with --resume to continue an interrupted attempt, or uninstall first and run it again from scratch.

Contributing

One pull request per change, the merge is a maintainer's decision. See CONTRIBUTING.md for the format of roles, commands, features and knowledge modules.

License

MIT.

Support

More links: txmska.com/links.