Current
AI news & practical reference.
For work, creativity, and everyday life.
Current
Development · Documented baseline v2
Separate coding work through a shared contract, isolated working areas, and one integration owner.
Developers coordinating coding agents or a small implementation team.
Contract
Agree on field names, errors, duplicates, and ownership before independent work begins.
Alternative: Keep one owner when the feature is too coupled to split.Isolation
Separate file edits and reserve independent ports and database schemas for concurrent tests.
Alternative: Sequential branches when the environment cannot isolate tests.Execution
Give each contributor a bounded task, owned files, acceptance criteria, and a handoff format.
Alternative: One coding session for small changes or unresolved design decisions.Integration
Review the combined tree against the actual user journey rather than assuming passing branches will compose.
Alternative: Pair on integration for a fragile migration or shared interface.Setup notes
Configure the tools here, then use the workflow to complete the task.
For a reading-list feature, the API contract, interface behavior, and storage invariants must agree. Parallel work helps only after those decisions are written down. Give one contributor the API and another the interface, with one integration owner reviewing their combined result. Use one coding session when a change touches the same component or the contract is still undecided. A third session is optional, not a prerequisite.
Begin with the coding client your team already uses: separate Claude Code sessions, another terminal client, or an editor agent can follow the same contract. A terminal multiplexer is useful for arranging sessions; it does not assign ownership or reconcile incompatible changes. An agent-team feature can coordinate messages, but you still need a single integration owner and clear completion evidence.
| Need | Default for this exercise | When to change it |
|---|---|---|
| Independent edits | Git worktree per implementation task | Use sequential branches for a small change or unresolved design. |
| Task execution | One coding session per owned area | Try a coordinated agent team when handoffs are frequent and tasks are already separable. |
| Session visibility | Terminal tabs or your existing multiplexer | Add a session manager only when you actually lose track of running tasks. |
| Shared behavior | Versioned API contract and acceptance cases | Change the contract through the integration owner; never let each contributor invent it. |
| Integration confidence | A clean integration worktree with a browser scenario | Keep unit tests too, but do not infer combined behavior from isolated test passes. |
Run the baseline tests in the original checkout and record the commit they cover. The commands below create three new branches and adjacent directories from that commit. They assume a clean starting point and unused branch/directory names. If the feature depends on uncommitted work, first preserve it according to your repository process; a new worktree does not copy those edits.
Reserve independent application ports and disposable test databases or schemas. Put those assignments in the task brief. A worktree only separates files: two sessions can still reset the same database or overwrite the same output directory. Install dependencies in each worktree using the repository's normal command.
git status --short
npm test
base_commit=$(git rev-parse HEAD)
git worktree add -b feature/reading-api ../reading-api "$base_commit"
git worktree add -b feature/reading-ui ../reading-ui "$base_commit"
git worktree add -b feature/reading-integration ../reading-integration "$base_commit"
git worktree list| Task | Port | Test database | Ownership |
|---|---|---|---|
| API | 3201 | reading_api_test | Route, validation, storage adapter |
| Interface | 3202 | reading_ui_test | Form, saved list, error and empty states |
| Integration | 3203 | reading_integration_test | Contract checks and browser acceptance scenario |
Implement the reading-list API against contract v2 below.
Own only the API route, validation module, and storage adapter.
Do not change the response contract, UI files, shared dependencies, or migrations
without identifying the conflict first. Use port 3201 and reading_api_test.
Acceptance: first save returns 201; duplicate returns the existing item with 200;
invalid URL returns 400; unavailable storage returns 503 without a fake success.
Finish with changed files, tests actually run and their output, known gaps,
and the exact commit for integration. Do not report planned tests as passed.Paste the actual contract and relevant repository instructions after this assignment. A task that says ‘build the backend’ is not bounded enough. Make the integration owner review the first response and error cases before the UI contributor relies on them. Keep the number of simultaneous contributors below the number of genuinely independent tasks.
The linked agent skill includes the contract, a validator, and deliberate incompatible responses. Work through those failures before merging real changes. You should be able to explain exactly why a branch passes its own tests but fails integration.
Initial authored baseline with a detailed integration workflow, reusable coordination skill, and downloadable handoff/checklist.
Parallel work helps only when tasks are independent enough to repay contract and integration effort.
Agent usage depends on the selected tools and number of sessions. Set task budgets and stop conditions before dispatch.
This is reference version 2. No independent compatibility test or vendor pricing has been attached. Treat this as a starting baseline, not a ranking or proof of compatibility.
These references support the setup. The exercises are original instructional material; compatibility has not been independently tested.
Worktrees provide multiple working directories attached to one repository. They do not isolate databases, ports, or external services.
Checked 2026-10-10. Recheck before adopting.
Vendor documentation for coordinated sessions. Check current availability and configuration before choosing this optional layer.
Checked 2026-10-10. Recheck before adopting.
Use observable behavior, user-facing locators, and retrying assertions in browser tests.
Checked 2026-10-04. A fresh review is due.