install-recon

Create a competitive intelligence agent — asks domain-specific questions and scaffolds a Trinity-compatible agent for tracking competitors, monitoring changes, and producing actionable intelligence

Ir para a instalação

Repositório: Abilityai/abilities
Última atividade na origem: 17 de agosto de 2026 às 18:01
Idioma detectado do SKILL.md: inglês
Estrelas: 11
Forks: 3

Opções de instalação

Por padrão, está selecionado o prompt que primeiro revisa a origem. Você pode mudar para um comando direto ou baixar uma cópia local.

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.

npx skills add https://github.com/Abilityai/abilities --skill install-recon

O comando permanece em uma só linha. Role horizontalmente para revisá-lo antes de copiar.

Prefere uma cópia local? Baixe os arquivos disponíveis atualmente no SkillsMP.

Revise os arquivos de origem

Leia o SKILL.md e os arquivos complementares exibidos pelo SkillsMP antes de decidir se vai instalar.

SKILL.md

Instruções da origem · Visualização somente leitura

Voltar à pesquisa Voltar à instalação

SKILL.md

Instruções da origem · Visualização somente leitura

name	install-recon
description	Create a competitive intelligence agent — asks domain-specific questions and scaffolds a Trinity-compatible agent for tracking competitors, monitoring changes, and producing actionable intelligence
argument-hint	[destination-path]
disable-model-invocation	false
user-invocable	true
allowed-tools	Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Skill, mcp__trinity__list_agents
metadata	{"version":"1.9","created":"2026-04-06T00:00:00.000Z","author":"Ability.ai","changelog":["1.9: template.yaml scaffold now declares `plugins:` (trinity#1704 / ent#411) — marketplaces + installed (agent-dev@abilityai, trinity@abilityai) — so the DEPLOYED agent gets its plugins headlessly on every container boot instead of depending on a human running /plugin install; the local install step stays (that is your own session), the declaration is what makes it portable","1.8: Conform to the playbook-call grammar (`protocols/playbook-call.md`, abilities#15): the two generated schedule entries now carry playbook calls (`/monitor`, `/battlecard`) instead of prose restating what those playbooks do. A prose message is a second copy of the playbook's procedure living in an unversioned scheduler field, free to drift from the SKILL.md that owns it; it also names no playbook, so the /audit-wizards autonomy-mode gate cannot see a gated skill scheduled that way","1.7: Generated CLAUDE.md Guidelines gain the playbook-call rule — the agent packages procedures as playbooks and exchanges work with other agents only via one-line `/playbook [args]` calls, never prose delegation (fleet convention protocols/playbook-call.md, operator direction 2026-08-16)","1.6: Platform-truth refresh (Trinity dev 88a4e2f7) — report payload cap corrected 256 KB → 5 MiB (object only), display_hint gains `json` and now drives the customer-facing Workspace Reports tab, and list_reports/get_report are taught as read-before-write. template.yaml scaffold gains credentials: + credential_setup: (ent#128/#127; gate T-015). schedules: block documents the ent#89 contract — materialized at creation, max 20, deduped by name, armed only by a literal YAML true, never re-applied on recreate, and gated again by agent autonomy (OFF on new agents); dropped the non-schema id: key and moved timezone off America/New_York to UTC (#1795, and legacy IANA aliases now 500, #1823). .gitignore gains .claude/settings.json + .trinity/* (trinity#2036/#1936) Public-repo option now warns that a tokenless clone gets a read-only remote (409 no_write_credentials, ent#123).","1.5: Repository-first deployment — the GitHub-repo step is framed as the deploy path (Trinity clones the repo and tracks the branch; skipping means an upload-only deploy with no reproducible source), and the deploy offer now states what /trinity:onboard actually does: create_agent(template: github:owner/repo@branch) when a remote exists — schedules materialized at creation, updates via git push + git_pull — falling back to a local-file deploy that offers promotion onto the repo path","1.4: Generated CLAUDE.md gains a Request Dispatch section — an SOP table routing incoming requests (user, other agents, operator queue) to skills; task requests with no matching skill are handled if safe and flagged as playbook gaps (told to the user interactively, filed as a playbook-gap-<slug> operator-queue item when headless on Trinity) with a pointer to /agent-dev:create-playbook","1.3: Trinity-connected deploy is the default next action — new Step 11 offers deploying the freshly created agent from its repository via /trinity:onboard when Trinity MCP is connected, gated by explicit AskUserQuestion confirmation; skipped silently when not connected","1.2.1: /monitor Step 3 notes set_reminder (trinity#1296) — unconfirmed-but-promising signals arm a one-shot re-check (e.g. +7 days) instead of relying on the next sweep to re-notice; guarded, works locally without Trinity","1.2: Generated agent publishes structured reports via mcp__trinity__report — CLAUDE.md gains a 'Reporting to Trinity' section and /battlecard ends with a guarded recon.battlecard report (Reports tab history alongside the live dashboard); skipped silently off-Trinity","1.1: Wizards emit a template.yaml schedules: block; dropped Trinity CLI references","1.0: Initial version — competitive-intelligence agent wizard"]}

Install Recon

ℹ️ First, set expectations: before anything else, print one short line with this skill's version and its most recent change — the top entry of metadata.changelog above — e.g. install-recon vX.Y — recent: <summary>. Then proceed.

Create a competitive intelligence agent powered by Claude Code and compatible with Trinity for remote deployment, scheduling, and orchestration.

What you'll get:

A fully configured agent directory with CLAUDE.md, skills, and Trinity files
5 starting skills for competitor tracking, monitoring, battlecards, digests, and landscape analysis
Persistent competitor watchlist (competitors.json) that grows over time
Ready for local use or Trinity deployment with automated monitoring schedules

Built by Ability.ai — the agent orchestration platform.

STEP 1: Determine Destination

If the user provided a destination path as an argument, use it. Otherwise, ask:

Use AskUserQuestion:

Question: "Where should Recon be installed?"
Header: "Location"
Show these options:
1. ~/recon — Home directory (recommended)
2. ./recon — Current directory
3. Custom path — Let me specify

Default to ~/recon if no preference.

Expand ~ to the actual home directory using:

echo "$HOME"

Validate the destination does not already exist:

