@ainova-systems/intelligence 0.11.0-rc.1

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

@@ -0,0 +1,53 @@
+---
+name: intelligence-add-skill
+description: "Create new skill"
+argument-hint: <domain> <verb-noun> [description]
+---
+
+# Add Skill
+
+## 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.
+   - **When no existing domain fits**, derive from repo structure:
+     - Single / root project → use the project codename from `intelligence/config.yaml` → `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-`
+   - 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.
+
+2. **Determine naming**: Build full name as `<domain>-<verb>-<noun>` using convention:
+   - `add-` — adds one new member to a set that already exists (a field on an existing type, a record among records)
+   - `create-` — brings into existence the container nothing hosted before (MUST use `create-`, never `add-`)
+   - `update-` — revises what is already there
+   - `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
+   - 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:
+   ```yaml
+   ---
+   name: <full-name>
+   description: "<what it does and when to use>"
+   argument-hint: "<expected arguments>"
+   agent: <matching-agent-name>
+   ---
+   ```
+
+   **YAML safety (required):** **always wrap `description`, `argument-hint` and any other free-text string value in double quotes**, regardless of content. Codex CLI uses strict YAML — an unquoted colon in `description: Build retrospective: monthly` parses as a nested mapping and the skill is rejected at startup. Quoting unconditionally removes the whole class of bug and makes lint trivial. If the value itself contains a double quote, escape it as `\"` or wrap the whole value in single quotes — e.g. `description: 'Use as a quick "what do we have" view'` — so an inner quote does not terminate the scalar early.
+
+6. **Write steps**: Numbered, concrete, executable. Include verification (build/test) at the end. A step that dispatches to another skill names it and never restates its content.
+
+7. **Update agent**: Add skill name to the `skills:` list in the matching agent's frontmatter.
+
+8. **Run `/intelligence-sync`** to distribute to all enabled IDE targets.

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

@@ -0,0 +1,47 @@
+---
+name: intelligence-extract-skill
+description: "Extract observed workflow into a reusable skill"
+argument-hint: "<skill-name-hint> [target: skill|rule|agent]"
+---
+
+# Extract Skill
+
+Use when a workflow that ran during this session should become a reusable artifact — same sequence will be needed again by this user or by someone else using shared intelligence. Starts from observed session behavior instead of design-from-scratch.
+
+## When to use this vs `intelligence-add-skill`
+
+- `intelligence-add-skill` — design from scratch / from codebase analysis
+- `intelligence-extract-skill` — extract from the conversation that just happened
+
+Both end at the same artifact format. Extract starts from observed behavior, so the steps already exist as real working procedure.
+
+## Steps
+
+1. **Identify the pattern from session**: list the concrete steps the assistant or user-and-assistant performed during the conversation. Include user decisions at each branch and assistant actions.
+
+2. **Generalize**: strip session-specific details (file names, dates, specific phrasing), keep the repeatable structure. The artifact should work for the next instance of this task type, not just the one that ran.
+
+3. **Determine artifact type**:
+   - Multi-step workflow with concrete steps → **skill**
+   - 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.
+
+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).
+
+6. **Check for matching agent**: if creating a skill and an agent already covers the domain, link via `agent:` frontmatter. If no matching agent and one is warranted, call `intelligence-add-agent` first.
+
+7. **Write the artifact** by delegating to the relevant `intelligence-add-*` skill (`intelligence-add-skill` / `intelligence-add-rule` / `intelligence-add-agent`). The add-* skills carry the authoring conventions — no need to duplicate them here.
+
+8. **Run sync**: `/intelligence-sync` to distribute to all enabled IDE targets.
+
+## 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.
+
+## Related skills
+
+- `intelligence-add-skill` — design new skill from scratch
+- `intelligence-learn-from-context` — capture a behavioral preference from session (often → rule update)
+- `intelligence-review-skills` — audit existing artifacts for duplication, staleness, discipline issues

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

@@ -0,0 +1,31 @@
+---
+name: intelligence-install-adapter
+description: "Enable IDE adapter for intelligence-sync"
+argument-hint: <target-name>
+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/`).
+
+## Steps
+
+1. Check whether target `$ARGUMENTS` is already enabled in `config.yaml` — 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.
+
+   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`:
+   - 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.
+
+4. Add the adapter's generated paths to `.gitignore` (the paths it writes, not the whole output root — a shared root like `.github/` or `.claude/` also holds tracked, hand-authored files).
+
+5. Run `/intelligence-sync` to generate the output.
+
+6. Report: adapter enabled, files generated, output location.

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

