Analyze

---
name: analyze
description: Kabo creator research analysis entry point. Use it when the user needs Instagram or YouTube competitor discovery and content analysis, public account review, named-handle follower-loss or funnel, continue/stop decisions, reach-drop or shadowban-pattern diagnosis, deterministic engagement-rate calculation or cross-platform ER comparison, YouTube public evidence collection, channel benchmarking and playbook summaries, account-relative outlier breakdowns and the topic ideas they support, emerging-creator breakout discovery, reverse-engineering of viral Instagram Reels, creator brand identity copy such as channel names, handles or bios, brand-deal and sponsorship pricing, monetization threshold gaps, or to verify a platform rule, rumour, official feature, setting, or ToS from the platform's own pages; this skill only starts the flow — the actual routing and execution rules live in meta-guidance.
---

# Kabo analysis entry point

The explicit entry point when the user states a creator research need. This skill **does not implement routing itself** — read `meta-guidance` and follow it.

1. Read `../meta-guidance/SKILL.md` in the sibling directory and execute per its "Single-skill flow" or "Composite requests".
   Call `registry_skill_search` once with an empty query: that lists every skill accessible on this account, and you pick the match by reading their descriptions and tags. Never guess a keyword and do not assume or hard-code a Skill id. A non-empty query is literal substring matching, so a sentence or a bundle of keywords will not match.
   **Fetch and verify are one step.** Cache check first — `<data root>/skill-cache/<id>/<version>/` already present → skip the download and run `'<plugin-root>/bin/skill-verify' <skill dir>` once (that is this run's verification); `<data root>/skill-cache/<id>.disabled` → platform-revoked, stop and say so. Otherwise, on Codex, follow the meta-guidance **Download-to-unpack bridge** exactly: the downloaded structured package is streamed once through the exact-count raw/no-echo bridge whose command ends in `'<plugin-root>/bin/skill-unpack' --verify - '<data-root>/skill-cache'`, so unpack, the `manifest:` digest line (`execution`, `has_pipeline`, `pipeline_operations`, `required.tools`, `min_plugin_version`, `skill=<id>@<version>`) and one `skill-verify` run with the network revocation check all happen inside that one stream. The package is never printed, put in a shell argument, or repeatedly downloaded after a local transport failure. Exit ≠ 0 → **never execute**; say why; the plugin handles `KABO_VERIFY_FAIL` telemetry as meta-guidance directs, with no agent relay. There is no separate `skill-verify` step afterwards and none later in the run; the only other verification is `kabo-run-pipeline`'s built-in `--local-only` hygiene check.
   **Readiness once**: reuse this search's `connectors_ready: true` note. Otherwise call `data_connector_catalog` once: use `skill_id` if search returned non-empty `required.connectors`; for older skills read SKILL.md and use its explicit `connector_ids` directly. Empty never proves readiness. Unready/unimplemented is a platform-side gap; stop that evidence path. Pass the note and relevant params schemas to the executor.
   **Dispatch** by the selected pipeline array: `pipeline_operations[operation]` overrides `pipeline` when the operation has its own entry. A non-empty array routes here; an empty override disables it. Use the digest's `has_pipeline` / `pipeline_operations` to find available fast paths, and SKILL.md to select the operation. Otherwise follow the unchanged `execution` string:
   - `pipeline` → **this task itself** executes, no subagent (turn sequence below).
   - `subagent` → a Codex subagent told to use `$skill-runner`, dispatched as the meta-guidance Codex deltas describe, given ① the skill path ② the task summary + the catalog readiness note ③ the path `<data root>/execution-conventions.md` (written by SessionStart) — paste Section C verbatim only if that file is missing.
   - `inline` → read that SKILL.md here and follow it.
2. **Invoked with no arguments** (nothing to analyze was named): check for `<data root>/onboarding-profile.json` (data root `$KABO_CODEX_DATA`, falling back to `~/.kabo/codex`). No profile, or a profile whose `onboarded_at` is empty (an interrupted onboarding) → hand off to `$kabo-start` (read `../kabo-start/SKILL.md` and follow it in this task) — it is the first-run path, offers Continue / Start over on an interrupted one, and discloses its own cost before anything runs. Profile complete → greet them by handle and ask what they want to look at today, using the goal and niche on file as the starting point; do not re-ask onboarding questions.
3. When the request is unclear, ask first: the analysis target (channel / niche / specific video), the conclusion they want, and the time window. **Do not guess.**
4. When the search finds no match for evidence-dependent analysis, state the coverage gap. Do not invent a Kabo analysis or substitute sources for a failed evidence path. Apply the Codex delivery rule to any independent need for general planning advice.
5. When all platform tools are unavailable, point the user to run `$kabo-login` first.

## Pipeline dispatch — this task's turn sequence

For a data-plane skill with a non-empty pipeline array for the selected operation, the whole run is a fixed sequence of tool turns and a reply. `<plugin-root>` is two levels up from this `SKILL.md` (also recorded as one line in `<data root>/plugin-root`); `<data root>` is `$KABO_CODEX_DATA` if set, otherwise `~/.kabo/codex`. Nothing is on PATH: call the bins by absolute path.

1. **Read** `<skill dir>/SKILL.md` (and only the references it names). Take from it the evidence plan — the literal connector/operation names and params — and the selected operation. The signed manifest supplies the commands.
2. **Shell**: `'<plugin-root>/bin/kabo-run-dir' --skill <skill dir>` — stdout is the run id.
3. **Connector calls, one assistant turn**: every `data_connector_run` (or `data_connector_batch_run`) the SKILL.md names, together; a call whose output another needs (a handle resolve) goes first, the rest in the same turn. The PostToolUse hook stages each envelope and prints a `kabo:` line — note the staging directory it names. Never retype an envelope, and never read one back just to carry it.
4. **Drain or write**: if a `kabo:` line named a staging directory, pass it as `--staging` in step 5 and do not write envelope files yourself. Only when nothing was staged, write every distinct response whose status is `completed`, `completed_partial` or `partial` (the partial ones are usable evidence and keep their `limitations`), byte-for-byte as returned, to `<data root>/work/<run-id>/snapshot/envelope-01.json`, `envelope-02.json`, ... in request order, with `umask 077` in the same command. Never abridge, re-serialize with fields dropped, or paraphrase an envelope; a large display is not a failed fetch and never authorizes a combined fallback query. Staged file numbers carry no request order (a number is reserved before its write finishes, so it follows neither request nor completion order): when a step pairs each envelope with one ordered input (a repeated `--query`), first run `'<plugin-root>/bin/kabo-save-envelope' --list --from <that directory>` and order those inputs by the listed `request_id`s — each one matches the call whose result carried it.
5. **Shell, one call**: execute the selected signed array without --step. Pass `--staging <dir from the kabo: line>` when a directory was named; omit `--staging` only when you wrote the files in step 4:

   ```bash
   '<plugin-root>/bin/kabo-run-pipeline' --run-id <run-id> --skill <skill-dir> --staging <dir from the kabo: line> --operation <operation> --language <tag> --param handle=<handle>
   ```

   Omit --operation for the default array. Pass only the parameters its templates require, shell-quoting flag values. Bare placeholders belong inside templates. Calls with dependencies run after their prerequisites; wait for terminal jobs and retrieve the artifact bodies required by SKILL.md before POST.

   Placeholders: `{run}` `{skill}` `{plugin}` `{cr}` (= `{plugin}/creator-research`) `{snapshot}` `{analysis}` `{report}` `{owner}` `{language}` `{param.<key>}` `{envelopes}` (one `--envelope <path>` per drained or written `snapshot/envelope-NN.json`, in numeric order). Write every placeholder bare: the pipeline single-quotes each value for `/bin/sh` as it substitutes it, so `--focus-handle "{param.handle}"` hands the script `'@handle'`, quote characters included, and `"{analysis}/x.json"` a path that does not exist. `${PLUGIN_ROOT}` in a SKILL.md body is `{plugin}`, `../../` is `{cr}/`, the skill's own `scripts/` is `{skill}/scripts/`; `--window auto` only when the user named no window. The pipeline runs the steps in order and stops at the first failure, checks the skill for bytecode, hardens the run directory, verifies the skill `--local-only`, finalizes `run-manifest.json`, and prints `step n/N ok` lines, a `drained=<n>` line when `--staging` was given, `creator_report: <run-id> → report/<file>` and `run-manifest: <run-id> → run-manifest.json`. Exit 1 or a `step n/N FAILED` line is a failed run: say which step failed, in task terms, and do not deliver.
6. **Read** every report named on a `creator_report:` line — a pipeline emits one line per file under `{run}/report`, and a composite run adds the lines of each skill it ran. Resolve each under `<data root>/work/<run-id>/report/<file>`.
7. **Reply** per meta-guidance Section E: one reply to the ask built from all of them. Apply the coverage check in the Codex delivery rule to a single report; several are merged, never dumped side by side and never as paths.

In this mode Section C of meta-guidance (on disk as `<data root>/execution-conventions.md`) binds you directly: the envelope-status matrix, the relabelling rule and the never-fabricate rule apply to what you write exactly as they would to `$skill-runner`.

When delivering, follow meta-guidance Section E: the reply body is the creator-facing report named on the `creator_report:` line (printed by `kabo-run-pipeline`, and repeated by the runner in its summary), delivered under the Codex coverage check (translated to the user's language if needed). It is named run-relative — `creator_report: <run-id> → report/<file>` — because an absolute path spells this machine's account name into a summary that is relayed off it. **Resolve it under `<root>/work/<run-id>/`, where `<root>` is `$KABO_CODEX_DATA` if set and `~/.kabo/codex` otherwise.** Without that root the path is unresolvable, and searching for the file name instead finds same-named reports from other runs and other projects. Skill/version, quota, truncation, and the `limitations` detail are run mechanics — keep them out of the reply and give them only when the user asks; what a limitation makes missing is stated in task terms inside the delivery itself.