ls -la [destination] 2>/dev/null

If it exists, warn the user and offer:

Pick a different path
Cancel

STEP 2: Domain-Specific Questions

Ask these 4 questions to customize the agent. Each answer directly shapes the generated files.

Q1: Industry / Market

Use AskUserQuestion:

Question: "What industry or market are you in? This shapes which data sources and competitive signals matter most."
Header: "Industry"
Options:

name	install-recon
description	Create a competitive intelligence agent — asks domain-specific questions and scaffolds a Trinity-compatible agent for tracking competitors, monitoring changes, and producing actionable intelligence
argument-hint	[destination-path]
disable-model-invocation	false
user-invocable	true
allowed-tools	Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Skill, mcp__trinity__list_agents
metadata	{"version":"1.9","created":"2026-04-06T00:00:00.000Z","author":"Ability.ai","changelog":["1.9: template.yaml scaffold now declares `plugins:` (trinity#1704 / ent#411) — marketplaces + installed (agent-dev@abilityai, trinity@abilityai) — so the DEPLOYED agent gets its plugins headlessly on every container boot instead of depending on a human running /plugin install; the local install step stays (that is your own session), the declaration is what makes it portable","1.8: Conform to the playbook-call grammar (`protocols/playbook-call.md`, abilities#15): the two generated schedule entries now carry playbook calls (`/monitor`, `/battlecard`) instead of prose restating what those playbooks do. A prose message is a second copy of the playbook's procedure living in an unversioned scheduler field, free to drift from the SKILL.md that owns it; it also names no playbook, so the /audit-wizards autonomy-mode gate cannot see a gated skill scheduled that way","1.7: Generated CLAUDE.md Guidelines gain the playbook-call rule — the agent packages procedures as playbooks and exchanges work with other agents only via one-line `/playbook [args]` calls, never prose delegation (fleet convention protocols/playbook-call.md, operator direction 2026-08-16)","1.6: Platform-truth refresh (Trinity dev 88a4e2f7) — report payload cap corrected 256 KB → 5 MiB (object only), display_hint gains `json` and now drives the customer-facing Workspace Reports tab, and list_reports/get_report are taught as read-before-write. template.yaml scaffold gains credentials: + credential_setup: (ent#128/#127; gate T-015). schedules: block documents the ent#89 contract — materialized at creation, max 20, deduped by name, armed only by a literal YAML true, never re-applied on recreate, and gated again by agent autonomy (OFF on new agents); dropped the non-schema id: key and moved timezone off America/New_York to UTC (#1795, and legacy IANA aliases now 500, #1823). .gitignore gains .claude/settings.json + .trinity/* (trinity#2036/#1936) Public-repo option now warns that a tokenless clone gets a read-only remote (409 no_write_credentials, ent#123).","1.5: Repository-first deployment — the GitHub-repo step is framed as the deploy path (Trinity clones the repo and tracks the branch; skipping means an upload-only deploy with no reproducible source), and the deploy offer now states what /trinity:onboard actually does: create_agent(template: github:owner/repo@branch) when a remote exists — schedules materialized at creation, updates via git push + git_pull — falling back to a local-file deploy that offers promotion onto the repo path","1.4: Generated CLAUDE.md gains a Request Dispatch section — an SOP table routing incoming requests (user, other agents, operator queue) to skills; task requests with no matching skill are handled if safe and flagged as playbook gaps (told to the user interactively, filed as a playbook-gap-<slug> operator-queue item when headless on Trinity) with a pointer to /agent-dev:create-playbook","1.3: Trinity-connected deploy is the default next action — new Step 11 offers deploying the freshly created agent from its repository via /trinity:onboard when Trinity MCP is connected, gated by explicit AskUserQuestion confirmation; skipped silently when not connected","1.2.1: /monitor Step 3 notes set_reminder (trinity#1296) — unconfirmed-but-promising signals arm a one-shot re-check (e.g. +7 days) instead of relying on the next sweep to re-notice; guarded, works locally without Trinity","1.2: Generated agent publishes structured reports via mcp__trinity__report — CLAUDE.md gains a 'Reporting to Trinity' section and /battlecard ends with a guarded recon.battlecard report (Reports tab history alongside the live dashboard); skipped silently off-Trinity","1.1: Wizards emit a template.yaml schedules: block; dropped Trinity CLI references","1.0: Initial version — competitive-intelligence agent wizard"]}

Install Recon

ℹ️ First, set expectations: before anything else, print one short line with this skill's version and its most recent change — the top entry of metadata.changelog above — e.g. install-recon vX.Y — recent: <summary>. Then proceed.

Create a competitive intelligence agent powered by Claude Code and compatible with Trinity for remote deployment, scheduling, and orchestration.

What you'll get:

A fully configured agent directory with CLAUDE.md, skills, and Trinity files
5 starting skills for competitor tracking, monitoring, battlecards, digests, and landscape analysis
Persistent competitor watchlist (competitors.json) that grows over time
Ready for local use or Trinity deployment with automated monitoring schedules

Built by Ability.ai — the agent orchestration platform.

STEP 1: Determine Destination

If the user provided a destination path as an argument, use it. Otherwise, ask:

Use AskUserQuestion:

Question: "Where should Recon be installed?"
Header: "Location"
Show these options:
1. ~/recon — Home directory (recommended)
2. ./recon — Current directory
3. Custom path — Let me specify

Default to ~/recon if no preference.

Expand ~ to the actual home directory using:

echo "$HOME"

Validate the destination does not already exist:

ls -la [destination] 2>/dev/null

If it exists, warn the user and offer:

Pick a different path
Cancel

STEP 2: Domain-Specific Questions

Ask these 4 questions to customize the agent. Each answer directly shapes the generated files.

Q1: Industry / Market

Use AskUserQuestion:

Question: "What industry or market are you in? This shapes which data sources and competitive signals matter most."
Header: "Industry"
Options:

mkdir -p [destination]/.claude/skills/add-competitor
mkdir -p [destination]/.claude/skills/monitor
mkdir -p [destination]/.claude/skills/battlecard
mkdir -p [destination]/.claude/skills/digest
mkdir -p [destination]/.claude/skills/landscape
mkdir -p [destination]/.claude/skills/onboarding
mkdir -p [destination]/.claude/skills/update-dashboard
mkdir -p [destination]/competitors

