yolo/agent-skills
3
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/main' into reviews

Browse Source
This commit is contained in:
Miguel Palhas
2026-08-23 10:08:16 +01:00
parent dba8416192 f29d170702
commit f61371c74a
9 changed files with 129 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+18 -7
View File
@@ -17,7 +17,7 @@ nix/home.nix # home-manager module for NixOS machines
flake.nix # exposes homeModules.default
```
Skills are portable: only `name`+`description` frontmatter is required by any of the tools; Claude-only fields (`user-invocable`, `args`) are ignored elsewhere. Claude Code reads them from `~/.claude/skills`, Codex and Pi from `~/.agents/skills`, and opencode auto-loads both — so the two links cover all four. Cross-skill refs use root-relative paths (`tracker-common/COMMON.md`), so they resolve under either root.
Skills are portable: only `name`+`description` frontmatter is required by any of the tools; Claude-only fields (`user-invocable`, `args`) are ignored elsewhere. Claude Code reads them from `~/.claude/skills`, Pi from `~/.agents/skills`, Codex from `~/.codex/skills` (and only there — `~/.agents/skills` is invisible to it), and opencode auto-loads the first two. Cross-skill refs use root-relative paths (`tracker-common/COMMON.md`), so they resolve under either root.
Context files differ: Claude Code and Codex support `@file` imports, so their entry files import the shared fragments by path. Pi and opencode do not, so each gets a single `AGENTS.md` generated by concatenating the same fragments — on NixOS the home-manager module builds it in the store, elsewhere `bin/link.sh` writes it (idempotent; set `MACHINE=name` to pick a `claude-md/machines/` profile, default is `default`).
@@ -30,7 +30,7 @@ git clone https://git.naps.pt/yolo/agent-skills.git ~/tea/agent-skills
~/tea/agent-skills/bin/link.sh
```
Symlinks each skill into `~/.claude/skills/` and `~/.agents/skills/`, commands into `~/.claude/commands/` and `~/.config/opencode/commands/`, hooks into `~/.claude/hooks/`, `claude-md/` fragments into `~/.claude/`, and generates `~/.pi/agent/AGENTS.md` and `~/.config/opencode/AGENTS.md` from the fragments. Idempotent; any pre-existing real dir (or non-generated AGENTS.md) is moved to `~/.agent-skills-backup/` (outside the discovery path, so it isn't picked up as a duplicate skill). Re-run after adding a skill.
Symlinks each skill into `~/.claude/skills/`, `~/.agents/skills/` and `~/.codex/skills/`, commands into `~/.claude/commands/` and `~/.config/opencode/commands/`, hooks into `~/.claude/hooks/`, `claude-md/` fragments into `~/.claude/`, and generates `~/.pi/agent/AGENTS.md` and `~/.config/opencode/AGENTS.md` from the fragments. Idempotent; any pre-existing real dir (or non-generated AGENTS.md) is moved to `~/.agent-skills-backup/` (outside the discovery path, so it isn't picked up as a duplicate skill). Re-run after adding a skill.
Hooks still need one manual step: the `settings.json` snippet in `hooks/README.md`. Entry files are linked automatically — `entry/CLAUDE.md` and `entry/codex-AGENTS.md` hold the machine-local sections and `@import` the shared fragments, so both tools read the same rules with no copy and no drift.
@@ -247,14 +247,25 @@ Config from `bin/reviewer-config.example.json` to `~/.config/reviewer/config.jso
Secrets in `~/.config/reviewer/env`, never here:
```sh
REVIEWER_GITEA_TOKEN=... # read-only
REVIEWER_GITHUB_TOKEN=... # read-only
REVIEWER_GITEA_SECRET=... # webhook HMAC
REVIEWER_GITEA_TOKEN=... # read-only
REVIEWER_GITHUB_TOKEN=... # read-only
REVIEWER_GITEA_REVIEW_TOKEN=... # optional, write:issue — handed to review sessions
REVIEWER_GITEA_SECRET=... # webhook HMAC
REVIEWER_GITHUB_SECRET=...
```
The daemon's tokens are read-only — it never writes to a forge, which is also
why it doesn't mark notifications read.
The daemon's own tokens are read-only — it never writes to a forge, which is
also why it doesn't mark notifications read.
A review session is a different case: it has to post its findings, and the
sandbox denies it `~/.env.claude`, where `$GITEA_TOKEN` normally comes from.
Name a write-capable variable in a forge's `reviewTokenEnv` and the daemon
passes its value into the session as `$GITEA_TOKEN` (`$GH_TOKEN` on GitHub) —
through the generated Claude settings file (`env`) or codex profile
(`shell_environment_policy.set`), both written 0600. Leave `reviewTokenEnv`
out and nothing is injected; the session falls back to the forge's credential
helper, which is what it did before. Scope it to commenting: on Gitea that is
`write:issue`, and nothing else.
Claude review sessions need `bubblewrap` and `socat` on the box, or the sandbox
cannot start and the session refuses to run (`failIfUnavailable`). That is