@ainova-systems/intelligence 0.14.0 → 0.16.0

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.