session-orchestrator 3.24.0 → 4.0.0

package/skills/contract-version-bump/SKILL.md

@@ -1,219 +0,0 @@
----
-name: contract-version-bump
-user-invocable: true
-tags: [contracts, versioning, schema, changelog, governance]
-model: sonnet
-model-preference: sonnet
-model-preference-codex: gpt-5.4-mini
-model-preference-cursor: claude-sonnet-4-6
-args-schema:
-  - flag: --contract <path>
-    description: "Path to the contract file being bumped (JSON Schema, API spec, config schema). Inferred from conversation context if omitted."
-description: >
-  Use this skill when changing a machine-readable contract — a JSON Schema, an API spec, or a
-  config schema — and bumping its version: tightening a constraint, adding/removing/renaming a
-  field, introducing a breaking change, raising an API version, or writing the changelog entry
-  for a schema change. Trigger on "change the schema", "tighten this constraint", "bump the
-  schema version", "breaking change to the API", "new API version", "changelog entry for a
-  schema change". Runs six phases — classify against the contract's OWN versioning rule (not
-  generic semver instinct), find every version literal and vendored copy, check consumer
-  compatibility for new keywords, apply consistently, write the changelog entry, and report
-  downstream drift — codifying three non-obvious traps hit in a real case (GitLab issue #17,
-  `aiat-enablement` repo, 2026-07-25).
----
-
-# Contract Version Bump
-
-> Project-instruction file resolution: `CLAUDE.md` and `AGENTS.md` (Codex CLI) are transparent
-> aliases — see [skills/_shared/instruction-file-resolution.md](../_shared/instruction-file-resolution.md).
-> Every reference to `CLAUDE.md` in this skill resolves via that precedence rule.
-
-A version bump on a machine-readable contract (JSON Schema, OpenAPI/API spec, config schema) is
-not just "increment the number." Three failure modes recur and are each individually
-non-obvious enough that a careful agent still misses them without a checklist: the contract's
-own versioning rule may not even cover the change you're making; version literals live in more
-places than you remember; and a schema keyword that no consumer evaluates is worse than no
-constraint at all, because it *looks* enforced. This skill runs six phases to close all three.
-
-**Reference case:** `aiat-enablement` repo, GitLab issue #17 (2026-07-25). A JSON Schema contract
-(`docs/spec/estate.schema.json`, draft/2020-12) had six fields tightened with new `pattern`
-constraints; `schema_version` moved `0.1.0` → `0.1.1`. All three traps below happened in that
-one change. Where cited, "the reference case" means this.
-
-## Phase 1: Classify against the CONTRACT'S OWN versioning rule
-
-Do not classify Patch/Minor/Major from generic semver instinct. Read the contract's own
-versioning-rules section (in its prose spec, README, or a `## Versioning` block near the schema)
-and ask explicitly: **does this rule even define the change class you're making?**
-
-```bash
-# Does the spec define rules for Patch changes at all? (substitute Minor/Major as needed)
-grep -n "^#.*[Vv]ersion" docs/spec/<contract>.md
-grep -c "Patch" docs/spec/<contract>.md
-```
-
-If the clause you need is missing, **authoring that clause is part of this change**, not a
-side quest — write it with an explicit justification for why the new class exists and why your
-change belongs in it, then proceed. If the clause exists but classifies your change as a stricter
-tier than you assumed (e.g. a "just tightening a pattern" edit is actually forbidden under an
-additive-only Minor rule), the rule wins — either recategorize the change or amend the rule
-first, but never bump the number past what the contract's own rule permits.
-
-Reference case: `docs/spec/estate-yaml-v0.md` defined only Minor (additive-only) and Major
-(needs a migration step). `grep -c "Patch" docs/spec/estate-yaml-v0.md` returned `0`. A
-constraint tightening is not additive, so under the existing rule alone it was forbidden. The
-Patch clause had to be authored — with a written justification (no production consumers yet
-validate against this vorproduktions-schema, so no migration burden exists) — before the bump
-was legitimate.
-
-## Phase 2: Find every version literal and copy — mechanically, not from memory
-
-Never trust "I updated it everywhere I remember." Grep for the literal.
-
-```bash
-# 1. Every occurrence of the current version string in this repo
-grep -rn "<current-version>" --include=*.json --include=*.md --include=*.yaml --include=*.yml .
-
-# 2. The field/key that carries the version, wherever it's mentioned in prose
-#    (field-catalog tables, example fixtures, README snippets)
-grep -rln "schema_version\|apiVersion\|<version-field-name>" docs/ examples/ 2>/dev/null
-
-# 3. Vendored copies in sibling repos — check every path under the instruction
-#    file's `cross-repos:` list. Match by basename, not by path: a vendored copy
-#    is rarely at an identical relative path.
-#    CLAUDE.md and AGENTS.md are transparent aliases — resolve whichever exists.
-INSTR=$([ -f CLAUDE.md ] && echo CLAUDE.md || echo AGENTS.md)
-for repo in $(yq '.["cross-repos"][]' "$INSTR" 2>/dev/null || grep -A20 '^cross-repos:' "$INSTR" | grep '  - ' | sed 's/^ *- *//'); do
-  find "$repo" -iname "$(basename <contract-file>)" 2>/dev/null
-done
-```
-
-For every location found, decide explicitly: **does it get bumped, or is it exempt?** Exemptions
-are legitimate (a dated SSOT snapshot like a PRD is allowed to stay frozen at the version it was
-approved under) but the exemption must be written down next to the literal that was skipped, or
-the next diff will read as silent divergence.
-
-Reference case: `schema_version` lived in five places — the schema file itself
-(`docs/spec/estate.schema.json`), the field-catalog table in the prose spec
-(`docs/spec/estate-yaml-v0.md`), an example fixture (`docs/spec/examples/estate.example.yaml`), a
-**vendored copy in a different repo** (`aiat-poc-infra/scripts/estate/estate.schema.json`), and
-the PRD (`docs/prd/2026-07-25-aiat-enablement.md`, Anhang D.1). The PRD was deliberately *not*
-bumped — but that decision was written into the spec's "Anmerkungen zu diesem Dokument" section
-explicitly, precisely so it would never be mistaken for an oversight.
-
-## Phase 3: Check consumer compatibility for every new/changed keyword
-
-For each keyword you are adding or changing (`pattern`, `maxLength`, `enum`, `format`,
-`additionalProperties`, a new required field, a new `apiVersion` value, …), find every known
-consumer of the contract and ask: **does this consumer actually evaluate this keyword, or does
-it silently ignore what it doesn't recognize?**
-
-- A full-featured library (ajv, `jsonschema`, an OpenAPI-generated client) generally implements
-  the standard vocabulary — trust it, but confirm the vocabulary/draft version matches (e.g. a
-  draft-07 validator will not enforce 2020-12-only keywords).
-- A hand-written parser/interpreter (a bash+heredoc validator, a custom regex-based checker, a
-  bespoke deserializer) is the risk case. Grep its source for the keyword name:
-
-```bash
-grep -n "maxLength\|minLength\|pattern\|format\|enum" <consumer-script-or-module>
-```
-
-If the keyword is absent from the consumer's implementation, you have three options — pick one
-and write it down, never leave it implicit:
-1. **Extend the consumer** to support the keyword (preferred when the consumer is yours to change).
-2. **Fold the constraint into a keyword the consumer already supports** (e.g. encode a length
-   limit inside a `pattern` instead of a separate `maxLength`).
-3. **Accept the gap and document it as a known limitation** in the spec, naming the consumer —
-   only when neither of the above is feasible right now.
-
-A constraint a consumer silently ignores is worse than no constraint: it looks enforced in the
-schema, so nobody double-checks the actual runtime behavior, and invalid data passes through
-undetected.
-
-Reference case: `maxLength: 63` was the natural way to express S3 bucket-name limits. The
-downstream validator (`aiat-poc-infra/scripts/estate/validate-estate-yaml.sh`) <!-- path-check: historical --> is a hand-written
-JSON-Schema mini-interpreter that does not implement `maxLength` — it would have parsed the
-schema, not recognized the keyword, and silently done nothing, so a 200-character bucket name
-would still validate green. Decision: extend the consumer (option 1) rather than relying only on
-the `pattern`'s implicit length ceiling — the `maxLength` branch was added to the interpreter in
-the same session, on branch `feature/estate-yaml-format-tightening-17`, and proven by a mutation
-test (disable the branch → the `[MAXLENGTH]` assertion goes red while `[PATTERN]` still fires).
-
-That mutation test is itself the lesson: because the bucket `pattern`
-(`^[a-z0-9][a-z0-9.-]{1,61}[a-z0-9]$`) already bounds total length via its quantifier, an
-over-length value trips BOTH rules. A fixture alone could not prove the new `maxLength` code was
-load-bearing — only disabling that code and watching the specific assertion fail could. When a
-new keyword overlaps an existing constraint, prove it in isolation or you have not proven it.
-
-## Phase 4: Apply consistently
-
-Bump the version literal and the constraint change together, everywhere Phase 2 found a
-non-exempt occurrence. For each exemption identified in Phase 2, write the reason next to it
-(a spec's "Anmerkungen"/decisions section, a code comment, a linked issue) — an exemption without
-a written reason is indistinguishable from a bug the next time someone diffs the two documents.
-
-## Phase 5: Write the changelog entry
-
-Follow [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) conventions already in use in
-this repo's `CHANGELOG.md` — add the entry under the repo's convention for in-progress work
-(commonly an `## [Unreleased]` section; check the top of the file for the existing pattern before
-inventing a new one). What goes in the entry depends on the classification from Phase 1:
-
-- **Patch (constraint tightening on an existing field):** name every field that changed, the old
-  constraint and the new one. **State explicitly that this can reject previously-valid documents
-  for consumers, even though the version number alone does not signal a breaking change** — the
-  version-number tier and the actual blast radius for a consumer are two different axes; do not
-  let the reader infer breaking-ness from the tier alone.
-- **Minor (additive field(s)):** name the new field(s) and confirm the change is additive-only —
-  no existing field's meaning, requiredness, or name changed.
-- **Major (breaking structural change):** name the field(s)/structure that changed and link the
-  migration step (e.g. `migrations/<contract>/`) a consumer must run.
-
-## Phase 6: Report downstream drift
-
-List every vendored copy or dependent repo found in Phase 2 that this change did **not** update.
-For each: name the repo/path, why it wasn't updated now (e.g. "follow-up MR pending, tracked
-separately"), and the tracking issue if one exists. Never let a known-stale copy pass silently —
-surface it as explicit follow-up work, even if fixing it is out of scope for this change.
-
----
-
-## Checklist
-
-- [ ] Read the contract's own versioning-rule section. Does it define the change class you're
-      making? If not, write the clause first (with justification), before touching the version.
-- [ ] Classify Patch / Minor / Major against that rule — not generic semver instinct.
-- [ ] `grep -rn` the current version literal across this repo (schema, prose spec, examples/fixtures).
-- [ ] Search every repo in the instruction file's `cross-repos:` list (`CLAUDE.md`, or `AGENTS.md`
-      on Codex CLI) for a vendored copy (basename match).
-- [ ] For every new/changed keyword, grep each known consumer's source for that keyword name.
-      Decide: extend / fold into a supported keyword / document the gap — pick one, write it down.
-- [ ] Apply the bump + constraint change to every non-exempt literal found in Phase 2.
-- [ ] Write the reason next to every exemption (a document deliberately NOT bumped).
-- [ ] Write the changelog entry — name the fields, old vs. new constraint, and call out breaking
-      risk for consumers explicitly, independent of the version tier.
-- [ ] List every dependent repo/copy left un-synced, with a tracking issue.
-
-## Anti-Patterns
-
-1. **Silent contract violation.** Bumping a version for a change class the contract's own rule
-   doesn't cover — or actively forbids — without amending the rule first. *Reference case:* the
-   spec defined only Minor (additive) and Major (needs migration); a constraint tightening isn't
-   additive, so it was forbidden under the existing rule until a Patch clause was authored with
-   an explicit justification.
-2. **Literal drift from memory.** Updating the version "everywhere I remember" instead of
-   grepping mechanically. *Reference case:* the version literal lived in five places, including a
-   vendored copy in a *different* repo (`aiat-poc-infra`) that a memory-based sweep would not
-   have found; one location (the PRD) was correctly left un-bumped, but only because that
-   exemption was written down explicitly instead of left silent.
-3. **Ignored keyword, worse than no keyword.** Adding a schema keyword without checking whether
-   every known consumer evaluates it. *Reference case:* `maxLength: 63` would have been silently
-   skipped by a hand-written validator that doesn't implement it — the schema would have *looked*
-   enforced while the runtime check let arbitrarily long values through.
-
-## When this does not apply
-
-Pure documentation-only edits to a contract (typo fixes, added examples, clarified descriptions)
-that change no validated field, constraint, or version-relevant semantics do not need a version
-bump or this skill — but if you're unsure whether a wording change is validation-relevant, treat
-it as a change and run Phase 1.

