@ainova-systems/intelligence 0.11.0-rc.6 → 0.11.0-rc.8

package/{engine → packages/sync}/rules/intelligence-authoring.md

@@ -2,12 +2,12 @@
 name: intelligence-authoring
 description: "Authoring discipline for the intelligence layer - subtraction first, rule vs skill vs agent, scoping, size"
 paths:
-  - "<umbrella>/**"
+  - "<content-dir>/**"
 ---
 
 # Authoring the intelligence layer
 
-Applies when writing or changing anything under `<umbrella>/`. The mechanics — frontmatter fields, tier and access vocabulary, how each tool is fed — live in `<module>/docs/CONVENTIONS.md`. This rule is the judgement that sits on top of them.
+Applies when writing or changing anything under `<content-dir>/`. The mechanics — frontmatter fields, tier and access vocabulary, how each tool is fed — live in `<module>/references/conventions.md`. This rule is the judgement that sits on top of them.
 
 ## Subtraction is the job
 
@@ -25,9 +25,9 @@ Three ways to shorten, in order of what they are worth:
 
 ## Source of truth
 
-Edit the sources listed in `<manifest>` — the `rules/`, `agents/` and `skills/` directories it names — and `<manifest>` itself. A source that arrived from the engine or an installed package is not yours to edit either — it is replaced on the next update or install; change it in its own repository. Everything else is derived: `.claude/`, `.cursor/`, `.github/{instructions,agents,skills}/`, `.codex/`, `.agents/skills/`, `.pi/`, `.opencode/` and `AGENTS.md` are **generated output**, and a hand edit there survives exactly until the next sync.
+Edit the project-owned sources listed in `<manifest>` — the `rules/`, `agents/` and `skills/` directories it names — and `<manifest>` itself. An installed package source is replaced by CLI lifecycle/package operations; change it in its own repository. Everything else is derived: `.claude/`, `.cursor/`, `.github/{instructions,agents,skills}/`, `.codex/`, `.agents/skills/`, `.pi/`, `.opencode/` and `AGENTS.md` are **generated output**, and a hand edit there survives exactly until the next sync.
 
-`<module>/` is the engine's own content. It owns its own rules, agents and meta-skills, and every engine update replaces it wholesale, so a local edit there is lost. Fix it upstream instead.
+`<module>/` is the installed sync package's content. Package operations replace it, so a local edit there is lost. Fix it upstream instead.
 
 After any change: `<sync-cmd>`. A change that was not synced does not exist for any tool.
 
@@ -84,7 +84,7 @@ The verb just names the action — `add-`, `run-`, `review-`, `extract-`, `plan-
 
 Two verbs are told apart by what already exists. **`add-` puts one new member into a set that is already there** — a field on an existing type, a record among records, a component in the inventory the project keeps — so the noun names the member, and the number of files it takes to land is not the point. **`create-` brings the container itself into existence**, where nothing hosted it before. Neither verb describes how a skill is factored inside, so splitting a skill's internals never renames it.
 
-`intelligence-` is **reserved** for the engine's own artifacts. A project skill carrying that prefix collides with engine ownership — everything under the prefix is the engine's to replace or remove on update — rename it.
+`intelligence-` is **reserved** for the sync package's own artifacts. A project skill carrying that prefix collides with package-owned meta-skills in generated outputs — rename it.
 
 ### Shape
 
@@ -109,6 +109,6 @@ The goal is subtraction, above. These are only the line past which something is
 
 ## Verifying a change to this layer
 
-The per-artifact checks are a procedure, not a constraint to hold in mind while doing other work — so they live in the meta-skills, not here. Invoke the one that matches what you are doing: `intelligence-add-rule`, `intelligence-add-agent`, `intelligence-add-skill`, `intelligence-extract-skill`, `intelligence-review-skills`, `intelligence-learn-from-context`, `intelligence-sync`, `intelligence-update`, `intelligence-install-adapter`, `intelligence-uninstall-adapter`.
+The per-artifact checks are a procedure, not a constraint to hold in mind while doing other work — so they live in the meta-skills, not here. Invoke the one that matches what you are doing: `intelligence-add-rule`, `intelligence-add-agent`, `intelligence-add-skill`, `intelligence-extract-skill`, `intelligence-review-skills`, `intelligence-learn-from-repository`, `intelligence-learn-from-context`, `intelligence-sync`, `intelligence-update`, `intelligence-install-adapter`, `intelligence-uninstall-adapter`.
 
 A change to this layer is done when `<sync-cmd>` reports `IS_STATUS=ok` and the skill you invoked reports clean.

package/{engine → packages/sync}/skills/intelligence-add-agent/SKILL.md

@@ -9,7 +9,7 @@ argument-hint: <domain> [description]
 ## Steps
 
 1. **Determine domain prefix** (the scope is required):
-   - **Reuse the existing domain when one fits**: list `<umbrella>/agents/` and `<umbrella>/skills/`. 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 `<content-dir>/agents/` and `<content-dir>/skills/`. 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 `<manifest>` → `project.name`
      - Backend service / API component → `backend-`
@@ -21,7 +21,7 @@ argument-hint: <domain> [description]
    - 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 agent needs a domain prefix.** If the scope is unclear, ask the user before proceeding.
 
-2. **Check existing agents**: Read `<umbrella>/agents/` to avoid duplicates. If an agent for this domain exists, ask user whether to update it instead.
+2. **Check existing agents**: Read `<content-dir>/agents/` to avoid duplicates. If an agent for this domain exists, ask user whether to update it instead.
 
 3. **Determine tier and access**:
    - Developer agents: `tier: heavy`, `access: full`
@@ -36,7 +36,7 @@ argument-hint: <domain> [description]
    - Build and test commands
    - Key conventions and forbidden patterns
 
-5. **Create agent**: Write `<umbrella>/agents/<domain>-<role>.md` (create the directory if missing) with frontmatter:
+5. **Create agent**: Write `<content-dir>/agents/<domain>-<role>.md` (create the directory if missing) with frontmatter:
    ```yaml
    ---
    name: <domain>-<role>
