v0.10.4 — Final vendored release

Intelligence Sync 0.10.4 is the final vendored release. The project is superseded by the stable Intelligence CLI; the frozen engine remains available so existing projects can reach the supported conversion boundary safely.

Highlights

Changed

• Replaced active README and INIT onboarding with direct stable-CLI installation and conversion guidance.
• Made update and sync handoffs link the successor, show the npm command, and actively offer a read-only conversion preview.
• Documented the two-invocation handoff for agents that begin on an older loaded update skill.
• Redirected contributions, issues, pull requests and reference documentation to the successor repository.

Migrate to Intelligence

From a clean legacy project:

npm install -g @ainova-systems/intelligence@latest
intelligence init --preview
intelligence init --apply
intelligence status --check

init --preview writes nothing. Projects below legacy schema 0.10.0 should first run their vendored Intelligence Sync update flow to reach this final release.

See the full changelog and the Intelligence CLI documentation.

v0.10.3

A follow-up to 0.10.2. The v2 CLI consolidated its command surface right after that release, so the switch described in the update skill named commands that no longer exist. Everything else in 0.10.2 stands: this is still the final vendored line, it keeps working, and this repository stays where it is.

Highlights

Fixed

• The CLI switch named retired commands. Converting an archived v1 project is now intelligence init — --preview stages and verifies without writing, --apply converts — instead of a separate migrate. doctor became status --check, and upgrade folded into a single intelligence update that covers the CLI, the project's schema and its package ranges in one plan. Step 7 of intelligence-update still used the old names and would have failed at the first command. Harmless in practice, since that step refuses to run while the CLI is a prerelease — but wrong.
• The availability check reads both npm dist-tags. A stable latest proceeds. A prerelease-only channel stops and says so, unless the user explicitly asks for the release candidate in that conversation — in which case it is named as a release candidate every time it is mentioned. The skill never puts a prerelease on a project on its own initiative.

No schema change: the stamp advances to 0.10.3 on update.

Full changelog: v0.10.2...v0.10.3

Install

Paste this to your AI agent:

Update intelligence-sync: fetch the latest engine from https://github.com/ainova-systems/intelligence-sync and run its update flow to migrate this project to the newest version. Leave my rules, agents, and project skills untouched. If it fails, read the CHANGELOG "### Breaking" entries between my version and the latest, base your fix plan on them, make sure you are running the latest scripts, and retry; ask me only if it still fails.

New projects: start with the CLI instead — npm install -g @ainova-systems/intelligence@next, then intelligence init.

v0.10.2

The final release of the vendored engine. It keeps working, this repository stays at the URL your update.sh already clones, and nothing changes on its own — a project can stand still here indefinitely. Development continues in the intelligence CLI (ainova-systems/intelligence), and from this release the update flow can walk you across, one way, on an explicit yes.

The CLI is still in prerelease, so the switch below stays dormant until it is generally available: the skill checks, says so, and leaves the project on the vendored setup.

Highlights

Added

• intelligence-update can perform the switch to the CLI — new step 7, only on an explicit yes. After a normal update leaves the project healthy it checks that the CLI is generally available (a published version with no prerelease suffix — otherwise it says so and stops), describes exactly what would change, requires a clean worktree, previews with intelligence migrate --dry-run, confirms a second time, then runs intelligence migrate and verifies with doctor + sync. The --yes flag covers the update diff only and never this decision.
• Two runs therefore get a project across: the first brings the engine to this final version, the second offers the move — which is also the order migrate requires, since it accepts only a project already at the final vendored schema.

Changed

• sync.sh and update.sh print one stderr line naming this the final vendored line and pointing at the update skill (IS_SUPPRESS_CLI_NOTE=1 silences it). stdout and the IS_STATUS contract are untouched.
• The release-npm workflow is removed — publishing the CLI belongs to its own repository.

No schema change: the stamp advances to 0.10.2 on update.

Full changelog: v0.10.1...v0.10.2

Install

Paste this to your AI agent:

Update intelligence-sync: fetch the latest engine from https://github.com/ainova-systems/intelligence-sync and run its update flow to migrate this project to the newest version. Leave my rules, agents, and project skills untouched. If it fails, read the CHANGELOG "### Breaking" entries between my version and the latest, base your fix plan on them, make sure you are running the latest scripts, and retry; ask me only if it still fails.

