docs: Add upgrade instructions to README - #80
Open
arnthorsnaer wants to merge 1 commit into
Open
Conversation
Add explicit upgrade workflow documenting the three-step process: 1. git pull (fetch latest changes) 2. make install (rebuild binary with updated embedded skill) 3. hey skill install (copy updated skill to ~/.agents/skills/hey/) The agent skill is embedded in the binary at build time, so users need to rebuild and reinstall after pulling updates to keep the skill in sync with the latest CLI version.
github-actions
Bot
added
the
documentation
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Pull request overview
Tip
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.
Adds explicit upgrade guidance to the project README so users understand they must rebuild the CLI binary and reinstall the embedded agent skill after pulling updates.
Changes:
- Add a new Upgrading section describing a 3-step update flow (
git pull,make install,hey skill install). - Document that the agent skill is embedded at build time and needs reinstalling to stay in sync with the binary.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+135
to
+139
| make install # rebuild binary with updated embedded skill | ||
| hey skill install # update agent skill to match new binary | ||
| ``` | ||
|
|
||
| The agent skill is embedded in the binary at build time, so all three steps are required to keep everything in sync. |
There was a problem hiding this comment.
The upgrade instructions call this an “agent skill”, but hey skill install is currently documented/implemented as Claude-specific and also creates a symlink under ~/.claude/skills/hey in addition to writing ~/.agents/skills/hey/SKILL.md. Consider clarifying this here (e.g., mention Claude explicitly and/or the two target locations) so users understand what gets updated when they rerun the command.
monorkin
added a commit
that referenced
this pull request
Aug 22, 2026
An ANSI slot's nominal value says nothing about what a reader sees. A theme retints the running terminal over OSC 4, so blue is #80 in the table and a light periwinkle on screen — and contrast measured against #80 put white text on it, which is why green and blue were the hard ones to make out. Omarchy's colors.toml has been answering this all along: background = "#060B1E" blue = "#7d82d9" green = "#92a593" red = "#ED5B5A" So Theme carries Background and Hues now, an event is filled with the theme's own value for its calendar's color, and the ink is whichever of the theme's paper or its text color contrasts better with that fill. Two colors the theme states, measured against each other. On a dark theme every hue arrives light and they all take the dark paper; on a light one the same hues arrive deep and the rule flips by itself, with nothing here asking which mode it is in. That is also why the light-mode blue was dark on dark. colorPaper came from theme.Dark, and a theme file's mode wins over the terminal's own report by design — so a light theme whose file says `mode = "dark"` got black ink on a light background. Reading `background` sidesteps the question. A terminal with no theme file still gets the ANSI slots and their nominal values, which is correct there: nothing retinted them.
monorkin
added a commit
that referenced
this pull request
Aug 22, 2026
An ANSI slot's nominal value says nothing about what a reader sees. A theme retints the running terminal over OSC 4, so blue is #80 in the table and a light periwinkle on screen — and contrast measured against #80 put white text on it, which is why green and blue were the hard ones to make out. Omarchy's colors.toml has been answering this all along: background = "#060B1E" blue = "#7d82d9" green = "#92a593" red = "#ED5B5A" So Theme carries Background and Hues now, an event is filled with the theme's own value for its calendar's color, and the ink is whichever of the theme's paper or its text color contrasts better with that fill. Two colors the theme states, measured against each other. On a dark theme every hue arrives light and they all take the dark paper; on a light one the same hues arrive deep and the rule flips by itself, with nothing here asking which mode it is in. That is also why the light-mode blue was dark on dark. colorPaper came from theme.Dark, and a theme file's mode wins over the terminal's own report by design — so a light theme whose file says `mode = "dark"` got black ink on a light background. Reading `background` sidesteps the question. A terminal with no theme file still gets the ANSI slots and their nominal values, which is correct there: nothing retinted them.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi! 👋
This PR suggests adding explicit upgrade instructions to the README to help users keep both the CLI and the embedded agent skill up to date.
Current situation:
make install) and the agent skill (hey skill install)make install) AND re-runhey skill installafter pulling updatesgit pullalone doesn't update itProposed change:
Add a new "Upgrading" section that documents the three-step process:
git pull(fetch latest changes)make install(rebuild binary with updated embedded skill)hey skill install(copy updated skill to~/.agents/skills/hey/)Note:
This is a suggestion to improve documentation clarity — feel free to close if you prefer a different approach or if this is already covered elsewhere. No pressure! Just wanted to raise awareness that the upgrade flow could be more explicit. 😊
Authored via OpenClaw agent 🦉
Summary by cubic
Adds an "Upgrading" section to the README that explains how to update
hey-cliand the embedded agent skill. Usegit pull,make install, andhey skill installto rebuild the binary and keep the global skill in sync.Written for commit 87862ab. Summary will update on new commits.