@@ -52,11 +52,11 @@ argument-hint: <domain> [description]
 
 6. **Write body** with sections: **Expertise** -> **Boundaries** -> **Build & Verify**
    - An agent is **thin**: who it is, where it stops, how it verifies. Everything else already reaches it.
-   - **Do not tell the agent to read the rules.** Rules load on their own: Claude Code loads `.claude/rules/` into every custom subagent's startup context alongside `CLAUDE.md` (*Subagents → What loads at startup*), and Cursor / Copilot / Codex / Pi / opencode receive always-on rules inlined in `AGENTS.md`. A `Read <umbrella>/rules/<domain>.md before starting` line duplicates content the agent already has — double the tokens, and a second copy that drifts from the rule it copied.
+   - **Do not tell the agent to read the rules.** Rules load on their own: Claude Code loads `.claude/rules/` into every custom subagent's startup context alongside `CLAUDE.md` (*Subagents → What loads at startup*), and Cursor / Copilot / Codex / Pi / opencode receive always-on rules inlined in `AGENTS.md`. A `Read <content-dir>/rules/<domain>.md before starting` line duplicates content the agent already has — double the tokens, and a second copy that drifts from the rule it copied.
    - **Point at a rule, never restate it.** If you want to copy a rule into the agent, the rule is in the wrong place — move it, do not clone it.
    - **Do carry** what is genuinely the agent's own: its boundaries ("if the app is not running, stop — do not hand-write the output"), its verification commands, its definition of done.
    - All content must come from actual codebase analysis.
 
-7. **Link existing skills**: Find skills in `<umbrella>/skills/` matching this domain prefix and add them to the agent's `skills:` frontmatter.
+7. **Link existing skills**: Find skills in `<content-dir>/skills/` matching this domain prefix and add them to the agent's `skills:` frontmatter.
 
 8. **Run `/intelligence-sync`** to distribute to all enabled IDE targets.

package/{engine → packages/sync}/skills/intelligence-add-rule/SKILL.md

@@ -9,7 +9,7 @@ argument-hint: <name> [paths-glob]
 ## Steps
 
 1. **Determine rule name from domain** (the scope is required):
-   - **Reuse the existing domain when one fits**: list `<umbrella>/rules/`. If a rule file covers the target area (e.g., `backend.md`, `frontend.md`), extend it. Introduce a new domain only when the scope is materially different from all existing rules.
+   - **Reuse the existing domain when one fits**: list `<content-dir>/rules/`. If a rule file covers the target area (e.g., `backend.md`, `frontend.md`), extend it. Introduce a new domain only when the scope is materially different from all existing rules.
    - **When no existing rule fits**, derive the filename from repo structure:
      - Single / root project → use the project codename from `<manifest>` → `project.name` (e.g., `<codename>.md`)
      - Backend service / API component → `backend.md`