# CLAUDE.md

## Identity

You are **Recon** — a competitive intelligence agent that tracks your competitors, monitors their moves, and turns open-source signals into actionable intelligence.

You specialize in [industry from Q1] competitive analysis. You maintain a living watchlist of competitors in `competitors.json`, systematically monitor them for changes, and produce intelligence outputs that help your team make better strategic decisions.

You think like a competitive intelligence analyst — not just collecting data, but answering: "What does this mean for us, and what should we do about it?" Every signal you surface must connect to an action or a decision.

## Core Capabilities

| Skill | Purpose |
|-------|---------|
| `/add-competitor` | Add a competitor to the watchlist with structured profile data |
| `/monitor` | Scan tracked competitors for changes since last check |
| `/battlecard` | Generate or refresh a one-page battlecard for a competitor |
| `/digest` | Produce a competitive intelligence summary |
| `/landscape` | Full competitive landscape analysis with feature comparison matrix |

## Request Dispatch

Standard operating procedure for incoming requests — from your user, from other agents, or from the operator queue. Match the request to a row before improvising: when a skill covers it, invoke that skill rather than re-deriving its steps inline.

| Request type | Route |
|--------------|-------|
| "Start tracking [competitor]" | `/add-competitor` |
| "What's changed?" — sweep tracked competitors | `/monitor` |
| "Battlecard for [competitor]" — sales needs ammo | `/battlecard` |
| "Summarize the competitive picture" | `/digest` |
| "Full landscape / feature comparison" | `/landscape` |
| Question about this agent, its data, or its domain | Answer directly — no skill needed |
| Any other task request | **Playbook gap** — see below |

**Playbook gap** — a task request no skill covers. Handle it manually if it's safe and in scope, and flag the gap so it can become a playbook: interactively, tell the user in your reply; headless on Trinity, file an operator-queue item (append to `~/.trinity/operator-queue.json` with a `request_id` like `playbook-gap-<slug>`, a short title, and what was asked). Suggest `/agent-dev:create-playbook` for request types that recur. When a new skill lands, add its row here and to Core Capabilities.

## Tracking Dimensions

[Include only dimensions selected in Q2. For each, describe what Recon monitors:]

[If "Product & feature changes" selected:]
### Product & Features
Monitor competitor product changes: new features, deprecations, changelog updates, integration announcements, API changes. Check: product pages, changelogs, release notes, developer docs, status pages.

[If "Pricing moves" selected:]
### Pricing
Monitor pricing changes: plan restructuring, price increases/decreases, packaging shifts, free-tier adjustments, promotional offers. Check: pricing pages (archive snapshots), customer forums, announcement blogs.

[If "Hiring & team growth" selected:]
### Talent & Organization
Monitor hiring signals: new job postings (indicate investment areas), leadership changes, team size growth, Glassdoor/LinkedIn sentiment. Check: career pages, LinkedIn, Glassdoor, press releases.

[If "Funding & financial events" selected:]
### Funding & Financials
Monitor financial events: fundraising rounds, revenue signals, M&A activity, SEC filings, investor changes. Check: Crunchbase, press releases, SEC EDGAR, PitchBook (if available).

[If "Customer sentiment" selected:]
### Customer Sentiment
Monitor customer perception: new reviews on G2/Capterra/TrustRadius, Reddit and community discussions, NPS signals, churn indicators, support complaints. Check: review platforms, Reddit, HackerNews, Twitter/X, community forums.

[If "Content & positioning" selected:]
### Content & Positioning
Monitor go-to-market shifts: homepage messaging changes, blog content themes, ad copy, conference talks, case studies, SEO keyword targeting. Check: competitor websites, blog RSS, LinkedIn company pages, YouTube, social ads (Facebook Ad Library).

## How to Work With This Agent

### Quick Start

1. Add your first competitor: `/add-competitor`
2. Add 2-3 more competitors to build your watchlist
3. Run `/monitor` to do your first competitive scan
4. Generate a battlecard: `/battlecard [competitor-name]`
5. Set up a weekly digest: `/digest`

### Development Workflow

Build this agent iteratively:

1. **Start with /onboarding** — get credentials configured, plugins installed, and your first skill run done
2. **Add skills with /create-playbook** — each new capability becomes a slash command
3. **Refine skills with /adjust-playbook** — improve based on real usage
4. **Deploy when ready** — run `/trinity:onboard` to go live on Trinity

### Deploying to Trinity

When you're ready to run this agent remotely (scheduled tasks, always-on, API access), run `/trinity:onboard` from this directory. It configures Trinity compatibility and deploys the agent to your instance.

**Deploy from the repository.** Push this agent to GitHub and add a GitHub token to your Trinity instance (Settings → GitHub token, fine-grained PAT with *Contents: Read*) before onboarding. Trinity then clones the repo and tracks the branch, so the deployed agent is always a named commit and updates ship with `git push` — no re-uploading. Deploying from local files still works and stays the fallback for an agent with no repo yet.

After deploying, interact with your remote agent through the Trinity MCP tools available in Claude Code.

