---
name: saf-implement-multi
description: Implement multiple SDD tasks using dependency-aware waves and isolated mutable ownership when safe and authorized. Use for multi-task implementation; use saf-implement for exactly one task.
compatibility: Requires Git and a compatible Agent Skills host.
---

# Implement multiple SDD tasks

## When to use

Use when a feature has multiple explicitly selected tasks that must be planned and implemented as dependency-aware waves. Use `saf-implement` for exactly one task.
Read the [TLC baseline](../sdd-agentic-flow-shared/references/tlc-baseline.md),
[TDD baseline](../sdd-agentic-flow-shared/references/tdd-baseline.md),
[engineering principles](../sdd-agentic-flow-shared/references/engineering-principles.md),
[handoff standard](../sdd-agentic-flow-shared/references/handoff-standard.md),
[task slicing](../sdd-agentic-flow-shared/references/task-slicing.md), and
[workflow safety rules](../sdd-agentic-flow-shared/references/workflow-safety.md) before acting.

## When not to use

Do not use for one task, vague feature requests, specification creation, PR work, or when dependencies, task identities, or authorization cannot be resolved.

## Inputs

- One feature identifier and optional explicit task subset.
- Optional `.sdd-agentic-flow/config.yml` overrides, feature SDD artifacts, and repository state.
- User-approved concurrency and isolation constraints when implementation orchestration is requested.

## Workflow

1. Read `.sdd-agentic-flow/config.yml` when present; otherwise use canonical effective defaults.
2. Read `.sdd-agentic-flow/context/project-context.md` and `.sdd-agentic-flow/context/domain-glossary.md` when they exist. Resolve one feature, enumerate tasks, and build a candidate dependency-wave grouping from SDD evidence. Mark ambiguous or externally blocked tasks instead of guessing. The documented chain is: tasks → dependencies → **DAG** (must be **acyclic**) → **waves** → isolated concurrent work only with explicit user authorization. In autonomous mode, the original bounded delegation supplies local authorization for sequential completion; parallel work still requires a valid isolation boundary and host capability. See `../sdd-agentic-flow-shared/references/execution-isolation.md`. Do not add a runtime scheduler.
3. Before recommending parallel work, analyze mutable paths, shared contracts/types, runtime/test state, and evidence ordering. Keep tasks sequential unless real independence and an isolation boundary are established. DAG-unblocked is not parallel-admissible by itself: require isolated mutable ownership, no conflicting shared contract mutation, compatible runtime/test state, and independently attributable evidence; otherwise use the existing sequential fallback.
4. Write `execution-plan.md` with waves, ownership, paths, sensors, and integration boundary. In `plan`/`guided` mode stop before mutations. In `apply`/`full`, require explicit authorization before creating an isolated workspace or changing code.
5. Plan each ready task as an independently verifiable vertical slice with a contractual seam (field label: `Public seam`), targeted sensor command, and evidence owner. Justify horizontal work explicitly. Expected RED is a diagnostic sensor hint (`n/a — not used as proof` is valid); do not instruct faking RED.
6. Execute every ready wave through `saf-implement`, once per task. Prefer host isolation when authorized and available, or execute sequentially. Lack of parallelism must not block completion. After an authorized worktree is created, apply the semantics in `../sdd-agentic-flow-shared/references/workspace-initialization.md` before starting its worker; do not locate the CLI package or invoke `npx`. Run `saf-check-task` for each completed task before allowing dependent work to proceed. After each wave barrier: collect task evidence, evaluate completion criteria and semantic progress, re-check affected stale evidence, classify decision gates, and unlock only legitimate dependent work. Record per-task ownership, isolation boundary, state (`implemented-isolated` before integration, then `integrated` only after authorized integration), check evidence, freshness, integration requirement, blocker/gate, and next admissible action. A recoverable blocker routes to its owning repair path; an authority or no-progress blocker returns control. Do not treat orchestration completion as feature validation or merge readiness.
7. Collect `multi-task-evidence` summarizing the ledger. Stop at blockers.

## Safety

Never share mutable state between concurrent tasks. Never create branches or worktrees without explicit authorization. Never commit, merge, cherry-pick, push, delete a worktree, or discard uncommitted changes implicitly. Preserve existing changes and stop on unknown mutable workspace state.

## Output

Return feature identity, dependency waves, per-task status, blockers, execution-plan and multi-task-evidence paths, integration state, and next safe action. Include `Status`, `Next recommended skill`, and `Reason`.

### Autonomy

Supports `manual`, `supervised`, and `autonomous` autonomy levels (`workflow.autonomy_level` in `.sdd-agentic-flow/config.yml`). In `autonomous` mode, advancing to delegated `saf-implement` runs requires execution-plan.md present, an acyclic dependency graph, and a declared isolation/scope boundary per task. See `../sdd-agentic-flow-shared/references/autonomy-guardrails.md`.