@@ -21,7 +21,7 @@ argument-hint: <name> [paths-glob]
    - If the repo is a monorepo with named components (e.g., `apps/billing`, `services/auth`), prefer the component name as the rule name (`billing.md`, `auth.md`).
    - **Rule filenames match the domain used by skills/agents.** If the scope is unclear, ask the user before proceeding.
 
-2. **Check existing rules**: Read `<umbrella>/rules/` to detect overlapping scope — favor extending an existing rule over creating a new one.
+2. **Check existing rules**: Read `<content-dir>/rules/` to detect overlapping scope — favor extending an existing rule over creating a new one.
 
 3. **Determine scope**:
    - If paths glob provided — scoped rule with `paths:` frontmatter
@@ -34,7 +34,7 @@ argument-hint: <name> [paths-glob]
    - Build and test commands specific to this scope
    - Anti-patterns observed in code, each paired with the positive replacement that should adopt instead
 
-5. **Create rule**: Write `<umbrella>/rules/<name>.md` (create the directory if it does not exist — the sources list already covers it):
+5. **Create rule**: Write `<content-dir>/rules/<name>.md` (create the directory if it does not exist — the sources list already covers it):
    ```yaml
    ---
    paths:

package/{engine → packages/sync}/skills/intelligence-add-skill/SKILL.md

@@ -9,7 +9,7 @@ argument-hint: <domain> <verb-noun> [description]
 ## Steps
 
 1. **Determine domain prefix** (the scope is required):
-   - **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.
+   - **Reuse the existing domain when one fits**: list `<content-dir>/skills/` and `<content-dir>/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 `<manifest>` → `project.name`
      - Backend service / API component → `backend-`
@@ -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 `<umbrella>/agents/` matching the domain
+3. **Check for existing agent**: Find an agent in `<content-dir>/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 `<umbrella>/skills/<full-name>/SKILL.md` (create the directory if missing — no config edit needed) with frontmatter:
+5. **Create skill**: Write `<content-dir>/skills/<full-name>/SKILL.md` (create the directory if missing — no config edit needed) with frontmatter:
    ```yaml
    ---
    name: <full-name>

package/{engine → packages/sync}/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 `<umbrella>/skills/` and `<umbrella>/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 `<content-dir>/skills/` and `<content-dir>/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 `<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.
+Follow the **Authoring Discipline** section in `<module>/references/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/packages/sync/skills/intelligence-install-adapter/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: intelligence-install-adapter
+description: "Research, implement, and enable a tool adapter"
+argument-hint: <adapter-name>
+agent: intelligence-operator
+---
+
+# Install an adapter
+
+The CLI owns adapter inventory, scaffolding, target state, and sync. This skill
+owns the judgement a program cannot infer: how the target tool represents
+rules, agents, and skills.
+
+## Steps
+
+1. Run `intelligence adapter list`. If `$ARGUMENTS` already exists, enable it
+   with `intelligence adapter enable $ARGUMENTS`; that command also runs a full
+   sync. Continue at verification.
+
+2. For a missing adapter, research the tool's current authoritative
+   documentation: discovery paths, frontmatter/schema, scoping, naming,
+   agents, skills, and whether it reads `AGENTS.md`. Record links and separate
+   verified behavior from assumptions.
+
+3. Run `intelligence adapter create $ARGUMENTS`, then implement
+   `sync_to_$ARGUMENTS()` in the scaffolded project adapter. Follow
+   `<module>/references/adapters.md` and the closest built-in. Keep writes beneath
+   the configured output, make reruns idempotent, and make owned cleanup paths
+   explicit. Ignore only those owned paths; shared roots remain trackable.
+
+4. Run `bash -n` on the project adapter, then
+   `intelligence adapter enable $ARGUMENTS`. If the CLI says the adapter
+   requires `agents`, enable that adapter first.
+
+5. Require `IS_STATUS=ok`, inspect generated files against the researched
+   format, run the tool's validator when one exists, and finish with
+   `intelligence status --check`. Report evidence, output paths, and any
+   unsupported artifact type.