package/skills/daily/SKILL.md

@@ -1,222 +0,0 @@
----
-name: daily
-user-invocable: true
-tags: [vault, daily, obsidian, pkm]
-model: haiku
-model-preference: sonnet
-model-preference-codex: gpt-5.4-mini
-model-preference-cursor: claude-sonnet-4-6
-description: >
-  Use this skill when creating today's daily note in the Meta-Vault (03-daily/YYYY-MM-DD.md) with valid
-  vaultFrontmatterSchema-compliant YAML frontmatter. Idempotent: re-running on the
-  same day opens the existing note instead of overwriting. Use when starting a work
-  day, capturing scratch notes, or bootstrapping the inbox flow.
----
-
-# Daily Skill
-
-## Status
-
-IMPLEMENTED 2026-04-13.
-
-## Purpose
-
-Bootstraps today's daily note in the Meta-Vault so the user can start capturing
-thoughts, scratch work, and "done today" items without yak-shaving YAML
-frontmatter each morning. The daily note is the anchor of the PKM workflow: it
-is where the inbox flow starts, where daily momentum is tracked, and where
-evening reflections land. Every daily note carries the same frontmatter shape
-(validated by `vaultFrontmatterSchema`), which makes Dataview queries and the
-vault-sync validator trivial.
-
-## Prerequisites
-
-- Must be invoked from inside a Meta-Vault root (cwd contains `03-daily/`) OR
-  with `VAULT_DIR` resolved to the vault path (see Resolution Order below).
-- `03-daily/` must already exist — the skill fails fast if it does not.
-- `bash` + `sed` + `date` (always available on macOS/Linux).
-
-### VAULT_DIR Resolution Order
-
-1. `vault-integration.vault-dir` in Session Config (highest precedence)
-2. `VAULT_DIR` environment variable
-3. `$PWD` (fallback when neither is set)
-
-Claude must read Session Config and export `VAULT_DIR` before calling
-`generate.sh`. The canonical pattern (mirrors `session-end` and `evolve`):
-
-```bash
-CONFIG=$(cat .orchestrator/session-config.yaml | yq -o json)
-VM_DIR=$(echo "$CONFIG" | jq -r '."vault-integration"."vault-dir" // empty')
-: "${VM_DIR:=$VAULT_DIR}"
-VAULT_DIR="$VM_DIR" bash /path/to/skills/daily/generate.sh
-```
-
-`generate.sh` itself reads only `VAULT_DIR` (pure bash, no Config parser).
-
-## Algorithm
-
-1. **Resolve `VAULT_DIR`.** Check `vault-integration.vault-dir` in Session
-   Config first; fall back to the `VAULT_DIR` env var; then `$PWD`. The
-   config field takes precedence — see Prerequisites for the canonical
-   resolution snippet. `generate.sh` then validates: template exists (exit 2
-   if not), vault dir exists (exit 3 if not), `03-daily/` exists (exit 4 if
-   not).
-2. **Compute today's date.** `date +%Y-%m-%d` — ISO 8601 date-only, respecting
-   the system timezone (the user is in Vienna, so `Europe/Vienna` via system TZ).
-3. **Target path.** `$VAULT_DIR/03-daily/YYYY-MM-DD.md`.
-4. **Idempotency check.** If the target already exists, print
-   `Daily note already exists: <path>` and exit 0. Never overwrite.
-5. **Render template.** Read `templates/daily.md.tpl` (next to this SKILL.md)
-   and substitute `{{date}}`, `{{id}}`, `{{created}}`, `{{updated}}`,
-   `{{title}}`, `{{weekday}}` via `sed`. The template is literal markdown; the
-   only shell interpolation happens in the `sed` substitutions.
-6. **Write to target path.** Uses `sed … > "$TARGET.tmp" && mv "$TARGET.tmp"
-   "$TARGET"` to avoid leaving a half-written file on disk if sed fails.
-7. **Validate** (recommended but not automatic in `generate.sh`). Callers
-   should run the vault-sync validator over the vault in hard mode to confirm
-   schema compliance:
-   ```bash
-   VAULT_DIR="$VAULT_DIR" bash ../vault-sync/validator.sh --mode hard
-   ```
-   The BATS test suite runs this check on every run — see
-   `tests/daily.bats`. If validation ever fails, the template has drifted from
-   the canonical Zod schema; fix the template, do not downgrade the gate.
-8. **Print success.** `Created daily note: <path>` on stdout, exit 0.
-
-## Implementation
-
-The deterministic path is implemented in `generate.sh` (pure bash). An
-LLM-driven fallback is unnecessary: daily-note creation is a 100%
-mechanical transform and a shell script is faster, cheaper, and more
-reliable than an LLM round-trip. Recommended invocation:
-
-```bash
-# Resolve vault dir from Session Config first, env var as fallback:
-CONFIG=$(cat .orchestrator/session-config.yaml | yq -o json)
-VM_DIR=$(echo "$CONFIG" | jq -r '."vault-integration"."vault-dir" // empty')
-: "${VM_DIR:=$VAULT_DIR}"
-VAULT_DIR="$VM_DIR" bash ~/Projects/session-orchestrator/skills/daily/generate.sh
-```
-
-Or, if `VAULT_DIR` is already set in the environment and Session Config has
-no `vault-integration.vault-dir` override:
-
-```bash
-VAULT_DIR=~/Projects/vault bash ~/Projects/session-orchestrator/skills/daily/generate.sh
-```
-
-Or, if the user's cwd is already the vault:
-
-```bash
-cd ~/Projects/vault && bash ~/Projects/session-orchestrator/skills/daily/generate.sh
-```
-
-## Template Placeholders
-
-| Placeholder   | Example            | Format                                                     |
-| ------------- | ------------------ | ---------------------------------------------------------- |
-| `{{date}}`    | `2026-04-13`       | ISO 8601 date (`YYYY-MM-DD`), also used inside the `id`    |
-| `{{created}}` | `2026-04-13`       | ISO 8601 date (`YYYY-MM-DD`) — matches `isoDateRegex`      |
-| `{{updated}}` | `2026-04-13`       | ISO 8601 date (`YYYY-MM-DD`) — matches `isoDateRegex`      |
-| `{{title}}`   | `Daily 2026-04-13` | Human-readable heading, `Daily YYYY-MM-DD`                 |
-| `{{weekday}}` | `Montag`           | Full German weekday name (lookup table keyed on `date +%u`) |
-
-Note: `{{id}}` is **not** a separate placeholder — the template inlines
-`id: daily-{{date}}` so there is only one date substitution. This keeps
-template rendering to a single `sed` pass and prevents drift between `id`
-and filename.
-
-The German weekday is computed via a hardcoded lookup (1=Montag,
-2=Dienstag, ..., 7=Sonntag) rather than `LC_TIME=de_DE.UTF-8 date +%A`
-because not every macOS install has the `de_DE.UTF-8` locale compiled.
-
-## Integration with vault-sync
-
-The template **must** stay in sync with `vaultFrontmatterSchema`. The canonical
-schema lives at:
-
-```
-~/Projects/projects-baseline/packages/zod-schemas/src/vault-frontmatter.ts
-```
-
-Required fields produced by the template: `id`, `type`, `created`, `updated`.
-Optional-but-useful fields: `title`, `tags`, `status`. The `type` is hardcoded
-to `daily` (one of the valid values in `vaultNoteTypeSchema`). The `id` is
-`daily-YYYY-MM-DD` which is kebab-case and 16 chars — passes
-`slugRegex.min(2).max(128)`.
-
-The BATS suite runs the vault-sync validator end-to-end (`bats tests/daily.bats`
-→ test 8), so any drift between the template and the schema breaks the build
-of this skill, not of the vault that consumes it.
-
-## Idempotency Guarantee
-
-Running `generate.sh` twice on the same day is a no-op when the existing
-file is valid:
-
-1. The first run creates `$VAULT_DIR/03-daily/YYYY-MM-DD.md`.
-2. The second run finds the file, confirms it is non-empty and starts with
-   `---\n` (valid YAML frontmatter opener), prints
-   `Daily note already exists: <path>`, and exits 0.
-
-If the existing file is 0 bytes or lacks the `---\n` opener (e.g. a previous
-run crashed between the `$TARGET.tmp` write and the `mv`), the corrupt file
-is removed and the note is re-created cleanly.
-
-The file is **never** re-rendered when intact. This matters because the user
-edits the daily note throughout the day (ticking checkboxes, filling in the
-Scratch section, etc.) and re-invoking `/daily` from anywhere — a later
-session, a different tool, a keybind — must not destroy that work.
-
-Verified by `tests/daily.bats` test 5: hash-compares the file before and after
-a second `generate.sh` invocation.
-
-## Anti-Patterns
-
-- **DO NOT overwrite existing daily notes.** Re-running `/daily` is routine;
-  losing the day's scratch notes is catastrophic. The idempotency check is
-  load-bearing.
-- **DO NOT hardcode the vault path.** `VAULT_DIR` is the contract. Hardcoding
-  `~/Projects/vault` breaks tests, breaks any future multi-vault setup, and
-  couples this skill to one user's machine.
-- **DO NOT skip the post-write validation step.** If the BATS suite stops
-  running the vault-sync validator, template drift will quietly ship invalid
-  frontmatter into the vault and only be caught at the next session-end gate.
-- **DO NOT use `LC_TIME` for the weekday.** The locale is not guaranteed to
-  exist. Use the hardcoded lookup table.
-- **DO NOT add `sed`-unsafe characters to the template.** The placeholders use
-  `|` as the sed delimiter; if you add a `|` to any substituted value, sed
-  will break. Keep substitutions plain.
-
-## Exit codes
-
-| Code | Meaning |
-|------|---------|
-| 0 | Success (created) or idempotent skip (already exists and valid) |
-| 1 | Unexpected runtime failure (`set -e` caught an unhandled error) |
-| 2 | Infra error: template file not found at `$SCRIPT_DIR/templates/daily.md.tpl` |
-| 3 | Config error: `VAULT_DIR` does not exist as a directory |
-| 4 | Vault structure error: `$VAULT_DIR/03-daily/` directory is missing |
-
-## Files
-
-- `SKILL.md` — this file.
-- `generate.sh` — the POSIX bash implementation of the algorithm above.
-- `templates/daily.md.tpl` — the daily-note template with `{{placeholder}}`
-  markers.
-- `tests/daily.bats` — 8 BATS test cases covering creation, substitution,
-  idempotency, missing-dir errors, and end-to-end schema validation via
-  vault-sync.
-
-## Testing
-
-From the skill directory:
-
-```bash
-bats tests/daily.bats
-```
-
-Expected: `8/8 passing`. Test 8 runs the vault-sync validator over a fixture
-vault that contains only the freshly-generated daily note, proving end-to-end
-schema compliance.

