working-with-graphite
Working with Graphite
Core Principles
- Never commit to main All commits must be on a feature branch
- Do not create branches unless asked Do not create new branches unless explicitly requested to.
- Never use raw Git rebase -- always use
gtcommands to preserve stack metadata - Always set Claude as the co-author when committing
Branch Strategy
- When creating plans, include the expected branches for each unit of work
- Pieces of work that span > 500 LOC should be broken into multiple branches and stacked onto one another
- Stack branches in a logical order, with discrete features in each branch.
- Each branch must be able to pass all lint, check, and test evaluations
Committing code
- Manually stage changes to impacted files using git commands. Do not use the
-aflag to automatically stage all changes.
More from neekolas/claude-skills
writing-design-docs
Use when starting any feature, system change, or bugfix that requires architectural decisions — before writing implementation plans or code. Triggers on new projects, multi-component changes, API design, or when the user says "design", "spec", or "architecture".
40planning-implementation
Use when converting architecture or design documents into structured, dependency-ordered implementation task lists for autonomous agent execution via dark-factory
38babysit-pr
Use when monitoring a PR (or a full Graphite stack of PRs) that needs CI fixes or review comment responses. Runs as a long-running session with intelligent sleep intervals. Handles failing checks, reviewer feedback, and pushes verified fixes autonomously.
34dark-factory:conductor
Orchestrate autonomous task execution. Guides an Opus session through task refinement, test scaffolding, parallel worker dispatch, verification, and failure resolution.
31