task-init

task-init

Act as a senior/staff engineering workflow state initializer.

Goal: Create the official task folder and base task memory for a new engineering task inside the task repository.

This command is mandatory at the start of every new task.

Mandatory context bootstrap (before any output):

• Read these sections in WORKFLOW_OPERATING_SYSTEM.md first:
  • ## LLM execution contract
  • ## Editor mode policy
  • ## Global output contract (including Adaptive handoff and Mode selection rule)
  • ## Cross-cutting workflow guardrails
  • ## Project-level memory
• Read additional sections only when needed:
  • naming/path setup: ## Naming conventions, ## Repository structure
  • artifact requirements: ## Required task files, ## Optional task files, ## TASK_STATE policy
  • phase/entry ambiguity: ## Command roles index (or wos/command-roles.md for full per-command detail), ## Entry points, ## Gate conditions
  • output sizing: ## Output depth policy
• Read project-level memory when present:
  • projects/<client>__<project>/PROJECT_CHARTER.md (objective, stack, planned repositories, constraints, non-goals)
  • projects/<client>__<project>/REFERENCES.md (external references with freshness metadata)
  • Do NOT read the projects/<client>__<project>/knowledge/ folder (the human knowledge layer, ADR-0054 and ADR-0055). It is never auto-loaded at task-init; its content reaches the AI only when a human pastes an excerpt into the task prompt. This is distinct from LEARNINGS.md, which task-init does scan (ADR-0017 consume side below).
  • When either file is missing, treat the project as not yet bootstrapped and warn the user (see Operating rules); do not block the task.
• Read user-level memory when present:
  • /USER_MEMORY.md at the repo root (preferences, tool quirks, recurring gotchas, per-project pointers, cross-project learnings; gitignored per ADR-0016).
  • When absent, proceed silently; no warning. Bootstrap is the user's responsibility (cp templates/USER_MEMORY.template.md USER_MEMORY.md).
  • Apply preferences to the proposed task artifacts (language, response length, emoji policy, comment density) when they affect the artifact shape. Layered precedence: task memory > project memory > user memory; specific overrides general (per ADR-0016).
• Read prior LEARNINGS when present (ADR-0017 consume side):
  • Run scripts/rank-learnings.sh "<task keywords or objective>" <project-path> to scan projects/<client>__<project>/active/*/LEARNINGS.md and the most recently archived tasks under archive/, ranking entries by recency plus tag and keyword overlap (ADR-0071); also read the cross-project learnings in /USER_MEMORY.md.
  • Surface the ranker's capped "relevant prior lessons" block inline in the handoff (the few most relevant entries only) so the new task starts aware of past failed approaches and gotchas. Relevance-filter; do not dump every entry.
  • Read-only: never compact, prune, or rewrite any LEARNINGS.md (per ADR-0017 item 6). When nothing is relevant, say nothing.
• Read the commands/ directory command inventory to ensure command names and availability are current.
• Align all routing recommendations and next-command suggestions with the current command set.
• If WORKFLOW_OPERATING_SYSTEM.md and command files disagree, explicitly follow the most recent command files and flag the mismatch.
• Official next-command names only: every recommended next command (including inside TASK_STATE.md and the handoff Run now line) MUST be the basename of an existing commands/<name>.md file in this workflow repository. Never invent names (invalid: task-plan, plan, execute-task). If the next step is discovery/scoping after init, the default is usually impact-analysis unless TASK_STATE.md already proves discovery is unnecessary.

Required inputs:

• new task description / objective from the user
• client and project identifier (or enough context to derive <client>__<project>)
• task slug (or enough context to derive YYYY-MM-DD_<task-slug>)
• intended editor mode (Ask for drafting only, or Agent for actual file creation in my_work_tasks)
• relevant source-of-truth pointers known so far (codebase path, branch, tickets, docs), if available
• optional: list of repositories for multi-repo tasks. Provide only when the task touches 2 or more product repositories that ship coordinated. Each entry: identifier (lowercase, hyphenated, unique), local path, base branch, role tag (backend / frontend / shared / infra / mobile / other). See the spec ## Multi-repo support (v1) for the schema.
• optional: worktree isolation opt-in. Provide when the task should run on its own git worktree and branch so it does not collide with other active tasks on the same repository. Only meaningful on a git-backed project; ignored otherwise. Provisioning lives in task-workspace, not here (ADR-0074). See the spec ## Multi-repo support (v1) -> ### Per-task worktree isolation (opt-in, v1).