Pilog

about this project

A journal built for the work, not the workflow.

Pilog is a quiet markdown scratchpad on a global hotkey and a local inbox that turns rough notes into repo-aware GitHub issue drafts. Capture fast. Draft when you have a moment.

01 — the story

The idea came from a familiar frustration. You are in the middle of something focused and you notice a bug, a gap, a thing worth fixing. Stopping to file a GitHub issue means switching context, loading a browser tab, and filling in fields when you just want to write one sentence. So the thought gets lost.

Pilog’s answer is a global hotkey scratchpad. Open it, write the note in plain markdown, save, and the window disappears. No required fields. No repo selector. No form. Just the note.

The inbox is the other half. When you have a moment, select the notes you want to work through and let the draft generator read them alongside your active repository. It groups related notes, names affected files, and writes structured issue drafts you can review before anything is published.

Your journal stays on your machine. Draft generation follows your Pi provider: local with Ollama, remote with a cloud API. Only the draft you publish goes to GitHub, and only when you say so.

02 — principles

  1. Capture before triage.

    The scratchpad is a sanctuary, not a form. No chrome competes with the writing. Required fields, label pickers, and repo selectors live elsewhere or are deferred until triage. The first beat of the experience is just typing.

  2. Show the source, always.

    Every generated draft is anchored visibly to its source notes and a short, user-facing reasoning summary. Confidence is named, rationale is concise, and source notes are never collapsed behind an expander by default.

  3. Local-first is a stance, not a fallback.

    Notes, drafts, repo metadata, and agent run history live in local SQLite. Secrets live in your OS keychain. Draft generation stays local only when you configure a local Pi model; otherwise Generate sends bounded context to your chosen API. Publishing is always explicit. The product makes each boundary obvious.

  4. Restraint over reflex.

    When the easy answer is "add another card," "open a modal," or "add a gradient," it is usually the wrong answer. The product earns weight through typography, rhythm, and considered surfaces. Density comes from signal, never from chrome.

  5. Keyboard-first, mouse-welcome.

    Every triage and review action has a shortcut; the mouse is a courtesy, not the primary path. The hotkey-driven scratchpad is the product's defining gesture, and that posture propagates through every surface.

03 — contributing

Open source, openly maintained.

Pilog lives on GitHub. The codebase, the issues, and the roadmap are all public. Contributions of any size are welcome.

  • Bug report

    Something broken or behaving unexpectedly? Open an issue on GitHub. The more detail the better: what you were doing, what you expected, what happened instead.

  • Feature request

    Have an idea that fits the product's direction? Open a discussion or issue. Explaining the problem you're trying to solve helps more than pitching a solution.

  • Pull request

    Fork the repo, run pnpm install and pnpm dev to get started. For anything beyond a small fix, open an issue first so we can align on scope before you put in the work.

  • Docs

    Spotted something unclear or missing in the documentation? A short PR fixing a doc is a meaningful contribution.

04 — made by

Nick Neely, a developer who got tired of losing good notes.