Awesome-omni-skill tbdflow
Manage Trunk-Based Development workflows using the tbdflow CLI. Use this skill to create short-lived branches, make standardised commits, sync with trunk, merge completed work, and generate changelogs.
git clone https://github.com/diegosouzapw/awesome-omni-skill
T=$(mktemp -d) && git clone --depth=1 https://github.com/diegosouzapw/awesome-omni-skill "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/tools/tbdflow" ~/.claude/skills/diegosouzapw-awesome-omni-skill-tbdflow && rm -rf "$T"
skills/tools/tbdflow/SKILL.mdtbdflow Skill
Overview
This skill enables an AI agent to manage a Trunk-Based Development (TBD) workflow using the
tbdflow CLI (v0.18.2).
The skill exists to:
- Enforce short-lived branches
- Standardise commits
- Reduce Git decision-making
- Maintain a fast, safe path back to trunk (
)main
tbdflow is the only interface the agent should use for Git workflow actions covered by this skill.
When to Use
Use this skill when the user wants to:
- Start work on a task, ticket, or feature
- Commit staged changes
- Sync with trunk or check repository status
- Merge completed work back to
main - See what has changed since the last release
Typical trigger phrases include:
- “Start working on…”
- “Commit this”
- “Merge my work”
- “Sync me up”
- “What’s new?”
When Not to Use
Do not use this skill to:
- Create or manage long-lived branches
- Perform manual Git commands outside
tbdflow - Rewrite commit history
- Perform interactive rebases
- Merge without explicit user intent
If an action cannot be performed via
tbdflow, explain the limitation instead of falling back to raw Git commands.
Instructions
Follow the instructions below exactly. Each capability defines intent, constraints, and decision rules.
1. Standardised Committing
Intent Create a structured, conventional commit on trunk or a short-lived branch.
Staging Behaviour
automatically stages the relevant changes when committingtbdflow- The agent must not run
or any raw Git staging commandsgit add - No explicit staging step is required from the user or the agent
Preconditions
- The working tree contains changes intended for commit
- No unresolved merge conflicts are present
Command
tbdflow commit -t <type> [-s <scope>] -m "<message>" [--issue <issue>] [-b]
Decision Rules
-
Allowed commit types:
,feat
,fix
,chore
,docs
,refactor
,test
,build
,ci
,perf
,revertstyle
-
Never invent new commit types
-
If no type is specified:
- Default to
unless behaviour changeschore
- Default to
-
DoD Checklist: If a
file exists in the project root and.dod.yml
is not passed, an interactive checklist will appear. Unchecked items will result in a--no-verify
footer being appended to the commit message.TODO: -
Use
/-b
if the change introduces breaking behaviour--breaking -
Use
when the user references a ticket ID (JIRA, GitHub, etc.)--issue
Use This When
- The user says “commit”, “save this”, or “check this in”
- The user describes completed work ready to be recorded
2. Creating Short-Lived Branches
Intent Start a new unit of work in a short-lived branch that will be merged back to trunk quickly.
Preconditions
- Working tree is clean or safely stashed
- The task is not exploratory or long-running
Command
tbdflow branch -t <type> -n <name> [--issue <issue>] [-f <from_commit>]
Decision Rules
-
Branch naming follows:
or<type>/<name><type>/<issue>-<name>
-
If the user provides a task description:
- Slugify it for the
parameter-n
- Slugify it for the
-
Use
when a ticket ID is available--issue -
Use
only if the user explicitly asks to branch from a non-HEAD commit-f
Use This When
- The user says “start working on…”
- A task requires isolation before merging to
main
3. Workflow Completion & Integration
Intent Safely merge completed work back into trunk and clean up the branch.
Preconditions
- All intended commits are complete
- The branch is ready to be merged
Command
tbdflow complete -t <type> -n <name>
Decision Rules
-
Infer
and<type>
from:<name>- The current Git branch name
- Fallback: the most recent
invocationtbdflow branch
-
The merge is performed using
--no-ff -
Both local and remote branch copies are deleted after merge
Use This When
- The user says “I’m done”, “merge my work”, or “ship this”
4. Syncing & Status
Intent Keep the local workspace aligned with trunk and provide situational awareness.
Commands
tbdflow sync tbdflow status
Decision Rules
-
Use
to:sync- Pull and rebase from remote
- Inspect recent history
- Identify stale branches
-
Use
to:status- Show context-aware Git status, In monorepos, this excludes sub-project directories when at the root.
- Handle monorepos correctly
Use This When
- The user says "sync", "catch me up", or "what's happening"
- Before committing, merging, or starting new work
Pre-Commit Workflow
Always run
before tbdflow sync
.tbdflow commit
The
sync command:
- Pulls and rebases from remote
- Shows current status (wraps
)git status - Ensures the workspace is aligned with trunk
This prevents conflicts and ensures commits are based on the latest trunk state.
Validation & Linting Behaviour
tbdflow enforces workflow correctness using an internal linter. The agent must understand and respect these rules.
Commit Message Rules
Subject Line (-m
message)
-m| Rule | Requirement | Example |
|---|---|---|
| Max Length | 72 characters | ✓ |
| Capitalisation | Must not start with a capital letter | ✓, ✗ |
| Punctuation | Must not end with a period | ✓, ✗ |
| Type | Must be one of: , , , , , , , , , , | ✓, ✗ |
| Scope | Optional, lowercase, no spaces | ✓, ✗ |
| Message | Required, non-empty, imperative mood | ✓, ✗ |
| Breaking | Must use flag if breaking change | for breaking ✓ |
Commit Body (Optional)
| Rule | Requirement |
|---|---|
| Line Length | Each line must not exceed 80 characters |
| Separation | Must be separated from subject by a blank line |
Issue Key (--issue
)
--issue| Rule | Requirement | Example |
|---|---|---|
| Format | Uppercase project key, dash, number | ✓, ✗ |
Branch Name Rules
| Rule | Requirement | Example |
|---|---|---|
| Type | Must match commit types | ✓, ✗ |
| Name | Lowercase, hyphen-separated, no spaces | ✓, ✗ |
| Issue | Optional, prefixed to name | ✓ |
Error Handling
If
tbdflow rejects input:
- Read the error message carefully
- Correct the input based on the rules above
- Retry with valid parameters
- Do not fall back to raw Git commands
The agent should prefer generating valid inputs over relying on linter errors.
5. Changelog Generation
Intent Summarise changes using structured commit history.
Command
tbdflow changelog [--unreleased] [--from <ref>]
Decision Rules
- Use
when the user asks “What’s new?”--unreleased - Use
when comparing against a specific tag or version--from <ref>
Use This When
- The user asks for release notes
- The user wants a summary of recent changes
Output Format
- Commands should be executed directly
- Explanations should be concise and factual
- Avoid narrating Git internals unless asked
- Prefer showing the command being run before or alongside results
Examples
| User Input | Action |
|---|---|
| “Commit this as a bug fix for login.” | |
| “Start working on API-456: Add user profile.” | |
| “Merge my current work back to main.” | |
| “Sync me up.” | |
| “What changed since the last version?” | |
Notes
- Treat
(trunk) as sacredmain - Prefer safety and clarity over cleverness
- Ask for clarification only when an action could be destructive