Dotychczas wszystko co robiliśmy działo się w edytorze – instrukcje, skills, agenci, MCP serwery, hooks. Copilot był asystentem który reagował na Twoje polecenia w VS Code, a potem sprzątał po sobie przez hooks. Ale co jeśli chcesz żeby cały workflow uruchamiał się samodzielnie, bez Twojego udziału – w nocy, przy każdym nowym issue, albo gdy ktoś wpisze /check w komentarzu do PR?

Agentic Workflows to odpowiedź na to pytanie. To pliki Markdown które definiują autonomiczne automatyzacje uruchamiane przez GitHub Actions – ale zamiast YAML z krokimi shellowymi, piszesz naturalne instrukcje dla agenta. GitHub kompiluje je do wykonywalnego workflow, Copilot Coding Agent przejmuje wykonanie i działa autonomicznie: analizuje kod, tworzy issues, pisze komentarze do PR, generuje raporty.

To jest szczyt drabiny którą wspinaliśmy się przez ostatnie dziewięć wpisów. Oryginalna dokumentacja: Agentic Workflows – Awesome GitHub Copilot Learning Hub. Pełna specyfikacja CLI: GitHub Agentic Workflows (gh.io/gh-aw). Biblioteka gotowych workflowów: awesome-copilot.github.com/workflows.

Zanim wejdziemy w szczegóły, jedno pytanie które na pewno masz: skoro hooks już automatyzują działania agenta – to po co jeszcze workflows? Oto czysta granica:

Kluczowy element który odróżnia Agentic Workflows od zwykłych GitHub Actions to kompilator gh aw. Zamiast ręcznie pisać YAML z krokami Actions – piszesz Markdown z naturalnymi instrukcjami, a CLI kompiluje to do gotowego .lock.yml.

Zarówno plik .md jak i wygenerowany .lock.yml commitujesz do repo – .md to źródło prawdy (tutaj edytujesz), .lock.yml to artefakt kompilacji który uruchamia GitHub Actions. Po każdej edycji .md rekompilujesz przez gh aw compile.

Plik workflow to Markdown z YAML frontmatter. Frontmatter deklaruje metadane, wyzwalacze, uprawnienia i guardrails. Treść Markdown to instrukcje naturalne które Copilot Coding Agent wykonuje.

Typy wyzwalaczy

To jest mój główny dodatek do tego wpisu. Zamiast omawiać ogólne przypadki użycia – konkretna tabelka która pokazuje jak Agentic Workflows mogą wyglądać w typowym projekcie backendowym .NET. Każdy wiersz to gotowy przepis: co wyzwala workflow, co agent robi, jaki jest wynik i jak go skonfigurować.

Schemat zakłada projekt z Clean Architecture, repozytorium na GitHub, CI w GitHub Actions i teamem kilku developerów.

Poniżej kompletny, gotowy do wklejenia workflow który implementuje "dzienny raport backlogu" z tabelki powyżej. To dobry punkt startowy bo jest całkowicie read-only – agent tylko czyta i komentuje, nie może nic zepsuć.

---
name: "Daily .NET Backlog Report"
description: >
  Codziennie rano generuje raport stanu backlogu dla projektu .NET.
  Identyfikuje zablokowane PR-y, stale issues i propozycje akcji dla teamu.
on:
  schedule: daily on weekdays at 8am UTC
permissions:
  contents: read
  issues: write
  pull-requests: read
safe-outputs:
  create-issue:
    title-prefix: "[daily-report] "
    labels: [automated-report, backlog]
---

## Cel

Wygeneruj dzienny raport stanu backlogu repozytorium. Raport ma pomóc
teamowi szybko zorientować się co stoi, kto jest zablokowany i na co
zwrócić uwagę podczas daily standup.

## Instrukcje krok po kroku

### 1. Zbierz dane o otwartych issues

Przejrzyj wszystkie otwarte issues. Dla każdego issue zanotuj:
- tytuł i numer
- etykiety
- przypisaną osobę (assignee) lub brak
- datę ostatniego komentarza lub aktywności

### 2. Zbierz dane o otwartych Pull Requestach

Przejrzyj wszystkie otwarte PR-y. Dla każdego zanotuj:
- tytuł i numer
- autora
- liczbę dni od otwarcia
- status review (approved / changes requested / brak review)
- czy CI przechodzi

