Daily Note Key

This is a very simple Obsidian plugin: a ribbon button and a configurable keyboard shortcut that open one pre-selected note. That is all.

The note can be any Markdown note in the vault. I use this for my "today" note, which is always the same file (not to be confused with daily notes), hence the name.

Use

1. Enable Daily Note Key in Obsidian's Community plugins settings.
2. Open its settings and select Choose note. Search the vault's Markdown files and select the note to open. The stored path includes its folders.
3. In Obsidian's Hotkeys settings, find Daily Note Key: Open today note and assign a shortcut.
4. Open the note with that shortcut, the Open today note command, or the calendar icon in Obsidian's ribbon. The icon is also the in-app access route intended for iOS.

The selected path persists in plugin settings; Obsidian manages the hotkey. The settings reset control clears the selection. Back closes settings.

If no note is selected, or the selected path no longer exists, the ribbon icon shows a red warning triangle. Attempting to open it displays a notice. After moving or renaming the note, select it again: the plugin does not follow renames or create a replacement.

Installation and compatibility

Community-directory publication is in preparation. The intended platforms are macOS and iOS using current stable Obsidian versions. The minimum supported version and platform checks still need release validation.

For manual installation, place these repository files together in <vault>/.obsidian/plugins/today-note-custom-hotkey/:

• main.js
• manifest.json
• styles.css

Reload Obsidian and enable Daily Note Key under Community plugins. Installing again replaces these three files while retaining plugin settings. For a vault using a custom configuration directory, substitute that directory for .obsidian; the Bash installer below supports the default directory only.

Earlier local installations used ID daily-note-key-plugin. When moving to the new ID, disable the old installation first, enable the new installation, select the note again, and reassign its hotkey. The installer leaves the old directory and settings untouched; it does not migrate them.

Privacy

The plugin stores only the selected vault-relative note path in its settings. It lists Markdown file paths for selection and asks Obsidian to open the exact file. It does not read note contents, modify notes, contact external services, collect telemetry, or require an account.

Project documents

• Vision describes purpose, scope, constraints, and deferred product decisions.
• Architecture describes the Obsidian boundary, technology choices, data flows, and operational ownership.
• Foundation review records the self-review and project-owner sign-off.

Local installation

Run the installer from the project root. make install asks for the Obsidian vault root and copies the existing plugin artefacts into the vault's standard community-plugin directory.

make install

Use ./scripts/install.sh --dry-run to validate the vault path and preview the destination without copying files. The Bash installer is copy-only.

main.js is the maintained plain-JavaScript entry file; no compilation, Node.js, or npm installation is needed. With oxlint installed, make lint checks it.

The release files are the same three files listed above. make build validates that they are present and that manifest.json carries an x.y.z version.

Marketplace preparation is tracked in W002 - marketplace prep.

Releasing

Publish a release from a clean master that matches origin/master:

make release

The target runs make lint, validates the three plugin files, increments the manifest's patch version, commits it as chore: release <version>, pushes the commit and an annotated tag atomically, and creates the GitHub release with main.js, manifest.json, and styles.css attached. LICENSE remains in the repository. Use VERSION=x.y.z make release for a version other than the next patch, and ./scripts/release.sh --dry-run to see what would be published without changing anything. Full options are in Release help.

The release refuses to run when the branch is not master, the working tree is dirty, the local branch differs from origin/master, or the tag already exists.

Release attestations

The Attest release GitHub Actions workflow runs when a release is published. It checks out the release tag, verifies that the attachments are exactly the three installation files and that they match the tagged source byte for byte, then attests them. It cannot modify release attachments.

Manual dispatch accepts an existing release tag and performs the same verification and attestation.

The 1.0.1 manifest attachment was updated after tagging to correct its description. That release will fail the source comparison until the discrepancy is resolved; no attestation is claimed for it.

Licence

MIT. Copyright (c) 2026 Tadhg O'Brien.