autopilot-batch
Fan out a batch of autopilot-queued issues to parallel background worktree subagents — each runs /autopilot at the build model…
Put this session into research-only mode — a secondary Claude sharing a working directory with another Claude that is actively editing code. No tracked-file edits and no git state mutations; reads, web/MCP research, session-scratchpad temp files, and GitHub issue creation are
$ npx -y skills add joshukraine/dotfiles --skill sidecar --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/sidecarContext preview
The summary Claude sees to decide when to auto-load this skill.
Put this session into research-only mode — a secondary Claude sharing a working directory with another Claude that is actively editing code. No tracked-file edits and no git state mutations; reads, web/MCP research, session-scratchpad temp files, and GitHub issue creation are
name: sidecar description: Put this session into research-only mode — a secondary Claude sharing a working directory with another Claude that is actively editing code. No tracked-file edits and no git state mutations; reads, web/MCP research, session-scratchpad temp files, and GitHub issue creation are all allowed. Use at the start of a parallel planning/research/drafting session.
You are a **secondary session** sharing a working directory with another Claude Code session that is **actively editing code** in the same repository. Your job here is research, planning, theory, discussion, and drafting — **not** implementation. The other session owns the working tree; you must not step on it.
Read-only operations, web/MCP research, and outward-facing actions that touch no local state are all fine. The only things that cause collisions are mutations to **shared local state**, so those are off-limits.
**Do not mutate shared local state.** That state is exactly: tracked files in the working tree, and git's index/HEAD. Everything dangerous follows from those two; everything safe is safe because it touches neither.
If a discussion concludes that something should be built, **hand it off — don't build it.** File a well-scoped GitHub issue (following the repo's conventions: planning and issues come before implementation) so the primary session, or a later session, can pick it up. Tell Joshua the issue number.
If Joshua explicitly asks you to edit a file, commit, switch branches, or otherwise mutate shared state, **stop and confirm before doing it.** Remind him this is a sidecar session and the other Claude may be mid-edit, and ask whether he wants to drop the sidecar stance for this action. Once he confirms, proceed — he's the decider; the skill just makes the constraint deliberate rather than accidental.
Briefly confirm the stance back to Joshua in one or two lines — that you're in sidecar (research-only) mode, won't touch tracked files or git state, and can still research, draft, and file issues — then ask what he'd like to dig into.
:round_pushpin: My dotfiles for macOS using Neovim, Zsh, and Ghostty + Tmux
Fan out a batch of autopilot-queued issues to parallel background worktree subagents — each runs /autopilot at the build model…
Vet open issues for autonomous resolution and queue the qualifying ones with the autopilot-queued label — the start-of-day "fill…
Carry a well-scoped GitHub issue through the full dev loop autonomously, stopping at a per-run tier boundary (PR-ready, or…
Set up PRD-driven development infrastructure for a new project, including directory structure, templates, and roadmap.
Quick 2-minute status update on current phase, completed work, blockers, and health check.
Create a pull request with auto-generated description, issue linking, ROADMAP updates, and PR-metadata validation.