# Otwarte decyzje: agent pyta zamiast zgadywać i przypomina, aż odpowiesz

> Agent zadaje pytanie, gdy brakuje mu ważnego faktu, zapisuje je i przypomina według drabiny wieku, aż zdecydujesz.

Canonical: https://dawidgac.com/pl/skills/otwarte-decyzje-ai-przypomina
Opublikowano: 2026-09-23

## Co robi

Agent najpierw przeszukuje Twoje notatki, zadania i repozytorium. Jeśli brakującego faktu nie ma nigdzie, a zmienia on decyzję, agent pyta wprost, na górze odpowiedzi, z opcjami do wyboru i ze skutkiem braku odpowiedzi. Pytanie bez odpowiedzi trafia do rejestru decyzji ze stałym kluczem. Rano i wieczorem agent pokazuje najwyżej trzy pozycje: świeże w jednej linii, starsze z wiekiem, po ósmym dniu z nazwą tego, co blokują, po piętnastym z wyborem: zrób albo skreśl. Przed każdym przypomnieniem agent sprawdza w źródle, czy sprawa jest nadal otwarta.

## Kiedy używać

- Agent pracuje dla Ciebie codziennie i podejmuje decyzje na podstawie faktów z Twojej firmy.
- Pytania do Ciebie giną w czacie albo na liście, której nikt nie czyta.
- Agent wpisuje wiarygodnie wyglądające liczby, których nigdzie nie sprawdził.
- Masz poranne albo wieczorne podsumowanie i chcesz w nim krótki blok decyzji.

## Kiedy nie używać

- Jednorazowe zadanie bez kolejnych sesji: rejestr i drabina nie mają czasu zadziałać.
- Agent nie ma dostępu do żadnych źródeł do przeszukania, więc każde pytanie byłoby ślepe.
- Chcesz tylko bramki pytań przed startem ryzykownej pracy: do tego lepszy jest szablon clarify-before-acting.

## Tabela decyzyjna

| Sytuacja | Co robi skill |
| --- | --- |
| Brakujący fakt jest w notatkach lub zadaniach | Agent go znajduje i nie pyta |
| Brak faktu nie zmienia decyzji | Agent zapisuje założenie w jednej linii i pracuje dalej |
| Brak faktu zmienia decyzję | Agent pyta na górze odpowiedzi, z opcjami i skutkiem |
| Pytanie wisi 8-14 dni | Agent nazywa, co blokuje, albo proponuje skreślenie |
| Pytanie wisi 15 dni lub dłużej | Agent daje dwie opcje: zrób albo skreśl, z rekomendacją |

## Czego potrzebujesz

### An AI coding agent: Claude Code, Codex CLI or Cursor

wymagane, aplikacja: https://code.claude.com/docs/en/overview

Skill to plik instrukcji w markdown. Potrzebujesz agenta, który go czyta i ma dostęp do Twoich plików.

