Menu
Discovery-based branch naming for Darwin agents (repo-agnostic)
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | darwin-branch-naming |
| description | Discovery-based branch naming for Darwin agents (repo-agnostic) |
| roles | ["developer","qe"] |
| modes | ["implement"] |
After cloning or pulling, inspect existing remote branches to learn the repo's naming patterns.
Extract the prefixes in use (e.g., feat/, fix/, chore/, hotfix/). Use these to guide your prefix choice.
Match the task from the event document to a prefix:
| Task Type | Prefix | Examples |
|---|---|---|
| New feature, endpoint, UI component | feat/ | New API route, new page |
| Bug fix, regression fix, error handling | fix/ | Crash fix, validation error |
| Dependency update, CI tweak, cleanup, docs | chore/ | Bump version, update README |
| Restructuring without behavior change | refactor/ | Extract module, rename files |
If the repo has no remote branches (fresh repo), fall back to these conventional prefixes.
Create a feature branch from the latest remote default branch (not local main) using the naming convention:
{type}/evt-{EVENT_ID}
Example: fix/evt-2cb52e7f or feat/evt-2cb52e7f
Read the event ID from the event document in your working directory at events/event-{id}.md.
After creating and pushing the branch, use team_send_to_teammate to tell the QE the branch name and any setup instructions (e.g., "Branch: fix/evt-2cb52e7f -- install deps before testing"). This avoids a race condition where the QE searches for the branch before it is pushed.
The QE checks for a teammate message first -- the Developer sends the branch name after pushing. If no message is available, discover the branch from the remote by searching for evt-{EVENT_ID}. Check it out and sync with the remote before pushing.
feat/customer-invoice-system).Safety rules for modifying Dockerfiles and Containerfiles. Use when editing container build files.
MR/PR context gathering and diagnostic reporting guidelines. Activates when working on events that reference MRs/PRs or when reporting investigation findings.
Team coordination for implement and test modes. Developer and QE use team_send_results for final reports, team_huddle for mid-task questions to FRIDAY.
GitOps workflow rules for modifying infrastructure via git. Use when cloning repos, modifying Helm values, committing, pushing, or verifying deployments.
MR/PR lifecycle operations -- pipeline check, retest, merge, conflict reporting. Extends darwin-gitlab-ops.
Report findings and status updates to the Darwin FRIDAY. Use team_send_results for final reports (task modes). In message mode, use team_send_message instead.