n8io/workflow
Ticket-to-merge workflow skills and subagents: ship, ticket-worker, grill, commit, PR triage and more
Write a commit message in this repo's gitmoji format. Use when composing or amending a commit message, or when asked to commit staged work. Covers gitmoji selection, subject-line shape, and ticket references.
Use when the user has an idea, feature, bug or epic in their own words that should become groomed, implementation-ready GitHub issues with priorities and a dependency graph, before any building starts. For a Slack thread or permalink use slack-triage instead.
Use when a JIRA ticket ID (e.g. PROJ-123, ABC-456) is mentioned and the user needs ticket context, or when explicitly invoked with /jira <ticket-id>.
Use when the user wants to start the next unit of GitHub-issue-driven work end-to-end (selection → plan → implement → PR → merge → cleanup).
Legacy, being replaced by ship. Use only when the user names parallel-tickets or asks for in-session subagents instead of worker sessions; otherwise use ship for working several issues at once.
Use when the user asks for a progress tracker, build tracker, or live progress page for the work in this session, or invokes /progress-tracker. Creates this session's own live tracker artifact (or updates the one this session already made) and keeps its steps, active task and log current as implementation proceeds.
Use when the user hands over a bug, feature, epic, issue number, or idea and wants it planned and built end to end as fast as the dependency graph allows, or says /ship with no argument to work the ready backlog. Orchestrates parallel tmux workers over a ticket dependency graph.
Use when reading, searching, sending, or replying to Slack messages, channels, DMs, or threads — including pulling Slack context into a task, posting an update, finding a past discussion, or following a Slack permalink someone pasted.
Use when a Slack thread, permalink, or pasted conversation carries user-reported bugs or feature requests that need to become tracked tickets — triaging user feedback, turning a report into an issue, or working out what a thread is actually asking for.
Use when a step needs stack-specific know-how — activating a runtime, installing dependencies, setting up a worktree, generating code or migrations, recording browser evidence, sizing a PR with generated files. Holds per-language and per-tool lessons so the workflow skills stay language-agnostic.
Legacy, being replaced by ship. Use only when the user names ticket-loop or explicitly asks for a strictly serial, one-ticket-at-a-time loop of remote-controllable worker sessions; otherwise use ship.
Use when you are a worker session or subagent assigned ONE already-claimed GitHub issue by an orchestrator (ticket-loop, parallel-tickets, ship). Holds the fixed worker contract so kickoffs only carry the issue, the settled decisions and repo-specific gates.
Use when bootstrapping or refreshing the AGENTS.md ## Verify section (test, fmt, lint, typecheck commands), or when the user runs /verify.