@ainova-systems/intelligence 0.14.0 → 0.15.0

package/engine/ENGINE_SHA

@@ -1 +1 @@
-a9cf448bc3f2944c988ce57581822df081195ca2
+b12551947be83587f4f74e79c5a56765a18dd52f

package/engine/VERSION

@@ -1 +1 @@
-0.14.0
+0.15.0

package/engine/lib/contract.sh

@@ -53,7 +53,7 @@ stamp_schema_version() {
 # --- bash ↔ skill status contract -------------------------------------------
 # Bash is the deterministic, fail-closed core: it never guesses. Any state it
 # cannot resolve safely is reported as a machine-readable status line on
-# stdout plus a stable exit code, and the intelligence-update SKILL (the
+# stdout plus a stable exit code, and the intelligence-upgrade SKILL (the
 # intelligent layer) decides what to do. Codes are part of the public
 # contract — do not renumber.
 IS_RC_OK=0                  # success (synced / migrated / nothing to do)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ainova-systems/intelligence",
-  "version": "0.14.0",
+  "version": "0.15.0",
   "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/packages/sync/agents/intelligence-architect.md

@@ -4,14 +4,10 @@ description: "Design and prune the intelligence layer - rule vs skill vs agent,
 tier: heavy
 access: full
 skills:
-  - intelligence-add-rule
-  - intelligence-add-agent
-  - intelligence-add-skill
-  - intelligence-extract-skill
-  - intelligence-compact-context
-  - intelligence-review-skills
+  - intelligence-update-context
+  - intelligence-review-context
   - intelligence-learn-from-repository
-  - intelligence-learn-from-context
+  - intelligence-learn-from-session
 ---
 
 # Intelligence architect
@@ -44,14 +40,12 @@ The per-artifact checks are procedure, so they live in the meta-skills rather th
 
 | Skill | Use it to |
 |---|---|
-| `intelligence-add-rule` / `intelligence-add-agent` / `intelligence-add-skill` | author one artifact |
-| `intelligence-extract-skill` | turn an observed workflow into a skill |
-| `intelligence-compact-context` | reduce context without changing behavior or teaching terse output |
-| `intelligence-review-skills` | audit the layer for duplication, drift, size, hardcoded paths |
+| `intelligence-update-context` | create, revise, or remove rules, agents, and skills |
+| `intelligence-review-context` | audit the layer and propose reductions that preserve behavior |
 | `intelligence-learn-from-repository` | recover and complete first-time repository onboarding |
-| `intelligence-learn-from-context` | fold one later session lesson into an established layer |
+| `intelligence-learn-from-session` | capture session lessons and observed workflows |
 | `intelligence-sync` | project the source to every tool channel |
-| `intelligence-update` | interpret and apply the CLI's unified update plan |
-| `intelligence-install-adapter` / `intelligence-uninstall-adapter` | research and manage a tool adapter |
+| `intelligence-upgrade` | interpret and apply the CLI's unified update plan |
+| `intelligence-manage-adapters` | enable, disable, remove, and assess output cleanup |
 
 A change is done when the sync is green and the skill you invoked reports clean. Size is a separate judgement: the caps are ceilings, not quotas, and a short artifact is not a defect.

package/packages/sync/agents/intelligence-operator.md

@@ -5,9 +5,8 @@ tier: standard
 access: full
 skills:
   - intelligence-sync
-  - intelligence-update
-  - intelligence-install-adapter
-  - intelligence-uninstall-adapter
+  - intelligence-upgrade
+  - intelligence-manage-adapters
 ---
 
 # Intelligence operator
@@ -27,7 +26,7 @@ the operation in prose.
 ## Boundaries
 
 - **Every flow goes through its skill.** The steps and their guards live in `intelligence-sync`,
-  `intelligence-update`, `intelligence-install-adapter` and `intelligence-uninstall-adapter`;
+  `intelligence-upgrade` and `intelligence-manage-adapters`;
   improvising around them produces an unverified version of the same work.
 - **Operating is not authoring.** A change to what an artifact says - a rule body, an agent persona,
   a skill's steps - belongs to `intelligence-architect` and the authoring meta-skills. This agent

package/packages/sync/references/conventions.md

@@ -422,7 +422,7 @@ The public lifecycle is deliberately compact:
 
 Implement Intelligence schema changes as idempotent structural checks. Stage and verify replacement state before deleting or replacing prior state. A stale engine refuses a manifest whose `schema_version` is a newer major; a newer minor or patch within the same major warns once and proceeds without restamping the project. Normal project entry points close a behind-project gap through lifecycle preflight.
 
-Breaking changelog entries use a `### Breaking` checklist of verifiable post-conditions. The update skill reads every release across the version gap, chooses the package/CLI/project command sequence and verifies those conditions after the deterministic command completes.
+Breaking changelog entries use a `### Breaking` checklist of verifiable post-conditions. The `intelligence-upgrade` skill reads every release across the version gap, chooses the package/CLI/project command sequence and verifies those conditions after the deterministic command completes.
 
 ### Engine status contract
 

package/packages/sync/rules/intelligence-authoring.md

@@ -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-repository`, `intelligence-learn-from-context`, `intelligence-sync`, `intelligence-update`, `intelligence-install-adapter`, `intelligence-uninstall-adapter`.
+The per-artifact authoring checks belong to `intelligence-update-context`. Session learning, repository onboarding, and accepted review findings use that same procedure. Invoke `intelligence-learn-from-session` to capture a lesson or workflow, `intelligence-learn-from-repository` for initial migration and recovery, and `intelligence-review-context` for audits and reductions. Operational work uses `intelligence-sync`, `intelligence-upgrade`, or `intelligence-manage-adapters`.
 
 A change to this layer is done when `<sync-cmd>` reports `IS_STATUS=ok` and the skill you invoked reports clean.

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

@@ -39,8 +39,7 @@ mechanics; this skill supplies repository judgement.
 
 5. Read `<manifest>` and resolve 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. When
+   `intelligence-update-context` skill before proposing authored content. When
    preserved or legacy instructions exist, also read
    `<module>/references/onboarding-migration.md` and use its inventory,
    reverse-mapping, packaging-safety, and stale-reference procedures.
@@ -87,10 +86,10 @@ explains itself well.
 
 ## Apply after approval
 
-9. 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 smaller, and edit an accepted manifest header directly. Never edit
+9. Apply only accepted proposals. Pass all artifact changes to
+   `intelligence-update-context`, retaining the migration evidence and acceptance
+   scope. Defer its batch sync to step 10 so the accepted manifest header and
+   content are verified together. Edit an accepted header directly. Never edit
    installed package content or generated tool output.
 10. Run `intelligence sync`, then `intelligence status --check`. Inspect the
     relevant generated `AGENTS.md`, Cursor rules, Claude rules, and any
@@ -106,6 +105,6 @@ explains itself well.
 
 ## Later learning
 
-After onboarding is complete, use `/intelligence-learn-from-context` to capture
+After onboarding is complete, use `/intelligence-learn-from-session` to capture
 a durable lesson from a working session. It does not repeat repository
 onboarding.

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

@@ -0,0 +1,50 @@
+---
+name: intelligence-learn-from-session
+description: "Capture session lessons and workflows in project context"
+agent: intelligence-architect
+---
+
+# Learn from a session
+
+Capture a durable preference, working pattern, recurring friction, or successful
+workflow from a session in an established Intelligence project. This skill owns
+identifying and generalizing the lesson; `intelligence-update-context` owns writing it.
+
+## Verify readiness
+
+1. Locate `<manifest>`, `<content-dir>`, and `<module>`, then run
+   `intelligence status --check`. Missing or inconsistent setup, an onboarding
+   pending header, or unresolved preserved instructions routes to
+   `/intelligence-learn-from-repository` for repair and migration. Stop session
+   capture until onboarding is complete. A retained backup manifest or converted
+   legacy config alone does not mean onboarding is incomplete.
+
+## Analyze and propose
+
+2. Identify the lesson from the conversation or explicit user input. For a
+   workflow, list the actual steps performed, user decisions, branches, failure
+   recovery, and verification. Retain the sequence that worked.
+3. Generalize the evidence by removing instance-specific filenames, dates, and
+   phrasing. Keep the reason needed to apply the lesson to the next task. Prefer
+   a positive instruction such as "Default to one recommendation" for "Stop
+   generating three options". Preserve safety prohibitions; confirm a translation
+   if changing the negation changes meaning. Keep a negative example only when
+   paired with its replacement and useful for recognizing the pattern.
+4. Inspect configured sources for an existing owner. A preference or constraint
+   belongs in a rule, path-specific context in a scoped rule, an observed
+   repeatable procedure in a skill, and a persona or expertise boundary in an
+   agent. Prefer extending an existing artifact over adding a sibling.
+5. Present each proposal with its action (`CREATE`, `UPDATE`, or `ARCHIVE`),
+   source path, concrete draft, and one-line reason. This phase is read-only;
+   only user-accepted lessons become persistent instructions. Reuse approval
+   already given for the exact proposal.
+
+## Apply and verify
+
+6. Pass accepted proposals and their session evidence to
+   `/intelligence-update-context`. It handles artifact-specific authoring,
+   references, a single batch sync, and the final status check.
+7. Compare the resulting source changes with the accepted lesson. For a workflow,
+   verify that its decisions, working steps, recovery, and proof of completion
+   remain executable without this conversation. Report the saved lesson, its
+   owner, and verification; a session-specific transcript is not completion.

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

@@ -0,0 +1,45 @@
+---
+name: intelligence-manage-adapters
+description: "Enable, disable, or remove adapters and assess generated-output cleanup"
+argument-hint: "<enable|disable|remove> <adapter-name>"
+agent: intelligence-operator
+---
+
+# Manage adapters
+
+Operate existing built-in or project adapters through the CLI. Resolve the requested
+action and adapter name as separate arguments; never pass the whole skill argument
+string as an adapter name. The CLI owns target state, dependency checks, ignores,
+scaffolding, and sync. Adapter implementation follows the public adapter guide.
+
+1. Run `intelligence adapter list` and identify the requested adapter, its source,
+   state, and output. If it does not exist, explain that implementation is needed
+   and point to `<module>/references/adapters.md`. This package does not include
+   an implementation skill; do not invoke a repository-only skill in consumers.
+
+2. For **enable**, run `intelligence adapter enable <name>`. If it requires the
+   shared `agents` target, enable that dependency first. Enabling performs a full
+   sync; require `IS_STATUS=ok` and inspect output for the selected adapter. Correct
+   Git policy in the contract instead of hand-editing `.gitignore` or ignoring a
+   shared output root.
+
+3. For **disable**, run `intelligence adapter disable <name>`. This changes target
+   state and deliberately retains output. For **remove**, read and retain the
+   contract's ownership information first so later cleanup remains attributable.
+   Disable an enabled project adapter, then run `intelligence adapter remove <name>`
+   (use `--apply` for already-approved non-interactive removal). Built-in adapter
+   source cannot be removed.
+
+4. Treat generated-output cleanup separately from disabling or removing source.
+   Inspect the contract's owned and managed paths, including dependencies and any
+   shared consumers. Present the exact deletion list and obtain approval before
+   deleting output. Preserve shared roots and hand-authored siblings. Remove obsolete
+   ignore entries only when no remaining adapter needs them. After disabling or
+   removing, sync remaining enabled adapters when any exist, and require
+   `IS_STATUS=ok` from that sync.
+
+5. Verify with `intelligence adapter list` and `intelligence status --check`:
+   requested target state is correct, retained files are intact, and only approved
+   adapter-owned output was deleted. Report state, output paths, and any remaining
+   implementation or cleanup work. Preserve CLI refusals instead of recreating
+   lifecycle mechanics manually.

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

@@ -0,0 +1,54 @@
+---
+name: intelligence-review-context
+description: "Audit rules, agents, and skills and propose behavior-preserving reductions"
+argument-hint: "[rules|agents|skills|all] [compact]"
+agent: intelligence-architect
+---
+
+# Review project context
+
+Audit the intelligence layer and propose improvements. Review and compaction
+analysis are read-only: do not sync or edit while inspecting. Accepted changes
+go through `intelligence-update-context`; this skill owns their review criteria.
+
+## Audit
+
+1. Read `<manifest>` and enumerate its configured rule, agent, and skill sources.
+   Read the `intelligence-authoring` rule and
+   `<module>/references/conventions.md`. Review project-owned sources; an installed
+   package finding belongs upstream. In a package's own repository, review its
+   authoritative source tree. Do not audit generated output prose. Its byte count
+   is the metadata-only exception.
+2. Record source line and byte counts, and git history when available: first
+   addition, last edit, and edit count. Find incoming references before proposing
+   an archive. Resolve the shared agents output from the manifest and measure its
+   bytes, or reuse a fresh `CONTEXT:` summary. Mark missing or stale measurements;
+   do not regenerate output during analysis.
+3. Read and apply [references/audit-checks.md](references/audit-checks.md). Reuse
+   these generic checks in any project-specific audit. Check subtraction before
+   proposing a split or rewrite: remove an unnecessary artifact, merge overlapping
+   owners, or replace prose with an existing deterministic gate where possible.
+4. When the user asks to compact context, or the audit proposes a merge, move,
+   deletion, scoping change, or size reduction, read
+   [references/compaction.md](references/compaction.md) and its principles. Build
+   the behavior ledger and draft the structural reduction before wording changes.
+   Review must preserve complete language and the layer's behavioral contract.
+5. Present a punch-list: finding, target file, proposed action, concrete draft,
+   reason, and priority (1: duplication, misplaced or unnecessary artifacts;
+   3: description or naming polish). Compaction items also show the authoritative
+   owner, behavior preserved, estimated byte savings, and any change to meaning,
+   scope, or loading. Surface unverified reasons without silently rewriting them.
+
+## Accepted changes
+
+6. The user accepts items individually; a batch acceptance may cover named items.
+   Pass accepted proposals to `/intelligence-update-context`, with the behavior
+   ledger and additional checks. Reuse existing approval for those exact changes.
+   If fresh rendered measurements are needed, capture them only after apply is
+   authorized and before editing; record `<sync-cmd> --compact` output and require
+   `IS_STATUS=ok`. The authoring skill performs the final batch sync and status check.
+7. Verify each accepted finding against the resulting sources. For reductions,
+   complete the ledger comparison, measurements, and behavioral evaluation in
+   the compaction reference. Report each artifact as pass, fixed (what), or
+   flagged (for whom), plus unresolved proposals. A read-only review ends with
+   the evidenced punch-list; an apply run ends only after its checks complete.

package/packages/sync/skills/intelligence-review-context/references/audit-checks.md

@@ -0,0 +1,56 @@
+# Audit checks
+
+Apply these checks to the source groups resolved by the review skill.
+
+| 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` |
+| **Shared instruction budget** | The measured shared agents output, or `agents-md` in sync's `CONTEXT:` summary, is over 32 KiB (32,768 bytes) | `COMPACT` — this is Intelligence's recommended maximum, not an adapter rejection threshold; use the compaction procedure in `intelligence-review-context` to reduce the owning sources without teaching terse output |
+| **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 `<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 |
+| **Pressure marker** | A heading or section named CRITICAL / MANDATORY / HARD RULE / READ FIRST, or a density of `MUST` / `NEVER` / `ALWAYS` with no reason beside it (`R5`) | `REWRITE` - plain heading, one reason per constraint; when several instructions are each marked critical the marker stops carrying information, so keep emphasis for the one instruction demonstrably under-weighted without it |
+| **History narrative** | A PR number, incident id, commit SHA, date or "this session" inside a rule body (`R6`) | `REWRITE` - keep the causal sentence, drop the archaeology; a rule's authority is the behaviour it prescribes, and git history keeps the date |
+| **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 `<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 |
+| **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
+# Shared instruction budget — resolve this output path from <manifest>
+wc -c "<agents-output>"
+
+# 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>
+
+# R5 - pressure markers: a heading or label named for urgency, then absolute-language density per file
+grep -rnE '^#+ .*(CRITICAL|MANDATORY|HARD RULE|READ FIRST)|\((CRITICAL|MANDATORY|HARD RULE)\)' <rule-dirs> <agent-dirs> <skill-dirs>
+grep -rcE '(MUST|NEVER|ALWAYS)' <rule-dirs> <agent-dirs> <skill-dirs> | grep -vE ':0$'
+
+# R6 - history narrative in a rule body: PR numbers, incident ids, dates, "this session", commit SHAs
+grep -rniE -e '(#|PR )[0-9]{3,}' -e '[0-9]{4}-[0-9]{2}-[0-9]{2}' -e 'this session|origin session' \
+  -e '`[0-9a-f]{7,40}`' <rule-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. So are `R5` and `R6`: a `NEVER` that carries its reason and a date inside a frontmatter template are both legitimate hits, and the row's action applies only where the marker or the id is doing no work.

package/packages/sync/skills/intelligence-review-context/references/compaction.md

@@ -0,0 +1,57 @@
+# Preserve behavior while compacting
+
+Read [principles.md](principles.md) when preparing a structural or size reduction.
+The review skill supplies the source inventory, audit findings, and baseline counts.
+
+## Behavior ledger
+
+Before drafting, record each candidate's behavior, constraint, procedure, or
+expertise; its authoritative owner; when it loads; the reason or example needed
+to apply it; and the repository evidence or documentation supporting it. Similar
+words with different scope, priority, or failure behavior are not duplicates.
+
+## Draft in this order
+
+1. Replace instructions with deterministic commands or gates the repository
+   already enforces where they cover the same behavior.
+2. Delete generic knowledge and directly readable facts unless their non-obvious
+   interpretation is the instruction.
+3. Keep one owner of duplicated guidance. Call skills by name without repeating
+   their procedure; let agents bind skills without copying their steps.
+4. Scope narrow rules with `paths:`. Move procedures to skills, constraints to
+   rules, and reusable expertise to agents.
+5. Move optional detail to skill-local references with exact read conditions.
+   An unconditional import spends the same context. A plain link is navigation,
+   not guaranteed loading; keep critical constraints in the executable core.
+   Large always-on rules need subtraction, scoping, or a gate, not a reference index.
+6. Tighten prose only after structural reductions. Keep complete sentences,
+   ordinary vocabulary, reasons that guide judgment, and one clarifying example.
+
+Preserve triggers, boundaries, ordering, failure behavior, verification, and output
+contracts. Keep descriptions distinguishable. Do not teach terse, abbreviated,
+clipped, or vague responses, introduce dense acronyms or unexplained labels, or
+remove grammar to reduce bytes. Response style changes require their own explicit
+product requirement.
+
+Proposals use `DELETE`, `MERGE`, `SCOPE`, `MOVE`, `REFERENCE`, or `REWRITE` and name
+the owner, semantic contract, estimated savings, and any changed behavior or load
+timing. Keep unapproved passages byte-for-byte; the review skill routes only
+accepted proposals to the shared authoring procedure.
+
+## Verify the accepted result
+
+1. Compare the ledger with the diff. Each original behavior exists once in its
+   authoritative owner, was deliberately removed with approval, or is enforced by
+   the named deterministic mechanism. Check for dead links, unconditional reference
+   loads, conflicting instructions, and unintended scope expansion.
+2. After the authoring skill's successful sync and `intelligence status --check`,
+   compare source line and byte counts and rendered `agents-md` bytes with the
+   baseline. Reuse its `CONTEXT:` output; do not run a duplicate sync. Report bytes
+   and percentages for always-on and on-demand context separately. Label estimates
+   or unavailable baselines rather than reporting them as measured savings.
+3. When behavioral evaluation is available, exercise three prompts: a direct case
+   governed by the changed instruction, an adjacent judgment needing its reason,
+   and an ordinary explanation that reveals clipped language. Report explicitly
+   when this evaluation is unavailable: fewer bytes prove size, not quality.
+4. Report artifacts changed, behavior checks, measurements, and remaining owner
+   decisions. Return these results to the review skill's final report.

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

@@ -0,0 +1,71 @@
+---
+name: intelligence-update-context
+description: "Create, revise, or remove project rules, agents, and skills"
+argument-hint: "[rule|agent|skill] [request or accepted proposals]"
+agent: intelligence-architect
+---
+
+# Update project context
+
+Own the authoring procedure for rules, agents, and skills. A direct request,
+accepted session lesson, repository-onboarding proposal, or review finding enters
+the same procedure. Updating the layer can create a new artifact.
+
+## Resolve and draft
+
+1. Read `<manifest>` and resolve its `sources.rules`, `sources.agents`, and
+   `sources.skills` directories. `<content-dir>` names the project's content
+   directory; `<module>` is installed package content. Read the
+   `intelligence-authoring` rule and `<module>/references/conventions.md`.
+   Edit project-owned sources, never installed packages or generated output.
+   When working in a package's own repository, use its authoritative source tree.
+
+2. Inspect existing artifacts, including configured package sources, for overlap.
+   Prefer extending an existing owner, merging duplicates, or enforcing a
+   convention mechanically. Resolve the writable directory from the manifest;
+   create a pre-listed missing directory without changing the source list. Add a
+   source entry only when an accepted destination is outside the listed groups.
+
+3. Establish the evidence and artifact type. A constraint is a rule, a repeatable
+   procedure is a skill, and a persona or expertise boundary is an agent. Verify
+   repository claims in code or executable configuration. An accepted session
+   preference is evidence of the user's intent; an observed workflow supplies its
+   working steps. Preserve that evidence rather than inventing repository precedent.
+
+4. Reuse the existing domain vocabulary. If none fits, derive it from the project
+   name or component: for example `backend`, `frontend`, `devops`, `core`, or
+   `tests`. Project artifacts do not use the package-reserved `intelligence-`
+   prefix. Resolve an unclear scope before writing. Read only the relevant
+   artifact reference, for both new content and changes to existing content:
+   - Rule: [references/rules.md](references/rules.md).
+   - Agent: [references/agents.md](references/agents.md).
+   - Skill: [references/skills.md](references/skills.md).
+
+5. Draft the smallest change with its action, source path, evidence, and reason.
+   Supported actions include `CREATE`, `UPDATE`, `REMOVE` (`DELETE` in a review), `ARCHIVE`, `MERGE`,
+   `MOVE`, `SCOPE`, `REFERENCE`, and `REWRITE`. Preserve an upstream proposal's
+   behavior checklist, approval scope, and verification requirements. Present
+   changes to meaning, ownership, scope, or load timing that the user has not
+   already authorized. Accepted proposals do not need a second approval round.
+
+## Apply and verify
+
+6. Apply the authorized changes and update every affected invocation, link, and
+   agent binding. Archive to the project content directory's `_archive/` when
+   requested; remove only the accepted sources. For a move or merge, retain each
+   behavior once in its new owner. Preserve unapproved passages byte-for-byte.
+
+7. Check the relevant artifact reference, frontmatter, configured source coverage,
+   and all changed cross-references. Confirm the intended triggers, boundaries,
+   ordering, failure handling, and verification survived. Run tests for bundled
+   helpers or changed executable behavior using the project's verification gate.
+
+8. Run `/intelligence-sync` once after the complete batch, require `IS_STATUS=ok`,
+   then run `intelligence status --check`. Verify that each enabled target received
+   the intended artifacts and resources and that removed names are absent. When
+   called by onboarding, defer this batch's sync to its final migration check so
+   the accepted manifest header and content are verified together.
+
+9. Report the created, updated, removed, or archived artifacts and their checks.
+   Return control to the originating workflow for its additional semantic,
+   compaction, migration, or packaging verification; those checks remain required.

package/packages/sync/skills/intelligence-update-context/references/agents.md

@@ -0,0 +1,31 @@
+# Author an agent
+
+1. Reuse an agent covering the domain when possible. Name a new one
+   `<domain>-<role>` and determine its expertise from the source evidence.
+2. Select tier and access: implementation normally uses `heavy` and `full`;
+   review or validation uses `standard` and `readonly`; simple lookup uses
+   `light` and `readonly`. Check the target's actual permission mapping when
+   external read tools are required. If native read-only restrictions exclude
+   those tools, use `full` only with a clear read-only boundary in the body.
+3. Keep the body thin: Expertise, Boundaries, and Build & Verify. Carry its own
+   completion criteria and limitations. Reference constraints by name instead
+   of copying rules, and put reusable procedures in skills.
+4. Find relevant existing skills across the configured sources and link them in
+   `skills:`. Do not create a sibling skill or agent merely to fill a binding.
+
+```yaml
+---
+name: <domain>-<role>
+description: "When to use this agent"
+tier: heavy
+access: full
+skills:
+  - <existing-skill>
+---
+```
+
+Quote free-text YAML strings and escape embedded quotes; malformed scalars can
+prevent discovery. Verify every skill binding resolves, the tier and access use
+the supported vocabulary, and the body defines a role rather than a checklist.
+Apply the agent size and description limits from the authoring conventions,
+then return to the shared sync and verification steps.

package/packages/sync/skills/intelligence-update-context/references/rules.md

@@ -0,0 +1,31 @@
+# Author a rule
+
+1. Reuse an existing rule covering the scope. A new filename matches its domain,
+   such as `backend.md`, a named component, or `context.md` for global context.
+2. Choose `paths:` when the guidance applies to particular files. Omit it only
+   for intentionally project-wide guidance; a missing argument alone is not
+   evidence that every task needs the rule.
+3. Extract required patterns, invariants, architecture, relevant build commands,
+   and examples from the evidence. State judgment calls as positive defaults;
+   reserve absolute constraints for safety, security, and output contracts.
+   Pair a useful anti-pattern with its positive replacement.
+4. Write only the sections the evidence needs: Required patterns, Invariants,
+   Architecture, Build and test, Examples, and Patterns to recognize and replace.
+   Keep reasons that guide judgment and reference real examples. An accepted
+   user preference is identified as a preference, not a claim about existing code.
+
+For a scoped rule:
+
+```yaml
+---
+description: "Conventions for the named component"
+paths:
+  - "<scope-glob>"
+---
+```
+
+Verify that the globs match the intended files, each constraint has evidence,
+and procedures have a skill owner. Name always-on rules rather than linking to
+their source paths: their bodies are inlined in shared output. Apply the rule
+size and description limits from the authoring conventions, then return to the
+shared sync and verification steps.

package/packages/sync/skills/intelligence-update-context/references/skills.md

@@ -0,0 +1,34 @@
+# Author a skill
+
+1. Name it `<domain>-<verb>-<noun>`. Reuse established verbs: `add` adds a member,
+   `create` creates a container, `update` revises existing state, `run` executes
+   an operation, and `review` analyzes it. Preserve a distinct, discoverable task.
+2. Reuse an existing skill when its trigger and responsibility fit. For a new
+   skill, find a matching agent across configured sources. Bind it when useful;
+   if a new specialist is warranted, include that agent in the authoring proposal.
+   A skill can stand alone when no specialist is needed.
+3. Write concrete ordered steps from repository evidence or an observed workflow.
+   Keep decisions, failure handling, and a final proof of completion. A step
+   calling another skill names it and passes its inputs instead of copying it.
+4. Bundle helpers, templates, and optional detail beside `SKILL.md`. Require each
+   reference only for the condition that needs it. Resolve movable project paths
+   and commands from the manifest or project profile. Test executable helpers.
+5. Quote free-text YAML values, including descriptions and argument hints. Escape
+   embedded quotes or use a compatible quoted scalar. Keep `name` equal to the
+   directory name and make the description distinguish its trigger.
+
+```yaml
+---
+name: <domain>-<verb>-<noun>
+description: "What the skill does and when to use it"
+argument-hint: "Expected arguments"
+agent: <existing-agent>
+---
+```
+
+Omit optional fields that do not apply. Add the skill to its matching agent's
+`skills:` list when that agent is project-owned; propose an upstream change for
+a package-owned agent instead of editing the installed copy. Verify bindings,
+relative resource links, executable steps, and final success criteria. Apply the
+1000-line skill limit and other budgets from the authoring conventions, then
+return to the shared sync and verification steps.

package/packages/sync/skills/{intelligence-update → intelligence-upgrade}/SKILL.md

@@ -1,11 +1,11 @@
 ---
-name: intelligence-update
-description: "Interpret an update plan and verify breaking post-conditions"
+name: intelligence-upgrade
+description: "Upgrade Intelligence and installed packages with migration checks"
 argument-hint: "[@scope/name]"
 agent: intelligence-operator
 ---
 
-# Update intelligence
+# Upgrade Intelligence and packages
 
 The CLI owns planning and application. This skill interprets the plan, reads
 the changelog across an engine-version gap, obtains approval, and verifies the

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

@@ -1,62 +0,0 @@
----
-name: intelligence-add-agent
-description: "Create new specialized agent"
-argument-hint: <domain> [description]
----
-
-# Add Agent
-
-## Steps
-
-1. **Determine domain prefix** (the scope is required):
-   - **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-`
-     - 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-` (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 agent needs a domain prefix.** If the scope is unclear, ask the user before proceeding.
-
-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`
-   - Reviewer/validator agents: `tier: standard`, `access: readonly`
-   - Simple lookup agents: `tier: light`, `access: readonly`
-   - Caveat: `readonly`'s closed tools list also removes MCP and tool-search access. A reviewer
-     that needs MCP reads takes `access: full` with a read-only boundary stated in its body.
-
-4. **Analyze codebase**: Read source files in the domain's directory to determine:
-   - Technology stack and frameworks
-   - Architecture patterns
-   - Build and test commands
-   - Key conventions and forbidden patterns
-
-5. **Create agent**: Write `<content-dir>/agents/<domain>-<role>.md` (create the directory if missing) with frontmatter:
-   ```yaml
-   ---
-   name: <domain>-<role>
-   description: "<when to use this agent - IDEs use this to suggest the agent>"
-   tier: heavy|standard|light
-   access: full|readonly
-   skills:
-     - <existing-skills-for-this-domain>
-   ---
-   ```
-
-   **YAML safety (required):** **always wrap `description` (and any other free-text string field) in double quotes**, regardless of content. Codex CLI uses strict YAML — an unquoted colon, leading hyphen, or word that parses as boolean (`yes`, `no`, `true`) silently breaks the agent. Quoting unconditionally prevents the entire class of bug. If the value itself contains a double quote, escape it as `\"` or wrap it in single quotes so an inner quote does not terminate the scalar early.
-
-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 / Antigravity 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 `<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/packages/sync/skills/intelligence-add-rule/SKILL.md

@@ -1,54 +0,0 @@
----
-name: intelligence-add-rule
-description: "Create new intelligence rule"
-argument-hint: <name> [paths-glob]
----
-
-# Add Rule
-
-## Steps
-
-1. **Determine rule name from domain** (the scope is required):
-   - **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`
-     - Frontend / web / UI component → `frontend.md`
-     - Infrastructure, IaC, CI/CD, deployment → `devops.md`
-     - Shared library / common / cross-cutting code → `core.md`
-     - Test suites (e2e, integration) → `tests.md`
-     - Always-loaded global context → `context.md`
-   - 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 `<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
-   - If no paths — always-loaded rule (no `paths:` in frontmatter)
-
-4. **Analyze codebase**: Read source files matching the scope to extract:
-   - REQUIRED patterns (conventions consistently followed across the codebase — judgment calls expressed as positive defaults)
-   - Invariants (true must-nots — safety, output format, security; not judgment calls)
-   - Architecture patterns (layer dependencies, module structure)
-   - 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 `<content-dir>/rules/<name>.md` (create the directory if it does not exist — the sources list already covers it):
-   ```yaml
-   ---
-   paths:
-     - "<glob-pattern>"
-   ---
-   ```
-
-6. **Write body** with sections: **REQUIRED** → **Invariants** → **Architecture** → **Build & Test** → **Examples** → **Patterns to recognize and replace** (optional)
-   - Lead with REQUIRED (positive defaults) — the LLM follows the positive instruction first
-   - Reserve **Invariants** for true must-nots — security, safety, output format. Use absolute language (MUST / NEVER) only here, never for judgment calls
-   - **Patterns to recognize and replace** is reference documentation of anti-patterns paired with positive replacements — readers recognize the pattern, apply the replacement
-   - Examples come from the actual codebase — reference real files
-   - Every REQUIRED / Invariant / Pattern is backed by observed code
-
-7. **Update `<manifest>` only when needed**: add the path to `sources.rules` only if the rule lives in a directory not already listed there — creating a pre-listed directory is enough.
-
-8. **Run `/intelligence-sync`** to distribute to all enabled IDE targets.

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

@@ -1,53 +0,0 @@
----
-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 `<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-`
-     - 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-` (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.
-
-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 `<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 `<content-dir>/skills/<full-name>/SKILL.md` (create the directory if missing — no config edit needed) 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/packages/sync/skills/intelligence-compact-context/SKILL.md

@@ -1,118 +0,0 @@
----
-name: intelligence-compact-context
-description: "Reduce rules, agents, and skills without changing behavior or teaching terse output"
-argument-hint: "[target: rules|agents|skills|all]"
-agent: intelligence-architect
----
-
-# Compact intelligence context
-
-Reduce persistent and on-demand prompt cost by changing structure before wording.
-The result must preserve the layer's behavioral contract and ordinary, complete
-language; a smaller file is not a success if agents become terse, vague, or less
-reliable.
-
-## Analyze
-
-1. Resolve `<manifest>`, `<content-dir>`, and `<module>`. Enumerate the source
-   directories declared under `sources.rules`, `sources.agents`, and
-   `sources.skills`; skip installed package sources and generated adapter output.
-
-2. Read `<module>/references/conventions.md`, the `intelligence-authoring` rule,
-   and [references/principles.md](references/principles.md). The reference
-   explains which forms of indirection save context and which merely move text.
-
-3. Run `<sync-cmd> --compact` and save the `CONTEXT:` line as the baseline,
-   including its rendered `agents-md` byte count. Record individual source-file
-   byte and line counts for the requested target.
-
-4. Invoke `intelligence-review-skills` for the same target. Reuse its findings
-   for duplication, misplaced content, scope, stale artifacts, pressure markers,
-   history narrative, and description budget; do not reproduce its audit.
-
-5. Build a semantic ledger before drafting edits. For every candidate passage,
-   record:
-
-   - the behavior, constraint, procedure, or expertise it carries;
-   - its one authoritative owner;
-   - when it must load;
-   - the reason or example needed to apply it correctly;
-   - the repository evidence or external documentation that supports it.
-
-   Two passages are duplicates only when those meanings match. Similar wording
-   with different scope, priority, or failure behavior is not duplication.
-
-## Draft the compaction
-
-6. Apply structural reductions in this order:
-
-   1. Replace an instruction with a deterministic gate or command when the
-      repository already enforces it.
-   2. Delete generic knowledge and facts the agent can read directly from the
-      repository, unless a non-obvious interpretation is the instruction.
-   3. Keep one owner for duplicated guidance and remove the copies. A skill may
-      invoke another skill by name; an agent may list a skill; neither restates
-      the called artifact.
-   4. Add `paths:` to rules that matter only in part of the repository.
-   5. Move multi-step procedures from rules or agents into skills, and move
-      reusable constraints or expertise to the artifact type that owns them.
-   6. Move optional skill detail into skill-local `references/` and state the
-      exact condition that requires each file. Do not use an always-loaded
-      import or an unconditional read step and call that compaction.
-   7. Tighten prose only after the preceding reductions are exhausted.
-
-7. Preserve language quality while tightening prose:
-
-   - Use complete grammatical sentences and ordinary project vocabulary.
-   - Preserve the reason when it guides judgment, and keep one minimal example
-     when the rule would otherwise be ambiguous.
-   - Preserve triggers, boundaries, ordering, failure behavior, verification,
-     and output contracts exactly.
-   - Shorten descriptions by retaining the unique trigger that distinguishes a
-     sibling; never reduce them to vague labels.
-   - Do not add instructions telling agents to be terse, abbreviated, clipped,
-     or concise unless that response style is an explicit product requirement.
-   - Do not turn prose into fragments, dense acronyms, slash-separated phrases,
-     or unexplained labels. Compression targets redundancy, not grammar.
-
-8. Treat references according to load behavior:
-
-   - A conditional skill reference saves startup context.
-   - An always-loaded import improves organization but does not save context.
-   - A plain link is navigation, not guaranteed instruction loading; never hide
-     a critical constraint behind one.
-   - An always-on rule that is too large normally needs deletion, scoping, a
-     gate, or conversion of its procedure into a skill—not a reference index.
-
-## Approval and apply
-
-9. Present a proposal grouped as `DELETE`, `MERGE`, `SCOPE`, `MOVE`,
-   `REFERENCE`, or `REWRITE`. For each item show the owner, semantic contract,
-   estimated bytes saved, and any behavior that could change. Ask for approval
-   before changing meaning, ownership, scope, or load timing.
-
-10. Apply only accepted items to project-owned sources. Preserve unapproved
-    passages byte-for-byte and never edit generated output or installed package
-    sources locally.
-
-## Verify
-
-11. Compare the semantic ledger with the diff. Every original behavior must be
-    present once in its authoritative owner, deliberately removed with approval,
-    or enforced by the named deterministic mechanism. Check that no move created
-    a dead link, unconditional reference load, conflicting instruction, or
-    broader scope.
-
-12. Run `<sync-cmd> --compact`, require `IS_STATUS=ok`, then run
-    `intelligence status --check`. Compare the new `CONTEXT:` line and per-file
-    counts with the baseline.
-
-13. Exercise three representative prompts when the environment supports agent
-    evaluation: one direct case governed by a compacted instruction, one adjacent
-    judgment case that needs its reason, and one ordinary explanation that would
-    reveal clipped language. If behavioral evaluation is unavailable, report
-    that explicitly; a smaller byte count proves size reduction, not quality.
-
-14. Report bytes and percentage saved for always-on and custom context, the
-    before-and-after `agents-md` size, the artifacts changed, the semantic
-    checks performed, and any remaining item that needs an owner decision.

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

@@ -1,47 +0,0 @@
----
-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 `<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).
-
-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 `<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
-
-- `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/packages/sync/skills/intelligence-install-adapter/SKILL.md

@@ -1,45 +0,0 @@
----
-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 keep
-   `adapter_contract_$ARGUMENTS()` aligned with every path the adapter writes
-   and 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, distinguish exclusive
-   `owned` paths from marker-based/shared `managed` paths, and declare exact
-   legacy, preserved, dependency, ignore, and include records when applicable.
-
-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.
-
-   The CLI derives generated-output ignores from the adapter contract. Do not
-   edit `.gitignore` manually; correct the contract when policy is wrong, and
-   never ignore a shared output root.
-
-5. Require `IS_STATUS=ok`, inspect generated files against the researched
-   format, deliberately fail a later test adapter to prove transactional
-   rollback when contributing a built-in, run the tool's validator when one exists, and finish with
-   `intelligence status --check`. Report evidence, output paths, and any
-   unsupported artifact type.

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

@@ -1,88 +0,0 @@
----
-name: intelligence-learn-from-context
-description: "Capture one approved lesson from a session in an established Intelligence project"
----
-
-# Learn from Context
-
-Use after repository onboarding is complete and a meaningful preference,
-working pattern, or recurring friction emerged during the current session and
-should persist. It runs analyze (read-only), then apply after approval. This
-skill extends an established project; it does not perform first-run repository
-analysis or migrate legacy instructions.
-
-## Onboarding gate
-
-1. Locate `<manifest>`, `<content-dir>`, and `<module>`, then run
-   `intelligence status --check`.
-2. If setup is missing or inconsistent, stop and ask the user to repair it with
-   `intelligence init`; then use `/intelligence-learn-from-repository`. Do not
-   reproduce CLI mechanics.
-3. If the generated header says onboarding is pending, or preserved legacy
-   evidence still has unresolved instructions, stop and route to
-   `/intelligence-learn-from-repository`. A retained
-   `<content-dir>/_backup/manifest.tsv` or converted legacy config alone does
-   not mean onboarding is incomplete; those may remain as intentionally kept
-   evidence after the transitional header and conflicts are resolved.
-
-## 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.** 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.
-
-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** (`<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
-
-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 `<content-dir>/_archive/` and update cross-references that point at it
-
-8. Run `intelligence sync` once all accepted items are applied. Require
-   `IS_STATUS=ok`, then run `intelligence status --check`.
-
-## Related skills
-
-- `intelligence-learn-from-repository` — first-run onboarding and legacy instruction migration; use it before this skill
-- `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/packages/sync/skills/intelligence-review-skills/SKILL.md

@@ -1,101 +0,0 @@
----
-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.
-
-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.** `<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, 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 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. Reading its byte count from sync's `CONTEXT:` summary or a byte-count command is the metadata-only exception—do not open the output to audit its prose.
-
-## 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.** Resolve the shared agents target output from `<manifest>` and measure only its byte count; use the `agents-md` value when a fresh `CONTEXT:` summary is already available. Apply the shared instruction budget below, but do not run sync during this read-only audit. 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` |
-   | **Shared instruction budget** | The measured shared agents output, or `agents-md` in sync's `CONTEXT:` summary, is over 32 KiB (32,768 bytes) | `COMPACT` — this is Intelligence's recommended maximum, not an adapter rejection threshold; use `intelligence-compact-context` to reduce the owning sources without teaching terse output |
-   | **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 `<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 |
-   | **Pressure marker** | A heading or section named CRITICAL / MANDATORY / HARD RULE / READ FIRST, or a density of `MUST` / `NEVER` / `ALWAYS` with no reason beside it (`R5`) | `REWRITE` - plain heading, one reason per constraint; when several instructions are each marked critical the marker stops carrying information, so keep emphasis for the one instruction demonstrably under-weighted without it |
-   | **History narrative** | A PR number, incident id, commit SHA, date or "this session" inside a rule body (`R6`) | `REWRITE` - keep the causal sentence, drop the archaeology; a rule's authority is the behaviour it prescribes, and git history keeps the date |
-   | **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 `<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 |
-   | **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
-   # Shared instruction budget — resolve this output path from <manifest>
-   wc -c "<agents-output>"
-
-   # 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>
-
-   # R5 - pressure markers: a heading or label named for urgency, then absolute-language density per file
-   grep -rnE '^#+ .*(CRITICAL|MANDATORY|HARD RULE|READ FIRST)|\((CRITICAL|MANDATORY|HARD RULE)\)' <rule-dirs> <agent-dirs> <skill-dirs>
-   grep -rcE '(MUST|NEVER|ALWAYS)' <rule-dirs> <agent-dirs> <skill-dirs> | grep -vE ':0$'
-
-   # R6 - history narrative in a rule body: PR numbers, incident ids, dates, "this session", commit SHAs
-   grep -rniE -e '(#|PR )[0-9]{3,}' -e '[0-9]{4}-[0-9]{2}-[0-9]{2}' -e 'this session|origin session' \
-     -e '`[0-9a-f]{7,40}`' <rule-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. So are `R5` and `R6`: a `NEVER` that carries its reason and a date inside a frontmatter template are both legitimate hits, and the row's action applies only where the marker or the id is doing no work.
-
-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-session lesson capture; this skill delegates accepted edits to its Phase B
-- `intelligence-extract-skill` — when the audit surfaces a workflow that should become a skill
-- `intelligence-compact-context` — approval-gated structural compaction when the shared instruction budget or source size needs reduction

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

@@ -1,24 +0,0 @@
----
-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.