wiki-keeper

name

wiki-keeper

description

Design and set up recurring knowledge-base update workflows for an Obsidian/LLM wiki or similar second-brain vault. Use for auto-update wiki setups, source monitoring/ingestion, daily reflection/reminder/status lanes, health checks, or cross-platform scheduler/runtime selection. Triggers on: auto-update wiki, maintain my vault, set up knowledge-base automation, recurring ingestion, nightly reflection, wiki health check, schedule wiki tasks, second-brain automation.

wiki-keeper: Automated Knowledge-Base Maintenance

Overview

Use this skill to turn a user's personal or team knowledge base into a maintained system: recurring source collection, candidate triage, object-level wiki writeback, health checks, summaries, reminders, and operations status.

The goal is not to copy one machine's automations. The goal is to interview the user, choose the right update lanes, create the minimum viable recurring tasks, and leave enough state and runbooks that future agents can continue safely.

Resource Map

Load only the reference files needed for the current phase:

• references/interview-and-selection.md: when starting with a new user, choosing sources, privacy boundaries, schedules, and the first automation bundle.
• references/control-plane.md: when designing state files, runbooks, compensation windows, ingest-run records, hot/log/index updates, and health gates.
• references/platform-scheduling.md: when choosing Codex heartbeat vs cron/worktree/local jobs vs Windows Task Scheduler/macOS launchd/Linux systemd/GitHub Actions.
• references/task-blueprints.md: when deciding what a concrete lane should do for chat, meetings, screen activity, web monitors, social content, reminders, daily reflection, health checks, and backups.
• references/templates-and-examples.md: when drafting the artifact shape: task cards, user confirmations, state files, runbooks, no-op records, blocked records, handoffs, and final prompts.
• references/validation-review.md: before finalizing, when blocked, or when you need independent review / forward testing.

Operating Principles

1. Start from the user's desired outcomes, not from available tools.
2. Separate knowledge update lanes from notification/reminder lanes.
3. Use compensation windows: every recurring task should resume from the last successful coverage point to the current trigger time, with overlap when useful.
4. Keep raw sources immutable when the vault has a .raw/ layer.
5. Write durable knowledge to object pages: people, projects, products, sources, concepts, risks, events, or decisions. Do not let daily run logs become the only knowledge store.
6. Record process evidence in run files: plan, run, review, health check, and state advancement.
7. Update shared entry points after meaningful changes: wiki/index.md, wiki/log.md, wiki/hot.md, and local equivalents.
8. Do not advance last_success_at after partial failure, missing review, failed health check, or unresolved pending queue.
9. Never copy private paths, user IDs, tokens, thread IDs, schedules, or platform accounts from another user's setup.
10. Explain every automation setting in plain language: what it does, why it exists, and what can go wrong if it is omitted.

Default Workflow

1. Restore Context

If the current project is an existing vault, read its local agent instructions first. For an Obsidian-style LLM wiki, prefer:

