skills/org-mode-syntax/SKILL.md
Write correct, idiomatic Org mode (vanilla) including denote-style optional frontmatter, agenda-aware tasks (TODO/STARTED/PAUSED/DONE, SCHEDULED/DEADLINE, repeaters, tags), and interactive executable Org Babel blocks (emacs-lisp, python, bash, sql) that produce in-buffer results. Use when asked to draft or transform .org files, planning/task documents, executable notes, or when Org syntax/agenda/Babel interactivity is needed instead of Markdown.
npx skillsauth add gregoryg/aipihkal org-mode-syntaxInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Operate as an Org author, not a Markdown author. Prefer Org-native constructs.
When drafting a new standalone note, optionally start with denote-style frontmatter:
#+title: …#+date: 2026-02-08 (YYYY-MM-DD)#+filetags: :tag1:tag2:
Only include this if the user is creating a new note/document (ask if unsure).When the user asks for plans, tasks, project tracking, or anything time-based:
SCHEDULED, DEADLINE).TODO, STARTED, PAUSED, DONE.:work:, :home:, :deep:).When computation, transformation, querying, or “let’s check” would help:
C-c C-c in the block).:results … and (often) :exports both so the document captures output as shared context.When a task subtree/phase is clearly complete and both user + LLM agree:
org-archive-subtree to reduce clutter.* Heading
** Subheading
*** Sub-subheading
*bold* /italic/ _underline_ +strike+ =verbatim=
[[https://www.example.com][This is the link description]]
[[file:references/org-mode-syntax-cheat-sheet-for-llms.org][File link to our Org Mode Cheatsheet]]
- item
- [ ] todo checkbox
- [X] done checkbox
- nested item
Org agenda primarily “sees” tasks via:
SCHEDULED/DEADLINE)** TODO Write proposal draft :work:writing:
SCHEDULED: <2026-02-10 Tue>
Use these when the state is meaningful to the user, not just the checkbox status.
** STARTED Implement parser :dev:
SCHEDULED: <2026-02-08 Sun>
** PAUSED Wait for API access :blocked:
SCHEDULED for “work on this on/after this date”.DEADLINE for “must be done by this date”.** TODO Submit expense report :admin:
DEADLINE: <2026-02-12 Thu>
** TODO Pay rent :home:
DEADLINE: <2026-03-01 Sun +1m>
:results verbatim when you want readable text/log output.:results value when you want a returned value (lists/tables).:exports both so the note shows code + results.When helpful, add a short instruction line:
C-c C-c.”If the user wants many executable blocks in one file, suggest:
#+property: header-args:bash :results verbatim :exports both
#+property: header-args:python :results verbatim :exports both
Also consider tangling when the user wants scripts checked into a repo or reused:
#+property: header-args:bash :shebang #!/usr/bin/env/bash :tangle ./scripts/example.sh
#+property: header-args:python :tangle ./scripts/example.py
These header-args properties affect all blocks of that language in the file.
#+begin_src emacs-lisp :results verbatim :exports both
(format-time-string "%Y-%m-%d")
#+end_src
#+begin_src python :results verbatim :exports both
import platform
print(platform.platform())
#+end_src
#+begin_src bash :results verbatim :exports both
pwd
ls -la
#+end_src
Assume the user has configured their SQL Babel engine(s). Prefer file-level header args for connection details.
Example (as Org content):
#+property: header-args:sql :engine postgres :dbhost protomolecule.magichome :database bartenders_friend :user lucille :dbport 31432
Then write SQL blocks like:
#+begin_src sql :results table :exports both
select now() as current_time;
#+end_src
Notes:
:results table when you want tabular output.| A | B |
|---+---|
| 1 | 2 |
#+TBLFM: $2=$1*2
Recalculate with C-c C-c on the #+TBLFM line.
When a subtree/phase is DONE and no longer needed in the active tracking context:
org-archive-subtree with point on the subtree headline.Rationale: keeps active PLANNING/TASK files (and shared LLM context) clean and reduces confusion over stale items.
references/org-mode-syntax-cheat-sheet-for-llms.org.tools
Write, review, and test Python code following PEP 8, type hints, and modern best practices (Python 3.12+). Use when writing, editing, debugging, or reviewing Python files. Enforces a mandatory verify-before-deliver rule - all written code must be tested for syntax and functionality using available shell tools before presenting to the user. Covers naming conventions, project layout, docstrings, formatting, and test authoring.
tools
Control and query Home Assistant via the hass-cli Python CLI. Use when Codex needs to interact with a Home Assistant instance for controlling devices (lights, switches, climate, covers, etc.), querying entity states or attributes, managing areas/devices/entities, calling services, checking system status, or any Home Assistant automation/control tasks. Supports JSON output for structured data.
tools
Write, review, and test Emacs Lisp code following idiomatic conventions and hard-won local best practices. Use when writing, editing, debugging, or reviewing .el files, Emacs packages, or gptel tools. Enforces a mandatory verify-before-deliver rule - all written code must be batch byte-compiled and smoke-tested before presenting to the user. Covers load-path management, buffer-local variable safety, HTML/XML parsing, file I/O patterns, and batch testing workflows.
testing
invoke multiple LLMs to gather different perspectives, review each other's outputs, and act as a council under the directorship of you the Council Head. Or more generally, call other LLM instances as agents to provide summaries without cluttering context.