Skip to content

docs: compact README; split details into docs/; add release script - #146

Merged
yourconscience merged 1 commit into
mainfrom
docs/compact-readme
Aug 23, 2026
Merged

docs: compact README; split details into docs/; add release script#146
yourconscience merged 1 commit into
mainfrom
docs/compact-readme

Conversation

@yourconscience

@yourconscience yourconscience commented Aug 23, 2026

Copy link
Copy Markdown
Owner

Summary by Sourcery

Streamline the README, move detailed guidance into dedicated documentation, and add a validated release workflow entry point.

New Features:

  • Add dedicated documentation covering setup, skills, roles, memory, comparisons, and troubleshooting.
  • Add a release script that validates repository state, runs tests, creates an annotated version tag, and pushes it to trigger publishing CI.

Enhancements:

  • Condense the README into a concise overview, quick start, command reference, configuration summary, and documentation index.
  • Expand the documented dotagents scope to include root instructions and memory tooling, and clarify current harness capabilities.

Deployment:

  • Automate the release handoff to CI for publishing binaries, Homebrew updates, and the npm package.

Documentation:

  • Split detailed operational and feature documentation out of README.md into the docs directory.
  • Add a comparison guide describing dotagents' positioning and supported capabilities.

@chatgpt-codex-connector

Copy link
Copy Markdown

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

@sourcery-ai

sourcery-ai Bot commented Aug 23, 2026

Copy link
Copy Markdown

Reviewer's Guide

