| name | assign |
| description | Assign first backlog issue and resolve it through to review |
/assign
Assign the first backlog issue and execute the full resolution workflow. If the description is unclear, interview the user first.
CLI only (no direct viban.json access)
Output Rules
- Do NOT output any preamble. No "Your Task:", "I'll now...", "Let me...", or task summaries before starting work.
- NEVER delegate work back to the user. You must complete the entire issue yourself — writing code, tests, and verifying. Phrases like "Your Task:", "TODO(human)", "Waiting for your implementation", "Take your time", or any message that asks the user to write code are strictly FORBIDDEN. If you encounter a TODO comment, implement it yourself.
- Start executing Step 0 immediately and silently.
Step 0: Read Workflow (CRITICAL)
Check in priority order — first match wins:
.viban/workflow.md → [ -f ".viban/workflow.md" ] && cat ".viban/workflow.md"
- CLAUDE.md (legacy, only if no workflow.md):
for path in "./CLAUDE.md" "./.claude/CLAUDE.md" "../CLAUDE.md"; do
[ -f "$path" ] && cat "$path"
done
Look for Issue Resolution Workflow or Workflow section.
If a workflow exists, follow it exactly — its pipeline, conventions, and stop points override the defaults below.
Step 1: Assign
ISSUE_ID=$(viban assign 2>&1 | tail -1)
[[ -z "$ISSUE_ID" || "$ISSUE_ID" == "No backlog" ]] && echo "No issues in backlog" && exit 0
If backlog is empty: notify user and exit.
Step 2: Read Issue
viban get $ISSUE_ID
Display the issue title, description, priority, and type to the user.
Step 3: Evaluate Clarity → Proceed Immediately
Assess whether the issue description provides enough context to start working.
- Clear → proceed directly to Step 4. Do NOT ask the user for confirmation. Do NOT ask "should I start?". Just start.
- Unclear → interview the user with AskUserQuestion to gather missing context, then proceed to Step 4 immediately.
Step 4: Locate Worktree
viban assign automatically creates a worktree. Locate it:
WT_DIR="$PWD/.viban/worktrees/$ISSUE_ID"
BRANCH="issue-$ISSUE_ID"
All subsequent work MUST happen inside $WT_DIR.
Step 5: Execute Workflow
Follow the workflow from Step 0. If no workflow was found, use this default pipeline:
5.1 Analyze
- Explore the codebase to understand the issue
- Identify root cause and scope of change
5.2 Implement
- Work inside the worktree:
cd $WT_DIR
- Make the fix/feature changes
- Write or update tests as appropriate
5.3 Verify
- Run build and tests inside the worktree to confirm the fix works
- Verify no regressions
5.4 Ship (MANDATORY — execute ALL 4 commands in sequence)
cd $WT_DIR
git add -A
git commit -m "fix: {description} (#$ISSUE_ID)"
git push -u origin $BRANCH
gh pr create --title "fix: {description}" --body "Resolves #$ISSUE_ID
## Summary
{what was changed and why}
## Test plan
{how it was verified}"
viban review $ISSUE_ID
If any command fails: fix the error and retry. Do NOT skip any step.
Do NOT remove the worktree — it stays for the review/approve/reject flow.
Completion Checklist (ALL must be true before you stop)
Issue #{id} resolved → review
Title: {title}
PR: {pr_url}
Worktree: .viban/worktrees/{id}
If you don't have a PR URL or haven't called viban review, you are NOT done. Go back and do it.
CRITICAL
- NEVER read or write
viban.json directly — always use viban CLI commands (viban assign, viban get, viban list, etc.)
- FORBIDDEN:
viban done — do NOT use viban done or viban done --remove. Cards must go to review, not done.
- MUST create a PR via
gh pr create unless the workflow explicitly says "stop before PR".
- MUST call
viban review after PR creation. This is the ONLY way to finish. Do NOT use any other status change.
- MUST include PR URL in the completion report. No URL = not done.
CLI Reference
| Command | Description |
|---|
viban assign [session] | Assign issue |
viban get <id> | View issue |
viban review [id] | Move to review (use this to finish) |