1. Zainstaluj jednego agenta: Claude Code (https://code.claude.com/docs/en/overview), Codex CLI (https://developers.openai.com/codex/cli) albo Cursor (https://cursor.com/docs).
2. Otwórz agenta w folderze, w którym trzymasz notatki i dokumenty.
3. Zainstaluj skill według kroków z sekcji instalacji.

### GitHub CLI with GitHub Issues

opcjonalne, CLI, licencja MIT: https://cli.github.com/

Opcjonalny rejestr decyzji w publicznym narzędziu zamiast pliku DECISIONS.md. Plik markdown w zupełności wystarcza.

1. Zainstaluj gh ze strony cli.github.com i zaloguj się we własnym terminalu poleceniem gh auth login.
2. Utwórz etykietę decide w repozytorium: gh label create decide.
3. Nowe pytanie: gh issue create --label decide, z kluczem w tytule. Lista otwartych: gh issue list --label decide.
4. Wpisz do CONTEXT.md nazwę repozytorium i etykietę.

### 1Password CLI

opcjonalne, CLI, licencja proprietary: https://developer.1password.com/docs/cli/get-started/

Jedno z miejsc na klucze dostępu, które agent sprawdza, zanim Cię o klucz zapyta. Wybierz jedno miejsce, nie potrzebujesz wszystkich trzech.

1. Zainstaluj CLI według oficjalnego przewodnika.
2. Utwórz osobny sejf tylko z kluczami, których potrzebuje ten agent. Zwykłe logowanie na Twoje konto sięga do wszystkich Twoich sejfów, więc sam osobny sejf nic nie ogranicza.
3. Utwórz konto usługowe (service account) z dostępem do odczytu tylko tego jednego sejfu: https://developer.1password.com/docs/service-accounts/.
4. Sam wpisz token konta usługowego do środowiska powłoki agenta, pod nazwą zmiennej podaną w dokumentacji 1Password. Nigdy nie loguj tej powłoki na swoje osobiste konto i nigdy nie wklejaj tokenu do czatu.
5. Na komputerze agenta wyłącz integrację CLI w aplikacji 1Password albo nigdy nie zatwierdzaj prośby o dostęp, którą wywołał terminal agenta. Nigdy nie wypisuj tokenu konta usługowego.
6. Agent przekazuje klucz prosto do polecenia przez op run --env-file=agent.env -- <polecenie>, gdzie agent.env zawiera tylko odwołania op://sejf/wpis/pole, nigdy wartości. op run maskuje wartości, które rozwiązuje.
7. Wpisz do CONTEXT.md tylko nazwę sejfu.

### Bitwarden CLI

opcjonalne, CLI, licencja GPL-3.0 (CLI): https://bitwarden.com/help/cli/

Druga możliwość na klucze dostępu, jeśli używasz Bitwarden.

1. Zainstaluj CLI według oficjalnej dokumentacji.
2. Załóż osobne konto Bitwarden tylko z kluczami, których potrzebuje ten agent. Sesja CLI odszyfrowuje cały sejf konta, więc folder ani kolekcja na Twoim koncie niczego nie ograniczają. Zespoły mogą zamiast tego użyć CLI Bitwarden dla kont maszynowych (bws), ograniczonego do jednego projektu.
3. Zaloguj powłokę agenta tylko na to osobne konto, nigdy na swoje. Ustaw dla bw agenta osobny katalog danych (ustawienie katalogu danych aplikacji z dokumentacji Bitwarden CLI), żeby Twoje własne logowanie nigdy tam nie trafiło. Nigdy nie wypisuj klucza sesji.
4. Agent wstawia wartość prosto do polecenia w jednej linii: my_key="$(bw get password <wpis>)" <polecenie>, a polecenie czyta my_key ze swojego środowiska. Nigdy nie uruchamia samego bw get, które wypisuje wartość.
5. Ta forma niczego nie maskuje: nigdy nie uruchamiaj takiego polecenia z -v, --verbose, flagami debug lub trace, nigdy nie używaj set -x i nigdy nie wypisuj zmiennej.
6. Wpisz do CONTEXT.md tylko nazwę tego konta. Nigdy nie wklejaj klucza, tokenu ani hasła do czatu.

### A .env file listed in .gitignore

opcjonalne, środowisko: https://git-scm.com/docs/gitignore

Najprostsza możliwość: klucze projektu w lokalnym pliku .env, którego Git nigdy nie wysyła do repozytorium.

1. Utwórz osobny plik .env tylko z kluczami tego agenta i wpisz je sam, w edytorze.
2. Dodaj linię .env do pliku .gitignore, zanim zrobisz pierwszy commit.
3. Wpisz do CONTEXT.md tylko ścieżkę do pliku, nigdy wartości. Plik wczytuje narzędzie, które go potrzebuje. Agent nigdy nie wyświetla jego zawartości.

## Instalacja

1. Skopiuj folder skilla do .claude/skills/ask-and-push/ w projekcie albo do ~/.claude/skills/ask-and-push/ dla wszystkich projektów (Claude Code).
2. W Codex albo Cursor wklej treść SKILL.md do AGENTS.md w katalogu głównym repozytorium.
3. W innym agencie wklej SKILL.md do pliku instrukcji projektu albo do promptu systemowego.
4. Zmień nazwę CONTEXT.template.md na CONTEXT.md, zostaw obok SKILL.md i uzupełnij każde pole.
5. Jeśli nie używasz narzędzia do zadań, skopiuj DECISIONS.template.md jako DECISIONS.md i wpisz jego ścieżkę w CONTEXT.md.

## Działa, jeśli

- Gdy agent nie zna ważnego faktu, pytanie stoi na górze odpowiedzi i ma opcje do wyboru.
- Przy pytaniu agent wymienia miejsca, które przeszukał.
- Pytanie bez odpowiedzi ląduje w rejestrze jako nowy wiersz z kluczem, datą i polem blokuje.
- Poranny blok „decyzje czekają” ma najwyżej trzy pozycje, a starsze pokazują swój wiek.
- Przy każdej pozycji agent potrafi dokończyć zdanie o tym, w jakim źródle sprawdził, że sprawa jest otwarta.
- Po Twoim odłożeniu z datą pozycja znika z bloków do tego dnia.

## Wymagania

- Agent, który czyta plik instrukcji w Markdown (Claude Code, Codex, Cursor lub podobny).
- Dostęp agenta do Twoich notatek, zadań albo repozytorium, żeby mógł szukać przed pytaniem.
- Jedno miejsce na rejestr decyzji: narzędzie do zadań albo plik DECISIONS.md.
- Stały moment dnia, w którym czytasz podsumowanie od agenta.

## FAQ

### Czy agent nie zasypie mnie pytaniami?

Nie powinien. Pyta tylko po przeszukaniu źródeł i tylko o fakty, które zmieniają decyzję. Blok w podsumowaniu ma limit trzech pozycji, a reszta czeka w rejestrze.

### Co jeśli nie chcę teraz odpowiadać?

Odłóż pytanie z datą. Agent zapisze nową datę i powód, zegar startuje od nowa, a pozycja nie wróci przed tym dniem. Możesz też pytanie skreślić.

### Dlaczego po 15 dniach agent każe wybrać między zrób a skreśl?

Pytanie, które wisi dwa tygodnie, zwykle nikogo nie blokuje albo blokuje coś ważnego. Obie odpowiedzi zamykają temat, a dalsze przypominanie bez wyboru tylko zużywa Twoją uwagę.

### Czy potrzebuję narzędzia do zadań?

Nie. Plik DECISIONS.md z szablonu wystarczy. Ma kolumny na klucz, pytanie, daty, blokowaną rzecz, opcje, status i datę ostatniego przypomnienia.

### Po co sprawdzać źródło przed przypomnieniem?

Sprawa mogła się rozwiązać bez zamknięcia pozycji w rejestrze. Przypomnienie o czymś już załatwionym uczy Cię ignorować cały blok.

## Gdzie to pasuje

Skill działa obok szablonu clarify-before-acting: tamten pilnuje startu ryzykownej pracy, ten pilnuje brakujących faktów w trakcie i po pracy oraz eskaluje pytania bez odpowiedzi. Z szablonem orkiestratora łączy się przez regułę, że podagenci pytają orkiestratora, a on zbiera pytania i przekazuje Tobie tylko te, których sam nie rozstrzygnie. Blok decyzji pasuje do każdego porannego lub wieczornego podsumowania.

## Źródła

- Claude Code docs: Skills: https://code.claude.com/docs/en/skills (dostęp 2026-09-22)
- OpenAI Codex: AGENTS.md guide: https://developers.openai.com/codex/guides/agents-md (dostęp 2026-09-22)
- Cursor docs: Rules: https://cursor.com/docs/context/rules (dostęp 2026-09-22)

## Pliki

### SKILL.md

Metoda: kiedy agent pyta, jak pyta, jak zapisuje otwarte pytania i jak je eskaluje według wieku.

Pobierz: https://dawidgac.com/pl/skills/otwarte-decyzje-ai-przypomina/files/SKILL.md

```markdown
---
name: ask-and-push
description: Turns every load-bearing unknown into an explicit question instead of a guess, files unanswered questions in a decision ledger, and escalates them on a fixed age ladder until they are answered, deferred or killed. Use it whenever a fact you cannot find would change a decision, and whenever you write a morning or evening summary for the person you work for.
---

# Ask when unknown, push when unanswered

Read `CONTEXT.md` next to this file before you start. It names the person you ask (the decider),
where you search, where open decisions live, and when the two daily surfaces run.

If `CONTEXT.md` is missing, or a field you need is still blank, do not guess it. Ask the decider
to fill it, in the language they write to you in, naming the field. For example, in English:
"Add where I should file open decisions: DECISIONS.md in this folder, or a GitHub repository and label."
In Polish: „Dodaj, gdzie mam zapisywać otwarte decyzje: plik DECISIONS.md w tym folderze albo repozytorium GitHub i etykieta.”

## Before you start / What you need

- **An AI coding agent (required).** Claude Code (https://code.claude.com/docs/en/overview),
  Codex CLI (https://developers.openai.com/codex/cli) or Cursor (https://cursor.com/docs),
  with read and write access to the folder that holds the ledger.
- **A decision ledger (required, nothing to install by default).** The `DECISIONS.template.md`
  that ships with this skill, copied to `DECISIONS.md`. If you prefer a public tracker, use
  GitHub Issues through the GitHub CLI (https://cli.github.com/, MIT licence): sign in with
  `gh auth login` in your own terminal, create a label with `gh label create decide`, file with
  `gh issue create --label decide` (key in the title), and list with `gh issue list --label decide`.
- **One place for access keys (optional, pick one).**
  1Password CLI (https://developer.1password.com/docs/cli/get-started/),
  Bitwarden CLI (https://bitwarden.com/help/cli/), or a `.env` file listed in `.gitignore`
  (https://git-scm.com/docs/gitignore). Write only the store's name or the file path in
  `CONTEXT.md`, never a value.

Give the agent its own scoped access, never your whole vault. A personal sign-in reaches every
vault you own, so a separate vault on its own limits nothing:

- 1Password: create a vault that holds only this agent's keys, then a service account with read
  access to that one vault (https://developer.1password.com/docs/service-accounts/). Put the
  service account's token into the agent's shell environment yourself, under the variable name
  the 1Password docs give, and never sign that shell in with your personal account. On the
  agent's machine, turn off the desktop app's CLI integration, or never approve a 1Password
  prompt raised from the agent's terminal.
- Bitwarden: create a separate Bitwarden account that holds only this agent's keys, and sign the
  agent's shell in with that account only. Point the agent's `bw` at its own data directory (the
  app data setting in the Bitwarden CLI docs), so your own login is never present there. Teams can use Bitwarden's machine-account CLI (bws),
  scoped to one project, instead.
- A `.env` file: a separate file that holds only this agent's keys, listed in `.gitignore`.

Never paste a key, token or password into the chat, and never print one. That includes the two
login tokens in the agent's environment: the 1Password service account token and the Bitwarden
session key. The agent passes a key
straight into the command that needs it:

- 1Password: `op run --env-file=agent.env -- <command>`, where `agent.env` holds only
  `op://vault/item/field` references, never values. `op run` masks the values it resolves.
- Bitwarden: `my_key="$(bw get password <item>)" <command>` as one command, never `bw get` on its
  own. The command reads `my_key` from its environment. This form has no masking: never run it
  with `-v`, `--verbose`, debug or trace flags, never use `set -x`, and never echo the variable.
- A `.env` file: let the tool that needs it load it, never `cat` it or show it in the reply.

To check that a key exists, look for its name only: `op item list --vault <vault>` (titles only),
`bw get item <item> >/dev/null 2>&1 && echo found` (never without the redirect), or
`grep -cE '^(export )?my_key=' .env`.

This skill fixes two failures with one root cause: treating "I don't know" as something to route
around instead of something to say.

- **The guess.** A missing fact gets filled with the most plausible value and shipped as if
  verified. When the fact concerns money, legal standing or a number the decider will
  repeat in public, a wrong plausible answer does more damage than no answer, because it looks
  verified.
- **The decay.** A question that does get asked lands in a list and sits there. A list nobody
  reads is storage, not escalation.

---

## PART 1: ASK

### 1. Search first, always

Never ask what searching would answer. Before any fact becomes a question, work through every
source listed under "Where to search" in `CONTEXT.md`: notes, the task tracker, logs, the
codebase, connected tools. Make at least three distinct search attempts. For a credential, check
every credential store listed in `CONTEXT.md` before raising it. If it is not there, ask the
decider where it lives or to provide it. Never print a credential value (check by name only, and
pass it into the command that needs it as shown in "Before you start"). Never invent a credential, and never store one in a
file, a ledger row or `CONTEXT.md`.

Only what survives the search may become a question. When you ask, name what you searched:
"Searched the notes folder, the tracker and the repo; the value is not recorded anywhere."

### 2. Sub-agents ask you, not the decider

If you orchestrate other agents, their questions come to you first. Answer them from the original
task prompt, the standing decisions in `CONTEXT.md`, or a source you can read. Only a question
that survives that pass goes to the decider, and it goes through you, grouped with the others,
never as a stream from each agent.

### 3. Is the fact load-bearing?

A fact is load-bearing if **any** of these holds:

| Test | Example |
|---|---|
| Getting it wrong changes a decision the decider would act on | which of two landing pages a promotion runs on |
| It is a number the decider would act on, repeat or publish | a conversion rate quoted in a newsletter |
| It is an unverifiable claim about their business, money, legal standing or compliance | which supplier invoice a refund belongs to |
| It selects between two or more materially different outputs | is this a supplier price-change notice or a customer apology email |
| Only their preference or authority can settle it | approve the default, or name the option to discuss |

If none holds, the gap is not load-bearing. State your assumption in one line and keep working.
Do not ask.

### 4. Banned substitutes

When a load-bearing fact is missing, each of these is a violation:

- A plausible value presented without a flag ("your list gets about a thousand opens per send").
- A silent assumption that never appears in your reply.
- `no data`, `TBD`, `unknown` or `n/a` sitting in a table cell or mid-report where the reader
  scrolls past it.
- Hedged prose that implies the fact while disclaiming it ("presumably around...", "likely the...").
- Deferring the question to a later session, a file or another agent instead of asking now.

### 5. How to ask

- **Placement.** Put the question at the top of the reply, or in the same paragraph as the
  conclusion it undermines. Never below the fold, never only inside a linked file.
- **Shape.** Binary or multiple choice beats open-ended: "The spring sale or the summer
  sale?" instead of "Which sale?"
- **Consequence named.** Every question says what it blocks or what you will assume without it:
  "Without this, the refund stays unmatched in the month-end check."
- **Rank, then ask the few that block most.** Order the open unknowns by what each one stops and
  raise only the top few (see `CONTEXT.md`, default 3). Everything below the line goes to the
  ledger, not into the reply.
- **Ask and keep working.** Unless the question truly blocks all progress, state your working
  assumption and carry on. The question and the work ship together.

### 6. Every unanswered ask becomes a ledger item

If a load-bearing question is not answered in the same session, file it in the decision ledger
named in `CONTEXT.md` before the session ends. The ledger can be any task list, an issue tracker
or the plain `DECISIONS.md` that ships with this skill. Each item carries:

- **key**: a stable, normalised identity for the underlying question, for example
  `ask:shop:checkout-provider`. Add a date only when the question itself is date-specific.
- **question**: one sentence, answerable as written.
- **opened**: the date you filed it.
- **origin date**: the date the question first arose, if earlier than `opened`.
- **blocks**: the concrete thing waiting on the answer (a task ID, a file, a named deliverable).
- **options**: the choices, with your recommendation marked.
- **status**: `decide`, `scheduled` (deferred), `done` or `dropped`.
- **deferred until**: for a `scheduled` item, the date it may be raised again. Empty otherwise.
- **last pushed**: the date and surface where you last raised it.

Before filing, search the ledger for both the key and the question text. One question, one row.

An unknown that is asked and then dropped is the same failure as never asking.

---

## PART 2: PUSH

### 7. The age ladder

Compute age from the item's `opened` date, unless the item's `origin date` (or its text) names an
earlier date. The older date sets the band. A re-filed item otherwise looks younger than it is.

| Age | Band | Treatment |
|---|---|---|
| 0-3 days | **Listed** | One line in the decision block. No commentary. |
| 4-7 days | **Re-raised** | Named with its age: "Open 5 days." Stated as still waiting, not re-explained. |
| 8-14 days | **Blocking-named** | Placed above younger items and must name the concrete thing it blocks. If nothing is blocked, that is the finding: propose dropping it. |
| 15+ days | **Forced disposition** | "Kill it or do it." Exactly two options and a recommendation, repeated at the top of both daily surfaces until it leaves `decide`. |

From day 8, "still open" is not a push. A push says what stopped moving because the answer is
missing. If you cannot name a downstream item, write: "Nothing is waiting on this. Drop it?"

### 8. Critical incidents bypass age

An item marked as a critical incident (the marker is defined in `CONTEXT.md`, for example
severity set to critical plus an incident label) is pushed from day 0, ahead of the age ladder.
Lead with containment status, then the exact decision the decider has to make now. A scary word
in the title does not make an incident; only the marker does. Keep critical incidents to at most
two slots per surface.

### 9. Two surfaces, every day

Run the ladder on two surfaces, at the times in `CONTEXT.md`:

- **Morning summary.** Sets the day's cycle. Pick the top items by band.
- **Evening summary.** Runs the ladder again but shows only items that became eligible today,
  items whose band advanced today, and every 15+ day item. Do not replay a younger, unchanged
  item already pushed that morning.

Update each item's `last pushed` field when you raise it.

---

## PART 3: ANTI-NAG GUARD

A channel that fires on everything gets tuned out, and then nothing gets pushed. This guard is
part of the method, not a softening of it.

### 10. Cap and shape

- **At most 3 items per surface** (morning, evening, and per working session outside them). The
  ladder selects; it never enumerates the whole ledger.
- **Selection order:** critical incidents, then 15+, then 8-14, then 4-7, then 0-3. Within a
  band, oldest first. Spread across areas when two items tie.
- **One labelled block.** Render the selected items in one block titled "decisions waiting",
  each with its area visible. Do not scatter pushes through a reply or re-argue them mid-answer.
  One block, then back to the work.
- For a full audit, list the whole ledger, but label it as diagnostic and never let that list
  feed a push surface or update `last pushed`.

### 11. Deferral and kill are real answers

- **Deferral.** When the decider says "not now", set status `scheduled`, record the new date in `deferred until` and
  the reason. The clock resets. Never push a deferred item before its date. Deferring must cost
  the decider less than ignoring you, or they will ignore you.
- **Kill.** Set status `dropped` with a one-line reason. A dropped decision is closed, not failed.
- **Answered.** Set status `done`, record the answer, and act on it.

### 12. Verify before you push

Never push an item without checking that it is still open against its source of truth. An item
can sit open for weeks after the underlying reality changed, because nobody closed it. Pushing a
stale item is the fastest way to lose the decider's trust.

Before you raise any item, you must be able to complete this sentence:

> "I verified this is still open by reading [source] which showed [evidence]."

If you cannot complete it, search first. If the reality already changed, close the item instead
of pushing it.

| Item type | Source of truth | Check |
|---|---|---|
| Follow-up with a person (client, customer, candidate) | Their record in your customer database or notes | Read the current status field |
| Link, page or account issue | The live link or the settings page | Open it; confirm it is still broken |
| Install or setup task | The target machine or project | An existence check on the path, package or service |
| Travel, booking or appointment | The booking itself or the calendar | Confirm the date and status |
| Deploy, migration or release | The repository or release log | Look for the commit, tag or release entry |
| Metric (revenue, signups, stock) | The raw data file or the analytics tool | Read the raw rows, never a summary written by an earlier session |
| Any ledger item | The ledger plus recent session notes | Confirm no later note already closed it |

When you check a raw data file, confirm its layout and the date span it covers before you read
a number from it.

---

## Does NOT fire on

- Lookups and status checks the search can answer.
- Gaps that are not load-bearing: state the assumption and move on.
- Creative latitude the decider granted ("use your judgment", "any approach is fine"): do not ask, but open your
  reply with the assumptions you made.
- Questions a specialist agent scopes for itself.
- A fact already established earlier in the session.

## Relationship to a clarify-first rule

A clarify-first rule is a gate before you start risky work. This skill fires whenever a
load-bearing fact is missing, including mid-work and after delivery, and adds the escalation loop
a pre-action gate lacks. An instruction like "just do it" suppresses clarifying questions, not
disclosure: you still state your assumptions.
```

### CONTEXT.template.md

Twoje dane: kto decyduje, gdzie agent szuka, gdzie leży rejestr decyzji i o której są podsumowania.

Pobierz: https://dawidgac.com/pl/skills/otwarte-decyzje-ai-przypomina/files/CONTEXT.template.md

```markdown
# Ask and push: context

Copy this file to CONTEXT.md next to SKILL.md and fill in every blank. The agent asks you for any blank it needs. Never put passwords, access keys or card numbers here.

## Decider
(Who answers the questions: a role or first name, and how they prefer to be asked.)
Example: The studio owner. Prefers multiple choice, one line per option.

## Where to search before asking
(Every place a fact might already live. The agent works through all of them before asking.)
Example: notes/ folder, the issue tracker, the project README, the shared drive "Ops" folder, the analytics dashboard.

## Credential stores
(Where credentials are kept, so the agent looks there instead of asking. Name the store, never the value.)
Example: the 1Password vault "agent-keys" (service account) or a separate Bitwarden account; the project's .env file, listed in .gitignore.

## Decision ledger
(Where unanswered questions are filed: a tracker project, a label, or the path to DECISIONS.md.)
Example: DECISIONS.md in the repository root. Or: GitHub Issues in the repository "your-org/ops", label "decide".

## Stable key format
(How keys are built so the same question is never filed twice.)
Example: ask:<area>:<short-question-slug>, e.g. ask:billing:annual-plan-discount

## Areas
(The areas an item can belong to, used for spreading the daily block.)
Example: product, billing, marketing, hiring, personal

## Critical incident marker
(What makes an item a critical incident that bypasses the age ladder.)
Example: severity = critical and label = incident

## Daily surfaces
(When the morning and evening summaries run, and where they appear.)
Example: Morning at 08:00 in the daily standup note; evening at 18:00 in the end-of-day note.

## Cap per surface
(Maximum decision items per surface. Default 3.)
Example: 3

## Standing decisions
(Answers the decider has already given that sub-agents' questions can be settled against.)
Example: Always use the existing email provider; never discount below the listed floor price without asking.

## Source of truth per item type
(Override or extend the verification table in SKILL.md with your real sources.)
Example: Client follow-ups: the contact record in the customer database. Deploys: the release list in the repository.
```

### DECISIONS.template.md

Prosty rejestr decyzji w Markdown dla osób bez narzędzia do zadań.

Pobierz: https://dawidgac.com/pl/skills/otwarte-decyzje-ai-przypomina/files/DECISIONS.template.md

```markdown
# Decisions ledger

Copy this file to DECISIONS.md (or the path named in CONTEXT.md). One row per open question. Search the key and the question text before adding a row.

Status values: decide · scheduled (deferred, date in "deferred until") · done · dropped.
Age uses the older of "opened" and "origin date". Bands: 0-3 listed · 4-7 re-raised · 8-14 blocking-named · 15+ kill it or do it.

<!-- Example row, not a real item. Never push it. Copy its shape into the table below.
| key | question | opened | origin date | blocks | options (recommended marked *) | status | deferred until | last pushed |
|---|---|---|---|---|---|---|---|---|
| ask:shop:returns-window | Keep the returns window at the current length or extend it for the holiday season? | YYYY-MM-DD | | Holiday returns page copy | *keep · extend | decide | | YYYY-MM-DD morning |
-->

| key | question | opened | origin date | blocks | options (recommended marked *) | status | deferred until | last pushed |
|---|---|---|---|---|---|---|---|---|

## Closed

| key | answer or reason | closed | status |
|---|---|---|---|
```