### 3. Identyfikuj problemy

Na podstawie zebranych danych zidentyfikuj:

**Stale issues** – otwarte issues bez aktywności przez 7 lub więcej dni.
Podaj ich listę z numerami i datami ostatniej aktywności.

**Zablokowane PR-y** – PR-y otwarte ponad 3 dni bez review lub
z requested changes bez odpowiedzi autora. Podaj listę.

**Nieprzypisane issues z etykietą "bug"** – bugi bez assignee
to potencjalne zagrożenia dla jakości. Wylistuj je osobno.

**PR-y z nieudanym CI** – PR-y gdzie pipeline się nie udał
a autor jeszcze nie zareagował (brak aktywności ponad 24h).

### 4. Przygotuj raport

Stwórz issue z raportem według poniższego formatu. Tytuł issue:
`[daily-report] Backlog Health – {data w formacie YYYY-MM-DD}`

Treść issue powinna zawierać:

```
## 📊 Backlog Health – {data}

### Stale Issues ({liczba})
| # | Tytuł | Ostatnia aktywność | Assignee |
|---|-------|--------------------|----------|
...

### Zablokowane PR-y ({liczba})
| # | Tytuł | Dni otwarty | Status review |
|---|-------|-------------|---------------|
...

### Nieprzypisane bugi ({liczba})
| # | Tytuł | Etykiety |
|---|-------|----------|
...

### PR-y z nieudanym CI ({liczba})
| # | Tytuł | Autor | Dni od awarii |
|---|-------|-------|---------------|
...

### 💡 Sugestie akcji
{3-5 konkretnych sugestii co team powinien zrobić dziś na podstawie danych}
```

Jeśli któraś sekcja jest pusta (np. brak stale issues) – napisz
"✅ Brak problemów w tej kategorii" zamiast pustej tabeli.

### 5. Nie twórz raportu jeśli brak problemów

Jeśli wszystkie cztery kategorie są puste – nie twórz issue.
Zamiast tego zakończ workflow z komunikatem sukcesu w logach:
"✅ Backlog w dobrym stanie – raport pominięty."

Drugi przykład – triage nowych issues, wywołany zdarzeniem:

---
name: "Issue Auto-Triage"
description: >
  Automatycznie analizuje nowe issues w projekcie .NET. Sugeruje etykiety,
  sprawdza duplikaty i prosi o brakujące informacje gdy opis jest niepełny.
on:
  issues:
    types: [opened]
permissions:
  contents: read
  issues: write
safe-outputs:
  add-issue-comment: true
---

## Cel

Przeanalizuj nowo otwarte issue i zostaw pomocny komentarz który:
1. Potwierdza że issue zostało odebrane
2. Sugeruje odpowiednie etykiety
3. Sprawdza czy nie ma duplikatu
4. Prosi o dodatkowe informacje jeśli opis jest niepełny

## Instrukcje

### 1. Przeczytaj issue

Przeczytaj tytuł i treść nowego issue.

### 2. Określ typ

Na podstawie treści oceń czy to:
- **bug** – coś nie działa jak powinno
- **feature** – nowa funkcjonalność
- **question** – pytanie o działanie systemu
- **docs** – problem z dokumentacją
- **chore** – maintenance, dependency update itp.

### 3. Sprawdź duplikaty

Przeszukaj ostatnie 50 otwartych i zamkniętych issues pod kątem
podobnych tytułów lub opisów. Jeśli znajdziesz potencjalny duplikat
– zanotuj jego numer.

### 4. Oceń kompletność opisu

Dla bugow sprawdź czy issue zawiera:
- opis problemu (co się dzieje)
- oczekiwane zachowanie (co powinno się dziać)
- kroki do reprodukcji

Dla feature requestów sprawdź czy jest:
- opis przypadku użycia (po co to potrzebne)
- propozycja rozwiązania lub oczekiwane zachowanie

### 5. Zostaw komentarz

Napisz przyjazny komentarz po polsku według szablonu:

```
Dziękuję za zgłoszenie! 🙏

**Proponowane etykiety:** {lista etykiet}
{Jeśli duplikat: "**Możliwy duplikat:** #{numer} – {tytuł}"}

{Jeśli opis jest kompletny:
"Opis wygląda kompletnie, przekazuję do teamu."}

{Jeśli opis jest niekompletny:
"Żeby szybciej pomóc, czy możesz uzupełnić:
- {brakujący element 1}
- {brakujący element 2}"}
```

