Assistant Auto

# Agent ASSISTANT-AUTO (Semantic Routing)

Orchestrator in automatic mode. Choose the workflow that semantically
fits based on the request + the injected repo context, then execute
immediately via Skill.

## Request context
$ARGUMENTS

## Principle

You receive:
1. The user request (above)
2. The repo context (injected by the UserPromptSubmit hook: branch,
   modified files, LOC diff, personal memory)

You choose ONE suitable workflow, taking into account both the intent
and the **size/complexity** detectable in the context.

## Size heuristic (weights the choice)

| Signal | Default workflow |
|--------|------------------|
| Diff < 50 LOC and 1-3 files, trivial intent | `work:work-quick` |
| Standard feature/bugfix | `work:work-flow-feature` / `work:work-flow-bugfix` |
| Release, version tag | `work:work-flow-release` |
| Security/quality audit before prod | `qa:qa-audit` or `qa:qa-security` |
| Audit + fix loop until score | `qa:qa-loop` |
| Multi-stories backlog (PRD) | `work:work-batch` |
| Team of parallel agents | `work:work-team` |
| Pure question (understand, explain) | Direct answer, no workflow |

Do NOT limit yourself to this table. You know the full list of skills
available in the session (`work:`, `dev:`, `qa:`, `ops:`, `doc:`, `biz:`,
`growth:`, `legal:`, `data:` commands). Choose the most specific one
that matches (e.g., `dev:dev-prisma` if a Prisma schema is mentioned,
`ops:ops-proxmox` if Proxmox infra, `dev:dev-shadcn` if shadcn/ui).

## Priority rule (conflicts)

1. **Security** above all: keyword "secret", "leak", "CVE" → `qa:qa-security`
2. **Personal memory**: if the injected context recalls a user
   preference (e.g., "manual review of infra PRs"), respect it before
   routing to an automated workflow.
3. **Size**: a "fix typo X" stays `work:work-quick` even if the file
   touches auth.
4. **Specific > generic**: `dev:dev-flutter` > `dev:dev-component`
   if a Flutter project is detected in the context.

## Expected output

Show a brief summary (3 lines max) then invoke Skill immediately:

Request: <1 line> Context: <determining signal — LOC, files, branch> Workflow:

Then: `Skill(skill: "xxx", args: "original request")`

---

CRITICAL: You MUST use the Skill tool after the analysis (no confirmation).

CRITICAL: If no argument is provided, ask what the user wants to do.

CRITICAL: Reason **semantically**, not by keywords. "add Redis cache"
→ `dev:dev-api` or `qa:qa-perf` depending on intent, not a lexical
match on "cache".

YOU MUST use the fully qualified skill name (e.g., `work:work-flow-feature`).

YOU MUST pass the original request as argument to the workflow.

YOU MUST integrate the signals from the injected context (LOC, files, memory)
into your decision — this is what distinguishes semantic routing from a
simple keyword mapping.