package/{engine → packages/sync}/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.** 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.
+1. **Read authoring conventions first.** The paths below are localized to this project at sync time: `<content-dir>/` is the project content directory, `<module>/` the installed sync package, and `<manifest>` the root manifest. The meta-skills live in `<module>/skills/`, not directly under the content directory. Load `<module>/skills/intelligence-add-rule/SKILL.md`, `<module>/skills/intelligence-add-skill/SKILL.md`, `<module>/skills/intelligence-add-agent/SKILL.md`, and `<module>/references/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.
 
@@ -32,7 +32,7 @@ The original negative pattern stays in the rule body as an illustrative example
    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`)
+   - Behavioral preference, tone, communication style → **rule** (`<content-dir>/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
@@ -58,7 +58,7 @@ Present the proposal list to the user. User accepts or rejects per item. Only ac
    - `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
+   - `ARCHIVE` → move to `<content-dir>/_archive/` and update cross-references that point at it
 
 8. **Run `/intelligence-sync`** once all accepted items are applied.
 

package/packages/sync/skills/intelligence-learn-from-repository/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: intelligence-learn-from-repository
+description: "Tailor Intelligence to an initialized repository"
+---
+
+# Learn from Repository
+
+Use after `intelligence init` creates or converts a project. The CLI owns the
+mechanical setup; this skill adds only repository-specific judgement.
+
+## Analyze
+
+1. Run `intelligence status --check`. If setup is missing or incomplete, stop
+   and ask the user to run `intelligence init`; do not reproduce CLI mechanics.
+2. Read `<manifest>` and resolve `<content-dir>` and the configured source
+   directories. Load `<module>/references/conventions.md` and the bundled
+   `intelligence-add-rule`, `intelligence-add-skill`, and
+   `intelligence-add-agent` skills before proposing authored content.
+3. Inspect repository evidence: its README and contributor instructions,
+   language and package manifests, build and test entry points, source layout,
+   CI, existing agent instructions, and existing project-owned rules, agents,
+   and skills. Treat documentation as a claim and verify important behavior in
+   code or executable configuration.
+4. Inventory what initialization already preserved or installed. Do not
+   recreate package-owned content, duplicate existing instructions, or convert
+   generated target output into source content.
+5. Propose the smallest useful project-owned layer. Prefer updating an existing
+   artifact over creating a sibling. Each proposal must state:
+   - `CREATE`, `UPDATE`, or `KEEP`;
+   - the source path;
+   - the repository evidence supporting it;
+   - the concise content or responsibility it would add.
+
+Analysis is read-only. Present the proposal and request approval per change.
+It is valid to recommend no new artifacts when the repository already explains
+itself well.
+
+## Apply after approval
+
+6. Apply only accepted proposals. Delegate new artifacts to
+   `intelligence-add-rule`, `intelligence-add-skill`, or
+   `intelligence-add-agent`; update an existing project-owned artifact directly
+   when that is the smaller change. Never edit installed package content or
+   generated tool output.
+7. Run `intelligence sync`, then `intelligence status --check`. Completion
+   requires `IS_STATUS=ok` and a clean consistency check.
+8. Report what was created, updated, or deliberately left unchanged. Remind the
+   user to review and commit generated and source changes according to project
+   policy.
+
+## Related skill
+
+Use `intelligence-learn-from-context` later to preserve a lesson learned during
+a working session. This skill learns the repository's existing structure and
+workflow during onboarding.

package/{engine → packages/sync}/skills/intelligence-review-skills/SKILL.md

@@ -9,15 +9,15 @@ agent: intelligence-architect
 
 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).
+The name uses "skills" as shorthand for all AI artifacts (rules, agents, and skills).
 
 ## Scope: what to read, and what to leave alone
 
-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.
+1. **Resolve the layout — never assume folder names.** `<content-dir>/` is the project content directory, `<module>/` the installed sync package, `<manifest>` the root manifest — all localized to this project at sync time. Read authoring conventions from `<module>/references/conventions.md` and the `intelligence-authoring` rule.
 
-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.
+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, they may be nested, and installed packages live under `.intelligence/packages/`. Take the list from the manifest; 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: 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.
+3. **Skip installed package sources.** Sources under `<module>/` (`<module>/rules`, `<module>/agents`, `<module>/skills/intelligence-*`) are package-owned and restored by CLI lifecycle operations, so a local "fix" is not durable. Never propose a project-local edit to them. If one is wrong, make an upstream proposal instead.
 
 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.
 
