@ainova-systems/intelligence 0.11.0-rc.4 → 0.11.0-rc.5

package/engine/skills/intelligence-add-skill/SKILL.md

@@ -9,15 +9,15 @@ argument-hint: <domain> <verb-noun> [description]
 ## Steps
 
 1. **Determine domain prefix** (the scope is required):
-   - **Reuse the existing domain when one fits**: list `intelligence/skills/` and `intelligence/agents/`. If a domain prefix is already established for the target area (`backend-`, `frontend-`, `devops-`), use it. Introduce a new domain only when the scope is materially different from all existing ones.
+   - **Reuse the existing domain when one fits**: list `<umbrella>/skills/` and `<umbrella>/agents/`. If a domain prefix is already established for the target area (`backend-`, `frontend-`, `devops-`), use it. Introduce a new domain only when the scope is materially different from all existing ones.
    - **When no existing domain fits**, derive from repo structure:
-     - Single / root project → use the project codename from `intelligence/config.yaml` → `project.name`
+     - Single / root project → use the project codename from `<manifest>` → `project.name`
      - Backend service / API component → `backend-`
      - Frontend / web / UI component → `frontend-`
      - Infrastructure, IaC, CI/CD, deployment → `devops-`
      - Shared library / common / cross-cutting code → `core-`
      - Test suites (e2e, integration) → `tests-`
-     - Tool-internal (intelligence-sync itself) → `intelligence-`
+     - Tool-internal (intelligence-sync itself) → `intelligence-` (only inside the intelligence-sync repo — downstream projects must not use this prefix)
    - If the repo is a monorepo with named components (e.g., `apps/billing`, `services/auth`), prefer the component name as the domain (`billing-`, `auth-`).
    - **Every skill needs a domain prefix.** If the scope is unclear, ask the user before proceeding.
 
@@ -28,13 +28,13 @@ argument-hint: <domain> <verb-noun> [description]
    - `run-` — executes an operation (tests, build, sync)
    - `review-` — read-only analysis
 
-3. **Check for existing agent**: Find an agent in `intelligence/agents/` matching the domain
+3. **Check for existing agent**: Find an agent in `<umbrella>/agents/` matching the domain
    - If found — this skill will be linked to that agent
    - If not — ask user whether to create a new agent via `/intelligence-add-agent` first
 
 4. **Analyze codebase patterns**: Read existing implementations to extract the repeatable steps this skill should automate. Each step must come from actual code patterns, not generic knowledge.
 