package/skills/daily/generate.sh

@@ -1,92 +0,0 @@
-#!/usr/bin/env bash
-# generate.sh — Create today's daily note in the Meta-Vault.
-#
-# Usage:
-#   bash generate.sh
-#   VAULT_DIR=/path/to/vault bash generate.sh
-#
-# Behavior:
-#   - Resolves VAULT_DIR from env, else $PWD. Must contain 03-daily/.
-#   - Computes today's date via `date +%Y-%m-%d` (Europe/Vienna via system TZ).
-#   - Target path: $VAULT_DIR/03-daily/YYYY-MM-DD.md
-#   - If target exists → idempotent no-op (exit 0).
-#   - Otherwise substitutes placeholders into templates/daily.md.tpl and writes.
-#
-# Exit codes:
-#   0 — created OR already-exists (idempotent)
-#   1 — unexpected runtime failure (set -e)
-#   2 — infra error: template file missing
-#   3 — config error: VAULT_DIR does not exist
-#   4 — vault structure error: 03-daily/ missing
-
-set -euo pipefail
-
-SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-TEMPLATE="${SCRIPT_DIR}/templates/daily.md.tpl"
-
-# ── Resolve VAULT_DIR ──────────────────────────────────────────────────────
-: "${VAULT_DIR:=$PWD}"
-
-if [[ ! -f "$TEMPLATE" ]]; then
-  echo "error: template not found: $TEMPLATE" >&2
-  exit 2
-fi
-
-if [[ ! -d "$VAULT_DIR" ]]; then
-  echo "error: VAULT_DIR does not exist: $VAULT_DIR" >&2
-  exit 3
-fi
-
-DAILY_DIR="$VAULT_DIR/03-daily"
-if [[ ! -d "$DAILY_DIR" ]]; then
-  echo "error: 03-daily/ not found in vault: $DAILY_DIR" >&2
-  echo "hint: run this skill from inside the Meta-Vault, or set VAULT_DIR." >&2
-  exit 4
-fi
-
-# ── Compute date / weekday ─────────────────────────────────────────────────
-DATE="$(date +%Y-%m-%d)"
-DOW="$(date +%u)"  # 1=Mon .. 7=Sun
-
-# Hardcoded German weekday lookup (locale-independent for reliability).
-case "$DOW" in
-  1) WEEKDAY="Montag" ;;
-  2) WEEKDAY="Dienstag" ;;
-  3) WEEKDAY="Mittwoch" ;;
-  4) WEEKDAY="Donnerstag" ;;
-  5) WEEKDAY="Freitag" ;;
-  6) WEEKDAY="Samstag" ;;
-  7) WEEKDAY="Sonntag" ;;
-  *) WEEKDAY="Unknown" ;;
-esac
-
-TARGET="$DAILY_DIR/${DATE}.md"
-
-# ── Idempotency check ──────────────────────────────────────────────────────
-if [[ -f "$TARGET" ]]; then
-  # corrupt file guard: 0-byte or missing YAML frontmatter opener → re-create
-  if [[ ! -s "$TARGET" ]] || [[ "$(head -c 3 "$TARGET")" != "---" ]]; then
-    rm -f "$TARGET"
-  else
-    echo "Daily note already exists: $TARGET"
-    exit 0
-  fi
-fi
-
-# ── Render template ────────────────────────────────────────────────────────
-TITLE="Daily ${DATE}"
-
-# sed substitution — placeholders are {{name}}, no shell interpolation in the
-# template, so this is safe with simple replacement.
-sed \
-  -e "s|{{date}}|${DATE}|g" \
-  -e "s|{{created}}|${DATE}|g" \
-  -e "s|{{updated}}|${DATE}|g" \
-  -e "s|{{title}}|${TITLE}|g" \
-  -e "s|{{weekday}}|${WEEKDAY}|g" \
-  "$TEMPLATE" > "$TARGET.tmp"
-
-mv "$TARGET.tmp" "$TARGET"
-
-echo "Created daily note: $TARGET"
-exit 0

package/skills/daily/templates/daily.md.tpl

@@ -1,36 +0,0 @@
----
-id: daily-{{date}}
-type: daily
-title: {{title}}
-created: {{created}}
-updated: {{updated}}
-tags:
-  - daily
-status: draft
----
-
-# {{title}} ({{weekday}})
-
-## Energie & Fokus
-
-- [ ]
-
-## Termine
-
--
-
-## Done heute
-
--
-
-## Scratch
-
--
-
-## Offen für morgen
-
--
-
-## Links
-
-- [[_MOC]]