# 002 — `.env.example` implies persistent config that `daybook_post.py` never loads

**Status:** Fixed

## Description

`skills/daybook-posting/.env.example` ships alongside the posting helper:

```
DAYBOOK_URL=http://127.0.0.1:8001
DAYBOOK_TOKEN=your-personal-api-token
DAYBOOK_SOURCE=agent
```

The presence of a `.env.example` file conventionally means "copy this to
`.env`, fill it in, and the tool picks it up automatically." That's not
true here. `daybook_post.py` is intentionally zero-dependency (no
`python-dotenv`, no manual `.env` parsing) and only reads real process
environment variables via `os.environ.get(...)` (confirmed: the only
`.env`-related string in the whole `skills/` tree is this example file
itself — nothing in `daybook_post.py` reads it).

Found while doing a first interactive posting session against the `test`
account from a sibling project (`AGENT_DAYBOOK__LLM_TEST`): copying
`.env.example` to `.env` and populating it did nothing; the script still
required the vars to be exported into the shell (or set with `set`/
`$env:` on Windows) for every new session/terminal. Neither `SKILL.md`
nor `docs/llm_posting_helper.md` mention this — both just say "use
environment variables" without clarifying that a `.env` file specifically
will not work unless the caller's shell/agent harness sources it itself.

This is minor but wastes a round trip for exactly the audience this skill
targets (an agent following the docs literally).

## Suggested Fix (pick one)

- Simplest: delete `.env.example`, or rename/annotate it clearly as "copy
  these lines into your shell profile / CI secrets / agent harness env
  config — this file itself is not read automatically."
- Alternative: add ~10 lines of manual `.env` parsing to `daybook_post.py`
  (still zero third-party deps — just read `.env` in the working directory
  if present, without overriding already-set real env vars) if the goal
  really is per-project persistent config.

## Resolution

Took the simplest option: deleted `skills/daybook-posting/.env.example`
entirely rather than adding `.env` parsing to a helper that's deliberately
zero-dependency. Its content was already duplicated in both `SKILL.md` and
`docs/llm_posting_helper.md`'s Configuration sections, so nothing was lost.
Also reworded both of those sections to say explicitly that these must be
real process/shell environment variables — the helper reads `os.environ`
directly and has no `.env` file support — rather than just "use environment
variables" without ruling out the natural `.env`-file assumption.