automate-me

Automate me

A skill named in bold or in backticks, or run as /<name>, is the file ../<name>/SKILL.md beside this skill's directory, and a principle named without its prefix is ../principle-<name>/SKILL.md. Read the file and follow it. Most pstack skills are user-only, so your skill tool cannot load them. Every delegate_task call follows the defaults in the Subagents section of ../poteto-mode/SKILL.md.

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 orchestrates three others: an inline mining pass (see step 1), the skill-creator skill (authoring), and the unslop skill (prose discipline). It sequences them. It doesn't replace them.

Flow

0. Check for an existing skill

Look recursively for .agents/skills/**/*-mode/SKILL.md, .claude/skills/**/*-mode/SKILL.md, ~/.agents/skills/*-mode/SKILL.md and ~/.claude/skills/*-mode/SKILL.md matching the user's handle. Entries that resolve to the same real path are one skill. Mode skills can live in a personal category directory (.agents/skills/<handle>/ or .claude/skills/<handle>/), not only at the top level. If one exists, confirm intent by asking in the thread (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 first makes sure the skill's real directory is under .agents/skills/ with the matching relative .claude/skills/ symlink (move it there if it lived only under .claude/skills/), then 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

Locate the active project's threads before fanning out. t3_thread_list and t3_thread_search scope to the calling thread's project when you omit projectId. Use only that scope. Don't pass another projectId. That crosses project boundaries and reads private chats from unrelated projects.

Survey recent agent conversations within that scope for recurring patterns. Run multiple parallel delegate_task children (mode: "async", a title naming the slice, a clientRequestId stable across retries of that slice and new per round, no target so they run on the parent model) across slices of history (e.g. last 2-4 weeks, split into 3 slices so each has enough material). Pick each subagent's reasoning level and fast or standard speed for the job, per the Subagents section of the poteto-mode skill. The child gets only its brief, so each slice's brief lists the thread IDs the parent found for that slice and says "read-only: inspect only, no writes, no git commands" and "Do not delegate". Each slice mining child reads those threads with t3_thread_read, looks for the signals below, and returns a short structured list of patterns it saw with 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)

End the turn and let the completion notifications wake you. Once every slice reports, 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. Ask plainly in the thread with structured multi-choice questions rather than asking the user to type from scratch.

Shape: one or two questions with 4-6 options each, multi-select for category questions. Start broad ("Which areas matter most?"), then follow up on selected areas with specific options. After the structured rounds, one free-form chat question catches anything the options missed.

Don't dump 20 questions.

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

Use the skill-creator skill to author the skill when it is installed, otherwise the Authoring-a-skill playbook (../poteto-mode/playbooks/authoring-a-skill.md). Placement:

• Path: preserve an existing mode skill's category. For a new mode, use .agents/skills/<handle>/<handle>-mode/SKILL.md when the repo has an established personal category for that handle. Otherwise default to .agents/skills/<handle>-mode/SKILL.md in the project (or ~/.agents/skills/<handle>-mode/ if the user prefers a personal skill). Create the real directory there, then a relative symlink at the matching path under .claude/skills/ (.claude/skills/<handle>-mode -> ../../.agents/skills/<handle>-mode, the same under ~/).
• 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 formatting: follow skill-creator's YAML rules. Keep description as one YAML scalar. Quote it or use description: >- with indented continuation lines when punctuation or wrapping requires it.
• Frontmatter disable-model-invocation: true by default, plus agents/openai.yaml with policy.allow_implicit_invocation: false so Codex hides it too. Opt out of both only if the user explicitly wants their mode to apply on every turn.

5. Iterate on prose

Apply the unslop skill and skill-creator's writing guidelines to every line.

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, open a PR with gh pr create, and link_pull_request its URL at once. 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.
• Don't force symmetry. If a user has no process rules worth writing down, skip the Process section entirely.

Evaluation

A -mode skill is subjective output. A skill-creator-style test/iterate benchmark loop isn't useful here. Vibe-check with the user: does it read like them? Did it miss anything? Then ship.

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): skill-creator alone, no mining required.
• User wants to capture one narrow workflow (e.g. "how I write commit messages"). That's a regular skill, not a mode skill.