analiz-task-spec

Analiz Task Spec

create_board_task fields for analiz:

• task_type: "analiz" — the exact tool argument is task_type, not type. Passing the wrong field name is silently dropped (the tool ignores unknown arguments) and the task is created as task_type: "task" instead, which breaks analiz filtering, routing and board semantics. Always pass task_type: "analiz" explicitly.

• column: todo

• assignee: system-architect (REQUIRED — pass assignee: "system-architect" to create_board_task). Without an assignee the architect is never dispatched and the task sits idle in todo. The architect is not subscribed to the todo column; it reaches an analiz task only via the assignee.

• title: "Analiz: [what is being investigated]"

• description: investigation goal, scope boundaries, available context (links, prior docs).

  • Relevant projects/repositories (required): name every project/repository you believe the work touches, so the system-architect knows what to clone and review. If you are unsure, say so — the architect will verify and pull anything you missed. Missing a repo here does not block the architect (it cross-checks the codebase indexes), but naming them speeds the analysis.
  • Design brief, if the work touches UI: carry the same block implementation-task-spec uses (audience/tone, content language, visual direction, references, states, primary action) so the architect's spec inherits real design direction instead of inventing it. Detect an existing design system first (get_design_system, see implementation-task-spec); if none exists, open it now with request_design_system (implementation-task-spec) and name its key in the description — it runs while the architect analyses, and the architect makes the UI tasks wait for it.

• acceptance_criteria — statements about the CONTENT of the spec and the plan, which is the only thing this task delivers. Write what must be true of the documents, e.g.:

  • "The spec names every repository the change touches and, per repository, the files and interfaces that change."
  • "Each unit of work in the plan states its inputs, its outputs and how it is verified."
  • "The plan orders the units so nothing depends on work scheduled after it."
  • "Every option considered is recorded with the reason it was or was not chosen."
  • "Any question only a stakeholder can answer is listed with the decision it blocks."

  Board actions are NEVER criteria. Not "moved to analiz_review", not "attached with add_task_document", not "presented for approval", and above all not "implementation tasks are created" — those are the workflow around the card (the architect's routine, the human's approval, what happens after it), and none of them says whether the analysis is any good. Worse, they cannot be ticked before the hand-off that ends the task, so the criteria gate holds the card and it never reaches done. The architect knows the workflow from its own role; the criteria are where you say what the documents must contain.

  Do NOT ask for the documents to be committed to the repository: an analysis produces a decision, not code, and a docs/ commit means a branch and a pull request for a task that ships nothing.

This analiz task is the permanent home of the spec and the plan. Every implementation task opened from it carries derived_from: ["A-N"] pointing back here, which is how the developer working that task is handed these documents; list_task_documents on this key returns them to anyone at any time. Nothing is ever copied into a repository, so if this card's documents are wrong or missing, so is every task built from it.

After creation: tell stakeholder "Opened an analiz task for the system-architect to investigate [topic]. It will come back to you in Analiz Review to approve the plan before any implementation task is created."