@@ -0,0 +1,69 @@
+---
+name: intelligence-learn-from-context
+description: "Capture session lessons and apply to intelligence/ after approval"
+argument-hint: <optional-lesson-statement>
+---
+
+# Learn from Context
+
+Use after a session where a meaningful preference, working pattern, or recurring friction emerged that should persist into future sessions. Runs in two phases — analyze (read-only) then apply (after user approval).
+
+## Principle: positive framing
+
+LLMs follow whatever is named. Negation ("never do X") often draws attention to X. Positive framing ("default to Y", "prefer Y") steers behavior more cleanly.
+
+This skill translates user-stated lessons before encoding:
+- "Don't use NOT-comparison structures" → "State positively what IS"
+- "Stop generating 3 options" → "Default to one strong recommendation"
+- "Never push toward architecture framing" → "Reflect the user's framing in their own words first"
+
+The original negative pattern stays in the rule body as an illustrative example (paired with positive replacement), but the LLM-facing instruction is positive.
+
+## 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.
+
+2. **Capture the lesson** from session context or user input. Strip session-specific detail, keep the underlying pattern.
+
+3. **Translate to positive form**:
+   - "Never do X" → "Default to Y"
+   - "Stop doing Y" → "Do Z instead"
+   - Already-positive lessons keep as-is.
+   Confirm the translation with the user if removing the negation changes meaning.
+
+4. **Route to the right artifact type**:
+   - Behavioral preference, tone, communication style → **rule** (`<umbrella>/rules/<name>.md`)
+   - Multi-step repeatable workflow → use `intelligence-extract-skill` instead
+   - Knowledge scope / persona / expertise area → **agent**
+   - Project-specific context tied to a path → scoped rule with `paths:` frontmatter
+
+5. **Check for an existing artifact to extend**: list the target directory and read titles. When the lesson fits an existing artifact's scope, propose `UPDATE` rather than `CREATE`. Artifact proliferation costs context space.
+
+6. **Output the proposal list** — one entry per change, each with:
+   - Action: `CREATE` / `UPDATE` / `ARCHIVE`
+   - Target file path
+   - Brief draft of the change (positive framing applied)
+   - One-line reasoning
+
+   **No files are written in this phase.**
+
+## User approval gate
+
+Present the proposal list to the user. User accepts or rejects per item. Only accepted items move to Phase B.
+
+## Phase B — Apply (after approval)
+
+7. For each accepted item, delegate to the appropriate add-* skill or edit directly:
+   - `CREATE` rule → call `intelligence-add-rule`
+   - `CREATE` skill → call `intelligence-add-skill`
+   - `CREATE` agent → call `intelligence-add-agent`
+   - `UPDATE` existing artifact → edit the file directly, applying the proposed change
+   - `ARCHIVE` → move to `<umbrella>/_archive/` and update cross-references that point at it
+
+8. **Run `/intelligence-sync`** once all accepted items are applied.
+
+## Related skills
+
+- `intelligence-extract-skill` — when the lesson is a multi-step workflow to be made reusable
+- `intelligence-review-skills` — broader audit across existing intelligence/ artifacts
+- `intelligence-add-rule`, `intelligence-add-skill`, `intelligence-add-agent` — each authors one artifact; Phase B delegates to them

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

