Identify and createt AI skills

[dfinke]

Look back over this GitHub repository and identify repeated manual workflows worth packaging.

Use available evidence in this order:

• Recent commits, branches, PRs, issues, and discussions.
• README, docs, AGENTS.md, CONTRIBUTING.md, scripts, examples, tests, and CI files.
• Existing GitHub Actions, issue templates, scripts, tasks, skills, custom agents, or automation already present in the repo.
• Repo structure and repeated patterns in code, docs, tests, release notes, examples, and maintenance work.

Look broadly for work that is repeated, time-consuming, error-prone, context-heavy, or benefits from a consistent process. Include workflows across coding, testing, docs, releases, issue triage, examples, demos, dependency updates, repo hygiene, packaging, and publishing.

Only act on a candidate when it:

• appears at least twice in the repo history or structure, or is clearly likely to recur;
• has stable inputs, a repeatable procedure, and a clear output or stopping condition;
• would materially improve speed, quality, consistency, or reliability;
• is not already adequately covered by existing repo automation or documentation.

Choose the smallest appropriate form:

• Script: reusable command-line automation.
• GitHub Action: scheduled, triggered, CI, release, validation, or maintenance workflow.
• Skill/playbook: reusable repo workflow documented for humans or agents.
• Custom subagent instruction: a bounded specialist role or investigation task suitable for delegation.
• Template: issue, PR, release, changelog, prompt, or documentation template.
• Extend existing: improve what is already present instead of duplicating it.
• Skip: work that is too one-off, ambiguous, sensitive, risky, or poorly evidenced.

First produce a compact shortlist with:

• repeated workflow
• supporting evidence from the repo
• frequency/confidence
• recommended form: script, GitHub Action, skill/playbook, subagent instruction, template, extend existing, or skip
• why it is or is not worth creating

Then create only the high-confidence missing items. Keep them narrow, practical, repo-aware, easy to validate, and consistent with the existing style of the project. Do not create speculative, overlapping, or overly broad assets.

When creating files:

• prefer small, composable additions;
• preserve existing conventions;
• include clear names and minimal documentation;
• avoid changing unrelated code;
• do not introduce new dependencies unless clearly justified;
• include validation steps or usage examples where appropriate.

Finish with:

• what you created or extended
• what you deliberately skipped
• what needs more evidence before packaging
• exact files changed and how to validate them