Update to fstack

{
  "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 skill via plugin-dev:skill-development + unslop, optionally pulling fresh evidence from recent transcripts.",
  "included_files": [],
  "name": "automate-me",
  "skill_md_contents": "---\r\nname: automate-me\r\ndescription: \"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 skill via plugin-dev:skill-development + unslop, optionally pulling fresh evidence from recent transcripts.\"\r\nmenu-description: draft your own personal -mode skill from recent transcripts\r\n---\r\n\r\n# Automate me\r\n\r\nA 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`).\r\n\r\nThis skill orchestrates three others: an inline mining pass (see step 1), the `plugin-dev:skill-development` skill (authoring), and the **unslop** skill (prose discipline). It sequences them; it doesn't replace them.\r\n\r\n**Platform note.** On Codex, the Claude tool names, `claude-*` slugs, and Claude built-in skills named below (including `plugin-dev:skill-development`) are Claude defaults. Resolve them via [`codex-tools.md`](../engineer-mode/references/codex-tools.md).\r\n\r\n## Flow\r\n\r\n### 0. Check for an existing skill\r\n\r\nLook recursively for `.claude/skills/**/*-mode/SKILL.md` and `~/.claude/skills/*-mode/SKILL.md` matching the user's handle. Mode skills can live in a personal category directory (`.claude/skills/<handle>/`), not only at the top level. If one exists, confirm intent with `AskUserQuestion` (unless they already said \"update my skill\" or similar):\r\n\r\n- Update the existing skill (default for repeat runs)\r\n- Start fresh (rare; ask why before doing it)\r\n\r\nUpdate mode changes the rest of the flow:\r\n- Step 1 mines only history since the skill was last edited (`git log -1 --format=%cI <path>`).\r\n- Step 2 asks what's changed or missing, not what to capture from zero.\r\n- 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.\r\n\r\n### 1. Mine their history\r\n\r\nLocate the active workspace's transcripts before fanning out. Claude Code stores them at `~/.claude/projects/<encoded-cwd>/*.jsonl`, where `<encoded-cwd>` is the workspace's working directory with `/` → `-`. Use only that path. Don't glob across `~/.claude/projects/`. That crosses workspace boundaries and reads private chats from unrelated projects.\r\n\r\nSurvey recent agent conversations within that scope for recurring patterns. Run multiple parallel subagents across slices of history (e.g. last 2-4 weeks, split into 3 slices so each has enough material). Each slice mining subagent reads transcripts from the workspace-scoped path the parent provides, looks for the signals below, and returns a short structured list of patterns it saw with evidence pointers. Default signals worth hunting:\r\n\r\n- Response preferences (length, tone, format, \"dumb it down\" corrections)\r\n- Delegation habits (subagents, models, specialized workflows, parallelism)\r\n- Verification posture (what \"done\" means; unit tests vs live repro; reviewers)\r\n- Code and prose discipline (style, principles cited, lint/format tools)\r\n- Process conventions (worktrees, commits, PRs, review/merge tooling)\r\n- Meta preferences (fixing skills mid-task, proposing new ones)\r\n\r\nCross-check across slices before elevating a signal. Patterns seen in 2+ slices are high-confidence; lone signals are weak and usually get dropped.\r\n\r\n### 2. Ask the user directly\r\n\r\nMining misses intent that hasn't come up yet. Use the `AskUserQuestion` tool (structured multi-choice) rather than asking the user to type from scratch. Lower cognitive load, higher hit rate.\r\n\r\nShape: one or two questions with 4-6 options each, `allow_multiple: true` 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.\r\n\r\nDon't dump 20 questions. Two structured rounds plus one open question is usually enough.\r\n\r\n### 3. Cluster findings\r\n\r\nGroup the combined signals into sections. Common ones (use only what applies):\r\n\r\n- **Response style**: length, tone, format.\r\n- **Autonomy**: how much to do without asking; MCP tool use.\r\n- **Understand first**: which skills to reach for when scoping or investigating a change.\r\n- **Subagents**: default, parallelism, model-to-task, specialized workflows.\r\n- **Prose / code discipline**: principles, lint tools, style guides.\r\n- **Review and verify**: repro posture, verification skills, live-testing tools.\r\n- **Process**: git worktrees, commits, PRs, review/merge tooling.\r\n- **Skills**: skill-authoring habits, fix-the-skill-first, proposing new skills.\r\n\r\nThe **engineer-mode** skill shows the shape. Read it for granularity. Don't copy its content; the user's rules are not the same as engineer-mode's.\r\n\r\n### 4. Draft the skill\r\n\r\nUse the **plugin-dev:skill-development** skill to author the skill. Placement:\r\n\r\n- Path: preserve an existing mode skill's category. For a new mode, use `.claude/skills/<handle>/<handle>-mode/SKILL.md` when the repo has an established personal category for that handle; otherwise default to `.claude/skills/<handle>-mode/SKILL.md` in the project (or `~/.claude/skills/<handle>-mode/` if the user prefers a personal skill).\r\n- Handle: the user's first name or chosen identifier.\r\n- Frontmatter `description`: trigger on their name + `/<handle>-mode` + \"work in their style\", not on generic keywords like \"write code\" or \"review PR\".\r\n- Frontmatter formatting: follow `plugin-dev:skill-development`'s YAML rules. Keep `description` as one YAML scalar; quote it or use `description: >-` with indented continuation lines when punctuation or wrapping requires it.\r\n- Frontmatter `disable-model-invocation: true` by default. Mode skills are heavy and opinionated; they should only apply when the user explicitly invokes them (by name or slash command), not auto-trigger on description matching. Opt out only if the user explicitly wants their mode to apply on every turn.\r\n\r\n### 5. Iterate on prose\r\n\r\nApply the **unslop** skill and `plugin-dev:skill-development`'s writing guidelines to every line. Both apply to any agent-read prose, not just skills.\r\n\r\nShow the draft to the user and take feedback. Expect multiple iterations. Cut ruthlessly; a mode skill is not a manual.\r\n\r\n### 6. Land it\r\n\r\nWork in a worktree off main. Commit and open a PR so the user can review it. Don't push to main directly.\r\n\r\n## Guardrails\r\n\r\n- **Don't overfit to one conversation.** A preference stated once and contradicted another time is noise. Require multiple instances before codifying it.\r\n- **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.\r\n- **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.\r\n- **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.\r\n- **Name conventions generic.** Use \"the user\" or \"the human\" in imperatives, not the author's first name. Others may read or adopt the skill.\r\n- **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.\r\n\r\n## Evaluation\r\n\r\nA `-mode` skill is subjective output. A `plugin-dev:skill-development`-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.\r\n\r\nRun a description-optimization loop only if the skill's trigger accuracy turns out to be a problem in practice.\r\n\r\n## When not to use\r\n\r\n- User wants a task-specific skill (not working conventions): `plugin-dev:skill-development` alone, no mining required.\r\n- User wants to capture one narrow workflow (e.g. \"how I write commit messages\"): that's a regular skill, not a mode skill.\r\n\r\n## Reference files\r\n\r\n- The **engineer-mode** skill: example of the output shape.\r\n- The **unslop** skill: prose discipline for every line.\r\n- the **plugin-dev:skill-development** skill: skill authoring process and writing guidelines.\r\n"
}