Requirements Workflow Guide

Requirements now use the same unified subject surface as tasks: animus subject ... --kind requirement.

Create a Requirement

animus subject create --kind requirement \
  --title "Add rate limiting" \
  --body "Protect the API from burst traffic and define rollout constraints." \
  --priority p1

Inspect and Update

animus subject list --kind requirement
animus subject get --kind requirement --id requirement:REQ-001
animus subject update --kind requirement --id requirement:REQ-001 --priority p0
animus subject status --kind requirement --id requirement:REQ-001 --status ready

Execute a Workflow for a Requirement

Use the workflow surface when the requirement itself should drive execution:

animus workflow run --requirement-id REQ-001

animus workflow run --requirement-id ... uses the same fallback pattern as task execution: Animus checks the in-tree requirement store first, then retries through the active subject_backend resolver when the requirement is owned by a plugin.

Then inspect the resulting workflow state:

animus workflow list --workflow-ref standard-workflow
animus workflow get --id <workflow-id>

Notes

• The legacy animus requirements ... command tree was removed.
• Requirement ids are backend-qualified on the subject surface; use animus subject list --kind requirement --json to inspect returned ids.
• The exact requirement lifecycle and field set depends on the active subject_backend plugin for kind=requirement.

See also: Task Management, Writing Workflows, and MCP Tools Reference.