Agentic Workflows

hve-core uses GitHub Agentic Workflows to automate the journey from issue creation through implementation, code review, and dependency management. Six event-driven workflows connect specialized agents into a pipeline where each stage triggers the next through labels, pull requests, and GitHub events.

NOTE

GitHub Agentic Workflows is an experimental/beta feature. The workflows described here represent hve-core's early experiments with the technology and may evolve as the platform matures.

End-to-End Process Flow

flowchart TD
    subgraph TRIGGER["Issue Created or Labeled"]
        A["New issue opened<br/>or labeled needs-triage"]
    end

    subgraph TRIAGE["Issue Triage Workflow"]
        B["Read issue title, body,<br/>and template metadata"]
        C["Classify by type<br/>and component"]
        D["Detect duplicates<br/>via keyword search"]
        E["Assess issue quality"]
        H{"Passes all<br/>agent-ready criteria?"}
        I["Apply labels,<br/>remove needs-triage"]
        J["Add agent-ready label"]
        K["Leave for human<br/>review"]
    end

    subgraph IMPLEMENT["Issue Implementation Workflow"]
        L["Read issue and<br/>acceptance criteria"]
        M["Research codebase:<br/>files, patterns, conventions"]
        N["Plan minimal<br/>change set"]
        O["Implement changes"]
        P["Verify against<br/>acceptance criteria"]
        Q["Open pull request<br/>referencing the issue"]
    end

    subgraph REVIEW["PR Review Workflow"]
        R["Detect PR opened<br/>or ready for review"]
        S["Analyze diff against<br/>coding standards"]
        T["Check conventions,<br/>security, quality"]
        U{"Review passed?"}
        V["Add review-passed label"]
        W["Add needs-revision label<br/>with inline comments"]
    end

    subgraph HUMAN["Human Review"]
        X["Maintainer reviews<br/>and merges"]
    end

    A --> B
    B --> C
    C --> D
    D --> E
    E --> H
    H -- Yes --> I
    I --> J
    H -- No --> I
    I --> K
    J --> L
    L --> M
    M --> N
    N --> O
    O --> P
    P --> Q
    Q --> R
    R --> S
    S --> T
    T --> U
    U -- Yes --> V
    V --> X
    U -- No --> W
    W -.-> O

Workflow Details

Workflow	Trigger	Execution Owner	Key Actions
Issue Triage	Issue opened or labeled `needs-triage`	Issue Triage Agent	Classify, detect duplicates, assess quality, label, evaluate readiness
Issue Implementation	Issue labeled `agent-ready`	Workflow-owned procedure in `.github/workflows/issue-implement.md`	Research codebase, plan changes, implement, open PR
PR Review	PR opened or marked ready for review	Code Review Agent	Review correctness, conventions, security; label `review-passed` or `needs-revision` for non-maintainer PRs, advisory `COMMENT` only for maintainer PRs
Dependabot PR Review	Dependabot PR opened or updated	Dependency Reviewer Agent	Validate licensing, SHA pinning, environment sync; approve safe bumps
Documentation Drift	Push to main	Documentation Agent (drift mode)	Map code changes to docs, flag stale documentation for follow-up
VEX Draft	`workflow_run` after VEX Detection succeeds, or `workflow_dispatch`	SSSC Reviewer	Enrich CVEs, analyze reachability, open one PR with OpenVEX draft statements for human review

TIP

The triage agent classifies issues, applies type, area, and priority labels, detects duplicates, assesses quality, and marks qualifying issues agent-ready. It does not create sub-issues, close issues, assign users, or modify issue titles.

NOTE

The implementation agent keeps PRs small and focused. If the issue is ambiguous or too large, it posts a comment requesting clarification instead of guessing.

NOTE

Maintainer advisory mode. When the PR author is a MEMBER, OWNER, or COLLABORATOR, the Code Review Agent switches to advisory mode: it posts a COMMENT review prefixed with "Advisory review …", never uses REQUEST_CHANGES, does not add the needs-revision label, and does not convert the PR to draft.

skip-review label guard. The skip-review label only skips the PR Review workflow when the PR author's association is MEMBER, OWNER, or COLLABORATOR; PRs from other authors are reviewed normally even when the label is present.

Workflow Configuration

All six workflows are defined as GitHub Agentic Workflow markdown files under .github/workflows/ and compiled to lock files using gh aw compile:

