3 agentic workflows that changed how I code
TL;DR
Three patterns that naturally emerged in a daily agentic workflow: automated morning briefing, versioned custom commands in Git, and parallel sessions in tmux splits. Each came from a real friction, not from theory.
After several months of daily coding agent use in the terminal, three workflows settled naturally. Not theoretical patterns — habits that stuck because they solve real friction.
1. The automated morning briefing
Every morning at 7:57, a cron runs the agent with a /morning skill. The agent scans Git projects, open MRs, assigned issues, active branches, and produces a structured briefing in an Obsidian note.
The result: when I open the terminal, I know exactly where I stand. Which MRs need review, which tickets moved since yesterday, what work is uncommitted. No need to open GitLab or mentally parse the state of 3 projects.
In the evening at 19:27, another cron runs /evening: cleanup of merged branches, capture of next actions, daily retro. The JSON it produces feeds the next morning’s briefing.
It’s not a dashboard. It’s a structured handoff between yesterday-me and today-me, with the agent as intermediary.
2. Versioned custom commands
Custom commands are Markdown files in .opencode/commands/ (or .kilocode/commands/), versioned in Git. Each command encodes a recurring workflow:
# .opencode/commands/new-endpoint.md
Create a complete API Platform 3 endpoint for the $ARGUMENTS entity.
Follow conventions in AGENTS.md.
Generate corresponding PHPUnit tests.
Run tests until they pass.The mechanics are identical today with Claude Code’s skills and custom commands — same versioned files, same principle.
The team has accumulated ~15 commands. A new dev clones the repo, types /new-endpoint Order, and gets a complete endpoint with tests in 5 minutes — without memorizing project conventions.
The difference from regular scripts: the custom command adapts to context. It reads existing code, project conventions, and produces code consistent with what already exists.
3. Parallel sessions in tmux splits
A permanent vertical split: Neovim on the left, agent on the right. When a task comes in, I brief it without leaving the editor.
But the real gain is parallelism. Two tmux splits, two independent agent sessions: one on backend refactoring, the other on corresponding tests. Sessions don’t share context — that’s by design, preventing cross-contamination.
On mechanical tasks (fixtures, DTOs, boilerplate tests), parallel sessions on a budget model — back then a free model via Kilo Gateway, today Claude Code’s sub-agents — let you tackle two workstreams simultaneously without blowing up the cost.
What connects the three
These workflows share one thing: they treat the agent as infrastructure, not as a one-off tool. The cron runs without intervention. Custom commands persist in Git. The tmux split is permanent.
The agent is no longer something you “open when you need it”. It’s part of the default workflow, like the linter or the test runner.
These three patterns are exactly what you hand a new dev on day one — this is team tooling, not personal habits.
Guide: OpenCode + Neovim + tmux setup Guide: Agentic workflow principles