## ✅ Najprostsze i najczęściej polecane podejście
### **Jeden plik `.txt` / `.md` jako dziennik pracy**
To nie żart – to świadomie opisywany i stosowany system.
**Opis systemu (źródło):**
Autor opisuje prowadzenie **jednego, rosnącego pliku tekstowego**, gdzie każdy dzień to nowa sekcja, a wszystko jest append-only.
👉 [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)
**Dlaczego to działa:**
* 1 plik = zero narzutu
* grep / search działa błyskawicznie
* nadaje się idealnie na „co robiłem danego dnia”
* versioning przez Git (jeśli chcesz)
**Przykład formatu:**
```txt
2026-03-13
- 08:30 analiza błędu ETL
- 09:10 fix indeksu w SQL Server
- 10:05 call z Adrianem
```
***
## ✅ Jeśli chcesz „system”, ale dalej **plain text**
### **Plaintext Productivity**
To nie aplikacja, tylko **metodyka** oparta o pliki tekstowe.
👉 [\[plaintext-...tivity.net\]](https://plaintext-productivity.net/)
Zawiera:
* work log / journal
* taski
* notatki
Wszystko w `.txt` / `.md`
***
## ✅ Gotowe narzędzie, ale nadal **jeden plik**
### **RedNotebook**
* open‑source
* dziennik pracy
* dane przechowywane jako **plain text**
👉
(ujęty w zestawieniu plain‑text tools) [\[github.com\]](https://github.com/tehtbl/awesome-note-taking)
***
## ✅ Developer‑friendly (pewnie najbliżej Twojego stylu)
### **Obsidian / VS Code + 1 plik Markdown**
Nie jako „system notatek”, tylko **jeden plik `worklog.md`**.
Obsidian:
👉
VS Code:
👉
Markdown = plain text
Możesz:
* trzymać to w repo
* robić commit per dzień
* mieć pełną historię
***
## ✅ Hardcore / UNIX‑style
### **Org‑mode (Emacs) – jeden plik `worklog.org`**
Jeśli lubisz minimalizm + automatyzację:
* timestamps
* clock-in / clock-out
* wszystko w jednym pliku
👉
***
## 🔍 TL;DR – jeśli chcesz tylko **link**
Najbliżej Twojego opisu:
* **** – dokładnie „logowanie tego co się robi w jednym pliku tekstowym” [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)
***
## 1. Czym **jest** system jednego pliku tekstowego
To **append‑only dziennik pracy**, w którym:
* **wszystkie działania** (zadania, spotkania, decyzje, problemy)
* są zapisywane **chronologicznie**
* w **jednym pliku tekstowym** (`.txt` albo `.md`)
* bez przenoszenia danych między narzędziami
Autor systemu wprost opisuje, że *porzucił task managery, notatniki i aplikacje* na rzecz **jednego pliku**, który rośnie w czasie i jest głównym źródłem prawdy. [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)
To **nie jest TODO‑lista**, tylko **dziennik operacyjny**.
***
## 2. Fundamentalne zasady (najważniejsza część)
### ✅ 1. Jeden plik = jedno źródło prawdy
Nie ma:
* osobnych notatek
* osobnych tasków
* osobnych dzienników
Wszystko trafia do **tego samego pliku**. [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)
***
### ✅ 2. Chronologia ważniejsza niż struktura
Wpisy są:
* dzienne
* liniowe
* nieprzenoszone wstecz
Autor podkreśla, że **nie reorganizuje historii** — nowy dzień = nowa sekcja, dopisywana na koniec pliku. [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)
***
### ✅ 3. Append‑only (brak „sprzątania”)
* stare wpisy **nie są kasowane**
* zakończone taski **zostają**
* plik jest **historią pracy**, nie tylko listą zadań
To kluczowa różnica względem Jira / Todoist / Notion. [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)
***
## 3. Minimalny, kanoniczny format
Najczęściej stosowany (i opisany w źródle) format wygląda tak:
```txt
2026-03-13
- 08:30 analiza błędu ETL (INC0783182)
- 09:05 poprawka indeksu na tbl_orders
- 10:00 sync z zespołem
- 11:40 decyzja: rollback joba nocnego
```
Ważne:
* **data = nagłówek**
* **jedna linia = jedno zdarzenie**
* wpisy są „co zrobiłem”, nie „co planuję” [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)
***
## 4. Jak wygląda typowy dzień pracy w tym systemie
Zgodnie z opisem autora: [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)
1. **Na koniec dnia**
* dopisujesz listę rzeczy zaplanowanych na jutro (z kalendarza)
2. **W trakcie dnia**
* dopisujesz kolejne linie
3. **Nic nie „odhaczasz”**
* fakt wykonania = wpis w logu
Czyli:
* kalendarz → plan
* plik tekstowy → rzeczywistość
***
## 5. Dlaczego to działa (technicznie, nie psychologicznie)
Źródła wskazują na konkretne zalety: [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/), [\[plaintext-...tivity.net\]](https://plaintext-productivity.net/)
### 🔹 Zero kontekstu narzędzia
* nie „zarządzasz systemem”
* tylko zapisujesz fakty
### 🔹 Pełna przeszukiwalność
* `Ctrl+F`
* `grep`
* `ripgrep`
### 🔹 Audyt i retrospekcja
Masz:
* historię decyzji
* historię problemów
* historię realnej pracy (nie planów)
***
## 6. Wariant „inżynierski” (często stosowany)
Chociaż źródła opisują ideę, **praktycy** (dev / infra / DB) bardzo często łączą to z:
* **Markdown (`worklog.md`)**
* **Git**
* commit = dzień pracy
To nadal **jeden plik**, tylko z wersjonowaniem (to jest rozszerzenie idei, nie sprzeczne z nią).
***
## 7. Czego TEN system **nie robi** (i to jest celowe)
Na podstawie opisu źródeł: [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)
* ❌ nie priorytetyzuje
* ❌ nie przypomina
* ❌ nie liczy czasu
* ❌ nie optymalizuje workflow
To **dziennik operacyjny**, nie system zarządzania.
***
## 8. Dla kogo to jest szczególnie dobre
Z opisu i praktyki:
* DBA / SRE
* DevOps
* Backend
* ETL / Data
* Osoby pracujące incydentowo
Czyli dokładnie **styl pracy, który masz** (incydenty, debug, decyzje, retry, rollback).
***
## 9. Najważniejsza myśl na koniec
> „To nie plik jest systemem.
> Systemem jest nawyk zapisywania faktów w jednym miejscu.”
— sens podejścia Jeffa Huanga [\[jeffhuang.com\]](https://jeffhuang.com/productivity_text_file/)
# praktyczny szablon workloga pod DBA / ETL
***
# 📘 `worklog.md` — DBA / ETL
```md
# WORKLOG
==================================================
2026-03-13 (Fri)
==================================================
## Plan dnia (z kalendarza)
- [ ] Monitoring nocnych jobów ETL
- [ ] Analiza INC0783182
- [ ] Sync z zespołem EU One
## Operacje / faktyczne działania
08:25 Sprawdzenie statusu nocnych jobów (Airflow)
08:40 Job `etl_orders_delta` FAILED – timeout na source
08:55 Analiza execution plan (SQL Server)
09:20 Dodany indeks NONCLUSTERED na dbo.orders(order_date)
09:32 Re-run joba – SUCCESS
## Incydenty / problemy
- INC0783182
- Objaw: timeout ETL po deployu
- Przyczyna: brak indeksu po migracji
- Działanie: hotfix (indeks)
- Status: ✅ zamknięty
## Decyzje techniczne
- ✅ zostawić indeks permanentnie
- ❌ nie zwiększać timeoutu ETL (root cause fixed)
## Zmiany w danych / DB
- dbo.orders
- dodany indeks: IX_orders_order_date
- impact: +15% write cost (akceptowalne)
## Ryzyka / follow‑up
- [ ] sprawdzić inne joby zależne od dbo.orders
- [ ] dodać check indeksów do pipeline CI
## Notatki luźne
- Po deployu schema diff nie wykrył brakującego indeksu
- Do omówienia na retro
--------------------------------------------------
```
***
## 🔑 Dlaczego ten szablon działa (DBA/ETL‑specific)
### 1. **Rozdziela plan od rzeczywistości**
* `Plan dnia` = intencja
* `Operacje` = fakty
To bardzo ważne przy audycie i retrospekcjach.
***
### 2. **Incydenty mają własne miejsce**
Nie giną w strumieniu:
```md
## Incydenty / problemy
```
To ułatwia:
* pisanie post‑mortem
* raportowanie
* przypominanie „dlaczego coś zmieniliśmy”
***
### 3. **Decyzje techniczne są jawne**
To jest złoto po 3 miesiącach:
```md
## Decyzje techniczne
```
Nie „co zrobiłem”, tylko **dlaczego**.
***
### 4. **Zmiany w DB są logowane jak changelog**
Sekcja:
```md
## Zmiany w danych / DB
```
To zastępuje:
* osobne notatki
* pamięć zespołową
* „kto dodał ten indeks?!”
***
## ✅ Minimalna wersja (jeśli chcesz ultra‑lean)
Jeśli wolisz **jeszcze prostsze**:
```md
2026-03-13
08:40 job etl_orders_delta FAILED – timeout
09:20 analiza execution plan
09:32 dodany indeks IX_orders_order_date
09:40 rerun job – OK
DECYZJA: nie zwiększamy timeoutu
```
To nadal **pełnoprawny system**.
***
## ✅ Wariant „hardcore DBA”
Dodatkowe prefiksy (opcjonalne):
```txt
[INC] INC0783182 timeout ETL
[SQL] execution plan scan on dbo.orders
[FIX] added IX_orders_order_date
[DEC] no timeout increase
[RISK] other jobs depend on orders
```
Potem:
```bash
grep "\[INC\]" worklog.md
grep "\[DEC\]" worklog.md
```
***
## ✅ Jak używać (ważne, ale krótkie)
* **jeden plik**
* **codziennie nowa sekcja**
* **nie poprawiasz historii**
* **piszesz fakty, nie opisy literackie**
***
### 📊 Diagram: Worklog DBA / ETL (one‑file system)
```mermaid
flowchart TD
A[Start dnia] --> B["Plan dnia
(z kalendarza)"]
B --> C[Operacje / faktyczne działania]
C --> D{Czy wystąpił problem?}
D -- Nie --> E[Kontynuacja pracy]
E --> C
D -- Tak --> F[Incydent / Problem]
F --> G["Analiza techniczna
(SQL / ETL / Infra)"]
G --> H{Decyzja techniczna}
H --> I["Fix / Zmiana w DB
(indeks, config, kod)"]
I --> J[Re-run / Weryfikacja]
J --> K{Sukces?}
K -- Tak --> L[Zamknięcie incydentu]
K -- Nie --> G
L --> M[Log decyzji
i zmian w DB]
M --> N[Follow-up / Ryzyka]
N --> O[Koniec dnia]
```
***
### 🧠 Jak czytać ten diagram (krótko)
* **Plan dnia** → tylko intencja
* **Operacje** → faktyczne działania (logowane linia po linii)
* **Incydent** → osobna ścieżka (nie ginie w logu)
* **Decyzja techniczna** → jawna, zapisana
* **Zmiany w DB** → traktowane jak changelog
* **Follow‑up** → rzeczy do sprawdzenia później
Wszystko trafia do **jednego pliku tekstowego**, w kolejnych sekcjach dnia.
***
### ✅ Wersja uproszczona (jeśli chcesz do README)
Pewnie — poniżej masz dopasowany diagram Mermaid **pod SQL Server + Airflow**, z typowymi ścieżkami: **DAG run → staging → transformy w SQL Server → walidacja → publikacja**, a przy awarii: **triage w Airflow logs + metryki/alerty + ServiceNow + działania DBA**. Dodałem też miejsca na logowanie w Twoim **worklogu**.
W diagramie uwzględniłem, że:
* Airflow ma **logi per task/DAG** (np. w bucketach / Composer) jak w runbookach, [\[EU Analyti...k (EUANAP) | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/197919037/EU+Analytics+Platform+Runbook+EUANAP)
* Monitorowanie/alertowanie po stronie DB jest standardowo podpinane pod **Splunk** (zgodnie z „MS SQL – Monitoring Standards”), [\[MS SQL - M...Standards | PDF\]](https://mydnb.sharepoint.com/sites/theHub-Technology/Documents%20Database%20Management/MS%20SQL%20-%20Monitoring%20Standards.pdf?web=1)
* W runbooku „Shipping 2.0” jest przykład, że monitorowanie jest realizowane przez **Airflow DAG monitor + email na failure**. [\[Shipping 2.0 | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/271386232/Shipping+2.0)
***
## 🧩 Diagram: Worklog + Airflow + SQL Server (DBA/ETL)
***
### 💡 Mini-legenda (żeby było „DBA-friendly”)
* **Airflow logs**: miejsce startu triage (per task), często przechowywane centralnie (np. bucket/Composer). [\[EU Analyti...k (EUANAP) | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/197919037/EU+Analytics+Platform+Runbook+EUANAP)
* **Splunk**: typowe narzędzie enterprise do monitoringu/alertów SQL Server (metryki, progi, routing). [\[MS SQL - M...Standards | PDF\]](https://mydnb.sharepoint.com/sites/theHub-Technology/Documents%20Database%20Management/MS%20SQL%20-%20Monitoring%20Standards.pdf?web=1)
* **Airflow DAG monitor + email na failure**: częsty model alertowania dla pipeline’ów. [\[Shipping 2.0 | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/271386232/Shipping+2.0)
***
Pewnie — poniżej masz dopasowany diagram Mermaid **pod SQL Server + Airflow**, z typowymi ścieżkami: **DAG run → staging → transformy w SQL Server → walidacja → publikacja**, a przy awarii: **triage w Airflow logs + metryki/alerty + ServiceNow + działania DBA**. Dodałem też miejsca na logowanie w Twoim **worklogu**.
W diagramie uwzględniłem, że:
* Airflow ma **logi per task/DAG** (np. w bucketach / Composer) jak w runbookach, [\[EU Analyti...k (EUANAP) | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/197919037/EU+Analytics+Platform+Runbook+EUANAP)
* Monitorowanie/alertowanie po stronie DB jest standardowo podpinane pod **Splunk** (zgodnie z „MS SQL – Monitoring Standards”), [\[MS SQL - M...Standards | PDF\]](https://mydnb.sharepoint.com/sites/theHub-Technology/Documents%20Database%20Management/MS%20SQL%20-%20Monitoring%20Standards.pdf?web=1)
* W runbooku „Shipping 2.0” jest przykład, że monitorowanie jest realizowane przez **Airflow DAG monitor + email na failure**. [\[Shipping 2.0 | Confluence\]](https://dnbenterprise.atlassian.net/wiki/spaces/ER/pages/271386232/Shipping+2.0)
***
## 🧩 Diagram: Worklog + Airflow + SQL Server (DBA/ETL)
```mermaid
flowchart TD
A[Start dnia] --> WL1[Worklog\nPlan dnia\nDAG-i / okna / incydenty]
WL1 --> AF0[Airflow Scheduler]
AF0 --> AF1[Trigger DAG]
AF1 --> AF2{Stan DAG}
AF2 -- SUCCESS --> OK0[Worklog\nDAG OK\nczas + dag_id + run_id]
AF2 -- FAILED --> TRI0[Triage\nAirflow task logs]
TRI0 --> TRI1[Worklog\nINC / Problem\nDAG + task + error]
TRI0 --> L1[Airflow Logs]
L1 --> TRI2{Typ błędu}
AF1 --> STG[Staging / Landing]
STG --> LOAD[Load step\nBCP / SSIS / Python]
LOAD --> MSSQL["(SQL Server)"]
MSSQL --> TSQL[Transformacje T-SQL]
TSQL --> DQ[Data Quality Checks]
DQ --> PUB[Publish / downstream]
PUB --> OK0
TRI2 -- DB --> DB0[SQL Diagnostics]
DB0 --> DB1[Waits / Locks / IO / TempDB]
DB1 --> DB2{Akcja}
DB2 -- Hotfix --> FIX1[DB Fix\nIndex / Stats / Config]
DB2 -- Mitigation --> FIX2[Mitigation\nRollback / Disable step]
DB2 -- Escalate --> SN0[ServiceNow / ECC]
TRI2 -- ETL --> ETL0[ETL Diagnostics]
ETL0 --> ETL1[Schema / Source / Timeout]
ETL1 --> ETL2{Akcja}
ETL2 -- Retry --> RERUN[Rerun DAG]
ETL2 -- Fix --> CODEFIX[Fix DAG / Operator]
ETL2 -- Escalate --> SN0
FIX1 --> RERUN
FIX2 --> RERUN
CODEFIX --> RERUN
RERUN --> AF2
FIX1 --> WL2[Worklog\nZmiany w DB]
FIX2 --> WL3[Worklog\nDecyzje techniczne]
CODEFIX --> WL4[Worklog\nZmiany ETL]
SN0 --> WL5[Worklog\nTicket INC/CHG]
WL2 --> END[Koniec dnia]
WL3 --> END
WL4 --> END
WL5 --> END
```
***
### 💡 Mini-legenda (żeby było „DBA-friendly”)
* **Airflow logs**: miejsce startu triage (per task), często przechowywane centralnie (np. bucket/Composer).
* **Splunk**: typowe narzędzie enterprise do monitoringu/alertów SQL Server (metryki, progi, routing).
* **Airflow DAG monitor + email na failure**: częsty model alertowania dla pipeline’ów.
***
Pewnie — poniżej masz **w pełni działający SKILL do OpenClaw** (folder skill‑a z `SKILL.md` + szablony) oraz **wersję README‑ready** do wrzucenia do repo/`skills/`.
Oparłem format o to, jak OpenClaw rozumie skills: **katalog z plikiem `SKILL.md` (YAML frontmatter + instrukcje)** oraz to, gdzie OpenClaw skills ładuje i jaka jest precedencja (`/skills` → `~/.openclaw/skills` → bundled).\
Dodałem też notkę o bezpieczeństwie i *exec approvals* (gdybyś kiedyś chciał dopiąć `exec`), zgodnie z dokumentacją OpenClaw. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills) [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/exec-approvals), [\[openclaw-d....amcp.site\]](https://openclaw-docs.amcp.site/en/tools/exec)
***
# 1) SKILL: `dba-etl-worklog` (gotowy katalog)
## Struktura katalogu (wrzuć do `skills/dba-etl-worklog/`)
```text
skills/
dba-etl-worklog/
SKILL.md
templates/
day.md
airflow-sqlserver-flow.mmd
```
> Lokalizacje, które OpenClaw skanuje na skills: `Bundled`, `~/.openclaw/skills`, `/skills` — a workspace ma najwyższy priorytet. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills)
***
## `skills/dba-etl-worklog/SKILL.md`
> To jest “serce” skill‑a: YAML frontmatter + instrukcje operacyjne dla agenta.
````md
---
name: dba-etl-worklog
version: 1.0.0
description: "One-file Worklog dla DBA/ETL (SQL Server + Airflow): twórz dzienną sekcję, dopisuj wpisy, prowadź incydenty, decyzje, zmiany DB i generuj diagram Mermaid."
trigger: "worklog|log pracy|dziennik pracy|dba worklog|etl worklog|airflow worklog|sql server worklog|wpis do workloga|sekcja workloga|diagram airflow sqlserver"
tools: [filesystem]
author: "Paweł Domański"
---
# DBA/ETL Worklog (SQL Server + Airflow)
## Cel
Utrzymuj jeden plik (domyślnie `worklog.md`) jako źródło prawdy: plan dnia + faktyczne operacje + incydenty + decyzje + zmiany DB + follow-up.
Skill ma:
1) tworzyć dzienną sekcję (jeśli nie istnieje),
2) dopisywać wpisy do właściwej sekcji,
3) utrzymywać porządek (append-only, bez przepisywania historii),
4) generować diagram Mermaid dla Airflow + SQL Server.
## Zasady bezpieczeństwa (twarde)
- NIE zapisuj sekretów: haseł, connection stringów, tokenów, pełnych danych wrażliwych.
- Wpisuj identyfikatory i referencje: `INC...`, `CHG...`, `dag_id`, `run_id`, `task_id`, nazwy tabel/indeksów, ale bez sekretów.
- Ten skill używa tylko `filesystem` (read/write). Nie uruchamiaj komend powłoki.
## Pliki
- Główny plik workloga: `./worklog.md` (w katalogu roboczym/workspace).
- Szablon dnia: `templates/day.md`
- Diagram Mermaid: `templates/airflow-sqlserver-flow.mmd`
## Jak działa (procedura)
### 1) Ustal ścieżkę workloga
Domyślnie: `worklog.md` w root workspace.
Jeśli użytkownik poda inną ścieżkę (np. `notes/worklog.md`) – użyj jej.
### 2) Jeśli `worklog.md` nie istnieje – utwórz
Utwórz plik i wstaw nagłówek:
- `# WORKLOG`
- krótka notka “append-only”
- pusta linia
### 3) Zapewnienie dziennej sekcji
Dla bieżącej daty (format: `YYYY-MM-DD`) sprawdź czy istnieje blok:
==================================================
YYYY-MM-DD (Day)
==================================================
Jeśli nie istnieje:
- wczytaj `templates/day.md`,
- podstaw `{{DATE}}` i `{{DOW}}`,
- dopisz na koniec `worklog.md`.
### 4) Dopisywanie wpisów
W zależności od intencji użytkownika dopisz do jednej z sekcji:
- `## Operacje / faktyczne działania` → wpisy z godziną (HH:MM)
- `## Incydenty / problemy` → wpisy INC/Problem
- `## Decyzje techniczne` → decyzje i uzasadnienie
- `## Zmiany w danych / DB` → indeksy, stats, config, hotfix
- `## Ryzyka / follow-up` → checkboxy `[ ]`
- `## Notatki luźne` → kontekst
Zasada dopisywania:
- Nie edytuj starych dni.
- Dopisuj na końcu właściwej sekcji w aktualnym dniu.
- Jeśli w sekcji nie ma jeszcze treści – dopisz jako pierwszą linię.
### 5) Generowanie diagramu Mermaid (Airflow + SQL Server)
Jeśli użytkownik prosi o diagram:
- wczytaj `templates/airflow-sqlserver-flow.mmd`,
- zwróć go w wiadomości (README-ready),
- opcjonalnie wstaw do `worklog.md` pod sekcją `## Diagram` (jeżeli user chce mieć w pliku).
WAŻNE: Mermaid parsing
- Nie używaj cudzysłowów w labelach węzłów.
- Zamiast `
` używaj `\n` w labelach.
## Odpowiedzi (format)
- Gdy tworzysz/aktualizujesz plik: napisz co zmieniłeś i gdzie (ścieżka).
- Gdy generujesz diagram: zwróć gotowy blok ```mermaid ... ```.
## Przykładowe polecenia użytkownika (obsługuj)
- "stwórz dzisiejszą sekcję workloga"
- "dopisz: 09:20 dodany indeks IX_orders_order_date"
- "dodaj incydent INC0783182: timeout na tasku load_orders"
- "zapisz decyzję: nie zwiększamy timeoutu, fixujemy indeks"
- "wygeneruj diagram airflow + sql server"
````
***
## `skills/dba-etl-worklog/templates/day.md`
```md
==================================================
{{DATE}} ({{DOW}})
==================================================
## Plan dnia (z kalendarza)
- [ ] Monitoring DAG-ów / okna ładowań
- [ ] Priorytetowe incydenty (INC/CHG)
- [ ] Review: failure/retry z nocy
## Operacje / faktyczne działania
## Incydenty / problemy
## Decyzje techniczne
## Zmiany w danych / DB
## Ryzyka / follow-up
- [ ] ...
## Notatki luźne
- ...
```
***
## `skills/dba-etl-worklog/templates/airflow-sqlserver-flow.mmd` (diagram)
To jest **Twoja poprawiona, parsująca się wersja**, bez `"` i z `\n` zamiast `
`.
***
# 2) README‑ready (gotowe do wklejenia do repo)
Poniżej masz kompletną sekcję README (opis + instalacja + użycie + diagram).
## `README.md`
````md
# DBA/ETL Worklog (OpenClaw Skill)
Skill do OpenClaw, który pomaga prowadzić **jeden plik workloga** (`worklog.md`) dla DBA/ETL z naciskiem na **SQL Server + Airflow**:
- tworzy dzienną sekcję (YYYY-MM-DD),
- dopisuje wpisy do właściwych sekcji (operacje, incydenty, decyzje, zmiany DB),
- generuje diagram Mermaid (Airflow → SQL Server → triage → fix → rerun).
## Instalacja
OpenClaw ładuje skills z kilku lokalizacji, m.in. z katalogu workspace:
`/skills` (najwyższy priorytet) oraz `~/.openclaw/skills`.
Precedencja: workspace → `~/.openclaw/skills` → bundled.
Szczegóły: docs OpenClaw.
1. Skopiuj katalog:
- `skills/dba-etl-worklog/`
do:
- `/skills/dba-etl-worklog/`
2. Upewnij się, że w środku jest `SKILL.md` oraz `templates/`.
## Użycie (przykłady)
- **Utwórz dzisiejszą sekcję:**
> "stwórz dzisiejszą sekcję workloga"
- **Dopisz operację:**
> "dopisz: 09:20 dodany indeks IX_orders_order_date"
- **Zapisz incydent:**
> "dodaj incydent INC0783182: timeout na tasku load_orders (dag_id=etl_orders, task_id=load_orders)"
- **Zapisz decyzję:**
> "zapisz decyzję: nie zwiększamy timeoutu, fixujemy indeks"
- **Wygeneruj diagram:**
> "wygeneruj diagram airflow + sql server"
## Diagram (Mermaid)
```mermaid
flowchart TD
A[Start dnia] --> WL1[Worklog\nPlan dnia\nDAG-i / okna / incydenty]
WL1 --> AF0[Airflow Scheduler]
AF0 --> AF1[Trigger DAG]
AF1 --> AF2{Stan DAG}
AF2 -- SUCCESS --> OK0[Worklog\nDAG OK\nczas + dag_id + run_id]
AF2 -- FAILED --> TRI0[Triage\nAirflow task logs]
TRI0 --> TRI1[Worklog\nINC / Problem\nDAG + task + error]
TRI0 --> L1[Airflow Logs]
L1 --> TRI2{Typ błędu}
AF1 --> STG[Staging / Landing]
STG --> LOAD[Load step\nBCP / SSIS / Python]
LOAD --> MSSQL[(SQL Server)]
MSSQL --> TSQL[Transformacje T-SQL]
TSQL --> DQ[Data Quality Checks]
DQ --> PUB[Publish / downstream]
PUB --> OK0
TRI2 -- DB --> DB0[SQL Diagnostics]
DB0 --> DB1[Waits / Locks / IO / TempDB]
DB1 --> DB2{Akcja}
DB2 -- Hotfix --> FIX1[DB Fix\nIndex / Stats / Config]
DB2 -- Mitigation --> FIX2[Mitigation\nRollback / Disable step]
DB2 -- Escalate --> SN0[ServiceNow / ECC]
TRI2 -- ETL --> ETL0[ETL Diagnostics]
ETL0 --> ETL1[Schema / Source / Timeout]
ETL1 --> ETL2{Akcja}
ETL2 -- Retry --> RERUN[Rerun DAG]
ETL2 -- Fix --> CODEFIX[Fix DAG / Operator]
ETL2 -- Escalate --> SN0[ServiceNow / ECC]
FIX1 --> RERUN
FIX2 --> RERUN
CODEFIX --> RERUN
RERUN --> AF2
FIX1 --> WL2[Worklog\nZmiany w DB]
FIX2 --> WL3[Worklog\nDecyzje techniczne]
CODEFIX --> WL4[Worklog\nZmiany ETL]
SN0 --> WL5[Worklog\nTicket INC/CHG]
WL2 --> END[Koniec dnia]
WL3 --> END
WL4 --> END
WL5 --> END
````
## Notka: exec / allowlista (opcjonalnie)
Ten skill domyślnie używa tylko `filesystem`.
Jeśli kiedyś dopniesz `exec` (np. do `git commit`), to pamiętaj o mechanizmie **exec approvals**:
komendy na hoście przechodzą przez politykę + allowlistę + (opcjonalnie) prompt użytkownika. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/exec-approvals), [\[openclaw-d....amcp.site\]](https://openclaw-docs.amcp.site/en/tools/exec)
```
---
# 3) (Opcjonalnie) Wersja “tool-first” z `exec` (tylko jeśli chcesz)
Jeżeli zechcesz, mogę od razu przygotować wariant skill‑a, który:
- potrafi `git status` / `git commit -am "worklog: YYYY-MM-DD"` (po zatwierdzeniu),
- ale **wymaga** ogarnięcia `exec approvals` i allowlisty na host‑exec zgodnie z dokumentacją.
Jasne — dodaję sub‑funkcję **„Podsumuj dzień”** do Twojego skill‑a `dba-etl-worklog`. Poniżej masz **konkretne zmiany do wklejenia** (aktualizacja `SKILL.md` + aktualizacja szablonu dnia). Skill dalej jest w formacie **katalog + `SKILL.md` z YAML frontmatter**, zgodnie z tym jak OpenClaw ładuje i rozumie skills. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills)
***
## 1) Aktualizacja `SKILL.md` — dodaj sub‑funkcję „Podsumuj dzień”
W pliku `skills/dba-etl-worklog/SKILL.md`:
### A) (Opcjonalnie) rozbuduj `trigger`
Dodaj do istniejącego `trigger` frazy, żeby skill łatwo się aktywował:
```yaml
trigger: "worklog|log pracy|dziennik pracy|dba worklog|etl worklog|airflow worklog|sql server worklog|wpis do workloga|sekcja workloga|diagram airflow sqlserver|podsumuj dzień|podsumowanie dnia|daily summary|summary worklog"
```
> Skill nadal pozostaje w standardowym układzie: YAML frontmatter + instrukcje w `SKILL.md`. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills)
***
### B) Dodaj nową sekcję w instrukcjach (wklej w `SKILL.md` pod „Jak działa (procedura)”)
Wklej ten blok (np. po punkcie „5) Generowanie diagramu Mermaid…”):
```md
### 6) Sub-funkcja: Podsumuj dzień
Aktywuj, gdy użytkownik poprosi o:
- "Podsumuj dzień"
- "Zrób podsumowanie dnia z workloga"
- "Daily summary" / "Summary worklog"
- "Podsumuj dzisiejszy worklog"
#### Wejście
- ścieżka do workloga (domyślnie `./worklog.md`)
- data: domyślnie dzisiejsza (YYYY-MM-DD); jeśli user poda inną datę, użyj jej
#### Krok po kroku (deterministycznie)
1) Wczytaj `worklog.md`.
2) Wytnij tylko sekcję dnia:
- start = linia z separatorem i datą:
`==================================================`
`YYYY-MM-DD (...)`
`==================================================`
- koniec = następna taka sekcja albo EOF.
3) Z parsowanej sekcji wyciągnij dane źródłowe:
- Operacje: linie zaczynające się od `HH:MM` oraz/lub krótkie wpisy operacyjne.
- Incydenty: bloki zaczynające się od `- INC` (lub `- Problem`) wraz z podpunktami.
- Decyzje: linie w `## Decyzje techniczne` (np. zaczynające się od ✅/❌).
- Zmiany DB: wpisy pod `## Zmiany w danych / DB` (obiekt + zmiana + impact).
- Follow-up: checkboxy `- [ ]` z `## Ryzyka / follow-up` (tylko otwarte).
4) Zbuduj streszczenie (bez “fantazjowania”):
- 5–10 bulletów “Najważniejsze” na podstawie Operacji/Incydentów/Decyzji/Zmian.
- Wypisz incydenty z: id + status (jeśli jest) + 1-liniowy opis.
- Wypisz decyzje (✅/❌) bez rozbudowy ponad to, co w logu.
- Wypisz zmiany DB (obiekt → zmiana).
- Wypisz otwarte follow-up (`- [ ] ...`).
- (Opcjonalnie) policz ilości: liczba operacji (HH:MM), liczba incydentów, liczba otwartych follow-up — to wolno policzyć, bo wynika z tekstu.
5) Zwróć wynik użytkownikowi w formacie README/Slack-friendly.
#### Format wyjścia (zawsze taki sam)
**Podsumowanie dnia: YYYY-MM-DD**
Najważniejsze:
- ...
Incydenty:
- INCxxxxx — status: (jeśli w logu) — krótko
Decyzje:
- ✅/❌ ...
Zmiany DB:
- db.schema.object — zmiana
Otwarte follow-up:
- [ ] ...
Statystyki (opcjonalnie, zliczone z logu):
- Operacje: N
- Incydenty: N
- Follow-up otwarte: N
#### Zapis do pliku (opcjonalny)
Jeżeli użytkownik chce, dopisz pod bieżącym dniem sekcję:
`## Podsumowanie dnia (auto)`
i wstaw tam wygenerowany blok.
Nie nadpisuj starego podsumowania — dopisz kolejne z timestampem lub nadpisz tylko jeśli user tego wymaga.
```
***
## 2) Aktualizacja szablonu dnia `templates/day.md`
Dodaj na końcu szablonu (lub po „Notatki luźne”) sekcję na auto‑summary:
```md
## Podsumowanie dnia (auto)
```
Pełny fragment do wklejenia (koniec pliku):
```md
## Notatki luźne
- ...
## Podsumowanie dnia (auto)
```
***
## 3) README‑ready: dopisz krótki opis funkcji
Do Twojego `README.md` (sekcja „Użycie”) dodaj:
```md
### Podsumuj dzień
Generuje krótkie podsumowanie z dziennej sekcji workloga:
- najważniejsze (5–10 bulletów),
- incydenty (INC + status),
- decyzje,
- zmiany DB,
- otwarte follow-up (checkboxy).
Przykład:
> "Podsumuj dzień"
> "Podsumuj 2026-03-13 z workloga"
```
***
### Dlaczego to jest zgodne z OpenClaw
* Trzymasz wszystko w **jednym skill folderze** i sterujesz zachowaniem przez instrukcje w `SKILL.md` (YAML frontmatter + opis procedur) — to dokładnie model skills w OpenClaw. [\[docs.openclaw.ai\]](https://docs.openclaw.ai/tools/skills)
***
Jeśli chcesz, od razu mogę dopisać w tej sub‑funkcji jeszcze **regułę “tagowania”** (np. `[AIRFLOW]`, `[SQL]`, `[INC]`, `[DEC]`) i wtedy “Podsumuj dzień” robi jeszcze lepsze grupowanie (bez LLM‑owego zgadywania), ale na razie powyższe działa już bardzo solidnie w trybie plain‑text.
Super — dokładamy **regułę tagowania**, tak żeby „Podsumuj dzień” mógł **parsować i grupować** wpisy deterministycznie (bez zgadywania). Przy okazji trzymamy się dobrej praktyki: **tagi jako key/value i najlepiej lowercase**, bo w części systemów są case‑sensitive i rekomendacja jest „lowercase wherever possible”.
Poniżej masz **gotowe fragmenty do wklejenia** do `skills/dba-etl-worklog/SKILL.md` + małą aktualizację `templates/day.md`.
***
## 1) `SKILL.md` — dodaj “Reguła tagowania” (nowa sekcja)
Wklej tę sekcję w `SKILL.md` np. **przed** „### 6) Sub-funkcja: Podsumuj dzień”:
```md
## Reguła tagowania (dla Podsumuj dzień)
### Cel
Ułatwić automatyczne grupowanie wpisów w dziennym podsumowaniu: Airflow vs SQL Server vs DQ vs Incydenty itd.
### Format tagów (2 warstwy)
#### A) Tag prefiksowy (czytelny, szybki)
Na początku linii wpisu:
- pojedynczy tag: `[AIRFLOW] ...`
- wiele tagów: `[AIRFLOW][ETL] ...` albo `[AIRFLOW] [ETL] ...`
Dozwolone tagi (prefiksowe):
- `[AIRFLOW]` / `[DAG]` / `[TASK]`
- `[SQL]` / `[MSSQL]` / `[DB]`
- `[ETL]` / `[SSIS]`
- `[DQ]`
- `[INC]` / `[CHG]`
- `[DEC]`
- `[RISK]`
- `[MEET]`
- `[NOTE]`
Normalizacja:
- W podsumowaniu traktuj tagi jako **case-insensitive** i normalizuj do lowercase (np. AIRFLOW → airflow).
(Tagi mogą być case-sensitive w niektórych systemach, zalecane jest lowercase nazw i wartości.)
#### B) Tagi key=value (strukturalne, do filtrów i statystyk)
Dopisuj na końcu lub w środku wpisu:
- `dag=etl_orders run_id=manual__2026-03-13T08:40 task=load_orders`
- `db=prod01 database=sales object=dbo.orders`
- `ticket=INC0783182 env=prod`
Zasady:
- klucze i wartości najlepiej lowercase (case może mieć znaczenie)
- bez spacji wokół `=`
- separacja spacją
- wartości bez wrażliwych danych (brak haseł / connection stringów)
### Minimalne przykłady wpisów
- `[AIRFLOW][ETL] 08:40 DAG failed task timeout dag=etl_orders task=load_orders run_id=scheduled__... ticket=INC0783182`
- `[SQL] 09:20 dodany indeks IX_orders_order_date db=prod01 database=sales object=dbo.orders`
- `[DQ] 09:35 rowcount mismatch source vs stage dag=etl_orders task=dq_orders`
- `[DEC] ✅ nie zwiększamy timeoutu; fixujemy indeks ticket=INC0783182`
- `[RISK] - [ ] dodać check indeksów do CI dag=etl_orders`
```
***
## 2) `SKILL.md` — modyfikacja sub-funkcji “Podsumuj dzień” (parsowanie tagów)
W sekcji „### 6) Sub-funkcja: Podsumuj dzień” **podmień** punkt 3) na wersję “tag-aware” (albo dopisz jako 3a/3b):
```md
3) Z parsowanej sekcji wyciągnij dane źródłowe + tagi:
- Każdą linię spróbuj zinterpretować jako:
a) prefiks tagów: `[TAG]` / `[TAG][TAG]` / `[TAG] [TAG]`
b) pary key=value (np. dag=..., task=..., ticket=...)
- Znormalizuj tagi do lowercase (AIRFLOW → airflow), bo tagi mogą być case-sensitive; zalecane lowercase nazw/wartości.
- Klasyfikacja wpisu:
* jeśli ma tag `inc` lub zawiera `INC\d+` → Incydenty
* jeśli ma tag `dec` lub zaczyna się od `✅/❌` w sekcji decyzji → Decyzje
* jeśli ma tag `sql`/`mssql`/`db` lub jest w sekcji zmian DB → Zmiany DB
* jeśli ma tag `airflow`/`dag`/`task` → Airflow
* jeśli ma tag `dq` → DQ
* jeśli ma tag `risk` lub jest checkbox `- [ ]` → Follow-up
- Zachowaj też metadane key=value:
* ticket=..., dag=..., run_id=..., task=..., db=..., database=..., object=..., env=...
4) Zbuduj streszczenie (tag-first, bez fantazjowania):
- Najważniejsze: 5–10 bulletów, preferuj wpisy z tagami `inc`, `airflow`, `sql`, `dec`, `dq`.
- Dodaj sekcję "Rozkład wg tagów" (opcjonalnie) z licznikami:
airflow: N, sql: N, dq: N, inc: N, dec: N, risk(open): N
(licz tylko z tekstu)
```
***
## 3) `SKILL.md` — format wyjścia “Podsumuj dzień” (dodaj tagi w podsumowaniu)
W części „#### Format wyjścia (zawsze taki sam)” dopisz po „Najważniejsze” nową mini-sekcję:
```md
Rozkład wg tagów (z logu):
- airflow: N
- sql: N
- dq: N
- inc: N
- dec: N
- follow-up(open): N
```
I (opcjonalnie) w “Najważniejsze” dopuszczaj prefiks tagów w bulletach, np.:
* `[airflow] ...`
* `[sql] ...`
***
## 4) `templates/day.md` — dodaj przykłady tagowanych wpisów (żebyś pisał konsekwentnie)
W `templates/day.md` pod sekcją `## Operacje / faktyczne działania` podmień komentarze na takie:
```md
## Operacje / faktyczne działania
```
Pod `## Ryzyka / follow-up` dodaj przykład:
```md
## Ryzyka / follow-up
- [ ] [RISK] dodać check indeksów do CI dag=etl_orders
```
***
## Dlaczego lowercase / key=value?
Bo „tagi” w różnych systemach bywają **case-sensitive** i rekomendacja jest, żeby używać lowercase dla nazw i wartości, plus model key/value jest standardem.
My robimy kompromis: **Ty możesz pisać prefiksowe tagi dużymi literami dla czytelności**, a “Podsumuj dzień” i tak **normalizuje** do lowercase w podsumowaniu.
***
Jeśli chcesz, mogę też dopisać **regułę priorytetu** (np. `[INC]` zawsze pierwsze w “Najważniejsze”, potem `[DEC]`, `[SQL]`, `[AIRFLOW]`, `[DQ]`) i wtedy “Podsumuj dzień” będzie jeszcze bardziej “opsowy” (SRE‑style).