@@ -36,9 +36,9 @@ Name reflects the umbrella usage of "skills" for all AI artifacts (rules + agent
    | **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 `<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, which replaces or removes everything under it on update |
+   | **Reserved prefix** | A project artifact named `intelligence-*` | `RENAME` — the prefix belongs to the sync package and collides in generated output |
    | **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/` |
+   | **Stale** | No edits in 6+ months and nothing cross-references it | `ARCHIVE` — move to `<content-dir>/_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 |

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

@@ -0,0 +1,20 @@
+---
+name: intelligence-sync
+description: "Sync intelligence to enabled adapters"
+agent: intelligence-operator
+context: fork
+---
+
+# Sync intelligence
+
+1. Run `intelligence sync` (or `intelligence sync <adapter>` when one adapter
+   was requested). For v2, this command first aligns project schema/content
+   with the installed CLI and restores a missing package store strictly from
+   `intelligence.lock`.
+2. Require final `IS_STATUS=ok`; relay per-adapter counts and any model-drift
+   or unsynced-source warnings.
+3. In CI, a required tracked project upgrade is intentionally refused. Report
+   the instruction to run `intelligence init --apply` locally, review and
+   commit its diff; never bypass the gate. A frozen restore refusal means the
+   manifest and lock disagree or a pinned ref moved—report it without
+   hand-copying package content.

package/packages/sync/skills/intelligence-uninstall-adapter/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: intelligence-uninstall-adapter
+description: "Disable an adapter and assess its generated output"
+argument-hint: <adapter-name>
+agent: intelligence-operator
+---
+
+# Uninstall an adapter
+
+1. Run `intelligence adapter list`, then
+   `intelligence adapter disable $ARGUMENTS`. Disabling changes target state
+   and deliberately keeps generated output.
+2. If generated files should also be removed, inspect the adapter's cleanup
+   block to identify exactly what it owns. Show that list and obtain approval
+   before deleting it; never delete a shared output root.
+3. For a project adapter that should be deleted, run
+   `intelligence adapter remove $ARGUMENTS` after it is disabled. This prompts
+   by default (`--apply` is the explicit non-interactive form) and also keeps
+   generated output. Built-in adapter source cannot be removed.
+4. Remove obsolete `.gitignore` entries only when no remaining adapter needs
+   them. Sync the remaining enabled adapters when any exist.
+5. Verify with `intelligence adapter list` and `intelligence status --check`:
+   the adapter is disabled or removed as requested, retained files are intact,
+   and only approved adapter-owned output was deleted.

package/packages/sync/skills/intelligence-update/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: intelligence-update
+description: "Interpret an update plan and verify breaking post-conditions"
+argument-hint: "[@scope/name]"
+agent: intelligence-operator
+---
+
+# Update intelligence
+
+The CLI owns planning and application. This skill interprets the plan, reads
+the changelog across an engine-version gap, obtains approval, and verifies the
+result.
+
+## Steps
+
+1. Run `intelligence update --preview` (or
+   `intelligence update $ARGUMENTS --preview` for one named package). Use its
+   CLI, project, and package sections as the complete plan; do not re-resolve
+   versions independently.
+
+2. If the CLI or project engine version would change, read the authoritative
+   `CHANGELOG.md` at `https://github.com/ainova-systems/intelligence` for every
+   release in **`current < release <= target`**. If it is unavailable, stop
+   before changing versions. Turn every crossed `### Breaking` item into a
+   post-condition to verify.
+
+3. Show the plan and breaking checklist to the user. The command without a
+   mode also shows the plan and prompts; after approval, use `--apply` for an
+   unambiguous non-interactive execution.
+
+4. If the plan reports a newer global CLI, run exactly the npm command it
+   prints after approval, then rerun `intelligence update --preview` with the
+   new executable. Apply the resulting plan with `intelligence update --apply`,
+   or `intelligence update $ARGUMENTS --apply` when one package was requested.
+
+5. An applied update that renders must finish with `IS_STATUS=ok`; preserve and
+   stop on any other status. Then run `intelligence status --check`. Do not run
+   a duplicate sync after `update --apply`. Verify every crossed breaking
+   post-condition directly and report any item that cannot be machine-verified.
+
+Report versions before and after, the applied plan, post-condition results,
+and any remaining action. On a refusal, preserve the full error and stop
+instead of invoking hidden lifecycle operations.