@@ -0,0 +1,86 @@
+---
+name: intelligence-review-skills
+description: "Audit the intelligence layer for duplication, drift, size, hardcoded paths and framing"
+argument-hint: "[target: rules|agents|skills|all]"
+agent: intelligence-architect
+---
+
+# Review the intelligence layer
+
+Read-only audit of the project's rules, agents and skills, ending in a punch-list. This skill owns the **generic** audit — everything true of any repository. A project that adds laws of its own layers a thin project audit on top and invokes this one; it never re-implements these checks.
+
+Name reflects the umbrella usage of "skills" for all AI artifacts (rules + agents + skills).
+
+## 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.
+
+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.
+
+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.
+
+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.
+
+## Steps
+
+5. **Pull git history** (when available) for each artifact — last edit, edit count, first-add date. A stale candidate has no recent edits *and* nothing cross-referencing it.
+
+6. **Run the detection checks.** Judgement decides; the checks only make a finding evidence rather than an impression.
+
+   | Check | What it is | Proposed action |
+   |---|---|---|
+   | **Duplicate content** | Two artifacts cover overlapping scope, or their descriptions share trigger phrases | `MERGE` — present both, propose one |
+   | **Misplaced content** | A checklist or procedure in an agent body; a convention in an agent; a workflow in a rule; expertise in a skill (the *Pick the right artifact* table in `intelligence-authoring`) | `MOVE` — a move, not a rewrite: both files change together |
+   | **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 |
+   | **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 |
+   | **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 |
+   | **Unbacked reason** | A rule asserts a *why* — a number, a measurement, a tool's behaviour — that nothing in the repo or in that tool's documentation supports | `FLAG` — an invented reason is worse than none: it sounds like evidence. Surface it with a draft; never rewrite the meaning yourself |
+   | **Always-on rule that should be scoped** | A concern that only matters in one area, loaded into every session and inlined into `AGENTS.md` | `SCOPE` — add `paths:`, or justify the cost out loud |
+   | **Weak / duplicate description** | Identical to a sibling, or too vague to choose between them | `DIFFERENTIATE` — add the distinguishing trigger |
+   | **Description over budget** | Over ~250 characters (the shared registry budget); over **1024** the tools reject the artifact outright | `TRIM` — keep the distinguishing trigger, drop the rest |
+   | **Missing frontmatter field** | `name` or `description` absent | `PATCH` — add it |
+   | **Orphan rule** | Nothing points at it and nothing loads it | `FLAG` — intentional, or dead? |
+
+   Detection commands, portable on purpose — no `\b` and no `-P`, so the same command works in Git Bash on Windows, on macOS (BSD grep) and on Linux. Run each over the source directories resolved in step 2, never over generated output:
+
+   ```sh
+   # R1 — a markdown link from one rule to another
+   grep -rnE '\]\([^)]*\.md\)' <rule-dirs>
+
+   # R2 — machine facts in a rule (a shell, someone's home directory, a drive letter)
+   grep -rinE 'powershell|cmd\.exe|/Users/|/home/|[A-Za-z]:[\\]' <rule-dirs>
+
+   # R3 — a path baked into a skill's steps, excluding the skill's own bundle
+   grep -rnE --include=SKILL.md '[A-Za-z0-9._-]+/[A-Za-z0-9._/-]+\.[A-Za-z0-9]+' <skill-dirs> \
+     | grep -vE '(^|[^A-Za-z0-9._/-])(references|scripts|assets)/'
+
+   # R4 — skills whose body never mentions verifying anything (-L lists files with NO match)
+   grep -riLE --include=SKILL.md 'verif|expect|assert|check|test|IS_STATUS' <skill-dirs>
+   ```
+
+   `R4` is a coarse net, not a verdict: a skill that merely *mentions* a verification command anywhere passes it. Read the final step of every skill regardless — the question is whether something at the end **proves the work landed**, not whether the word appears.
+
+7. **Ask subtraction first.** Before proposing any `SPLIT`, `REWRITE` or `PATCH`, ask whether the artifact should exist at all, whether two should become one, and whether the rule could be replaced by a gate the model cannot skip. A deletion is a better outcome than a tidy-up, and the punch-list should say so when it is true.
+
+8. **Build the punch-list**: finding, target file, proposed action, one-line reasoning, priority (1 = high-impact: duplication, misplaced content, an artifact that should not exist; 3 = low: description tweaks). Read-only — this skill writes nothing.
+
+## User approval gate
+
+The user accepts items individually; bulk-accept for low-impact tweaks is fine. Anything that changes **meaning** (a law, a boundary, a gate, an unbacked reason) is surfaced with a draft and left to the human who owns it — never auto-fixed.
+
+## Apply phase
+
+9. Accepted items go to `intelligence-learn-from-context` Phase B, which owns the write machinery — do not invent a second apply path. Pass the action, the target file, the drafted change and the reasoning.
+
+10. Run `/intelligence-sync` once, after all accepted items are applied, and report one line per artifact: **pass / fixed (what) / flagged (for whom)**.
+
+## Related skills
+
+- `intelligence-learn-from-context` — single-lesson capture; this skill's apply phase delegates to its Phase B
+- `intelligence-extract-skill` — when the audit surfaces a workflow that should become a skill

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