1. AGENTS.md / CODEX.md / equivalent agent instructions.
2. wiki/hot.md or the shortest recent context cache.
3. wiki/index.md only when you need the catalog.
4. Existing wiki/meta/*runbook*, wiki/meta/*state*, and automation memory.
5. Existing scheduler definitions, such as Codex automations, Task Scheduler jobs, cron files, launchd plists, systemd timers, or CI workflows.

If there is no vault yet, use the existing wiki/scaffold skill if available, or create only the minimal structure needed for the selected automations: wiki/, .raw/, wiki/meta/, wiki/index.md, wiki/log.md, wiki/hot.md.

2. Interview the User

Read references/interview-and-selection.md. Ask only the minimum high-impact questions first:

• What knowledge base should be maintained?
• Which sources should be automated now?
• Which sources or external actions are explicitly forbidden?
• Which operating system and always-on environment will run the tasks?
• Should tasks only update the wiki, or may they send notifications / create external actions?

After the first answers, propose a phased task list instead of asking every possible question. Ask for the seven-day success metric in the second round, after the user has seen the proposed lanes. Explain why each chosen task exists.

3. Design the Automation Bundle

Read references/control-plane.md and references/task-blueprints.md. For each selected lane define:

• lane_id: stable machine-readable name.
• purpose: what long-term knowledge problem it solves.
• source: APIs, local files, browser/session, manual inbox, or existing run outputs.
• frequency: schedule and rationale.
• state: where last_success_at, pending queue, and last successful run are stored.
• run artifacts: plan/run/review/log paths.
• writeback target: object pages and shared indexes.
• health gate: command or manual check.
• failure behavior: blocked vs no-op vs pending.
• notification behavior: none, IM, email, issue, task, or user prompt.

Prefer a small, working bundle over a large fragile one. A typical starter bundle is:

1. Core wiki health check.
2. Daily or nightly reflection / summary.
3. One high-value source lane.
4. Operations status panel.
5. Backup or git push.

4. Choose Scheduler

Read references/platform-scheduling.md.

Use a thread/heartbeat automation when continuity and accumulated conversation state matter. Use cron/local/worktree/scheduler jobs for independent checks, deterministic scripts, status panels, and backups.

Distinguish scheduler from executor. Windows Task Scheduler, launchd, cron, systemd, and CI are trigger mechanisms; they do not by themselves provide LLM judgment, source triage, or conversation continuity. If a lane requires semantic judgment and no deterministic script exists, choose an agent automation runtime or explicitly create a script/runner that calls the model.

If the Codex App automation tool is available, use it for creating/updating automations. Inspect existing automation definitions before creating duplicates. Preserve existing fields unless the user asks to change them.

If the app automation tool is not available, create scheduler-specific instructions or scripts for the user's system. Do not pretend an automation has been created when you only wrote documentation.

5. Create Runbooks and State

For every lane that will run more than once, create or update:

• A runbook explaining source access, workflow, writeback rules, health checks, and blocked recovery.
• A state file containing coverage cursor, overlap, pending queue status, last run, and known blockers.
• A run artifact folder or convention for dated plan/run/review files.
• A short operations status page if there are at least three lanes.

State and runbooks are not bureaucracy. They allow another agent to recover after sleep, reboot, context loss, token compaction, or a failed run.

6. Create the Automation Prompt

Every recurring task prompt should include:

1. Its real purpose.
2. Compensation rule: last_success_at - overlap -> trigger_start.
3. Startup files to read.
4. Source collection method.
5. Candidate ledger requirements.
6. Object-level writeback rules.
7. Review / validation requirements.
8. Health check.
9. State advancement conditions.
10. Notification and privacy boundaries.
11. Final report fields.

Use references/task-blueprints.md for concrete wording.

7. Verify Before Declaring Done

Read references/validation-review.md. At minimum:

• Inspect the created automation definitions.
• Run one dry-run or manual trigger for each deterministic script lane.
• Confirm state files are parseable and contain initial values.
• Confirm generated runbooks contain recovery steps.
• Confirm no private path or user ID from an example was copied.
• Confirm the user knows which tasks are active, paused, or only documented.

For high-risk or multi-source systems, run at least two independent reviews: one for configuration correctness and one for privacy/failure behavior.

Hard Boundaries

• Do not silently crawl broad personal files, browser history, chats, or cloud drives. Ask for explicit source scope.
• Do not turn reminders into tasks, calendar events, or outbound messages without explicit user confirmation.
• Do not send private knowledge into public social replies or public posts.
• Do not mark no-op by assumption. A no-op needs evidence: what was checked, which window, what changed or did not change.
• Do not advance state if the task did not actually cover the window.
• Do not use a date-only rule when the intended behavior is compensation from the last success cursor.
• Do not delete, merge, rename, or archive wiki pages automatically unless the runbook explicitly allows it and the risk is low.
• Do not make platform-specific promises. Windows, macOS, Linux, hosted runners, and Codex heartbeats have different persistence and permission models.

Final Response Checklist

When finishing setup or a design pass, report:

• Created or updated skill/runbook/state/automation files.
• Which lanes are active, paused, proposed, or unsupported.
• Scheduler used for each lane and why.
• Source permissions still needed.
• Verification commands and results.
• Known risks and the first recovery step.
• The next seven-day success metric.