@ainova-systems/intelligence 0.13.0 → 0.15.0

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.