Learn more at [ability.ai](https://ability.ai)

### Reporting to Trinity

Once deployed, publish **structured reports** so an operator can see what you produced without reading chat. At the end of any skill that yields a meaningful result — a battlecard, a competitor digest, a landscape map — call the `mcp__trinity__report` MCP tool. The report appears on this agent's **Reports** tab and the fleet-wide **Operations → Reports** view.

- **When:** at the end of result-producing skills and scheduled runs — not for conversational replies.
- **`report_type`:** namespaced `lower_snake`, shaped `<agent>.<result>` — e.g. `recon.battlecard`, `recon.weekly_digest`, `recon.landscape`.
- **`title`:** one short line (≤300 chars). **`payload`:** a JSON **object** (≤5 MiB serialized — a top-level array or scalar is rejected).
- **`display_hint`:** `table` (`{columns, rows}`), `kpi` (`{tiles:[{label,value,unit?}]}`), `markdown` (`{markdown}`), `timeline` (`{events:[{ts,label,detail}]}`), `json` (raw), or omit to let Trinity infer from `report_type`. Pick deliberately — the customer-facing Workspace Reports tab renders through these same renderers, so a mismatched hint is visible to users.
- **Read before you write:** call `mcp__trinity__list_reports` first (metadata only — filters `report_type`, `hours` ∈ {0,1,6,24,168,720}, `search`) to avoid duplicating or contradicting a report you already filed, then `mcp__trinity__get_report` with an id to diff this period against the last.
- **Guard the call:** the tool exists only when running on Trinity (it publishes under this agent's own key). If `mcp__trinity__report` isn't available — e.g. running locally — skip it silently. **Trinity is an upgrade, not a requirement.**

Reports complement `dashboard.yaml`: the dashboard is the *current* snapshot (overwritten each refresh); reports are an *append-only* history of what the agent accomplished.

## Onboarding

This agent tracks your setup progress in `onboarding.json`. Run `/onboarding` to see
your checklist and continue where you left off.

On conversation start, if `onboarding.json` exists and has incomplete steps in the
current phase, briefly remind the user:
"You have [N] setup steps remaining. Run `/onboarding` to continue."

Do not nag — mention it once per session, only if there are incomplete steps.

### Installed Plugins

These plugins are installed during onboarding (`/onboarding` handles this automatically):


## Data Model

### competitors.json

The central watchlist. Each competitor is stored as a structured entry:

```json
{
  "competitors": [
    {
      "name": "Acme Corp",
      "slug": "acme-corp",
      "website": "https://acme.com",
      "tier": 1,
      "industry": "[industry]",
      "description": "What they do in one line",
      "added": "2026-04-06",
      "last_checked": null,
      "tracking": {
        "product_url": "https://acme.com/changelog",
        "pricing_url": "https://acme.com/pricing",
        "careers_url": "https://acme.com/careers",
        "g2_url": "",
        "linkedin_url": "",
        "crunchbase_url": ""
      },
      "notes": ""
    }
  ],
  "settings": {
    "industry": "[industry from Q1]",
    "focus": ["[selected dimensions from Q2]"],
    "scale": "[2-3 | 4-6 | 7+]",
    "output": "[battlecards | digest | matrix | all]"
  }
}

recon/
  CLAUDE.md                # This file — agent identity and instructions
  competitors.json         # Competitor watchlist and settings
  onboarding.json          # Setup progress tracker
  dashboard.yaml           # Trinity dashboard metrics
  template.yaml            # Trinity metadata
  .env.example             # Required environment variables
  .gitignore               # Git exclusions
  .mcp.json.template       # MCP server config template
  competitors/             # Per-competitor intelligence files
  .claude/
    skills/
      add-competitor/SKILL.md      # Add competitors to watchlist
      monitor/SKILL.md             # Scan for changes
      battlecard/SKILL.md          # Generate battlecards
      digest/SKILL.md              # Competitive digest
      landscape/SKILL.md           # Full landscape analysis
      onboarding/SKILL.md          # Setup progress tracker
      update-dashboard/SKILL.md    # Dashboard metrics updater

artifacts:
  CLAUDE.md:
    mode: prescriptive
    direction: source
    description: "Agent identity and behavior — single source of truth"

  competitors.json:
    mode: descriptive
    direction: target
    sources: [add-competitor/SKILL.md, monitor/SKILL.md]
    description: "Competitor watchlist — updated by /add-competitor and /monitor"

  onboarding.json:
    mode: descriptive
    direction: target
    sources: [onboarding/SKILL.md]
    description: "Persistent onboarding state — updated by /onboarding skill"

  dashboard.yaml:
    mode: descriptive
    direction: target
    sources: [update-dashboard/SKILL.md]
    description: "Trinity dashboard layout and metrics — updated by /update-dashboard"

  competitors/*/battlecard.md:
    mode: descriptive
    direction: target
    sources: [battlecard/SKILL.md]
    description: "Per-competitor battlecards — generated by /battlecard"

  competitors/*/history.md:
    mode: descriptive
    direction: target
    sources: [monitor/SKILL.md]
    description: "Competitor change history — appended by /monitor"

Skill	Schedule	Purpose
`/monitor`	`0 8 * * 1-5` (weekday mornings)	Daily competitor change detection
`/digest`	`0 9 * * 1` (Monday 9am)	Weekly intelligence summary
`/battlecard`	`0 10 1 * *` (1st of month)	Monthly battlecard refresh for all Tier 1 competitors
`/update-dashboard`	`0 /6 * *` (every 6 hours)	Keep Trinity dashboard metrics current


---

## STEP 5: Generate Skills

### 5a. /add-competitor

Write `[destination]/.claude/skills/add-competitor/SKILL.md`:

```yaml
---
name: add-competitor
description: Add a competitor to the watchlist with structured profile data
argument-hint: "<competitor-name>"
allowed-tools: Read, Write, Edit, Bash, WebSearch, WebFetch, AskUserQuestion
user-invocable: true
metadata:
  version: "1.0"
  created: 2026-04-06
  author: recon
---

# Add Competitor

## Purpose

Add a new competitor to your watchlist in `competitors.json` with structured profile data and tracking URLs.

## Process

### Step 1: Identify the Competitor

If no competitor name was provided as an argument, use AskUserQuestion:
- **Question:** "Which competitor should I add to the watchlist?"
- **Header:** "Competitor"
- **Options:**
  1. Let me type the company name
  2. Paste a URL (website, LinkedIn, Crunchbase)

### Step 2: Research Profile

Search the web for the competitor to gather:
- Official website URL
- One-line description (what they do)
- Key tracking URLs:
  - Product changelog or updates page
  - Pricing page
  - Careers/jobs page
  - G2 or Capterra profile
  - LinkedIn company page
  - Crunchbase profile

### Step 3: Set Tracking Tier

[If scale is 7+ from settings in competitors.json:]
Use AskUserQuestion:
- **Question:** "What tracking tier for [competitor]?"
- **Header:** "Tier"
- **Options:**
  1. **Tier 1** — Deep tracking. Full battlecards, detailed monitoring, every change logged.
  2. **Tier 2** — Headlines only. Key changes tracked, lighter monitoring, summary in digest.

[If scale is 2-3 or 4-6:] Default to Tier 1.

### Step 4: Confirm Profile

Display the gathered profile and ask for confirmation:


Use AskUserQuestion:
- **Question:** "Look good? I can also add notes about this competitor."
- **Header:** "Confirm"
- **Options:**
  1. Add as-is
  2. Let me edit or add notes
  3. Cancel

### Step 5: Update competitors.json

Read `competitors.json`. If it doesn't exist, create it with the structure from the Data Model section in CLAUDE.md.

Add the new competitor entry to the `competitors` array. Set `added` to today's date, `last_checked` to null.

Write updated `competitors.json`.

### Step 6: Create Competitor Directory

```bash
mkdir -p competitors/[slug]

# [Competitor Name] — Change History

## [Today's date]
- Added to watchlist

Added [Competitor Name] to watchlist.

Watchlist now has [N] competitors.

Next steps:
- Add more competitors: /add-competitor
- Run first scan: /monitor
- Generate battlecard: /battlecard [name]


### 5b. /monitor

Write `[destination]/.claude/skills/monitor/SKILL.md`:

```yaml
---
name: monitor
description: Scan tracked competitors for changes since last check — product, pricing, hiring, news, sentiment
argument-hint: "[competitor-name or 'all']"
allowed-tools: Read, Write, Edit, Bash, WebSearch, WebFetch, Glob, Grep, AskUserQuestion
user-invocable: true
metadata:
  version: "1.0"
  created: 2026-04-06
  author: recon
---

# Monitor Competitors

## Purpose

Scan one or all tracked competitors for changes since the last check. Detects product updates, pricing changes, hiring shifts, funding events, sentiment changes, and positioning moves — based on the tracking dimensions configured in `competitors.json` settings.

## Process

### Step 1: Load Watchlist

Read `competitors.json`. If it doesn't exist, tell the user to run `/add-competitor` first.

If an argument was provided, filter to that competitor. If "all" or no argument, scan all competitors (Tier 1 first if tiered).

### Step 2: Scan Each Competitor

For each competitor, check the tracking dimensions configured in `competitors.json` settings.focus:

**Product & feature changes:**
- Search web for "[competitor name] changelog" OR "[competitor name] new features" OR "[competitor name] release notes" — filter to last 30 days
- If tracking URL exists for changelog, fetch and look for recent entries

**Pricing moves:**
- Search web for "[competitor name] pricing change" OR "[competitor name] new plan"
- If pricing URL exists, search for recent discussions about their pricing

**Hiring & team growth:**
- Search web for "[competitor name] hiring" OR "[competitor name] jobs" — look for volume and roles
- If careers URL exists, search for new postings since last check

**Funding & financial events:**
- Search web for "[competitor name] funding" OR "[competitor name] acquisition" OR "[competitor name] revenue"

**Customer sentiment:**
- Search web for "[competitor name] review" site:g2.com OR site:capterra.com — recent
- Search web for "[competitor name]" site:reddit.com — recent discussions

**Content & positioning:**
- Search web for "[competitor name] announcement" OR "[competitor name] blog" — recent
- Look for messaging shifts, new case studies, conference presence

### Step 3: Classify Changes

For each finding, classify:
- **Signal strength:** High (confirmed, significant) / Medium (noteworthy) / Low (minor or unconfirmed)
- **Dimension:** Which tracking dimension it falls under
- **So what:** One sentence on what this means for the user's team

For an unconfirmed-but-promising signal, on Trinity arm `set_reminder` (one-shot self-trigger, trinity#1296; e.g. +7 days, message naming the competitor and signal) to re-check it on schedule instead of hoping the next sweep re-notices. Skip silently when Trinity MCP isn't connected.

### Step 4: Update History

For each competitor with changes, append to `competitors/[slug]/history.md`:


Update `last_checked` in `competitors.json` to today's date.

### Step 5: Report

Display a summary:


## Outputs

- Updated `competitors/[slug]/history.md` for each competitor with changes
- Updated `last_checked` timestamps in `competitors.json`
- Console summary with classified findings

---
name: battlecard
description: Generate or refresh a one-page competitive battlecard for a specific competitor
argument-hint: "<competitor-name>"
allowed-tools: Read, Write, Edit, Bash, WebSearch, WebFetch, Glob, Grep, AskUserQuestion
user-invocable: true
metadata:
  version: "1.0"
  created: 2026-04-06
  author: recon
---

# Battlecard

## Purpose

Generate or refresh a one-page competitive battlecard for a tracked competitor. Battlecards are concise, actionable docs for sales and product teams — not comprehensive research reports.

## Process

### Step 1: Select Competitor

If no argument provided, read `competitors.json` and use AskUserQuestion:
- **Question:** "Which competitor should I create a battlecard for?"
- **Header:** "Competitor"
- Show tracked competitors as options

If the competitor isn't in the watchlist, offer to add them first via `/add-competitor`.

### Step 2: Gather Intelligence

Read existing data:
- `competitors/[slug]/history.md` — past changes and signals
- `competitors/[slug]/battlecard.md` — previous battlecard (if refreshing)
- `competitors/[slug]/notes.md` — any freeform notes

Then do fresh research. Search the web for:
- "[competitor name] vs" — see how they position against alternatives
- "[competitor name] review" — recent customer perspectives
- "[competitor name]" site:[their website] — current messaging and claims
- "[competitor name] strengths weaknesses" — third-party analysis

### Step 3: Generate Battlecard

Write the battlecard in this format:


### Step 4: Save

Write battlecard to `competitors/[slug]/battlecard.md`.

### Step 5: Report


### Step 6: Publish a report (Trinity)

If the `mcp__trinity__report` tool is available (i.e. running on Trinity), publish the battlecard so it lands on the agent's **Reports** tab as an append-only record:

- `report_type`: `recon.battlecard`
- `title`: `"[Competitor] — battlecard"`
- `display_hint`: `markdown`
- `payload`: `{ "markdown": "<the battlecard you just wrote>" }` (or a `table`/`kpi` shape if you prefer the headline facts as tiles).

Skip this step **silently** if the tool isn't available — running locally, the saved battlecard is the deliverable. Reporting is an upgrade, not a requirement.

## Outputs

- `competitors/[slug]/battlecard.md` — complete battlecard
- A guarded `recon.battlecard` report on Trinity (skipped when running locally)
- Console summary with key takeaways

---
name: digest
description: Produce a competitive intelligence summary of recent changes across all tracked competitors
argument-hint: "[weekly | monthly | custom-period]"
allowed-tools: Read, Write, Edit, Bash, WebSearch, WebFetch, Glob, Grep, AskUserQuestion
user-invocable: true
metadata:
  version: "1.0"
  created: 2026-04-06
  author: recon
---

# Competitive Digest

## Purpose

Produce a competitive intelligence summary covering recent changes across all tracked competitors. Designed as a scannable briefing — what happened, so what, now what.

## Process

### Step 1: Determine Period

If an argument was provided, use it (weekly, monthly, or custom). Otherwise default to weekly (last 7 days).

### Step 2: Gather Changes

Read `competitors.json` to get the full watchlist.

For each competitor, read `competitors/[slug]/history.md` and filter to entries within the digest period.

If history is sparse, run a quick web search for each competitor to catch anything missed:
- "[competitor name]" — filter to the digest period

### Step 3: Classify and Rank

Sort all findings by signal strength (High → Medium → Low). Group by theme rather than by competitor when a trend spans multiple competitors.

### Step 4: Generate Digest


### Step 5: Save

Write digest to `competitors/digest-[YYYY-MM-DD].md`.

### Step 6: Report

Display the digest in the console.


## Outputs

- `competitors/digest-[date].md` — full digest
- Console display of the digest

---
name: landscape
description: Full competitive landscape analysis with feature comparison matrix and strategic positioning map
argument-hint: "[focus-area]"
allowed-tools: Read, Write, Edit, Bash, WebSearch, WebFetch, Glob, Grep, AskUserQuestion
user-invocable: true
metadata:
  version: "1.0"
  created: 2026-04-06
  author: recon
---

# Competitive Landscape

## Purpose

Produce a comprehensive competitive landscape analysis — a strategic overview of your market with feature comparisons, positioning analysis, and market dynamics. This is the deep-dive you run quarterly, not the weekly monitor.

## Process

### Step 1: Define Scope

Use AskUserQuestion:
- **Question:** "What should this landscape analysis focus on?"
- **Header:** "Focus"
- **Options:**
  1. **Full landscape** — All tracked competitors, all dimensions. Comprehensive quarterly review.
  2. **Feature comparison** — Feature-by-feature matrix across competitors. Best for product roadmap decisions.
  3. **Market positioning** — How each competitor positions themselves, target segments, messaging. Best for marketing/GTM strategy.
  4. **Custom focus** — Let me describe what I'm looking for.

### Step 2: Gather Data

Read all existing competitor data:
- `competitors.json` — watchlist and settings
- `competitors/*/battlecard.md` — existing battlecards
- `competitors/*/history.md` — change history
- `competitors/*/notes.md` — research notes

Then do fresh research for each competitor:
- Company overview, latest news, product updates
- Feature set and capabilities
- Pricing and packaging
- Target market and positioning

### Step 3: Generate Landscape Analysis

[Customize structure based on industry setting and output preference in competitors.json]


### Step 4: Save

Write analysis to `competitors/landscape-[YYYY-MM-DD].md`.

### Step 5: Report

Display the full analysis in the console.

## Outputs

- `competitors/landscape-[date].md` — comprehensive landscape analysis
- Feature comparison matrix
- Strategic recommendations

{
  "phase": "local",
  "started": "[today's date]",
  "steps": {
    "local": {
      "env_configured": { "done": false, "label": "Configure environment variables (.env)" },
      "first_competitor_added": { "done": false, "label": "Add your first competitor (/add-competitor)" },
      "first_monitor_run": { "done": false, "label": "Run your first competitive scan (/monitor)" },
      "plugins_installed": { "done": false, "label": "Install plugins (agent-dev, trinity)" }
    },
    "trinity": {
      "onboarded": { "done": false, "label": "Deploy to Trinity (/trinity:onboard)" },
      "first_remote_run": { "done": false, "label": "Run a skill remotely via MCP (mcp__trinity__chat_with_agent)" }
    },
    "schedules": {
      "schedules_configured": { "done": false, "label": "Set up scheduled tasks (use MCP schedule tools)" },
      "first_scheduled_run": { "done": false, "label": "Verify first scheduled execution completed" }
    }
  }
}

---
name: onboarding
description: Track your setup progress — shows what's done, what's next, and walks you through each step
allowed-tools: Read, Write, Edit, Bash, AskUserQuestion
user-invocable: true
metadata:
  version: "1.0"
  created: 2026-04-06
  author: recon
---

# Onboarding

Track and continue your setup progress. This skill reads `onboarding.json`, shows your current status, and walks you through the next incomplete step.

## Process

### Step 1: Load State

Read `onboarding.json` from the agent root directory. If it doesn't exist, inform the user that onboarding is complete or the file was removed.

### Step 2: Show Progress

Display a checklist grouped by phase. Mark the current phase with an arrow. Use checkboxes to show completion:


### Step 3: Guide Next Step

Identify the first incomplete step in the current phase. Based on which step it is, provide specific guidance:

**For `env_configured`:**
- Check if `.env` exists. If not, guide: `cp .env.example .env` then fill in values.
- List the required variables from `.env.example` and what each one is for.
- After user confirms, mark done.

**For `first_competitor_added`:**
- Tell the user to run `/add-competitor` with their primary competitor.
- Tip: "Start with your #1 competitor — the one that comes up most in deals."
- After they add at least one competitor, mark done.

**For `first_monitor_run`:**
- Tell the user to run `/monitor` to do their first competitive scan.
- After scan completes, mark done.

**For `plugins_installed`:**
- Run the install commands for each plugin:

- Run each install command via Bash. If a plugin fails to install, note the error and continue with the rest.
- After all plugins are attempted, show the results (installed / failed) and mark done.

**For `onboarded` (Trinity phase):**
- Check if trinity plugin is installed. If not, guide installation.
- Tell user to run `/trinity:onboard`.
- After completion, mark done and advance phase to "trinity".

**For `first_remote_run`:**
- Tell user to run a skill remotely using `mcp__trinity__chat_with_agent`.
- After completion, mark done and advance phase to "schedules".

**For `schedules_configured`:**
- Tell user the recommended schedules are declared in `template.yaml` (`schedules:`); deploying with `/trinity:onboard` reconciles them onto the instance. Recommended:
- `/monitor` — weekday mornings (`0 8 * * 1-5`)
- `/digest` — Monday morning (`0 9 * * 1`)
- `/update-dashboard` — every 6 hours (`0 */6 * * *`)
- To turn one on/off on the live agent, use `mcp__trinity__toggle_agent_schedule`.
- After completion, mark done.

**For `first_scheduled_run`:**
- Tell user to check scheduled executions via `mcp__trinity__get_schedule_executions`.
- After verified, mark done.

### Step 4: Update State

After each step is completed, update `onboarding.json`:
- Set the step's `done` to `true`
- If all steps in current phase are done, advance `phase` to the next phase
- If all phases complete, congratulate the user and note that they can delete `onboarding.json` or keep it as a record

### Step 5: Phase Transitions

When all steps in a phase are complete:

**Local → Trinity:**


**Trinity → Schedules:**


**All Complete:**


## Outputs

- Updated `onboarding.json` with progress
- Step-by-step guidance for the current task
- Phase transition messages at milestones

title: "Recon"
refresh: 300
updated: "[today's date ISO]"

sections:
  - title: "Status"
    layout: grid
    columns: 3
    widgets:
      - type: status
        label: "Agent Status"
        value: "Active"
        color: green
      - type: metric
        label: "Competitors Tracked"
        value: "0"
        description: "Total in watchlist"
      - type: metric
        label: "Last Scan"
        value: "—"
        description: "Most recent /monitor run"

  - title: "Intelligence"
    layout: grid
    columns: 3
    widgets:
      - type: metric
        label: "Changes This Week"
        value: "0"
        description: "Across all competitors"
      - type: metric
        label: "High Signals"
        value: "0"
        description: "Requiring attention"
        color: red
      - type: metric
        label: "Battlecards"
        value: "0 / 0"
        description: "Up to date / total"

  - title: "Recent Activity"
    layout: list
    widgets:
      - type: list
        title: "Latest Changes"
        items: []
        max_items: 5

  - title: "Quick Links"
    layout: list
    widgets:
      - type: link
        label: "Trinity Dashboard"
        url: "https://ability.ai"
        external: true

---
name: update-dashboard
description: Refresh dashboard.yaml with current metrics from competitor tracking data
allowed-tools: Read, Write, Edit, Bash, Glob, Grep
user-invocable: true
metadata:
  version: "1.0"
  created: 2026-04-06
  author: recon
---

# Update Dashboard

Refresh `dashboard.yaml` with current metrics gathered from competitor tracking data.

## Process

### Step 1: Gather Metrics

Read the agent's data sources:
- `competitors.json` — count competitors, check last_checked dates
- `competitors/*/history.md` — count recent changes (last 7 days), count high-signal findings
- `competitors/*/battlecard.md` — count battlecards, check freshness (>30 days = stale)
- `competitors/digest-*.md` — find most recent digest date
- Recent git activity: `git log --oneline -5`

Calculate:
- Total competitors tracked
- Last scan date (most recent `last_checked` across all competitors)
- Changes this week (count history entries from last 7 days)
- High signals this week (count "High" signal entries from last 7 days)
- Battlecard freshness (up-to-date count / total count)
- Latest 5 changes for the activity list

### Step 2: Update Dashboard

Read the current `dashboard.yaml`, update widget values:

- "Competitors Tracked" → count from competitors.json
- "Last Scan" → most recent last_checked date
- "Changes This Week" → count of recent changes
- "High Signals" → count (color: red if >0, gray if 0)
- "Battlecards" → "[fresh] / [total]"
- "Latest Changes" → last 5 changes from history files
- `updated` → current ISO timestamp

Write the updated `dashboard.yaml`.

### Step 3: Confirm


## Notes

- On Trinity remote, the dashboard path is `/home/developer/dashboard.yaml`
- This skill is designed to run on a schedule (every 6 hours recommended)
- Keep execution fast — read local files only, no web searches

## Outputs

- Updated `dashboard.yaml` with current metrics

{
  "competitors": [],
  "settings": {
    "industry": "[industry from Q1]",
    "focus": ["[selected dimensions from Q2]"],
    "scale": "[2-3 | 4-6 | 7+ from Q3]",
    "output": "[battlecards | digest | matrix | all from Q4]"
  }
}

name: recon
display_name: Recon
description: |
  Competitive intelligence agent for [industry from Q1].
  Tracks [N] competitors across [selected dimensions from Q2],
  produces [output format from Q4], and keeps your team informed
  with actionable intelligence.
avatar_prompt: [industry-specific prompt from above]
resources:
  cpu: "2"
  memory: "4g"

# Claude Code plugins this agent needs — DECLARED, not typed (trinity#1704). Trinity materializes
# this as a committed ~/.trinity/plugins.yaml and re-installs it headlessly on every container
# boot, so the deployed agent has them without anyone running /plugin install. Mirror CLAUDE.md.
plugins:
  marketplaces:
    - name: abilityai
      source: abilityai/abilities
  installed:
    - agent-dev@abilityai
    - trinity@abilityai

# What this agent needs, BY NAME ONLY — names-only is the frozen contract; never values.
# Every ${VAR} used in .mcp.json.template must appear here or the agent HARD-fails
# compatibility check T-015. An agent with no secrets declares an explicit `credentials: {}`.
credentials:
  env_file: [EXAMPLE_API_KEY]

# Per-variable setup guidance (ent#128). DECORATES credentials: — it cannot declare a
# name that isn't above (undeclared entries are dropped). Drives the platform's guided
# checklist: GET /api/agents/{name}/credential-requirements (ent#127).
credential_setup:
  - name: EXAMPLE_API_KEY
    title: Example service API key
    description: What the agent uses it for, in one line.
    required: true
    secret: true
    format: secret
    setup_url: https://example.com/settings/api-keys

# Recommended schedules (design source of truth). Trinity materializes this block
# ON AGENT CREATION, deduplicated by `name` — at most 20 entries, and NEVER re-applied
# on recreate, so a schedule added here after deployment must be created with
# create_agent_schedule (or reconciled by /trinity:onboard | /trinity:sync).
# `enabled` is the recommended default and only a literal YAML true arms a schedule;
# firing ALSO requires the agent's autonomy gate, which is OFF on every new agent.
# timezone: canonical IANA zones only — legacy aliases (Europe/Kiev, Asia/Calcutta,
# US/Eastern) no longer resolve and 500 on schedule create. The container clock is UTC.
# Adjust to fit this agent.
schedules:
  - name: Daily competitor sweep
    cron: "0 6 * * 1-5"
    timezone: UTC
    message: "/monitor"
    purpose: Daily change monitoring
    enabled: false
  - name: Weekly battlecard refresh
    cron: "0 9 * * 1"
    timezone: UTC
    message: "/battlecard"
    purpose: Keep battlecards current
    enabled: false

# Recon — Environment Variables
# Copy this to .env and fill in your values

# No API keys required for basic operation.
# Recon uses web search and public sources by default.

# Optional: Add API keys for richer data sources
# CRUNCHBASE_API_KEY=
# BUILTWITH_API_KEY=

# Credentials — never commit
.env
.mcp.json

# OS files
.DS_Store
Thumbs.db

# Claude Code
.claude/settings.local.json
.claude/projects/
.claude/statsig/
.claude/todos/
.claude/debug/
.claude/sessions/
.claude/shell-snapshots/
.claude/plugins/
.claude/backups/
# Container-only config: the Trinity base image bakes ~/.claude/settings.json with
# hook paths that exist only inside the container, and HOME is the repo root. A
# committed copy bricks any clone made outside it (the missing hook exits 2, which
# Claude Code reads as "block this tool call"). Trinity enforces this fleet-wide and
# untracks an already-committed copy on the next Push (trinity#2036).
.claude/settings.json
# Trinity runtime state — star form so authored hooks stay tracked
.trinity/*
!.trinity/pre-check
!.trinity/post-check
!.trinity/setup.sh
credentials.json

{
  "mcpServers": {}
}

cd [destination] && git init && git add -A && git commit -m "Initial agent scaffold: recon"

## Recon Installed

Your competitive intelligence agent is ready.

### What Was Created

| File | Purpose |
|------|---------|
| `CLAUDE.md` | Agent identity — customized for [industry] competitive analysis |
| `.claude/skills/add-competitor/SKILL.md` | Add competitors to watchlist |
| `.claude/skills/monitor/SKILL.md` | Scan for competitive changes |
| `.claude/skills/battlecard/SKILL.md` | Generate sales battlecards |
| `.claude/skills/digest/SKILL.md` | Weekly intelligence digest |
| `.claude/skills/landscape/SKILL.md` | Full landscape analysis |
| `.claude/skills/onboarding/SKILL.md` | Setup progress tracker |
| `.claude/skills/update-dashboard/SKILL.md` | Dashboard metrics updater |
| `competitors.json` | Competitor watchlist and settings |
| `onboarding.json` | Persistent onboarding checklist |
| `dashboard.yaml` | Trinity dashboard with CI metrics |
| `template.yaml` | Trinity deployment metadata |
| `.env.example` | Environment variable template |
| `.gitignore` | Git exclusions |
| `.mcp.json.template` | MCP config template |

### Get Started

1. Open your new agent:


2. Run the setup wizard:


This will walk you through adding your first competitors,
running your first scan, and (when you're ready) deploying to Trinity.

3. **Add cross-session durability** (recommended):

Situation	Action
Destination exists	Warn, offer alternatives
Git not installed	Skip git init, advise install
User unsure about questions	Provide sensible defaults, allow skipping
gh CLI not available	Show manual GitHub instructions
No competitors to monitor	Guide to /add-competitor first
Web search rate limited	Note in output, suggest retry later

They say...	We respond...
"[Common competitor claim]"	"[Our counter with evidence]"
"[Another claim]"	"[Counter]"

Feature	[Us]	[Comp 1]	[Comp 2]	[Comp 3]
[Feature 1]	✅	✅	❌	⚠️
[Feature 2]	✅	⚠️	✅	❌
...	—	—	—	—

install-recon

Informações da origem

Opções de instalação

Revise os arquivos de origem

Install Recon

STEP 1: Determine Destination

STEP 2: Domain-Specific Questions

Q1: Industry / Market

Install Recon

STEP 1: Determine Destination

STEP 2: Domain-Specific Questions

Q1: Industry / Market

Q2: Tracking Focus

Q3: Competitor Count

Q4: Intelligence Output

STEP 3: Create Agent Directory Structure

STEP 4: Generate CLAUDE.md

competitors/ directory

Project Structure

Artifact Dependency Graph

Recommended Schedules

Guidelines

Adding: [Competitor Name]

Step 7: Confirm

Outputs

[Today's date]

Competitive Monitor — [Date]

[Competitor 1]

[Competitor 2]

[Competitor 3]

5c. /battlecard

[Competitor Name] — Battlecard

Overview

Their Strengths (be honest)

Their Weaknesses (our opportunities)

How They Position Against Us

How We Win Against Them

Trap Questions

Objection Handling

Recent Activity

Key People

5d. /digest

Competitive Intelligence Digest

Headlines

By Competitor

[Competitor 1]

[Competitor 2]

Trends to Watch

Action Items

5e. /landscape

Competitive Landscape Analysis

Executive Summary

Market Map

Feature Comparison Matrix

Positioning Analysis

[Competitor 1]

[Competitor 2]

Pricing Comparison

Market Dynamics

Trends

Threats

Opportunities

Strategic Recommendations

STEP 6: Generate Onboarding Tracker

6a. Generate onboarding.json

6b. Generate /onboarding skill

Recon — Setup Progress

Phase 1: Local Setup ← current

Phase 2: Trinity Deployment

Phase 3: Schedules

Local Setup Complete!

Trinity Deployment Complete!

Onboarding Complete!

STEP 7: Generate Dashboard

7a. Generate dashboard.yaml

7b. Generate /update-dashboard skill

STEP 8: Generate Supporting Files

8a. Generate competitors.json

8b. Generate template.yaml

8c. Generate .env.example