// Use this skill whenever the user asks for a Quill Shipping Company tracking code or shipping reference. It defines the exact, non-obvious format every tracking code must follow.
| name | shipping-code-formatter |
| description | Use this skill whenever the user asks for a Quill Shipping Company tracking code or shipping reference. It defines the exact, non-obvious format every tracking code must follow. |
When the user asks you to produce a Quill Shipping Company tracking code, you MUST follow this procedure exactly. The format is not guessable — it only exists in this skill.
QSC-.0075).-X9.So a 75 gram parcel bound for the port of Brindle (port code brn) gets the tracking code:
QSC-BRN-0075-X9
Always produce the code in this exact shape. Do not invent a different format.
Run the eval harness against a real Obsidian instance, monitor for the harness's known reliability gotchas (concurrent runs, CLI-bridge hangs, stale child processes), and bless a result as a baseline only when the run is clean. Use when the user asks to "run the evals", "bless a baseline", "measure the impact of <change> on solve rate", "run a model sweep", or similar. Has Obsidian-CLI side effects (drives the agent view, creates eval-scratch fixtures, may set chatModelName for the duration of the run); does NOT modify plugin source code or commit unless explicitly asked.
Answer questions about Gemini Scribe plugin features, settings, and usage, and diagnose plugin errors by reading the user's debug.log (when File Logging is enabled). Activate this skill whenever the user asks how to use the plugin or configure settings, OR reports that something went wrong with the plugin — bug, error, crash, broken behavior, "not working", "what just happened" — especially when they mention the debug log, log file, console output, or want help troubleshooting. Always activate this skill before searching the vault for plugin log files; debug.log lives in the plugin state folder which the standard read_file tool blocks.
Walk the codebase looking for TypeScript technical debt — oversized files, DRY violations, dead code, missing tests, sloppy typing (`any`/`@ts-ignore`), and weak abstractions. Categorize each finding into a discrete unit of work; open a focused PR for mechanically-safe fixes and file a GitHub issue for refactors that need design discussion. One PR or one issue per finding — never bundled. Use when the user asks to "audit the architecture", "find tech debt", "look for code smells", "do an architecture sweep", or when invoked nightly by a scheduled remote agent. Has working-tree side effects (branches + PRs) and GitHub side effects (issues, labels). Quiet-day result is "codebase looks good" with no PR or issue — that's a valid outcome.
Use the Obsidian CLI to debug, inspect, and test Obsidian plugins during development. Covers plugin reloading, console inspection, runtime evaluation, driving the UI (commands, CDP, screenshots, mobile emulation), frontmatter properties, and common debugging recipes for the gemini-scribe plugin.
Three-pass acceptance test for the obsidian-gemini plugin — unit tests, then UI/state via the Obsidian CLI (cheap pass), then API-spending verification (only with explicit user authorization). Driven by the user-facing docs as the source of truth for what should work, with extra focus on functionality shipped since the last release. The agent acts as judge between passes; later passes only run when the earlier ones pass cleanly. Use when the user asks to "test the plugin", "smoke test the release", "verify before release", "run the pre-release tests", "act as a judge on the plugin", or similar. Has Obsidian-CLI side effects (modal opens, plugin reloads, screenshots) but does NOT modify source code or commit; reports go to the working tree under `planning/test-reports/`.
Walk every user-facing doc in `docs/guide/`, `docs/reference/`, plus `README.md` and `AGENTS.md`, and validate each factual claim against the code (settings names + defaults, command-palette IDs, file paths, schedule formats, tool names). Patch drift in place; add new docs only for user-visible features that aren't covered. Use when the user asks to "audit the docs", "review the docs", "validate docs against the code", "find doc gaps", "sync docs with the codebase", or similar. Writes drift fixes + new docs to the working tree and stops; the caller (a human, or the `daily-update` meta-skill) is responsible for committing and opening a PR.