Bądź zwięzły i przyjazny. Nie komentuj spraw oczywistych.
Nie używaj markdown w komentarzu poza pogrubionymi nagłówkami.

Do pracy z Agentic Workflows potrzebujesz rozszerzenia gh aw dla GitHub CLI.

# Zainstaluj gh CLI jeśli jeszcze nie masz:
# https://cli.github.com

# Zainstaluj rozszerzenie agentic workflows:
gh extension install github/gh-aw

# Sprawdź że działa:
gh aw --version

# Walidacja bez generowania pliku:
gh aw compile --validate --no-emit .github/workflows/daily-backlog-report.md

# Kompilacja – generuje .lock.yml obok pliku .md:
gh aw compile

git add .github/workflows/daily-backlog-report.md
git add .github/workflows/daily-backlog-report.lock.yml
git commit -m "Add daily backlog report agentic workflow"
git push

# Uruchom workflow bez czekania na trigger:
gh aw run daily-backlog-report

# Obserwuj status:
gh aw status

# Przejrzyj logi jeśli coś nie gra:
gh aw logs daily-backlog-report

Least-privilege permissions – zawsze

Definiuj tylko uprawnienia których workflow faktycznie potrzebuje. Jeśli tylko czyta issues i pisze komentarze – issues: write i contents: read wystarczy. Nie dawaj contents: write jeśli workflow nie musi modyfikować kodu – to otwiera możliwość na modyfikację plików przez prompt injection w treści issue.

safe-outputs jako guardrail

Pole safe-outputs to Twój ostatni bastion kontroli. Nawet jeśli ktoś wstrzyknie sprytny prompt do treści issue próbując skłonić agenta do tworzenia issues ze złośliwym tytułem – title-prefix w safe-outputs gwarantuje że każdy issue stworzony przez workflow zacznie się od Twojego prefiksu. Łatwo go potem wyfiltrować lub usunąć.

Zacznij read-only, rozszerzaj stopniowo

Pierwszy workflow w projekcie powinien być całkowicie read-only (tylko contents: read, issues: read). Gdy masz pewność że działa jak oczekujesz – dodaj uprawnienie do komentowania. Dopiero gdy to jest stabilne – rozważ tworzenie issues lub PR-ów.

Edytuj .md, nie .lock.yml

Plik .lock.yml jest generowany automatycznie i nie powinien być edytowany ręcznie. Wszelkie zmiany rób w pliku .md, a następnie rekompilujesz przez gh aw compile. PR review dotyczy zmian w .md – to jest czytelny diff który można sensownie zreviewować.

Agentic Workflows zamykają pętlę całego cyklu. Masz teraz wszystkie warstwy: instrukcje kształtują zachowanie agenta, skills dają mu wyspecjalizowane zdolności, agenci orkiestrują złożone zadania, MCP serwery łączą z zewnętrznymi narzędziami, hooks pilnują jakości w trakcie pracy, a workflows działają autonomicznie gdy Cię nie ma.

• ✅ Agentic Workflows ≠ GitHub Actions – piszesz Markdown z naturalnymi instrukcjami, gh aw compile generuje Actions YAML. Edytujesz .md, nie YAML.
• ✅ Cztery typy triggerów: schedule (naturalny język, nie cron!), zdarzenia repo, slash commands i ręczne uruchomienie.
• ✅ safe-outputs to obowiązek – definiuj co agent może tworzyć. Prefiks tytułu i etykiety to minimum dla każdego workflow który tworzy issues.
• ✅ Schemat dla .NET projektu – osiem gotowych workflowów: triage issues, review PR, security check, dzienny raport, tygodniowy raport velocity, pokrycie testami, estymacja i dependency audit.
• ✅ Dwa gotowe pliki .md: daily backlog report i issue auto-triage – skopiuj, dostosuj nazwy, skompiluj, commituj.
• ✅ Zacznij read-only – pierwszy workflow tylko czyta. Uprawnienia do zapisu dodajesz gdy masz pewność że workflow działa zgodnie z oczekiwaniami.

W kolejnym wpisie wchodzimy w szczegóły tego co napędza autonomiczne workflows: Copilot Coding Agent w praktyce – jak przypisywać go do issues, jak monitorować postęp i jak skutecznie reviewować jego pracę.