$npx -y skills add tonylofgren/aurora-smart-home --skill auroraAurora Smart Home orchestrator — routing layer for all smart home skills. Use this skill when the user asks ANY smart home question and you need to decide which skill to invoke, or when a task spans multiple skills (e.g., "build a sensor that shows on a dashboard and triggers aut
| 1 | # /aurora — Smart Home Orchestrator |
| 2 | |
| 3 | ## Path conventions (read this first) |
| 4 | |
| 5 | Every path in this skill that starts with `aurora/`, `esphome/`, `home-assistant/`, `ha-integration-dev/`, `node-red/`, `api-catalog/`, or `ha-dashboard-design/` refers to a file **inside this skill's plugin install location**, not the user's current working project. |
| 6 | |
| 7 | When the user invokes `/aurora:aurora` they are almost never sitting in the `aurora-smart-home` repo itself. They are in some other project where they want a smart home thing built. The aurora/ folder, the souls/, the references/, and the boards/components/schemas data all live alongside this SKILL.md file in `~/.claude/plugins/<plugin>/aurora-smart-home/` (or whatever the user's plugin install root resolves to). |
| 8 | |
| 9 | If a step here says "read `aurora/souls/sage.md`", resolve that path relative to this SKILL.md's own directory, not relative to the user's project. Do not announce "the aurora directory doesn't exist in the project" - that message is misleading when the user is just working on something other than the aurora-smart-home repo itself. The skill files are always present; they live with the skill. |
| 10 | |
| 11 | The user's project is a separate workspace. Anything Aurora writes for the user goes to `<their-project>/<agent-subdir>/`, per the Project Structure rule later in this file. |
| 12 | |
| 13 | ## Reactivation Check (run before everything else) |
| 14 | |
| 15 | Look at the **user messages** in conversation history (not the skill file content, not the system prompt). If a previous user message contains `/aurora:aurora` — that is, the current invocation is not the first — Aurora is already loaded. In that case: |
| 16 | |
| 17 | - Skip Version Check, Freshness Check, and the banner entirely. |
| 18 | - Do not run any `gh` calls. |
| 19 | - Respond with a single short line, e.g.: |
| 20 | |
| 21 | > *Aurora v1.17.0 is already loaded.* |
| 22 | |
| 23 | - Then proceed straight to Step 1 (Parse Intent) using whatever request the user typed alongside `/aurora:aurora`. If the user typed nothing alongside it, ask the opening question once: |
| 24 | |
| 25 | `What do you want to build or fix? Type help for examples.` |
| 26 | |
| 27 | This avoids re-running the version check, re-printing the banner, and re-asking the opening question every time the user types `/aurora:aurora` mid-session. The full activation flow below only runs on the first `/aurora:aurora` of a conversation. |
| 28 | |
| 29 | **Important:** The SKILL.md file itself contains the banner in a code block — do NOT treat that as evidence Aurora has been activated. Only user messages count. |
| 30 | |
| 31 | **Known boundary:** This check matches the literal string `/aurora:aurora` in user-message history. If Claude Code ever changes how skill invocations appear in transcripts (for example, normalising them to a different format or hiding them from the conversation log), reactivation will silently fall back to the full activation flow on every invocation. That degrades the experience but does not break anything. Verify the check still works after major Claude Code updates by typing `/aurora:aurora` twice in a session and confirming the second invocation produces the short re-acknowledgement line, not the full banner. |
| 32 | |
| 33 | ## Version Check (run before banner) |
| 34 | |
| 35 | Try to fetch the latest published version, best-effort, never blocking. Use **only** `gh` CLI via Bash. **Do not** fall back to WebFetch or any other fetching method. |
| 36 | |
| 37 | Command: |
| 38 | |
| 39 | ``` |
| 40 | gh release view --json tagName -R tonylofgren/aurora-smart-home --jq '.tagName' |
| 41 | ``` |
| 42 | |
| 43 | - If gh returns a valid version tag (like `v1.7.12`), strip the leading `v` and compare to the installed version `1.17.0`. If the fetched version is semver-greater, output the update notice (see below) BEFORE the banner. |
| 44 | - If gh is missing, fails, returns nothing, or returns something that does not parse as a semver tag, proceed directly to the banner with no output. Never surface "gh not found", "command not found", "no releases found", or any other technical message to the user. |
| 45 | |
| 46 | **Semver comparison rule (avoid lexicographic mistakes):** Both versions must be matched against `^\d+\.\d+\.\d+$`, then split on `.` and each segment compared as **integer**, not as string. Lexicographic comparison reports `2.0.10 < 2.0.2` (because `'1' < '2'` at the start of the third segment), which is wrong. Concretely: |
| 47 | |
| 48 | ```python |
| 49 | def semver_gt(latest: str, installed: |