New projects: start with the CLI instead — npm i -g @ainova-systems/intelligence, then intelligence init.

v0.10.1

A pack mirrored into a Windows project came back dirty after every sync — no content diff, only line endings, and back again the moment it was reverted. The clone ran under the host's git configuration, and core.autocrlf=true, the Git for Windows default, rewrites a checkout to CRLF whenever the remote repo declares no .gitattributes of its own. materialize_pack then copies those bytes verbatim into the declared mirror:, so a project that normalizes to LF saw its entire vendored pack reported as modified on every run. A pack cannot be relied on to declare its line endings, so the engine no longer relies on the host either.

Highlights

Fixed

• The pack clone materializes the bytes the pack has stored, whatever the host's core.autocrlf says. fetch_remote_source now pins core.autocrlf=false and core.eol=lf next to the core.symlinks=false that was already there, on the shallow clone, the full-clone fallback, and the SHA checkout beside it. autocrlf=false covers packs declaring no attributes; eol=lf covers those that mark files text.
• update.sh pins the same two on its own upstream clone. That checkout is copied straight into intelligence/sync/scripts/, so a CRLF one would install CRLF shell scripts — the thing the engine's own .gitattributes exists to prevent.

Added

• CI asserts it: a job sets core.autocrlf=true globally, syncs a pack that declares no attributes, and fails if a single \r reaches the mirror.

Full changelog: https://github.com/ainova-systems/intelligence-sync/blob/v0.10.1/CHANGELOG.md

Install

Set up intelligence-sync in this project: clone https://github.com/ainova-systems/intelligence-sync, copy its `intelligence/` folder here, and follow intelligence/sync/INIT.md to bootstrap config.yaml and the first rules, agents and skills.

Already installed? Paste this instead:

Update intelligence-sync: fetch the latest engine from https://github.com/ainova-systems/intelligence-sync and run its update flow to migrate this project to the newest version. Leave my rules, agents, and project skills untouched. If it fails, read the CHANGELOG "### Breaking" entries between my version and the latest, base your fix plan on them, make sure you are running the latest scripts, and retry; ask me only if it still fails.

v0.10.0

0.9.0 put the mirror location in one global external: block, but the identity of each pack — its url and its ref — stayed duplicated inside every sources.* entry that used it. A pack spanning rules, agents and skills carried its url@ref three times, and nothing detected the drift when only two of them were bumped: rules pinned at one commit and skills at another is a config that looks fine and reads wrong. packs: inverts it — a remote is declared once and referenced by name.

Highlights

Added

