jj-workflow

Automate non-interactive jj version-control tasks with mandatory -m messages.

1|Updated Nov 1, 2025

Search Tags:#workflow #jj #version-control #non-interactive #mental-model #commit-descriptions #oplog

Ready to run

npx skills add https://github.com/rselbach/dotfiles --skill jj-workflow

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: jj-workflow
Source: https://github.com/rselbach/dotfiles/tree/main/agents/skills/jj-workflow
Command: npx skills add https://github.com/rselbach/dotfiles --skill jj-workflow

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

JJ version-control often requires interactive sessions that interrupt automation, so this skill enforces a non-interactive, commit-based workflow with clear guidance.

Core Features & Use Cases

Enforces non-interactive commands with -m for every operation.
Provides a no-staging mental model where @ is the current change and @- is the parent.
Supports common workflows like new, describe, squash, op log, restore, and push, across branches and remotes.

Quick Start

Begin by creating a new change with a descriptive message using jj new -m "feat: start".

Frequently Asked Questions about jj-workflow

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I automate jj version control tasks without an interactive session?▼

Automating jj version control tasks requires a non-interactive workflow that enforces mandatory -m commit messages for every operation. This approach replaces interactive staging with a mental model where @ is the current change and @- is the parent, streamlining automated commit descriptions and pushes.

What is the no-staging mental model in jj and how does it work?▼

The no-staging mental model in jj treats @ as your current change and @- as its parent, eliminating the need for traditional staging areas. This model enforces commit-based workflows by requiring descriptive -m messages for operations, ensuring every change is safely recorded without manual intervention.

How do I recover changes in jj after a bad squash or describe operation?▼

Recovering changes in jj after a bad squash or describe operation uses the oplog-based recovery mechanism. By accessing the operation log, you can restore previous states of your repository, ensuring safe commits are preserved even when non-interactive commands modify or squash changes unexpectedly.

Can I use jj workflows in a colocated repository setup?▼

JJ workflows support colocated repository setups identified by a .jj directory or system reminders indicating vcs=jj-colocated. This skill applies non-interactive commands like new, describe, squash, and push across branches and remotes seamlessly within both standard and colocated environments.

Why does jj require a descriptive message for every commit operation?▼

JJ requires a descriptive message for every commit operation to enforce a strict non-interactive workflow. By mandating -m flags for commands like new, describe, and squash, the system ensures clear commit descriptions and maintains a safe, automated version-control history without user prompts.

What are the limitations of a non-interactive jj workflow?▼

A non-interactive jj workflow limits manual intervention during commit creation, squashing, and describing. It requires mandatory -m messages for all operations and relies on oplog for recovery, meaning users cannot selectively stage files interactively and must adapt to the @ and @- mental model for all version control tasks.