Skill Radar

skill-radar

Find recurring manual workflows in the user's data sources, score each by how much toil it costs, check whether an existing public skill already solves it, and for every unmatched opportunity draft a complete, installable SKILL.md. Produce a ranked report the user can act on — not a list of vague suggestions.

What good output looks like (the contract)

The analysis is the contract. Where it lands is the user's call — written to disk, sent by email, or both (see the Delivery section below). The full ranked report uses the template at the bottom of this skill. When the user opts to write drafts to disk, each selected opportunity gets its own folder:

• skill-radar-report-<YYYY-MM-DD>.md — the full ranked report (written when the user picks disk). Every NEW or PARTIAL opportunity has its drafted SKILL.md embedded inline. An Installation appendix lists per-target install commands.
• skill-radar-report-<YYYY-MM-DD>/drafts/<skill-name>/SKILL.md — one folder per opportunity the user selected for write-to-disk. Ready to copy into ~/.claude/skills/ or any other supported target.

A good report is:

• Specific. Each opportunity names the exact trigger, action, variable parts, and stable parts. No "consider an email skill."
• Quantified. Each opportunity carries a toil score with a visible friction breakdown so the user can see the math.
• Honest. Every recommendation includes a "why it might not be" line. Skipped patterns are listed with reasons.
• Already-checked against public skills. No recommendation to build something Anthropic already ships.
• Installable. Drafts are full SKILL.md files, not scope summaries.

If the report reads like a generic productivity audit, it has failed.

Inputs: what to scan

skill-radar is source-agnostic. The user names what to scan — there is no fixed list. Common sources:

