| name | automate-me |
| description | Use for "automate me", "create/update/refresh my -mode skill", "turn/capture my preferences or working style into a skill", or wanting agents to follow how the user works. Drafts or revises a personal -mode Agent Skill, optionally pulling evidence from recent sessions. |
Automate me
A guided flow for turning the user's working conventions into a skill agents will follow. The output is one -mode skill tailored to them (e.g. jay-mode, priya-mode).
This skill combines an inline mining pass, Agent Skills authoring rules, and the unslop skill.
Flow
0. Check for an existing skill
Look recursively for .github/skills/**/*-mode/SKILL.md and ~/.agents/skills/*-mode/SKILL.md matching the user's handle. Mode skills can live in a personal category directory (.github/skills/<handle>/), not only at the top level. If one exists, confirm intent with ask_user (unless they already said "update my skill" or similar):
- Update the existing skill (default for repeat runs)
- Start fresh (rare; ask why before doing it)
Update mode changes the rest of the flow:
- Step 1 mines only history since the skill was last edited (
git log -1 --format=%cI <path>).
- Step 2 asks what's changed or missing, not what to capture from zero.
- Step 4 edits the existing file in place. Preserve sections the user hasn't contradicted; revise ones with new evidence; add new sections only for genuinely new rules.
1. Mine their history
Use session_store_sql when available. Query recent sessions for the active repository, with a two-to-four-week time window, and inspect only matching session IDs. Never scan unrelated projects. If history tools are unavailable, use the visible conversation and ask the user for missing preferences.
Survey those conversations for recurring patterns. Run parallel subagents only when the result set is large enough to split into distinct time slices. Each returns a short structured list with session IDs as evidence pointers. Default signals worth hunting:
- Response preferences (length, tone, format, "dumb it down" corrections)
- Delegation habits (subagents, models, specialized workflows, parallelism)
- Verification posture (what "done" means; unit tests vs live repro; reviewers)
- Code and prose discipline (style, principles cited, lint/format tools)
- Process conventions (worktrees, commits, PRs, review/merge tooling)
- Meta preferences (fixing skills mid-task, proposing new ones)
Cross-check across slices before elevating a signal. Patterns seen in 2+ slices are high-confidence; lone signals are weak and usually get dropped.
2. Ask the user directly
Mining misses intent that hasn't come up yet. Use the ask_user tool (structured multi-choice) rather than asking the user to type from scratch. Lower cognitive load, higher hit rate.
Ask one focused question at a time with 4-6 choices. Start broad ("Which area matters most?"), then follow up with specific options. Use one final free-form question only when the choices could not capture the preference.
Don't dump 20 questions. Two structured rounds plus one open question is usually enough.
3. Cluster findings
Group the combined signals into sections. Common ones (use only what applies):
- Response style: length, tone, format.
- Autonomy: how much to do without asking; MCP tool use.
- Understand first: which skills to reach for when scoping or investigating a change.
- Subagents: default, parallelism, model-to-task, specialized workflows.
- Prose / code discipline: principles, lint tools, style guides.
- Review and verify: repro posture, verification skills, live-testing tools.
- Process: git worktrees, commits, PRs, review/merge tooling.
- Skills: skill-authoring habits, fix-the-skill-first, proposing new skills.
The poteto-mode skill shows the shape. Read it for granularity. Don't copy its content; the user's rules are not the same as poteto-mode's.
4. Draft the skill
Author or update the skill directly. Placement:
- Path: preserve an existing mode skill's category. For a new project skill, use
.github/skills/<handle>-mode/SKILL.md. Use ~/.agents/skills/<handle>-mode/ only when the user explicitly wants a personal skill.
- Handle: the user's first name or chosen identifier.
- Frontmatter
description: trigger on their name + /<handle>-mode + "work in their style", not on generic keywords like "write code" or "review PR".
- Frontmatter: require lowercase kebab-case
name matching the folder and a specific description. Keep description as one YAML scalar; quote it or use description: >- with indented continuation lines when punctuation or wrapping requires it.
5. Iterate on prose
Apply the unslop skill to every line. Keep SKILL.md lean; move long explanations to references/, deterministic helpers to scripts/, and fixtures to evals/.
Show the draft to the user and take feedback. Expect multiple iterations. Cut ruthlessly; a mode skill is not a manual.
6. Land it
Work in a worktree off main. Commit and open a PR so the user can review it. Don't push to main directly.
Guardrails
- Don't overfit to one conversation. A preference stated once and contradicted another time is noise. Require multiple instances before codifying it.
- Don't be clever. Restating other skills' contents, inventing metaphors, or writing "poetic" prose for an agent reader is cost without benefit. Keep it operational.
- Reference, don't inline. Other skills the user relies on should appear as path references, not pasted excerpts. Same for any principle docs they maintain elsewhere.
- Keep sections minimal. Only add a section if the user has a specific, non-default rule there. "Communicate clearly" is not a section. "Short paragraphs. Tables when comparing options. Bullets only when items are genuinely parallel." is.
- Name conventions generic. Use "the user" or "the human" in imperatives, not the author's first name. Others may read or adopt the skill.
- Don't force symmetry. If a user has no process rules worth writing down, skip the Process section entirely. Sparse is fine; bloated is not.
Evaluation
A -mode skill is subjective output. A task benchmark is rarely useful here. Review the draft with the user: does it read like them, and did it miss anything?
Run a description-optimization loop only if the skill's trigger accuracy turns out to be a problem in practice.
When not to use
- User wants a task-specific skill (not working conventions): use the poteto-mode Authoring a skill playbook, with no preference mining.
- User wants to capture one narrow workflow (e.g. "how I write commit messages"): that's a regular skill, not a mode skill.
Reference files
- The poteto-mode skill: example of the output shape.
- The unslop skill: prose discipline for every line.
- The Agent Skills specification: required structure and frontmatter.