Compact the top-level README by moving detailed usage, setup, skills, roles, memory, troubleshooting, and comparison content into new docs/* files, add a concise quick-start plus docs links, and introduce a scripts/release.sh helper to cut tagged releases safely.

Flow diagram for the release script

flowchart TD
    A["scripts/release.sh vX.Y.Z"] --> B["Validate repository and tag format"]
    B --> C["Require clean main synced with origin/main"]
    C --> D["Run go test ./..."]
    D --> E["Show changes since previous tag"]
    E --> F{"Confirm release"}
    F -->|yes| G["Create annotated git tag"]
    G --> H["Push tag to origin"]
    H --> I["CI publishes binaries, Homebrew, and npm"]
    F -->|no| J["Abort"]
Loading

File-Level Changes

Change Details Files
Restructure README to be a compact overview with quick-start commands and pointers into the docs directory.
  • Shorten initial product description and include root instructions and memory tooling in the overview.
  • Replace verbose installation and setup walkthrough with a two-line brew + setup snippet and a sentence summary of setup behavior.
  • Condense descriptions of skills, memory tiers, roles, configuration, releases, and differences vs other tools into brief sections that link to dedicated docs/*.md files.
README.md
Add dedicated documentation pages for setup, skills (including external skills and plugins), roles, memory, comparison with other tools, and troubleshooting.
  • Create docs/setup.md capturing the full setup walkthrough, multi-machine workflow, memory tier selection, and root-instructions behavior previously in README.
  • Create docs/skills.md documenting skill structure, promotion from harnesses, external skill pinning and auditing, and plugin discovery.
  • Create docs/roles.md explaining role file format, model tiers and per-harness overrides, and rendering targets per harness.
  • Create docs/memory.md detailing memory tiers, locations, Go helper tools, the rem workflow, and the review-first design rationale.
  • Create docs/comparison.md with a detailed feature comparison table vs rulesync, ruler, and openskills, plus positioning notes.
  • Create docs/troubleshooting.md aggregating common operational and upgrade issues and their resolutions.
docs/setup.md
docs/skills.md
docs/roles.md
docs/memory.md
docs/comparison.md
docs/troubleshooting.md
Introduce a scripted release workflow that tags versions and relies on CI to build and publish artifacts.
  • Add scripts/release.sh that validates the working tree and branch, runs tests, shows changes since the last tag, confirms interactively (or via --yes), creates an annotated vX.Y.Z tag, and pushes it to origin.
  • Document the release script usage briefly in README under a Releases section, noting CI will publish binaries, Homebrew tap updates, and npm package releases on tag push.
scripts/release.sh
README.md

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@yourconscience
yourconscience merged commit 9a9b970 into main Aug 23, 2026
5 checks passed
@yourconscience
yourconscience deleted the docs/compact-readme branch August 23, 2026 06:14

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've found 2 issues

Prompt for AI Agents
Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path="scripts/release.sh" line_range="1" />
<code_context>
+git rev-parse -q --verify "refs/tags/$TAG" >/dev/null && { echo "$TAG already exists"; exit 1; }
+
+echo ">> go test ./..."
+go test ./...
+
+prev=$(git describe --tags --abbrev=0)
</code_context>
<issue_to_address>
**issue (bug_risk):** The script does not enable `set -e`, so a failing `go test ./...` is ignored and the script continues to tag and push the release. The same missing error propagation causes failed `git tag` or `git push` commands to be followed by successful `echo` commands, allowing the script to report success despite not publishing the tag.

**Triggers:** When the test suite or either tag operation fails.

**Suggested fix:** Add `set -eu` (or explicitly check every fallible command, especially `go test`, `git tag`, and `git push`) before performing the release.

```suggestion
#!/usr/bin/env sh
set -eu
```
</issue_to_address>

### Comment 2
<location path="scripts/release.sh" line_range="13" />
<code_context>
+YES="${2:-}"
+
+[ -f .goreleaser.yaml ] || { echo "run from the dotagents repo root"; exit 1; }
+case "$TAG" in v[0-9]*.[0-9]*.[0-9]*) ;; *) echo "usage: scripts/release.sh v0.7.0 [--yes]"; exit 1 ;; esac
+confirm() {
+	[ "$YES" = "--yes" ] && return 0
</code_context>
<issue_to_address>
**issue (bug_risk):** The shell pattern `v[0-9]*.[0-9]*.[0-9]*` is not a semantic-version check: each `*` accepts arbitrary characters and the pattern also permits extra components. Values such as `v1foo.2bar.3` or `v1.2.3.4` pass validation and are then pushed as release tags, causing the release workflow or npm versioning step to reject the malformed version.

**Triggers:** When a maintainer supplies a tag that is not strictly `vMAJOR.MINOR.PATCH`.

**Suggested fix:** Validate with a stricter POSIX-compatible check, such as extracting the version and matching each numeric component explicitly, or use a dedicated semver validator.

```suggestion
case "$TAG" in v*) printf '%s\n' "${TAG#v}" | grep -Eq '^[0-9]+\.[0-9]+\.[0-9]+$' || { echo "usage: scripts/release.sh v0.7.0 [--yes]"; exit 1; } ;; *) echo "usage: scripts/release.sh v0.7.0 [--yes]"; exit 1 ;; esac
```
</issue_to_address>

Sourcery assessment

Needs a human reviewer. 2 findings to address first, and the change is documentation plus a release helper that can create and push a version tag, triggering publication of binaries, Homebrew updates, and an npm release. If the script is wrong and run, those published artifacts outlive a revert, though the impact is bounded and can be corrected with a follow-up release or package retirement.

Blocking findings: scripts/release.sh:1, scripts/release.sh:13


Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

Comment thread scripts/release.sh
@@ -0,0 +1,41 @@
#!/usr/bin/env sh

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (bug_risk): The script does not enable set -e, so a failing go test ./... is ignored and the script continues to tag and push the release. The same missing error propagation causes failed git tag or git push commands to be followed by successful echo commands, allowing the script to report success despite not publishing the tag.

Triggers: When the test suite or either tag operation fails.

Suggested fix: Add set -eu (or explicitly check every fallible command, especially go test, git tag, and git push) before performing the release.

Suggested change
#!/usr/bin/env sh
#!/usr/bin/env sh
set -eu

Comment thread scripts/release.sh
YES="${2:-}"

[ -f .goreleaser.yaml ] || { echo "run from the dotagents repo root"; exit 1; }
case "$TAG" in v[0-9]*.[0-9]*.[0-9]*) ;; *) echo "usage: scripts/release.sh v0.7.0 [--yes]"; exit 1 ;; esac

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

issue (bug_risk): The shell pattern v[0-9]*.[0-9]*.[0-9]* is not a semantic-version check: each * accepts arbitrary characters and the pattern also permits extra components. Values such as v1foo.2bar.3 or v1.2.3.4 pass validation and are then pushed as release tags, causing the release workflow or npm versioning step to reject the malformed version.

Triggers: When a maintainer supplies a tag that is not strictly vMAJOR.MINOR.PATCH.

Suggested fix: Validate with a stricter POSIX-compatible check, such as extracting the version and matching each numeric component explicitly, or use a dedicated semver validator.

Suggested change
case "$TAG" in v[0-9]*.[0-9]*.[0-9]*) ;; *) echo "usage: scripts/release.sh v0.7.0 [--yes]"; exit 1 ;; esac
case "$TAG" in v*) printf '%s\n' "${TAG#v}" | grep -Eq '^[0-9]+\.[0-9]+\.[0-9]+$' || { echo "usage: scripts/release.sh v0.7.0 [--yes]"; exit 1; } ;; *) echo "usage: scripts/release.sh v0.7.0 [--yes]"; exit 1 ;; esac

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant