add

Tip: Run /clear before /viban:add for a clean context.

/add - Register Issue

Register a problem as a viban issue. No codebase exploration, no solutions — symptoms only.

CLI only (no direct viban.json access)

Input: $ARGUMENTS

Step 1: Clarify (only if vague)

If clear enough (who/what/where), skip to Step 2. Otherwise, one AskUserQuestion:

• header: "Problem", question: "Can you describe the symptom more specifically?"
• options: context-appropriate (e.g. "Error/crash", "Feature not working", "Performance issue", "Let me describe")

Step 2: Priority & Type

Infer from description. Don't ask unless truly ambiguous.

Priority	Condition	Type	When
P0	System down, data loss	bug	Something broken
P1	Feature broken, errors	feat	New functionality
P2	Performance, warnings	chore	Maintenance, config
P3	Improvements, refactoring	refactor	Code restructuring

Step 3: Issue Numbering

[ -f ".viban/workflow.md" ] && cat ".viban/workflow.md"

• Workflow says Manual → ask user for external ID (e.g. PROJ-42)
• Auto or no workflow → let viban auto-assign
• ID in $ARGUMENTS → use it regardless

Step 4: Register

mkdir -p .viban/tmp
cat > .viban/tmp/desc.md <<'VIBAN_EOF'
## Symptoms
{one-sentence symptom}
{additional context, if any}
VIBAN_EOF

# Auto numbering (default)
viban add "{title}" --desc-file .viban/tmp/desc.md --priority {priority} --type {type}
rm -f .viban/tmp/desc.md

# Manual numbering (when workflow specifies)
viban add "{title}" --desc-file .viban/tmp/desc.md --priority {priority} --type {type} --ext-id "{external_id}"
rm -f .viban/tmp/desc.md

Use <<'VIBAN_EOF' (quoted) to prevent shell interpretation.

Step 5: Report

Issue #{id} registered
  Title: {title}
  Priority: {priority} | Type: {type}
  Status: backlog

Step 6: Done

Report the registered issue and stop immediately. Do not suggest next steps, do not offer to plan, do not continue.