@@ -0,0 +1,18 @@
+---
+name: intelligence-sync
+description: "Sync intelligence to enabled IDE targets"
+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.
+
+> **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.
+
+## 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:`.

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

@@ -0,0 +1,42 @@
+---
+name: intelligence-uninstall-adapter
+description: "Disable IDE adapter and clean up output"
+argument-hint: <target-name>
+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/`).
+
+## Steps
+
+1. Set `enabled: false` for the target in `config.yaml`.
+
+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.
+
+   | Target | Remove | Keep (never adapter-owned) |
+   |---|---|---|
+   | `claude` | `.claude/rules/`, `.claude/agents/`, skill subdirs in `.claude/skills/` | `.claude/` itself, `settings.json`, `settings.local.json`, `commands/` |
+   | `cursor` | `.cursor/rules/`, `.cursor/agents/`, `.cursor/skills/` | `.cursor/` itself, `settings.json` |
+   | `copilot` | `.github/instructions/`, `.github/prompts/`, `.github/agents/`, skill subdirs in `.github/skills/` | `.github/` itself, `workflows/`, `ISSUE_TEMPLATE/`, a hand-authored `copilot-instructions.md` |
+   | `codex` | `.codex/agents/` | `.codex/` itself |
+   | `pi` | `.pi/intelligence-sync/`, `.pi/extensions/intelligence-sync-rules.ts`, `.pi/prompts/intelligence-agent-*.md` | `.pi/settings.json`, any other extension or prompt |
+   | `opencode` | `.opencode/agents/`, and only the files in `.opencode/commands/` carrying the `<!-- Generated by intelligence-sync. Do not edit manually. -->` marker | `.opencode/opencode.json`, hand-authored commands |
+   | `agents` | `AGENTS.md` — only if the user confirms; it is a committed project doc | — |
+
+   `.agents/skills/` is **shared** by `codex`, `pi` and `opencode`. Remove it only when none of those three remains enabled.
+
+   For an adapter not in this table (a project adapter under `<umbrella>/adapters/`), read its `sync_to_<name>()` cleanup block: whatever it deletes on every re-sync is exactly what it owns.
+
+3. Remove the adapter's paths from `.gitignore` if nothing else needs them.
+
+4. Run `/intelligence-sync` to regenerate the remaining targets.
+
+5. **Verify** — an uninstall that removed the wrong thing must not pass quietly:
+   - sync reports `IS_STATUS=ok`;
+   - every path listed under *Remove* for this target is gone;
+   - every path listed under *Keep* still exists, with its content intact (`.github/workflows/`, `.claude/settings.json`, `.opencode/opencode.json`, hand-authored commands);
+   - the other enabled targets still produce their output.
+
+6. Report: adapter disabled, which paths were removed, which were deliberately kept, and the verification result.

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

@@ -0,0 +1,159 @@
+---
+name: intelligence-update
+description: "Update or migrate intelligence-sync: discover engine, read changelog, run migration chain, verify"
+argument-hint: "[--yes]"
+agent: intelligence-operator
+---
+
+# Update intelligence-sync
+
+You are the **intelligent driver** of an update. The bash engine is
+deterministic and fail-closed — it never guesses; on any state it cannot
+resolve it prints `IS_STATUS=<code>` and stops. Your job: discover the engine,
+understand what is changing (read the CHANGELOG across the version gap), run
+the migration chain, branch on the status, and **verify afterward**. Ask the
+user only when genuinely ambiguous.
+
+Trigger: the user says something like *"update / migrate intelligence-sync"*.
+They never run shell commands by hand — you do.
+
+## Key facts
+
+- **Umbrella** = whatever directory holds `config.yaml` (`intelligence/`,
+  `Intelligence/`, …). Never assume the name — find it.
+- **Engine = a module discovered by ROLE, not by name**: a directory under
+  the umbrella whose `scripts/sync.sh` **and** `scripts/VERSION` both exist
+  (conventionally `sync/`, but never assume the folder name).
+- **Applied schema version** is the frozen contract key
+  `sync_version` in `config.yaml` (a permanent top-level scalar;
+  absent ⇒ pre-0.3.1). **Engine version** is `<module>/scripts/VERSION`.
+  The gap between them is the set of breaking changes to apply.
+- Pre-0.3.1 projects have the engine flat at `<umbrella>/scripts/` and **no**
+  `sync_version` key. Their frozen `update.sh` fails closed
+  against the modular upstream (changes nothing) — you bootstrap the first hop.
+- The `intelligence-` skill prefix is **reserved** for upstream meta-skills.
+
+## Steps
+
+### 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
+`<M>/scripts/sync.sh` and `<M>/scripts/VERSION`.
+
+- Several candidates → pick the one with the highest `scripts/VERSION`.
+- A module engine exists → use it; **never** fall back to a flat
+  `<umbrella>/scripts/` even if present (that's stale legacy).
+- No module engine, only flat `<umbrella>/scripts/` (or nothing) → this is a
+  pre-0.3.1 / un-bootstrapped project; go to step 2's bootstrap.
+- No `config.yaml` at all → not bootstrapped; point the user at upstream
+  `INIT.md` and stop.
+
+### 2. Fetch upstream (read-only) — do NOT write into the project yet
+Clone upstream into a temp dir (default
+`https://github.com/ainova-systems/intelligence-sync`, or the user's
+`REPO_URL`/fork). The upstream module is always `intelligence/sync/`.
+
+```
+git clone --depth=1 <repo> <tmp>
+```
+
+**Make no changes to the project before step 3's confirmation.** In
+particular do not copy anything into `<umbrella>/sync` yet — that would
+modify (and could downgrade) an already-modular project even if the user then
+declines. The temp clone is only for reading the CHANGELOG and as the source
+for the eventual write.
+
+### 3. Understand what is changing (changelog-aware)
+Determine the project's current version = the `sync_version`
+value in `config.yaml`, or `0.0.0` if the key is absent (pre-0.3.1). The
+engine version = `<tmp>/intelligence/sync/scripts/VERSION`.
+
+Read `<tmp>/CHANGELOG.md`. For every release in the range
+**`current < release <= engine`** (inclusive of the target release — its
+entry holds the destination's breaking post-conditions), read its entry. Pay
+special attention to any **`### Breaking`** subsection (the
+machine-distinguishable marker). Build a short list of breaking items, new
+migrations, and anything to verify afterward. Surface it to the user; without
+`--yes`, let them confirm before any write.
+
+### 3a. Ensure the engine to run (only now, post-confirmation)
+- **Modular project** (a module engine was discovered in step 1): run *its*
+  `update.sh` — at the discovered module dir, whatever its name. `update.sh`
+  re-clones upstream internally, shows the diff, and is authoritative; do not
+  hand-copy over the module.
+- **No module engine** (pre-0.3.1 flat or un-bootstrapped): only here create
+  the module from the temp clone, and only after confirmation:
+  ```
+  mkdir -p <umbrella>/sync
+  cp -r <tmp>/intelligence/sync/. <umbrella>/sync/
+  ```
+  then run `<umbrella>/sync/scripts/update.sh`.
+
+### 4. Run the engine
+Run the `update.sh` of the engine determined in 3a — the **discovered module
+dir** for a modular project (whatever its name), or the just-created
+`<umbrella>/sync` for the legacy bootstrap path:
+
+```
+bash <engine-module>/scripts/update.sh --yes   # omit --yes to confirm the diff
+```
+Capture stdout; find the last `IS_STATUS=<code> [IS_DETAIL=...]` line.
+
+### 5. Branch on `IS_STATUS`
+
+| Code | Meaning | Action |
+|---|---|---|
+| `ok` | Already current | Go to step 6. |
+| `migrated` | Migration chain applied | Go to step 6; note the relocation/changes. |
+| `aborted-incomplete` | Staged module incomplete; legacy intact (safe) | Re-run step 2–4 once (clone hiccup). Persists → show output, stop, don't hand-fix. |
+| `ahead-of-engine` | Project schema newer than this engine | Do **not** downgrade. Point `REPO_URL` at the correct/newer upstream, or accept it's already ahead. Stop. |
+| `needs-update` | Pending breaking changes (sync refused) | Expected pre-migration; proceed — `update.sh` is the migrator. If it persists *after* update, investigate. |
+| `config-missing` | No `config.yaml` | Not bootstrapped — direct user to `<umbrella>/sync/INIT.md`. Stop. |
+| `error` | Engine couldn't proceed | Show message; check `REPO_URL`. Stop. |
+| *(no status)* | Engine crashed before contract | Show full output; don't modify the tree. Stop. |
+
+On any failure code, first re-read the upstream `CHANGELOG.md` entries for `current < release <= engine` (esp. `### Breaking`) — the breaking change usually explains the error and what the user must do — before retrying or escalating.
+
+Genuinely **ambiguous** tree (e.g. both a legacy flat `<umbrella>/scripts/`
+and a populated module, no clear `sync_version`): inspect both,
+summarize the difference, ask the user which is authoritative, apply their
+choice. Never guess.
+
+### 6. Verify (always, after `ok`/`migrated`)
+
+Structural — always:
+- No `intelligence-*` directory directly under `<umbrella>/skills/`
+  (meta-skills live only in the module's `skills/`).
+- Project content intact: `<umbrella>/{rules,agents}/` and any
+  non-`intelligence-` skills untouched.
+- `config.yaml` has `sync_version` equal to the engine
+  `scripts/VERSION`, and `sources.skills` includes the module skills path
+  exactly once.
+
+Changelog-driven — per release crossed:
+- For each **`### Breaking`** item in the crossed range, verify its stated
+  post-condition actually holds (e.g. a removed/renamed file is gone, a
+  config-schema change is reflected). If a breaking item has no verifiable
+  post-condition, state that you could not auto-verify it.
+
+Then regenerate IDE outputs:
+```
+bash <umbrella>/sync/scripts/sync.sh
+```
+Relay any model-drift report. Finally summarize: versions before→after, the
+breaking changes applied, verification result, anything the user must act on.
+Clean up the temp clone.
+
+## Notes
+
+- Everything is **idempotent**. Re-running on a current project is a safe
+  no-op (`IS_STATUS=ok`).
+- Correctness rests on the engine's idempotent structural preconditions, not
+  on the version stamp — a missing/wrong `sync_version` cannot
+  cause a needed migration to be skipped; it only weakens the
+  `ahead-of-engine` guard until re-stamped.
+- Never touch `config.yaml` beyond what the engine does (the idempotent
+  `sources.skills` line and the `sync_version` key). Never
+  move/delete project skills, rules, or agents.
+- Sibling modules beside the engine module are independent — only operate on
+  the discovered engine module.

package/package.json

@@ -0,0 +1,39 @@
+{
+  "name": "@ainova-systems/intelligence",
+  "version": "0.11.0-rc.1",
+  "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"
+  },
+  "files": [
+    "bin",
+    "cli",
+    "engine",
+    "registry"
+  ],
+  "engines": {
+    "node": ">=18"
+  },
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/ainova-systems/intelligence-sync.git"
+  },
+  "homepage": "https://github.com/ainova-systems/intelligence-sync#readme",
+  "bugs": {
+    "url": "https://github.com/ainova-systems/intelligence-sync/issues"
+  },
+  "keywords": [
+    "ai",
+    "agents",
+    "claude-code",
+    "cursor",
+    "copilot",
+    "codex",
+    "agents-md",
+    "rules",
+    "skills",
+    "prompt-engineering",
+    "package-manager"
+  ]
+}

package/registry/index.yaml

@@ -0,0 +1,15 @@
+# The default Intelligence Registry index, bundled with the CLI.
+#
+# Maps a package name to the git repo (and path inside it) the package lives
+# in. Needed exactly when a name is not the repo — monorepos like
+# intelligence-dev-packs. A name absent here falls through to the convention:
+# @org/name -> https://github.com/org/name.git, content at the repo root.
+# Organizations override or extend this per scope with `intelligence registry
+# add @scope <registry-repo-url>`.
+packages:
+  "@ainova-systems/core":
+    url: "https://github.com/ainova-systems/intelligence-dev-packs.git"
+    path: "packs/core"
+  "@ainova-systems/spec":
+    url: "https://github.com/ainova-systems/intelligence-dev-packs.git"
+    path: "packs/spec"