-5. **Create skill**: Write `intelligence/skills/<full-name>/SKILL.md` with frontmatter:
+5. **Create skill**: Write `<umbrella>/skills/<full-name>/SKILL.md` (create the directory if missing — no config edit needed) with frontmatter:
    ```yaml
    ---
    name: <full-name>

package/engine/skills/intelligence-extract-skill/SKILL.md

@@ -26,7 +26,7 @@ Both end at the same artifact format. Extract starts from observed behavior, so
    - Behavioral preference / constraint / pattern to default to → **rule** (use `intelligence-learn-from-context` for single preferences from session)
    - Knowledge area / persona / expertise scope → **agent**
 
-4. **Determine domain prefix** (for skill / agent): reuse the existing domain when one fits — list `intelligence/skills/` and `intelligence/agents/`. Derive from repo structure only when no existing domain matches.
+4. **Determine domain prefix** (for skill / agent): reuse the existing domain when one fits — list `<umbrella>/skills/` and `<umbrella>/agents/`. Derive from repo structure only when no existing domain matches.
 
 5. **Determine naming** (for skill): `<domain>-<verb>-<noun>` with convention verbs — `add-` (one new member of a set that already exists), `create-` (the container itself, where nothing hosted it), `update-` (revise what is there), `run-` (execute), `review-` (read-only analysis).
 
@@ -38,7 +38,7 @@ Both end at the same artifact format. Extract starts from observed behavior, so
 
 ## Authoring guidance
 
-Follow the **Authoring Discipline** section in `docs/CONVENTIONS.md` when writing the artifact body — size budgets (<500 lines for SKILL.md body), imperative form, explain WHY, reserve absolute language for true invariants, lead with positive defaults.
+Follow the **Authoring Discipline** section in `<module>/docs/CONVENTIONS.md` when writing the artifact body — size budgets (<500 lines for SKILL.md body), imperative form, explain WHY, reserve absolute language for true invariants, lead with positive defaults.
 
 ## Related skills
 

package/engine/skills/intelligence-install-adapter/SKILL.md

@@ -7,19 +7,19 @@ agent: intelligence-operator
 
 # Install Adapter
 
-The umbrella is whatever directory holds `config.yaml` (`intelligence/`, `Intelligence/`, a codename — never assume the name or casing); the engine module is the directory under it holding `scripts/sync.sh` (conventionally `sync/`).
+The project's config is `<manifest>`; the content dir is `<umbrella>/` (never assume the name or casing); the engine's own files live under `<module>/` — these paths are localized to this project at sync time.
 
 ## Steps
 
-1. Check whether target `$ARGUMENTS` is already enabled in `config.yaml` — if yes, report and stop.
+1. Check whether target `$ARGUMENTS` is already enabled in `<manifest>` — if yes, report and stop.
 
-2. **Locate the adapter.** `sync.sh` discovers adapters in two places:
-   - **Built-in**: `<module>/scripts/adapters/$ARGUMENTS.sh` — upstream-owned. `update.sh` replaces that whole directory on every engine update.
-   - **Project-owned**: `<umbrella>/adapters/$ARGUMENTS.sh` — `update.sh` never touches it. A project adapter of the same name overrides the built-in.
+2. **Locate the adapter.** The sync discovers adapters in two places:
+   - **Built-in**: `<module>/scripts/adapters/$ARGUMENTS.sh` — upstream-owned. Every engine update replaces that whole directory.
+   - **Project-owned**: `<umbrella>/adapters/$ARGUMENTS.sh` — updates never touch it. A project adapter of the same name overrides the built-in.
 
    If neither exists, research the tool's prompt format (web search for its rules / agents / skills file layout), then copy `<module>/scripts/adapters/_template.sh` to **`<umbrella>/adapters/$ARGUMENTS.sh`** and implement `sync_to_$ARGUMENTS()`. Author it there, never inside the engine's `scripts/adapters/` — a file written there is deleted by the next engine update. Adapter contract: `<module>/docs/ADAPTERS.md`. An adapter that would serve every project is worth contributing upstream.
 
-3. Update `config.yaml`:
+3. Update `<manifest>`:
    - Target exists with `enabled: false` → flip to `enabled: true`.
    - Target missing → add it under `targets:` with its `output:` path.
    - If the target reads always-on rules from `AGENTS.md` (`cursor`, `copilot`, `codex`, `pi`, `opencode`), `targets.agents` must be enabled too — sync fails closed otherwise.

package/engine/skills/intelligence-learn-from-context/SKILL.md

@@ -21,7 +21,7 @@ The original negative pattern stays in the rule body as an illustrative example
 
 ## Phase A — Analyze (read-only)
 
-1. **Read authoring conventions first.** Discover the paths, never assume them: the umbrella is the directory holding `config.yaml` (`intelligence/`, `Intelligence/`, a codename), and the engine module is the directory under it holding both `scripts/sync.sh` and `scripts/VERSION` (conventionally `sync/`). The meta-skills live in `<module>/skills/`, not directly under the umbrella. Load `<module>/skills/intelligence-add-rule/SKILL.md`, `<module>/skills/intelligence-add-skill/SKILL.md`, `<module>/skills/intelligence-add-agent/SKILL.md`, and `<module>/docs/CONVENTIONS.md` (Authoring Discipline section). This skill writes nothing on its own — it delegates to the add-* skills, which carry the authoring conventions.
+1. **Read authoring conventions first.** The paths below are localized to this project at sync time: `<umbrella>/` is the content dir, `<module>/` the engine's own files, `<manifest>` the config. The meta-skills live in `<module>/skills/`, not directly under the umbrella. Load `<module>/skills/intelligence-add-rule/SKILL.md`, `<module>/skills/intelligence-add-skill/SKILL.md`, `<module>/skills/intelligence-add-agent/SKILL.md`, and `<module>/docs/CONVENTIONS.md` (Authoring Discipline section). This skill writes nothing on its own — it delegates to the add-* skills, which carry the authoring conventions.
 
 2. **Capture the lesson** from session context or user input. Strip session-specific detail, keep the underlying pattern.
 

package/engine/skills/intelligence-review-skills/SKILL.md

@@ -13,11 +13,11 @@ Name reflects the umbrella usage of "skills" for all AI artifacts (rules + agent
 
 ## Scope: what to read, and what to leave alone
 
-1. **Resolve the layout — never assume folder names.** The umbrella is the directory holding `config.yaml`; the engine module is the directory under it holding `scripts/sync.sh` and `scripts/VERSION` (conventionally `sync/`). Read authoring conventions from `<module>/docs/CONVENTIONS.md` and the `intelligence-authoring` rule.
+1. **Resolve the layout — never assume folder names.** `<umbrella>/` is the content dir, `<module>/` the engine's own files, `<manifest>` the config — all localized to this project at sync time. Read authoring conventions from `<module>/docs/CONVENTIONS.md` and the `intelligence-authoring` rule.
 
-2. **Enumerate from `config.yaml`, not from a guessed path.** The artifacts are exactly the directories listed under `sources.rules`, `sources.agents` and `sources.skills` — there may be several groups (e.g. a shared one and a project one), they may be nested, and an `@<pack>` (or inline `git+`) entry is a remote pack declared under `packs:`. Take the list from the config; a literal `intelligence/rules/` is wrong in any project that named things differently.
+2. **Enumerate from `<manifest>`, not from a guessed path.** The artifacts are exactly the directories listed under `sources.rules`, `sources.agents` and `sources.skills` — there may be several groups (e.g. a shared one and a project one), they may be nested, and a remote entry is a declared pack (vendored setups, `packs:`) or an installed package (CLI setups, `packages:`, content under `.intelligence/packages/`). Take the list from the config; a literal `intelligence/rules/` is wrong in any project that named things differently.
 
-3. **Skip everything the engine owns.** Sources under `<module>/` (`<module>/rules`, `<module>/agents`, `<module>/skills/intelligence-*`) are upstream-owned: `update.sh` replaces them wholesale, so a local "fix" there is deleted at the next update. Never propose an edit to them. If one of them is genuinely wrong, or a generic check is missing from this skill, that is a **proposal to upstream** — say so in the report rather than patching locally.
+3. **Skip everything the engine owns.** Sources under `<module>/` (`<module>/rules`, `<module>/agents`, `<module>/skills/intelligence-*`) are upstream-owned: every engine update replaces them wholesale, so a local "fix" there is deleted at the next update. Never propose an edit to them. If one of them is genuinely wrong, or a generic check is missing from this skill, that is a **proposal to upstream** — say so in the report rather than patching locally.
 
 4. **Never read or edit generated output** (`.claude/`, `.cursor/`, `.github/`, `.codex/`, `.agents/`, `.pi/`, `.opencode/`, `AGENTS.md`). Sync owns those entirely; the finding always belongs to the source.
 
@@ -34,9 +34,9 @@ Name reflects the umbrella usage of "skills" for all AI artifacts (rules + agent
    | **Over the cap** | `SKILL.md` over 1000 lines, rule over 500, agent over 200 | `SPLIT` — two artifacts, or move detail into `references/<topic>.md` |
    | **Rule links to a rule** | A markdown link from one rule to another (`R1`) | `UNLINK` — name the rule instead: always-on rules are inlined into `AGENTS.md` and the scoped channels carry only scoped rules, so the link is dead in at least one output |
    | **Machine facts in a rule** | OS, shell, editor or a local absolute path (`R2`) | `MOVE` — these belong in a personal, gitignored `CLAUDE.md`; a rule is committed and read by everyone, including whoever is on another platform |
-   | **Literal path or command in a skill** | A path *outside the skill's own folder* baked into a procedure (`R3`) | `PARAMETERIZE` — a skill is *executed*, so a literal path breaks the moment the layout moves; resolve it from a rule or from `config.yaml`. **Exempt:** the skill's own bundle (`references/`, `scripts/`, `assets/` — content is co-located with its skill by default); rules and agents (describing the repository is their job); an example inside an output-format block; the resolution step itself |
+   | **Literal path or command in a skill** | A path *outside the skill's own folder* baked into a procedure (`R3`) | `PARAMETERIZE` — a skill is *executed*, so a literal path breaks the moment the layout moves; resolve it from a rule or from `<manifest>`. **Exempt:** the skill's own bundle (`references/`, `scripts/`, `assets/` — content is co-located with its skill by default); rules and agents (describing the repository is their job); an example inside an output-format block; the resolution step itself |
    | **Skill with no verification** | Nothing at the end proves the procedure worked (`R4`) | `FLAG` — a procedure that proves nothing is a note, or just the work: give it a verification, or delete it |
-   | **Reserved prefix** | A project artifact named `intelligence-*` | `RENAME` — the prefix belongs to the engine, and the updater prunes what matches it |
+   | **Reserved prefix** | A project artifact named `intelligence-*` | `RENAME` — the prefix belongs to the engine, which replaces or removes everything under it on update |
    | **Naming** | A skill that is not `<domain>-<verb>-<noun>`, or a domain invented rather than reused | `RENAME` — or introduce the new domain deliberately |
    | **Stale** | No edits in 6+ months and nothing cross-references it | `ARCHIVE` — move to `<umbrella>/_archive/` |
    | **Negative-framed judgement call** | "Never do X" where a positive default fits, outside safety / security / output-format | `REWRITE` — state the default; reserve NEVER for true must-nots |

package/engine/skills/intelligence-sync/SKILL.md

@@ -5,14 +5,12 @@ agent: intelligence-operator
 context: fork
 ---
 
-Run the sync engine to transform rules, agents, and skills from the intelligence source directory to each enabled IDE's native format.
+Run the sync engine to transform rules, agents, and skills from the intelligence sources to each enabled IDE's native format.
 
-> **Folder name:** `<intel>` is whatever holds your `config.yaml` — typically `intelligence/`, but may have been renamed (e.g. `Intelligence/`). The engine lives in the module subfolder `<intel>/sync/` and is self-locating, so any spelling works as long as you point bash at the right `sync/scripts/sync.sh` path.
->
-> **sync.sh never migrates.** It is a pure synchronizer: on a pre-0.3.1 / non-modular layout or an un-applied schema it **fails closed** with `IS_STATUS=needs-update` (exit 6) and changes nothing. Migration is owned entirely by the `intelligence-update` flow — tell your agent *"Update intelligence-sync"* (or run `<intel>/sync/scripts/update.sh`) first, then re-run sync.
+> **The sync never migrates.** It is a pure synchronizer: across an un-applied schema it **fails closed** with `IS_STATUS=needs-update` (exit 6) and changes nothing. Bringing the project up to the engine is the update flow's job — in a vendored setup tell your agent *"Update intelligence-sync"* (the `intelligence-update` skill); in a CLI setup (root `intelligence.yaml`) run `npm i -g @ainova-systems/intelligence@latest` and `intelligence upgrade` — then re-run sync.
 
 ## Steps
 
-1. Run `bash <intel>/sync/scripts/sync.sh` (where `<intel>` is your intelligence source folder; default `intelligence`).
-2. Review the output — verify rule, agent, and skill counts per target.
-3. If warnings about unsynced directories appear, add the missing paths to `<intel>/config.yaml` under `sources:`.
+1. Run `<sync-cmd>`.
+2. Review the output — verify rule, agent, and skill counts per target, and that it ends with `IS_STATUS=ok`.
+3. If warnings about unsynced directories appear, add the missing paths under `sources:` in `<manifest>`.

package/engine/skills/intelligence-uninstall-adapter/SKILL.md

@@ -7,11 +7,11 @@ agent: intelligence-operator
 
 # Uninstall Adapter
 
-The umbrella is whatever directory holds `config.yaml` (`intelligence/`, `Intelligence/`, a codename — never assume the name or casing); the engine module is the directory under it holding `scripts/sync.sh` (conventionally `sync/`).
+The project's config is `<manifest>`; the content dir is `<umbrella>/` (never assume the name or casing); the engine's own files live under `<module>/` — these paths are localized to this project at sync time.
 
 ## Steps
 
-1. Set `enabled: false` for the target in `config.yaml`.
+1. Set `enabled: false` for the target in `<manifest>`.
 
 2. **Remove only the paths the adapter owns — never the output root.** Several adapters write into a shared root that also holds files nobody generated: `.github/` holds `workflows/`, `.claude/` holds `settings.json`, `.opencode/` holds `opencode.json`. Deleting the root destroys hand-authored work, and no adapter ever does that on re-sync.
 

package/engine/skills/intelligence-update/SKILL.md

@@ -35,6 +35,12 @@ They never run shell commands by hand — you do.
 
 ## Steps
 
+### 0. Vendored setups only
+If the project has a root `intelligence.yaml` (a CLI setup), **stop** — this
+flow is vendored-only. There the engine ships inside the CLI package: run
+`npm i -g @ainova-systems/intelligence@latest`, then `intelligence upgrade`,
+and verify with `intelligence doctor`.
+
 ### 1. Locate the umbrella & discover the engine
 Find the dir containing `config.yaml` → `<umbrella>`. Then find the engine by
 role: search `<umbrella>` (one level deep) for a directory `<M>` with both

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ainova-systems/intelligence",
-  "version": "0.11.0-rc.4",
+  "version": "0.11.0-rc.5",
   "description": "Build, version and distribute AI agent intelligence across your organization — one CLI, versioned Intelligence Packages, and a sync engine for Claude Code, Cursor, Copilot, Codex, Pi and OpenCode.",
   "bin": {
     "intelligence": "bin/intelligence.js"

package/registry/index.yaml

@@ -12,6 +12,10 @@
 # explicitly (`intelligence registry add @ainova-systems <url>`) to read the
 # newest entries without waiting for a CLI release.
 packages:
+  "@ainova-systems/sync":
+    url: "https://github.com/ainova-systems/intelligence-sync.git"
+    path: "intelligence/sync"
+    description: "The engine's own content: authoring rule, engine agents and the intelligence-* meta-skills. Auto-installed by init; pinned to the engine version."
   "@ainova-systems/core":
     url: "https://github.com/ainova-systems/intelligence-dev-packs.git"
     path: "packs/core"