Skip to content

Workflow: Implement Linear Issue

Use this workflow from an interactive Codex App task opened in the repository that owns an implementation child or marked standalone repository-change issue.

This is the tracked-issue path. Phase 4 plugin source makes routine and material repository work issue-free by default through $anuva-development:anuva-repository-change. Use this Linear workflow for Product Main-created children or when the user explicitly requested standalone tracking. Shared skills are supplied only by the installed plugin.

Discover work

$anuva-development:linear-list-ready-issues

The skill runs:

anuva linear issue list-ready --repository current --json

It returns issue IDs, titles, descriptions, priority, dependencies, and linked Product Main docs. It does not change issue state.

Implement selected work

$anuva-development:linear-implement-issue ANU-201

The wrapper validates the issue kind and repository, then invokes the repository's $anuva-development:anuva-implement-issue skill. For CMS work it uses the Implement CMS Issue prompt.

flowchart TD
    Get["anuva linear issue get ANU-201 --json"]
    Validate["Validate issue kind, repository, status, dependencies, scope"]
    Start{"Implementation child?"}
    Child["anuva work start ANU-201 --confirm"]
    Standalone["Verify guarded intake branch"]
    Preflight["Revalidate Product Main disposition"]
    Plan["Create ImplementationPlan.md"]
    Approve{"User approves plan?"}
    Build["Implement code, tests, docs"]
    Verify["Run repository checks"]
    Report["Update ImplementationLog and CompletionReport"]
    PR["anuva pr create ANU-201 --draft --confirm"]
    Review["Set Linear status In Review and link PR"]
    Ready["anuva pr ready ANU-201 --confirm"]
    Merge["anuva pr merge ANU-201 --report absolute-path --confirm"]

    Get --> Validate --> Start
    Start -- "Yes" --> Child --> Preflight
    Start -- "No" --> Standalone --> Preflight
    Preflight --> Plan --> Approve
    Approve -- "Revise" --> Plan
    Approve -- "Approved" --> Build --> Verify --> Report --> PR --> Review --> Ready --> Merge

A standalone issue is created directly In Progress by anuva repository-change start; anuva work start remains child-specific. If preflight now requires escalation, stop before artifacts and request explicit recovery direction.

Proportionate implementation artifacts

For Product Main-created children, repository instructions, or work whose risk requires durable recovery, use docs/changes/<change-id>-<slug>/ and create:

  • index.md before any other page and keep it aligned with the folder contents;
  • ImplementationPlan.md before code changes;
  • ImplementationLog.md throughout implementation, including deviations and evidence-producing commands; and
  • CompletionReport.md before the PR is submitted for completion review.

ImplementationPlan and CompletionReport record the Product Main documentation disposition and evidence. A tracked Required standalone issue may also deliver one bounded Product Main documentation companion after its implementation PR is created.

Do not require all three artifacts for routine issue-free work merely to satisfy the workflow. After each logical Markdown update, run one strict verification for all changed pages and return exact machine-specific preview links at the next approval or delivery pause.

CMS-specific verification

CMS changes should run the repository's lint, typecheck, unit/integration checks, and relevant Playwright tests. Playwright is deterministic repository testing; it is not an autonomous browser-agent workflow. Python and Unity use their own documented verification commands and manual checks where automation is not yet practical.