diff --git a/modules/opencode/default.nix b/modules/opencode/default.nix index ea9cd61..551ea78 100644 --- a/modules/opencode/default.nix +++ b/modules/opencode/default.nix @@ -87,7 +87,15 @@ in enableMcpIntegration = cfg.enableMcp; commands = ./commands; agents = ./agents; - skills = ./skills; + skills = toString ( + pkgs.symlinkJoin { + name = "opencode-skills"; + paths = [ + ./skills + self'.packages.strands-agents-sops-skills + ]; + } + ); settings = { plugin = [ "@mohak34/opencode-notifier@0.2.8" ]; experimental = { diff --git a/modules/opencode/skills/prr/SKILL.md b/modules/opencode/skills/prr/SKILL.md deleted file mode 100644 index 53e01e7..0000000 --- a/modules/opencode/skills/prr/SKILL.md +++ /dev/null @@ -1,139 +0,0 @@ ---- -name: prr -description: Reference for the prr offline PR review file format. Covers comment types (PR-level, file, inline, spanned), snips, code suggestions, format constraints, common mistakes, and troubleshooting. Load when generating, validating, or editing a `.prr` file. The `review` skill loads this as needed. ---- - -# prr — File Format Reference - -A `.prr` file is a PR diff, quoted with `> `. Non-quoted text between quoted lines becomes a comment. File layout, top to bottom: - -1. Optional PR-level review comment (free text, before any `> ` content) -2. Optional `@prr` directive (`approve` | `comment` | `reject`) — **required for `prr submit`** -3. Quoted diff, with comments interleaved - -## Comment types - -**PR-level review comment** — free text at the very top of the file, before any `> ` content. You get exactly one. Use for overall feedback that doesn't attach to a line. - -**File comment** — non-quoted text immediately after the `> diff --git ...` header, before any `> index`/`> ---`/`> +++` lines. Attaches to the whole file. - -**Inline comment** — non-quoted text on the line(s) right after a `> ` diff line. Attaches to that single line. - -**Spanned inline comment** — like inline, but covers multiple lines. To **open** a span, insert a blank line before a `> ` line. To **close** it, follow the span with a non-quoted comment line. The blank line opens; the comment closes. - -**Snip** — `[...]` or `[..]` on its own line. Replaces contiguous `> ` lines from the diff. Use to focus the review file on what matters. - -## Code suggestions - -Inside any comment block, a fenced ` ```suggestion ` block renders as GitHub's "suggested change" button. Use to propose concrete edits: - -``` -> +old line - -How about: - -```suggestion -new line -``` - -> +next line -``` - -## Review directive - -Place near the top of the file, before any `> ` content: - -``` -Overall this is solid; a few nits below. - -@prr comment # or: approve, reject -``` - -Without one, `prr submit` errors. - -## Constraints - -- MUST preserve every `> ` line from the original diff verbatim. Only `[...]` may remove quoted content. -- MUST have a blank line between a `> ` line and its inline comment. -- A blank line before a `> ` line OPENS a span. Every open span MUST be closed by a non-quoted comment. -- A blank line between a comment and a `[...]` snip is **forbidden when more `> ` content follows** — the comment becomes stranded and the snip is misinterpreted. Put the snip directly after the comment (no blank line) or close the span differently. -- Snips (`[...]` or `[..]`) MUST be on their own line, between quoted sections. -- File comments go immediately after `> diff --git`, not after the `> index`/`> ---`/`> +++` lines. -- A PR-level review comment goes before any `> ` content and is the only non-quoted text outside inline/file comments. -- The `@prr` directive is required for `prr submit`. - -## Common Mistakes - -### Unterminated span - -A blank line before `> ` opens a span. Every span needs a non-quoted comment to close it. - -BAD — `[...]` is not a comment, so the span stays open and `prr` errors: - -``` -> +line - -> +next_line -[...] -``` - -GOOD — comment closes the span, then the snip is fine: - -``` -> +line - -> +next_line - -comment about both lines - -[...] -``` - -### Stranded comment - -A comment followed by a blank line followed by a snip followed by more `> ` content. The blank line before `[...]` makes prr treat the comment as still-open, and the snip can't resolve. - -BAD: - -``` -> +code - -my comment - -[...] -> +more_code -``` - -GOOD — snip tight against the comment, no blank line between them: - -``` -> +code - -my comment -[...] -> +more_code -``` - -### Missing directive - -If `prr submit` errors with "no review event", the file is missing `@prr approve|comment|reject` at the top. - -### Deleted diff lines - -The most common corruption. Hand-editing the file easily drops a `> ` line. Re-run `prr get --force` to start clean. - -## Vim - -The upstream `prr` repo ships a `vim/` plugin with syntax and folding for `*.prr`. Add `vim/` to runtimepath or use a plugin manager. Skip if the user doesn't use Vim. - -## Troubleshooting - -**"Failed to resolve snips"** — `[...]` is adjacent to content it can't snip. Make sure `[...]` is between quoted sections, not stranded after a comment block. - -**"Detected span that was not terminated"** — a blank line before `> ` created an open span. Add a closing comment after the span's last `> ` line, or remove the blank line. - -**"Detected corruption in quoted part"** — a `> ` line was modified or deleted. Re-download with `prr get --force`. - -**"no review event"** — the file is missing `@prr approve|comment|reject`. Add one at the top. - -**API 401** — token missing/invalid. Check `[prr] token` in `~/.config/prr/config.toml`, or `GH_TOKEN`/`GITHUB_TOKEN` env vars. diff --git a/modules/opencode/skills/review/SKILL.md b/modules/opencode/skills/review/SKILL.md deleted file mode 100644 index ce3fb00..0000000 --- a/modules/opencode/skills/review/SKILL.md +++ /dev/null @@ -1,30 +0,0 @@ ---- -name: review -description: Workflow for reviewing a GitHub PR offline using prr. Covers reading PR context, fetching the diff into a .prr file, supporting the user as they write inline comments in their editor, and validating the file. Use when the user wants to review a pull request, prepare a review, or run prr get/edit/status. Do NOT run prr submit — the user posts reviews themselves. Do NOT use for non-PR work (general codebase exploration, RFCs, etc.). ---- - -# Reviewing a Pull Request - -The user does the reading and writing in their editor. Your job is to fetch, validate, and hand off. The user runs `prr submit` themselves — you never post a review to GitHub. - -## Workflow - -1. **Read context** — pull the PR description, linked issues, and any prior review comments. Don't dive into the diff blind. -2. **Fetch the diff** — `prr get owner/repo/N` writes the review file to `workdir/owner/repo/N.prr` and prints the path. Confirm if the file exists; pass `--force` to overwrite. -3. **Open the file** — read it with the read tool, or have the user open it via `prr edit`. -4. **User writes feedback** — they type comments inline between the `> ` diff lines. Don't pre-fill unless asked. -5. **Validate** — read the file back. Check it against the `prr` skill's constraints. Fix obvious mistakes silently; flag anything ambiguous (e.g. an unterminated span the user might have meant to extend). -6. **Pick a directive** — `@prr approve` | `comment` | `reject`. Ask the user if it's not obvious from the comments. -7. **Hand off** — the user runs `prr submit owner/repo/N` themselves. Do not run submit. Once the file is validated and a directive is in place, print the submit command and stop. - -## What the user is doing - -The typical flow is: open the `.prr` file in their editor, write comments inline, edit some `> ` lines by mistake, ask the model to clean it up, add a directive, then run `prr submit` themselves. Be tolerant of formatting slips — fix the file rather than reject it. - -## If prr isn't installed - -Say so and point at https://doc.dxuuu.xyz/prr/ for installation. Don't try to substitute a different tool mid-flow. - -## See also - -- `prr` skill — file format reference (comment types, snips, constraints, common mistakes, troubleshooting) diff --git a/modules/opencode/skills/task-decomposition/SKILL.md b/modules/opencode/skills/task-decomposition/SKILL.md deleted file mode 100644 index d3c4866..0000000 --- a/modules/opencode/skills/task-decomposition/SKILL.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -name: task-decomposition -description: Breaks complex tasks into ordered sub-tasks with dependencies. Use when a task requires multiple implementation steps that cannot be expressed as a single delegation. ---- - -# Task Decomposition - -You are decomposing a task into executable sub-tasks. The goal is to produce a plan that a coordinator can execute step-by-step by delegating each sub-task to a specialist. - -## Input - -You MUST receive: -- The task description -- Relevant file paths -- Any constraints or decisions already made - -## Output Format - -Produce a plan as an ordered list of sub-tasks. Each sub-task MUST include: - -1. **Summary** — one sentence describing what this step accomplishes -2. **Subagent** — which specialist handles this step -3. **Dependencies** — which prior sub-tasks MUST complete before this one -4. **Files** — files the subagent will need to read or modify -5. **Acceptance criteria** — how to verify this step succeeded - -## Decomposition Rules - -- Each sub-task MUST be completable by a single subagent in one invocation. -- Sub-tasks MUST be ordered by dependency. If B depends on A, A comes first. -- You MUST NOT decompose into more than 7 sub-tasks. If you need more, group related steps. -- You MUST identify sub-tasks that can run in parallel (no mutual dependencies). -- You MUST NOT include design decisions in sub-task descriptions — those belong in the design phase. - -## Anti-patterns - -- **Too granular.** "Add import statement" is not a sub-task. "Implement the UserService module" is. -- **Too broad.** "Build the backend" is not a sub-task. "Implement the /users endpoint with CRUD operations" is. -- **Mixed concerns.** A single sub-task that requires both design and implementation has been decomposed incorrectly. -- **Missing verification.** Every sub-task MUST have acceptance criteria. If you can't define what "done" looks like, the sub-task is too vague. - -## Validation - -Before returning the plan, verify: - -- Every sub-task maps to exactly one subagent -- Dependencies form a DAG (no circular dependencies) -- Acceptance criteria are testable -- The plan is complete — executing all sub-tasks in order fulfills the original task diff --git a/pkgs/browsermcp-lock.json b/pkgs/browsermcp/browsermcp-lock.json similarity index 100% rename from pkgs/browsermcp-lock.json rename to pkgs/browsermcp/browsermcp-lock.json diff --git a/pkgs/browsermcp.nix b/pkgs/browsermcp/package.nix similarity index 100% rename from pkgs/browsermcp.nix rename to pkgs/browsermcp/package.nix diff --git a/pkgs/golangci-lint-langserver.nix b/pkgs/golangci-lint-langserver/package.nix similarity index 100% rename from pkgs/golangci-lint-langserver.nix rename to pkgs/golangci-lint-langserver/package.nix diff --git a/pkgs/gotools.nix b/pkgs/gotools/package.nix similarity index 100% rename from pkgs/gotools.nix rename to pkgs/gotools/package.nix diff --git a/pkgs/pokego.nix b/pkgs/pokego/package.nix similarity index 100% rename from pkgs/pokego.nix rename to pkgs/pokego/package.nix diff --git a/pkgs/strands-agents-sops-skills/package.nix b/pkgs/strands-agents-sops-skills/package.nix new file mode 100644 index 0000000..7d19d03 --- /dev/null +++ b/pkgs/strands-agents-sops-skills/package.nix @@ -0,0 +1,47 @@ +# Upstream's strands-agents-sops CLI used purely as a build-time generator: +# the exported artifact is just the five SOPs rendered as Agent Skills +# (/SKILL.md), ready to be merged into an opencode skills directory. +{ + lib, + runCommand, + python3Packages, + fetchFromGitHub, +}: + +let + version = "1.1.3"; + src = fetchFromGitHub { + tag = "v${version}"; + repo = "agent-sop"; + owner = "strands-agents"; + hash = "sha256-843c6dwc4Mct1T46LIBIx2ZxZnnoMA0Wprnwi4UHqew="; + }; + + strands-agents-sops = python3Packages.buildPythonApplication { + inherit version src; + pname = "strands-agents-sops"; + pyproject = true; + + sourceRoot = "source/python"; + + nativeBuildInputs = [ python3Packages.hatchling ]; + + postPatch = '' + substituteInPlace pyproject.toml \ + --replace-fail 'dynamic = ["version"]' 'version = "${version}"' \ + --replace-fail '"hatchling", "hatch-vcs"' '"hatchling"' + ''; + + dependencies = [ python3Packages.mcp ]; + + meta = { + description = "Natural language workflows (SOPs) for AI agents"; + license = lib.licenses.asl20; + mainProgram = "strands-agents-sops"; + }; + }; +in +runCommand "strands-agents-sops-skills-${version}" { } '' + mkdir $out + ${lib.getExe strands-agents-sops} skills --output-dir $out +'' diff --git a/pkgs/strands-agents-sops.nix b/pkgs/strands-agents-sops.nix deleted file mode 100644 index 3bd6a53..0000000 --- a/pkgs/strands-agents-sops.nix +++ /dev/null @@ -1,36 +0,0 @@ -{ - lib, - python3Packages, - fetchFromGitHub, -}: - -python3Packages.buildPythonApplication rec { - pname = "strands-agents-sops"; - version = "1.1.1"; - pyproject = true; - - src = fetchFromGitHub { - tag = "v${version}"; - repo = "agent-sop"; - owner = "strands-agents"; - hash = "sha256-7OtPiR5v++oGU9r7ojnFTgIR67Zz+K7IGk1bQw7GyDo="; - }; - - sourceRoot = "source/python"; - - nativeBuildInputs = [ python3Packages.hatchling ]; - - postPatch = '' - substituteInPlace pyproject.toml \ - --replace-fail 'dynamic = ["version"]' 'version = "${version}"' \ - --replace-fail '"hatchling", "hatch-vcs"' '"hatchling"' - ''; - - dependencies = [ python3Packages.mcp ]; - - meta = { - description = "Natural language workflows (SOPs) for AI agents"; - license = lib.licenses.asl20; - mainProgram = "strands-agents-sops"; - }; -}