plan

name	plan
description	Plan a task — complexity + stack detection.
effort	medium
context	inline

/plan — Task Planning (SENAR-aligned)

Plans a new feature with complexity scoring.

Model hint (phase=planning): plan quality compounds across the whole task, so run planning on a strong model — Fable 5 (or Opus 4.8). Do NOT downgrade the planner for a "simple" task; complexity does not lower the planning tier. Rationale: docs/ru/research/model-routing-matrix.md.

Algorithm

0. Interview phase (User Specification)

Before decomposing, gather requirements. This prevents missed requirements and scope drift.

For complex or vague requests: invoke the /interview skill — it asks at most 3 clarifying questions (prompt-master "max 3" principle) and stops as soon as answers would no longer change the plan. Prefer it over asking ad-hoc questions.

Fallback if /interview is not applicable: ask the user up to 3 clarifying questions covering:

• Expected behavior: "What should happen when...?"
• Edge cases: "What if the user does...?"
• Non-functional requirements: "Any performance/security constraints?"

Then summarize answers into a user specification (3-5 bullet points) and confirm: "Is this spec correct? Anything to add?"

Skip this phase if the user passes --skip-interview or provides a detailed spec upfront (more than 3 sentences describing the feature, or an obviously simple ask).

Save the user specification via tausik_task_log after task creation.

1. Analyze scope

1. Which domains are affected? (frontend, backend, database, devops)
2. How many files/components?
3. Risk level?
4. Is the domain well-known? If unfamiliar — suggest .tausik/tausik explore start "..." first (SENAR Section 5.1).

Complexity scoring:

• 1-2 signals: simple (1 task)
• 3-5 signals: medium (2-3 tasks)
• 6+ signals: complex (decompose)

2. Check existing knowledge

Use MCP tools:

• tausik_memory_search — search for relevant patterns and conventions
• tausik_memory_list with type=dead_end — don't repeat failed approaches
• brain_search (cross-project, 1.4+) — category="patterns" and category="gotchas", limit=3 each, query = task topic keywords + stack tag. Skip silently if tausik-brain MCP is unavailable. Filter out any page id that already appears in memory_list type=convention with title prefix brain.ignored: (user previously marked it unhelpful).

3. Detect stack and load defaults

Determine stack from project structure (package.json, requirements.txt, go.mod). Check harness/stacks/ for valid names.

Load defaults from config: Read .tausik/config.json — use bootstrap.stacks[0] as default stack. Use developer as default role unless task requires otherwise.

4. Create task

Epic/story are optional. For standalone tasks, use task quick or task add without --group.

MCP-first (preferred):

• Auto-slug: tausik_task_quick with title="Task title", goal="What success looks like", role="developer", stack="python"
• Explicit slug: tausik_task_add with slug="my-task", title="Task title", goal="...", role="developer", stack="python", complexity="medium"

CLI fallback:

# Quick (auto-slug):
.tausik/tausik task quick "Task title" --role developer --stack python --goal "What success looks like"

# Full (with explicit slug):
.tausik/tausik task add "Task title" --slug my-task --complexity medium --role developer --stack python --goal "What success looks like"

# With epic/story grouping (optional):
.tausik/tausik task add "Task title" --group my-story --slug my-task --complexity medium --role developer --stack python --goal "What success looks like"

If the work is part of a larger initiative, create or reuse an epic/story:

.tausik/tausik epic add <slug> "Epic title"
.tausik/tausik story add <epic-slug> <story-slug> "Story title"

4b. Estimate tier (agent-native sizing)

After the task exists, set a tool-call budget — NOT human hours. Agents are measured in tool calls, not wall-clock time. Pick --call-budget (preferred, auto-derives --tier) or --tier directly.

Tier	Budget	Real-session example
trivial	≤10	one-line config tweak, doc fix, single-arg flag
light	≤25	schema migration + helpers + tests (agent-units-schema)
moderate	≤60	recording wiring + hook + service edit + tests
substantial	≤150	CLI + service + MCP + mirror + tests across many files
deep	≤400	full vertical (new stack support, end-to-end feature)

MCP-first: tausik_task_update with slug="{slug}", call_budget=25.

CLI fallback:

.tausik/tausik task update <slug> --call-budget 25
# or, if you prefer the tier directly:
.tausik/tausik task update <slug> --tier light

Skipping estimation is allowed but flag it explicitly — the task closes without call_budget/call_actual data, hurting future tier calibration.

5. Set acceptance criteria (SENAR QG-0 MANDATORY)

CRITICAL: Without acceptance criteria, task start will be blocked by QG-0 Context Gate.

Write clear, verifiable acceptance criteria. Each criterion must be independently testable.

MCP-first: tausik_task_update with slug="{slug}", acceptance_criteria="1. POST /login returns JWT on valid creds. 2. Returns 401 on invalid password. 3. Returns 422 on missing email."

CLI fallback:

.tausik/tausik task update <slug> --acceptance-criteria "1. POST /login returns JWT on valid creds. 2. Returns 401 on invalid password. 3. Returns 422 on missing email."

AC quality rules (SENAR):

• Each criterion independently testable
• At least one negative scenario (error case, boundary)
• No vague criteria ("works correctly", "handles edge cases")

6. Set plan steps

MCP-first: tausik_task_plan with slug="{slug}", steps=["Step 1", "Step 2", "Step 3"]

CLI fallback:

.tausik/tausik task plan <slug> "Step 1" "Step 2" "Step 3"

7. Present plan

Show: task slug, title, complexity, role, goal, plan steps, acceptance criteria. Verify: "Goal and AC are set — QG-0 will pass." Ask: "Proceed with /task <slug>?"

Suggest next: "Run /task <slug> to start working."

Gotchas

• Roles are free-text — use any role name, not limited to a fixed set.
• Slug format must be ^[a-z0-9][a-z0-9-]*$, max 64 chars.
• Epic/story are optional — tasks can exist without grouping.
• QG-0 blocks without goal + AC — always set both during planning.
• Defect tasks — use --defect-of <parent-slug> when creating a fix for a bug found in an existing task.