• packs: — declared remote sources, referenced by name. packs.<name>.{url,ref,mirror} sits at three levels, exactly like targets:, so it is read by the existing get_nested_yaml_value and adds no parser. A source entry becomes @<pack>[/<subpath>], and every section referencing that pack shares one clone and one pin.
• mirror: is both the location and the switch. Present, the pack is materialized there and committed, so bumping ref: reads as an ordinary git diff; absent, the pack stays transient in the run cache — 0.9.0's default behaviour, with no flag needed to express it.
• An undeclared @pack reference fails the run (exit 1, naming the pack and listing the declared ones), deliberately unlike a missing local path, which only warns: the config claims to know that name, so a typo must not silently drop a whole rule set. The check runs up front, in validate_pack_refs, because resolve_source_dir is always called inside $( ) — an error raised there would exit the substitution subshell, not the sync.
• Inline git+<url>[@<ref>][#<subpath>] specs keep working as anonymous packs: no name, no mirror, always transient.

Changed

• The mirror directory is declared, never derived. The whole name-derivation machinery 0.9.0 needed is gone — no basename extraction, no charset sanitizing, no pack-<key> fallback, no collision suffix. A pack name is now purely a reference handle that never becomes a path component.
• Ownership of a mirror is the presence of its .pack stamp, not the url inside it. A stamped directory stays the pack's even after you edit url:, so a moved or renamed upstream refreshes the mirror instead of freezing it at the old content while the generated output silently follows the new repo. A non-empty directory without a stamp is still never touched.
• Two packs declaring the same mirror: are refused with exit 1 naming both, as is a mirror that resolves to the repo root, escapes the repo, or sits inside a configured sources.* directory.

Fixed

• get_nested_yaml_value cut values at the last colon, not the first. The value strip was a greedy .*:[[:space:]]*, which on url: https://host/repo.git matched through https: and yielded //host/repo.git. It is now anchored at the first colon, and an unquoted value additionally drops a trailing # comment per YAML while a # inside quotes stays content. Latent in 0.9.0 — nothing read a URL through this helper — but it also silently truncated any models.<ide>.<tier> value containing a colon.
• A sub-key is matched literally, never interpolated into a regex. A pack named my.pack would otherwise have matched myXpack.
• A pack could lose every subpath but the last when the run cache was unset. materialize_pack recorded its "already cleared this run" claim only when IS_REMOTE_CACHE was exported, yet cleared the directory unconditionally.

Breaking

external: { dir: … } is replaced by packs:; migrate_to_0_10_0 rewrites the config automatically and preserves comments. Every inline git+ spec becomes a declared pack plus an @name reference, external.dir becomes each pack's mirror: so vendored content keeps landing where it already is, and the external: block is dropped. Post-condition: no external: key in config.yaml, and a packs: block declaring every remote previously reached inline. Idempotent — a config with no external: key and no git+ token is left untouched.

Full changelog: https://github.com/ainova-systems/intelligence-sync/blob/v0.10.0/CHANGELOG.md

Install

Set up intelligence-sync in this project: clone https://github.com/ainova-systems/intelligence-sync, copy its `intelligence/` folder here, and follow intelligence/sync/INIT.md to bootstrap config.yaml and the first rules, agents and skills.

Already installed? Paste this instead:

Update intelligence-sync: fetch the latest engine from https://github.com/ainova-systems/intelligence-sync and run its update flow to migrate this project to the newest version. Leave my rules, agents, and project skills untouched. If it fails, read the CHANGELOG "### Breaking" entries between my version and the latest, base your fix plan on them, make sure you are running the latest scripts, and retry; ask me only if it still fails.

v0.9.0

A remote git+ pack has so far existed only inside the run cache: cloned, consumed, deleted. The only evidence that an upstream pack had changed was a shifted diff in the generated output, interleaved with your own rules and skills — there was no way to review what a pin bump actually brought in. external: fixes that by materializing each pack into a directory you commit.

Highlights

Added

• external: { dir: … } — remote packs materialized into the repo and committed. Each pack is copied into <dir>/<repo-name>/ with a .pack stamp recording url, ref and resolved SHA. Commit that directory and bumping @v1.2.0 to @v1.3.0 reads as an ordinary git diff, deleted skills included.
• Only the subpaths your sources reference are copied, so a pack's README, CI config and tests stay out of your repo. .git is never copied — a nested repository would be recorded as a gitlink, whose contents git does not track, which is the exact state this avoids.
• One directory per repo@ref. The first source entry to touch a pack in a run clears it, so content from a previous ref or a since-deleted source entry does not linger.
• Never destructive: the clear is guarded by the stamp. A directory whose .pack does not name the same repo is left alone and the pack takes a suffixed name, so neither a folder of your own nor a second pack with a colliding repo basename can be deleted.
• Two consequences fall out for free — pack files now have committed paths, so AGENTS.md and the Pi adapter link to them like any local source instead of naming them bare, and a pinned pack that is already committed keeps working when its remote is unreachable.

Changed

• external.dir is validated like an adapter output — repo root, outside-the-repo and inside-a-source values are refused with exit 1 before anything is written — but is deliberately allowed inside the intelligence umbrella, since <umbrella>/external is the recommended location. Adapter outputs aimed at the external dir are refused symmetrically, and warn_unsynced no longer flags materialized packs.
• get_yaml_field is now the single two-level config reader, shared by project.name and external.dir.

Omit the block and behaviour is unchanged: packs stay transient. No schema change — the stamp advances to 0.9.0 on update.

Full changelog: https://github.com/ainova-systems/intelligence-sync/blob/v0.9.0/CHANGELOG.md

Install

Set up intelligence-sync in this project: clone https://github.com/ainova-systems/intelligence-sync, copy its `intelligence/` folder here, and follow intelligence/sync/INIT.md to bootstrap config.yaml and the first rules, agents and skills.

Already installed? Paste this instead:

Update intelligence-sync: fetch the latest engine from https://github.com/ainova-systems/intelligence-sync and run its update flow to migrate this project to the newest version. Leave my rules, agents, and project skills untouched.

v0.8.1

intelligence-sync routes AI coding rules, agents, and skills authored once in plain markdown into each IDE's native format (Claude Code, Cursor, GitHub Copilot, Codex, Pi, OpenCode, AGENTS.md). Zero dependencies, bash + awk, MIT.

Highlights

Changed

• add- and create- are told apart by what already exists, not by how a skill is built inside. The old contract defined them by implementation facts — add- "creates exactly one artifact", create- "orchestrates several add- skills" — and both mispredict a real registry: a skill that writes a doc type, an element type, several config files and a template is still plainly an add-, and a create- skill that orchestrates nothing had to carry a written note explaining its name "despite the naming contract". A call-graph definition also makes a name depend on today's factoring, so splitting a skill's internals would have demanded a rename though nothing changed for the caller. The verbs now split on the host — add- puts one new member into a set that is already there, and create- brings the container itself into existence, where nothing hosted it before — and neither says anything about the inside of a skill. The Atomic / Orchestrator / Meta-orchestrator tier vocabulary goes with it: how much a skill body carries turns on whether that skill dispatches to others, which was always the real question and never a function of its verb.

No schema change — the stamp advances to 0.8.1 on update.

Full changelog: https://github.com/ainova-systems/intelligence-sync/blob/main/CHANGELOG.md

Install

Paste the Quick Start prompt from the README into your AI coding agent.

0.8.0

intelligence-sync routes AI coding rules, agents, and skills authored once in plain markdown into each IDE's native format (Claude Code, Cursor, GitHub Copilot, Codex, Pi, OpenCode, AGENTS.md). Zero dependencies, bash + awk, MIT.

The engine now ships two personas: intelligence-architect owns what the layer contains, and the new intelligence-operator runs the machinery that ships it.

Highlights

Added

• intelligence-operator — a standard-tier agent for the engine's mechanical flows. Sync, update, and adapter install/removal are deterministic, fail-closed procedures whose failure mode is a loud refusal and a retry, not a plausible wrong answer, so they do not need the heavy model the judgement work runs on. The four flow skills (intelligence-sync, intelligence-update, intelligence-install-adapter, intelligence-uninstall-adapter) now declare agent: intelligence-operator, following the agent: intelligence-architect precedent set in 0.7.2. intelligence-sync — the one flow with no human step mid-run — additionally sets context: fork, so a direct /intelligence-sync runs in the operator's own context where the tool supports forking. No schema change; the stamp advances to 0.8.0 on update.

Changed

• Full-access agents no longer emit a tools: list in .claude/agents/. A closed list restricts the agent to exactly the named tools and silently drops every MCP server; omitting the field lets the agent inherit every session tool, MCP servers included (confirmed empirically in Copilot reading .claude/agents/, and Claude Code behaves the same). readonly agents keep their explicit allowlist and disallowedTools.

Full changelog: https://github.com/ainova-systems/intelligence-sync/blob/main/CHANGELOG.md

Install

Paste the Quick Start prompt from the README into your AI coding agent.

0.7.4

Fixed

• Engine-shipped description fields no longer carry an em dash. The intelligence-architect agent and the intelligence-authoring rule described themselves with an em dash, and the intelligence-add-agent frontmatter template modelled one - so every consumer that inlines a description into a registry (AGENTS.md, the agent and skill pickers) inherited it, which is wrong for a project whose house voice forbids the character. A description is compact metadata reproduced verbatim across every tool, so these are plain hyphens now; the em-dash voice in prose bodies is unchanged. No schema change - the stamp advances to 0.7.4 on update.

0.7.3

Fixed

• migrate_to_0_3_1 no longer deletes a project's own <umbrella>/scripts/. The 0.3.1 migration detected the pre-0.3.1 flat engine by the bare presence of <umbrella>/scripts/ and then rm -rf'd it — but a modular project may legitimately keep its own tooling there (build/design scripts, tests, fixtures), and the migration relocated the real engine into sync/ while deleting the project's code as "legacy". Because run_migrations walks the whole chain on every update.sh, this fired on each update, not once. The flat engine is now identified by its entry script scripts/sync.sh — the same sentinel the migration's own postcondition already verifies — so a <umbrella>/scripts/ without it is left untouched, and the destructive cleanup is guarded by the same sentinel. A genuine pre-0.3.1 layout (which always ships scripts/sync.sh) still migrates exactly as before; a modular project that owns <umbrella>/scripts/ is now a correct no-op. No schema change — the stamp advances to 0.7.3 on update; re-run sync afterwards.