# Candidate selection

Read this at step 2, or when someone asks which jobs are worth packaging. Fill [../assets/candidate-scorecard.csv](../assets/candidate-scorecard.csv) as you go; one row per candidate, including the ones you reject, so the next review can see why.

## The five qualifying conditions

A job becomes a skill only when all five hold. Record the evidence for each in the scorecard, not a yes or no.

1. Recurrence: at least 3 occurrences in the last 90 days, or a fixed weekly or monthly cadence. Count from calendar entries, tickets, chat history or the output folder. Memory overstates how often a job happens.
2. Read-only input route: the inputs can be read without write access. Acceptable routes: an export file, a read-only MCP mode or switch, a read-only identity (View-only CRM user, GTM Read permission, a SELECT-only warehouse role). If the only route today is an admin login that can write, fix the route before building anything.
3. Written acceptance check: the reviewer writes "look at X, pass = Y" before the build. Example: "look at the row count of reviewed.csv; pass = equal to the input row count, and every campaign_id present". If nobody can write it, nobody can review the output either.
4. Observed baseline failure: run one real example in a fresh session with no skill installed, under the session rules in [testing.md](testing.md) (no write-capable MCP, app or connector tool, manual approval, tool list recorded), and record which check it failed. A real request can include the live change, and without the skill nothing stops the agent making it. Typical baseline failures in marketing work: counts an incomplete day, invents a missing value, merges or drops rows, matches records by name, proposes a live change. If the baseline passes every check, the model already knows the job and a skill adds tokens without adding value.
5. Named owner: one person approves the procedure, answers when it breaks and owns the review date. A team alias is not an owner.

## Scorecard columns

- `job`: the job in a few words, as people say it.
- `owner_role`: the role that approves the procedure (paid media lead, RevOps manager).
- `occurrences_90d`: counted occurrences in the last 90 days; leave blank if not counted yet.
- `cadence`: weekly, monthly, ad hoc.
- `inputs`: the files, exports or systems the job reads, and the `martech-context/` files it needs.
- `read_only_route`: how the inputs are read without write access.
- `output`: what the job hands back.
- `acceptance_check`: the "look at X, pass = Y" check.
- `baseline_failure`: what the no-skill run got wrong, or "not run".
- `systems_touched`: systems the output affects, and whether through exports only.
- `write_risk`: none (reads and local files), draft (prepares a change list, import file or message draft for someone else to apply), live (would change a system itself). Version 1 never ships with live.
- `net_minutes_saved`: per run, after preparation, run, review and fixes (formula below).
- `priority`: occurrences_90d times net_minutes_saved.
- `classification`: one of adapt, wrap, instruction rule, script, manual-only skill with command, skill, prompt.
- `reuse_candidate`: the pack, vendor or installed skill to adapt or call, or none.
- `decision`: build now, wait, do not build, and the rank.
- `notes`: anything the reviewer needs, such as the hand-off for live changes.

## Classification, first match wins

Check these in order and stop at the first that fits.

1. An existing skill covers it: adapt it (installed or pack skill) or wrap it (official vendor skill). Same inputs and same output means the same skill.
   - "Audit our GTM container before the agency hand-over": gtm-container-audit, adapted with the team's expected and retired IDs.
   - "Reconcile Shopify orders with GA4 purchases": purchase-reconciliation.
   - Official vendor skills seen on 2026-11-06, each with its repository in `sources.yaml`, to confirm live before relying on one: HubSpot, Mixpanel, PostHog, Amplitude, Salesforce, dbt Labs, Fivetran, and Google Ads API skills in `google/skills`. Snowflake's skills ship built into its CoCo CLI (formerly Cortex Code); check whether a portable copy exists before planning a wrap. Wrapping one means the vendor skill does the tool-level work and the team skill adds `martech-context/` definitions, thresholds, acceptance checks and the hand-off for live changes.
2. It applies to every task and fits in about five lines: a rule in the project instruction file or in `martech-context/`.
   - "Never put personal data in UTM values."
   - "Amounts are USD unless the column name says otherwise."
3. It is fully mechanical, with no judgement call: a script or CI step. A skill may call it.
   - UTM syntax and allowed-value validation per row.
   - Header and row-count check on an import file before anyone opens it.
4. The run itself sends, schedules or posts something, or produces a file someone applies as-is, or it must only run when a person chooses: a manual-only skill whose command is its own name, so it never loads on its own ([commands.md](commands.md)).
   - Weekly preparation of a budget change file that the paid media lead imports into Google Ads Editor.
   - CRM duplicate review whose output is the merge queue for agent-write-safety.
5. Multi-step with at least one judgement call: a skill that may load automatically, often with a command as well.
   - Conversion discrepancy investigation: which definitions differ, which gap is explained.
   - Weekly paid pacing review: which variance needs a decision, which is a partial-day artefact.
6. Otherwise: a prompt. Write it down; it becomes a candidate when it recurs.
   - A one-off competitor question.
   - "Why did signups drop?" asked twice in 90 days with different inputs each time; route it to tracking-break-map when it recurs.

The distinction between 4 and 5 is about side effects, not importance. A read-only analysis that people also ask about ad hoc should load automatically. A run that hands a file to someone who applies it without rereading should only run when called.

## Net time saved

Net minutes saved per run = old minutes minus (preparation + run and inspection + exception handling and fixes). Count review time; leaving it out is the usual way a skill looks better than it is.

- Example: a campaign URL audit took 90 minutes by hand. With the skill it takes 10 minutes to prepare inputs, 15 to run and inspect, and 20 to resolve exceptions. Net saving 45 minutes, not 80.
- Record defects found after approval. Their fix time comes off the saving at the next review.
- A skill that saves 10 minutes of drafting and adds 20 minutes of reconciliation has negative value: repair its inputs or scope before building more.

## Anti-candidates

Do not build a skill when:

- The inputs change shape every time and nobody will fix the export.
- Nobody can say what a correct output looks like.
- The real problem is bad data. A skill would only expose it on every run; send the defect to the data owner first and build a monitoring skill later.
- It is strategy without evidence ("plan our Q3 positioning").
- It needs a secret pasted into chat to work.

## Write risk and two at a time

- A job with write risk live still qualifies, but version 1 writes the change list (before, after, reason, rollback) and stops. agent-write-safety runs approval, the smallest batch, read-back and rollback.
- Ties on priority go to the lower write risk: a read-only skill teaches the team the testing routine with less at stake.
- Build two at a time. One owner can run, review and fix two new skills in a cycle. A third starts only when both have passed step 7, so half-finished skills do not pile up in the drafts folder.