• Email — Gmail, Outlook (via MCP)
• Cloud drives — Google Drive, OneDrive, Dropbox (via MCP)
• Calendars (via MCP)
• Chat — Slack, Teams, Discord (via MCP)
• Issue trackers, code hosts, CRMs (via MCP)
• Local filesystem paths
• Terminal / shell history (zsh, bash, fish)
• Browser history exports
• Note systems — Obsidian, Apple Notes, Notion
• AI assistant conversation history:
  • Past sessions on disk — ~/.claude/projects/*.jsonl, ~/.codex/sessions/, Cursor's local DB, ChatGPT / Claude.ai exports. The strongest single source for recurring AI-assisted toil: if the user has asked Claude the same question twelve times across months, that's a skill candidate that nothing else surfaces. Opt-in (sensitive — see Principle 8).
  • The current session — the conversation in which skill-radar is being invoked. Useful as priming context (what mode is the user in, what's already been discussed, which sources are likely relevant) rather than as the primary pattern source. A single session is too small a sample to call something "recurring," but it sharpens the scan that runs across the larger corpus.
• Personal task managers — Todoist, Apple Reminders, OmniFocus, Things, Notion-as-task-manager. Recurring tasks are self-labeled in these apps, which makes them an unusually direct toil signal.
• Time-tracking tools — Toggl, Harvest, RescueTime, Clockify. The user has already logged where their hours go.
• The user's existing automation surface — crontab -l, macOS Shortcuts (shortcuts list), Zapier, IFTTT, GitHub Actions in nearby repos, shell aliases in ~/.zshrc, installed skills in ~/.claude/skills/. Not a source of new toil signals — a source for detecting what the user has already automated, so the report doesn't propose rebuilding what works. See Principle 5.
• Anything else the user provides as a path or MCP-connected service

If the user is vague ("just look at my stuff"), enumerate the available MCP connections and local paths and ask them to pick. Never silently scan anything not explicitly authorized — that is the floor, not a preference.

Process

1. Capture sources. If the user is vague ("just look at my stuff"), introspect on the MCP tools loaded in this session (Gmail, Drive, Calendar, Slack, Spotify — whatever's wired up) and list them back alongside common local paths (terminal history, shell config, AI session logs, crontab -l, ~/.claude/skills/). Ask the user to pick which to authorize. Confirm the time window (default 60–90 days) and exclusions. Repeat the final authorized list back to the user before starting.
2. Gather signals. Pull representative activity per source. Breadth before depth — sample widely first, then drill into the patterns that look promising. Cache raw signal to the working directory under skill-radar-cache-<YYYY-MM-DD>/ so reruns don't re-fetch.
3. Detect patterns. Find recurring tasks both within a single source and across sources (see Principle 1).
4. Score. Rank by toil cost (see Principle 3).
5. Match against existing skills. Before drafting anything new, check public skills (see Principle 5).
6. Draft SKILL.md per opportunity. For each NEW or PARTIAL match, produce a full SKILL.md, not a scope summary (see Principle 6).
7. Present, then ask. First, show the user the full report inline — every opportunity ranked by toil cost, with toil score breakdown, sources, pattern, evidence, sensitivity, recommendation classification, agentic complexity, why-good and why-not lines, plus the drafted SKILL.md per opportunity. The skipped patterns and assumptions sections too. The user reads everything before being asked to decide anything. Once they've seen what was found, ask: (a) which drafts to write to disk — all / none / specific opportunity numbers (default: none, since every file written should be an explicit choice), and (b) should the report be archived — saved to disk as .md, emailed, both, or neither (they've already read it inline). Execute per their choices. The user can't decide what to keep until they see what was found, so this order matters. In unattended mode with a config file at ~/.skill-radar/config.json, skip the inline display and deliver per the config — there's no human to ask. See the Delivery section below.

Smart principles

These are the difference between this skill and a generic productivity audit. Each is first-class.

1. Cross-source workflow detection

A workflow that spans Calendar + Drive + Email is one skill, not three. Look explicitly for chains: a calendar event triggers a Drive lookup which triggers an email reply. These chains are usually the highest-value opportunities — they save more time per instance, and a per-source scan misses them entirely. Label them Cross-source in the report's source line and lead the ranking with them when toil scores are close.

2. Specificity principle

Every opportunity must drill from category to a specific job. Vague is the enemy. Each opportunity must answer four blanks:

• Trigger — the exact moment that starts the work (e.g., "auditor email lands in the audit-2026 Gmail label")
• Action — what the user does manually (e.g., "searches Drive for the control evidence, copies the link, replies with a 3-paragraph template")
• Variable parts — what changes each time, named (e.g., "control ID, evidence link, auditor name")
• Stable parts — what stays the same (e.g., "the 3-paragraph reply body, the closing line")

If any blank is unfillable, the opportunity isn't specific enough yet — keep digging, or drop it.

Skills are named for the specific job, not the domain. Specific names self-describe; vague names trigger badly because they fight every other skill in the catalog.

3. Toil scoring with friction multipliers

score = frequency × per-instance time × friction multiplier

Where friction multiplier is the product of:

• Context switching ×1.5 if the task interrupts focused work
• Cognitive load ×1.3 if the user has to recall state from memory
• Error sensitivity ×1.2 if mistakes are costly (audit, finance, customer-facing, regulated)
• Mood tax ×1.2 if the user visibly dreads the task (signals: avoidance, end-of-week batching, repeated complaints)

Estimate conservatively — under-promising the savings is better than overselling. Drop candidates below ~5 hours/year unless they carry named strategic value: consistency, audit defensibility, cognitive offload. State the strategic value explicitly when keeping a low-score item.

Show the breakdown in the report so the user can push back on the math:

Toil: ~23 hrs/year (75 instances × 8 min × 1.5 context-switch × 1.2 error-sensitivity)

4. One workflow, one proposed skill

Three distinct recurring email patterns is three opportunities and three proposed skills, not one bundled "email helper." Bundling robs the user of the choice of which to build first, produces sprawling SKILL.md files that trigger badly, and hides the real cost/benefit of each piece.

If you're tempted to merge — don't. The Specificity principle and this one reinforce each other.

5. Existing-skill matching before proposing new skills

Search order, every time, before drafting anything new:

1. Anthropic public skills at /mnt/skills/public/ (if available in this environment)
2. The official anthropics/skills GitHub repository
3. Any additional public skill repositories the user names

Do not search the user's own code repositories. Recommending the user's own past work back to them is noise, not insight.

Do check the user's existing automation surface, though — crontab -l, macOS Shortcuts, installed skills in ~/.claude/skills/, shell aliases in ~/.zshrc, GitHub Actions in nearby repos. If a workflow is already running there, classify it as EXISTING and skip the rebuild. This is different from searching code repos for past work — this asks "has the user already solved this?" and respects the answer. Zapier, IFTTT, and Make.com scenarios can't be detected locally; ask the user about those.

Match semantically, not by keyword. xlsx matches "I keep manually rebuilding the same monthly spreadsheet" even though neither phrase mentions Excel. pdf matches "every Friday I have to pull text out of those scanned reports."

Classify each opportunity:

• EXISTING — an available public skill solves the job directly. Recommend installing it, don't draft a new one.
• PARTIAL — an existing skill covers part. Name the gap and draft a thin SKILL.md that calls the existing skill plus closes the gap.
• NEW — no match. Draft a full SKILL.md.

6. Drafted SKILL.md per NEW or PARTIAL opportunity

This is the difference between skill-radar and a list of suggestions. For every NEW or PARTIAL opportunity, produce a complete, installable SKILL.md at skill-radar-report-<YYYY-MM-DD>/drafts/<skill-name>/SKILL.md. Each draft follows skill-creator best practices:

• Pushy YAML description with multiple trigger phrasings
• Contract before recipe — what good output looks like, then how to produce it
• Imperative form ("Draft the email", not "The skill should draft the email")
• ≤ 200 lines
• Anti-patterns section when relevant
• Examples drawn from the actual evidence gathered in Step 2 — real subject patterns, real folder names from the user's data. Do not invent placeholders; the whole point is that the draft is grounded in this user's workflow.
• Footer line: "Refine via skill-creator and run evals before relying on this in production."

The draft is a starting point, not a finished product. Be explicit about that in the report.

7. Cross-platform install commands

Not everyone running skill-radar lives in Claude Code. The Installation appendix in the report lists per-target install one-liners. Be honest about which targets accept the SKILL.md format directly and which need adaptation.

8. Privacy-first defaults

Sensitive sources are opt-in, never opt-out.

By default, skill-radar does not scan email labels, folders, or channels likely to contain:

• Financial content (banking, payroll, tax)
• Medical content (health records, insurance, therapy)
• Legal content (counsel, contracts under negotiation)
• HR content (performance, hiring, terminations, employee relations)
• Family-private content (relationships, kids, household)
• AI assistant conversation history — past sessions with Claude Code, Codex CLI, Cursor, ChatGPT, etc. often contain work code, financial or medical questions the user has asked, personal context, and private credentials in worked-through examples. Opt-in only, even when the path is technically readable.

If sensitive content surfaces during a scan of an authorized source, exclude it from the report entirely — don't redact. Even the count of how many sensitive items were seen is signal worth omitting.

Tag every opportunity with a sensitivity label (public, internal, confidential) so the user can filter before sharing the report.

9. Anti-pattern checks

Do not propose automating:

• Creative work where the value is human judgment — writing, design, hiring decisions, performance feedback
• Relationship maintenance disguised as repetition — birthday messages, condolence emails, 1:1 prep notes. The manual effort is the point; automating it cheapens the relationship.
• Workflows that exist because of a broken upstream process. If the user re-runs the same fix every week, the right move is to repair the upstream — don't paper over it with a skill.
• Anything below the time-cost floor (~5 hours/year) unless strategic value is named.
• Anything the user explicitly excluded in Step 1.

List the patterns you considered and skipped in the report with one-line reasons. Silent dropping is wrong — it hides reasoning the user might want to argue with. Transparency about what was rejected is part of being smart.

10. Honest counter-arguments

Every recommendation includes a "why it might not be" line. The report is not a hype list. Reasons a recommendation might not survive scrutiny:

• The pattern looks recurring but is one-off variations clustered in time
• The variable parts are too unpredictable to template
• The user enjoys the work (mood signal misread)
• An upstream fix would obsolete the skill
• The toil estimate relies on extrapolation from a small sample
• The skill would need data the user is unwilling to give the agent

If you can't think of a counter-argument, you haven't thought hard enough. The user must be able to push back informedly.

Delivery

skill-radar's analysis is fixed; its delivery is flexible. The user picks at runtime — unless a config file overrides for unattended runs. The skill never writes drafts or sends email without an explicit choice.

Interactive mode (default)

Order matters: show the full report first, then ask. The user can't decide what to keep until they see what was found. Asking upfront makes the skill feel pushy and forces decisions on information that isn't yet visible.

1. Show the full report inline in the conversation — all opportunities, ranked, with embedded drafts and counter-arguments. The skipped patterns and assumptions sections too. This is the same content that would land on disk as skill-radar-report-<YYYY-MM-DD>.md, just rendered into the chat.
2. Then ask: which drafts to write to disk? — all / none / specific opportunity numbers (e.g., "1, 3"). Default to none if the user gives an ambiguous answer — every file written should be an explicit user choice.
3. Then ask: should the report be archived? — save the .md to disk for later reference, email a copy, both, or neither (the user has already read it inline, so "neither" is a valid finish).
4. Execute per their choices.

The full report always covers every opportunity surfaced — including ones the user didn't pick to write to disk. Choosing "none" for drafts just means no per-skill folders get created; the report itself still names the skipped opportunities so the user can come back to them later.

Unattended mode (cron, /schedule, GitHub Action)

If ~/.skill-radar/config.json exists, treat it as the source of truth and skip the interactive prompts entirely — there's no human to answer. The config specifies email recipient, send mechanism (SMTP / Resend / Gmail draft), and which drafts to auto-write. A complete template with inline comments and SMTP examples for multiple providers lives alongside this SKILL.md at config.example.json — copy it to ~/.skill-radar/config.json, fill in your values, and store the SMTP password in the env var named in the config (never in the config file itself).

Sending mechanics

skill-radar is agnostic to how email leaves the laptop. Use whatever tools are available, in this preference order:

1. SMTP if the config has SMTP credentials — most universal. Works with Gmail (via app password), Outlook, ProtonMail Bridge, Fastmail, custom domains. Standard protocol, no vendor relationship.
2. External email API (Resend, Postmark, SendGrid) if configured. Cleaner HTML rendering, free tiers cover personal volume, but adds an external account.
3. Gmail draft via the Gmail MCP as a fallback when SMTP/API aren't configured. Creates a draft the user clicks to send. Zero setup but not headless.

HTML formatting

When the user picks email, render the Markdown report to HTML at send time. Include a plain-text alternative in the email's text part so non-HTML clients (and unsubscribed-from-rich-content people) get a readable version. Key rendering points:

• Headings → <h1>/<h2>/<h3> with sensible inline styling so the report reads well in Gmail's web client and macOS Mail
• Tables → real <table> markup, not pre-formatted text — readable on mobile
• Code blocks → <pre><code> with a monospace font
• Each opportunity's embedded SKILL.md draft → render as a <pre><code> block (preserving Markdown source) rather than HTML — the user copies the draft as-is

What gets sent vs. written

Drafts that don't get written can always be regenerated by re-running skill-radar — the analysis is cheap relative to the underlying scan.

Report template

Use this exact shape for skill-radar-report-<YYYY-MM-DD>.md. The structure is the contract; the prose inside each section is for you to write.

# skill-radar report — <YYYY-MM-DD>

**Sources scanned:** <list>
**Time window:** <start> – <end>
**Exclusions:** <labels / folders / channels the user opted out of>

## Summary

- Opportunities surfaced: <N>
- Total estimated toil: ~<X> hours/year
- Covered by existing skills: <N>
- New skill drafts produced: <N>
- Patterns skipped: <N> (see below)

## Opportunities (ranked by toil cost)

### 1. <Title — the specific job>

- **Toil:** ~<X> hrs/year (<freq> × <time> × <friction breakdown>)
- **Sources:** <e.g., Gmail + Drive — Cross-source>
- **Pattern:** <1–2 sentences — Trigger → Action → Variable parts → Stable parts>
- **Evidence:** <concrete examples from the actual scan — subject lines, folder names>
- **Sensitivity:** <public | internal | confidential>
- **Recommendation:** <EXISTING | PARTIAL | NEW>
- **Agentic complexity:** <template-only | tool-orchestration | decision-making>
- **Scope at a glance:** <one paragraph>
- **Why it's a good candidate:** <…>
- **Why it might not be:** <honest counter-argument>

<!-- For NEW / PARTIAL only: -->

**Drafted SKILL.md:**

```markdown
---
name: <skill-name>
description: <pushy description with multiple trigger phrasings>
---

<full SKILL.md body — ≤ 200 lines, contract before recipe, imperative form>

Refine via skill-creator and run evals before relying on this in production.
```

**Quick install (Claude Code, personal):**

```bash
cp -r skill-radar-report-<YYYY-MM-DD>/drafts/<skill-name> ~/.claude/skills/
```

### 2. <next opportunity>
...

## Skipped patterns

- **<Pattern>** — <one-line reason>
- **<Pattern>** — <one-line reason>

## Assumptions

- **Time-per-instance:** <how it was estimated — direct timing, user report, conservative default>
- **Frequency:** <how it was extrapolated — last N days × annualization factor>
- **Friction multipliers applied:** <which and why>
- **Sources excluded:** <list — with reason>

## Installation appendix

<per-target one-liners — see the table in skill-radar's SKILL.md>

Notes for the model running this skill

• Trust the user's time estimates over your own when they give one. Use defaults only when the user can't estimate.
• Cache raw signal to skill-radar-cache-<YYYY-MM-DD>/. Reruns and refinements shouldn't re-fetch source data.
• Don't ask permission for the same thing twice. Once a source is authorized, scan it without checking back in for every label.
• Don't pad the report with low-confidence guesses. Five strong opportunities beats fifteen mediocre ones — quality is the contract, length isn't.
• If you find nothing worth automating, say so. A short, honest report that recommends nothing is better than an inflated one.
• Tag every opportunity with Agentic complexity so the user can pick what to build first. The three levels are:
  • template-only — fixed structure, swap-in values, no tool calls or judgment. A snippet manager could almost do it. Cheapest to build, lowest risk.
  • tool-orchestration — calls MCP / external tools on a deterministic path (read X, extract Y, write Z). No branching judgment. Medium build cost, medium risk; failure modes are mostly "tool unavailable" or "data shape changed."
  • decision-making — the skill chooses between actions based on content (draft vs. escalate, category A vs. B, send vs. hold). Highest build cost, highest risk; needs evals before production. Sort within the same toil tier by ascending agentic complexity — cheap wins build the user's trust in the system before they invest in the harder ones.

This is the v0.1.0 release. Drafts it produces are starting points — refine via skill-creator and run evals before relying on any drafted skill in production.