Workflow File	Lock File	Trigger	Execution Owner
`issue-triage.md`	`issue-triage.lock.yml`	Issue opened or labeled `needs-triage`	Issue Triage Agent
`issue-implement.md`	`issue-implement.lock.yml`	Issue labeled `agent-ready`	Workflow-owned procedure
`pr-review.md`	`pr-review.lock.yml`	PR opened or marked ready for review	Code Review Agent
`dependency-pr-review.md`	`dependency-pr-review.lock.yml`	Dependabot PR opened or updated	Dependency Reviewer
`doc-update-check.md`	`doc-update-check.lock.yml`	Push to main	Documentation Checker
`vex-draft.md`	`vex-draft.lock.yml`	VEX Detection `workflow_run` + dispatch	SSSC Reviewer

Each workflow file declares permissions, safe output limits, and activation guards that prevent unintended execution.

Lock File Ownership

The *.lock.yml files under .github/workflows/ are generated outputs of gh aw compile. Editing them directly is not supported: the next compile overwrites the change. Edit the source .md workflow instead, then recompile.

Because these files are generated, Dependabot is configured to leave them alone. .github/dependabot.yml excludes the .github/workflows/*.lock.yml path and the github/gh-aw-actions/* action family, so action bumps inside a lock file never arrive as a pull request.

Upgrading gh-aw-actions

The gh-aw-actions version is pinned in .github/aw/actions-lock.json, which maps each action reference to a resolved commit SHA. This file, not Dependabot, is the upgrade path:

Upgrade the gh aw CLI/compiler (the resolved gh-aw-actions version is tied to the compiler release, not set independently).
Run gh aw compile (or gh aw update-actions) with API access to re-resolve actions and regenerate actions-lock.json plus every *.lock.yml file.
Commit actions-lock.json and the regenerated lock files together.

The pinned version is version-locked to the gh aw compiler that produces the lock files, so the bump and the recompile belong in the same change.

Label-Driven Handoffs

Labels serve as the event bus connecting workflows. Each label transition triggers the next stage:

stateDiagram-v2
    [*] --> needs_triage: Issue opened
    needs_triage --> classified: Triage removes needs-triage,<br/>adds type + component labels
    classified --> agent_ready: Triage adds agent-ready<br/>(if criteria met)
    classified --> human_review: Criteria not met,<br/>awaits human labeling
    agent_ready --> pr_opened: Implementation agent<br/>opens PR
    pr_opened --> review_passed: Review agent approves
    pr_opened --> needs_revision: Review agent requests changes
    needs_revision --> pr_opened: Author pushes fixes
    review_passed --> merged: Maintainer merges
    merged --> [*]

Interactive Agent Workflows

Beyond the automated GitHub event-driven pipeline, hve-core provides interactive agents invoked through VS Code Copilot Chat. These agents support the manual side of the development lifecycle.

RPI Orchestration

The RPI Agent coordinates Research, Plan, Implement, Review, and Follow-up by activating four reusable phase skills:

Skill	Responsibility
`rpi-research`	Closes demonstrated evidence gaps and produces research evidence
`rpi-plan`	Creates marker-addressed plans, phase details, and independent critique
`rpi-implement`	Executes approved work and records changes, amendments, and validation
`rpi-review`	Reconciles evidence, records findings, and routes the next action

The skills coordinate through durable artifacts stored in .copilot-tracking/.

Prompt Engineering

The hve-builder skill uses one lifecycle for agents, prompts, instructions, subagents, and skills:

Resolve mode, targets, write boundary, architecture, and applicable conventions
Author or perform read-only review according to the selected mode
Run fresh-context static review and one behavior gate with route-specific execution: Major mutations and behavior-bearing review targets execute testing, while eligible no-runtime review targets and Minor or Medium mutations are satisfied-and-skipped
Keep known target files and caller-supplied canonical references as bounded lifecycle reads; activate rpi-research for open-ended exploration and decision-critical research
Run non-mutating host validation and resolve one overall outcome

HVE Builder selects a reasoning profile from each worker's responsibility. High uses Claude Opus 5, GPT-5.6 Sol, then GPT-5.5 for architecture and consequential decisions. Medium uses GPT-5.6 Terra, Claude Sonnet 5, then MAI-Code-1-Flash for semantic discovery, authoring, research, implementation, and review. Low uses GPT-5.6 Luna, MAI-Code-1-Flash, then Claude Haiku 4.5 for literal simulation and mechanical validation.

Each ordered list is an availability fallback within its selected profile. The retained prompt-builder, prompt-analyze, and prompt-refactor skills remain compatibility aliases that route legacy requests to this lifecycle.

Security Review

The Security Reviewer orchestrates security skill assessment through four subagents: Codebase Profiler, Skill Assessor, Finding Deep Verifier, and Report Generator. It supports audit, diff, and plan modes across OWASP and Secure by Design frameworks.

Code Review

The Code Review agent reviews branch diffs through one or more perspectives (functional, standards, accessibility, security, and PR-level) and merges them into a single human-gated report. It runs before code reaches a pull request and also backs the PR Review workflow after PR creation.

Documentation Operations

The Documentation agent coordinates documentation audit, drift, authoring, and validation work through its four modes, covering style compliance, accuracy against implementation, and coverage gaps.

Backlog Management

The Backlog Manager resolves the backing tracker at runtime and coordinates work discovery, triage, sprint planning, assigned-work retrieval, task planning, and execution across Azure DevOps, GitHub, and Jira. Its planning modes are read-only and produce reviewed handoffs, and a separate execution pass applies those handoffs under a three-tier autonomy model with dry-run preview.

The Functional Planner turns a PRD into a validated work item hierarchy handoff and never mutates a tracker.

Project Planning

Five agents support upstream planning activities:

Agent	Purpose
BRD Builder	Business Requirements Documents
PRD Builder	Product Requirements Documents
ADR Creation	Architecture Decision Records
Architecture Diagrams Skill	ASCII system architecture diagrams
Security Plan Creator	Security assessment and mitigation plans

How It All Connects

flowchart LR
    subgraph AUTOMATED["Automated Pipeline"]
        direction TB
        TRIAGE["Issue Triage<br/><i>event-driven</i>"]
        IMPL["Issue Implementation<br/><i>event-driven</i>"]
        REVIEW["PR Review<br/><i>event-driven</i>"]
        DEPEND["Dependabot PR Review<br/><i>event-driven</i>"]
        DOCS["Doc Update Check<br/><i>event-driven</i>"]
        VEX_DETECT["VEX Detection<br/><i>scheduled scan</i>"]
        VEX_DRAFT["VEX Draft<br/><i>event-driven</i>"]
        TRIAGE -- "agent-ready label" --> IMPL
        IMPL -- "opens PR" --> REVIEW
        VEX_DETECT -- "untriaged CVEs" --> VEX_DRAFT
    end

    subgraph INTERACTIVE["Interactive Agents"]
        direction TB
        RPI["RPI Orchestration"]
        HB["HVE Builder"]
        SR["Security Reviewer"]
        CR["Code Review"]
        DOC["Documentation"]
        BM["Backlog Manager"]
        PP["Project Planning"]
    end

    subgraph ARTIFACTS["Shared Artifacts"]
        direction TB
        INST["Instructions<br/>.github/instructions/"]
        TRACK[".copilot-tracking/<br/>plans, research, changes"]
        LABELS["GitHub Labels<br/>and Milestones"]
    end

    AUTOMATED --> INST
    INTERACTIVE --> INST
    RPI --> TRACK
    BM --> LABELS
    TRIAGE --> LABELS

The automated pipeline and interactive agents share instruction files for consistent coding standards. Interactive agents produce tracking artifacts that inform implementation. The automated pipeline uses GitHub labels as its coordination mechanism, while interactive agents coordinate through .copilot-tracking/ files.

🤖 Crafted with precision by ✨Copilot following brilliant human instruction, then carefully refined by our team of discerning human reviewers.

In this article

End-to-End Process Flow​

Workflow Details​

Workflow Configuration​

Lock File Ownership​

Upgrading gh-aw-actions​

Label-Driven Handoffs​

Interactive Agent Workflows​

RPI Orchestration​

Prompt Engineering​

Security Review​

Code Review​

Documentation Operations​

Backlog Management​

Project Planning​

How It All Connects​

End-to-End Process Flow

Workflow Details

Workflow Configuration

Lock File Ownership

Upgrading gh-aw-actions

Label-Driven Handoffs

Interactive Agent Workflows

RPI Orchestration

Prompt Engineering

Security Review

Code Review

Documentation Operations

Backlog Management

Project Planning

How It All Connects