Skip to content
42 changes: 34 additions & 8 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -60,7 +60,8 @@ npx skills add https://github.com/codebeltnet/agentic --skill git-repo-digest
npx skills add https://github.com/codebeltnet/agentic --skill trunk-first-repo
npx skills add https://github.com/codebeltnet/agentic --skill dotnet-strong-name-signing
npx skills add https://github.com/codebeltnet/agentic --skill dotnet-new-app-slnx
npx skills add https://github.com/codebeltnet/agentic --skill dotnet-new-lib-slnx
npx skills add https://github.com/codebeltnet/agentic --skill dotnet-new-lib-slnx
npx skills add https://github.com/codebeltnet/agentic --skill git-remote-release
# npx skills add https://github.com/codebeltnet/agentic --skill another-skill
```

Expand Down Expand Up @@ -91,7 +92,8 @@ npx skills add https://github.com/codebeltnet/agentic --skill dotnet-new-lib-sln
| [dotnet-new-lib-slnx](skills/dotnet-new-lib-slnx/SKILL.md) | Scaffold a new .NET NuGet library solution following codebeltnet engineering conventions. Dynamic defaults for TFM/repository metadata, latest-stable NuGet package resolution, tuning projects plus a tooling-based benchmark runner, TFM-aware test environments, strong-name signing, NuGet packaging, DocFX documentation, CI/CD pipeline, and code quality tooling. |
| [dotnet-new-app-slnx](skills/dotnet-new-app-slnx/SKILL.md) | Scaffold a new .NET standalone application solution following codebeltnet engineering conventions. Supports Console, Web, and Worker host families with Startup or Minimal hosting patterns; Web expands into Empty Web, Web API, MVC, or Web App / Razor, plus functional tests and a simplified CI pipeline. |
| [trunk-first-repo](skills/trunk-first-repo/SKILL.md) | Initialize a git repository following [scaled trunk-based development](https://trunkbaseddevelopment.com/#scaled-trunk-based-development). Seeds an empty `main` branch and creates a versioned feature branch (`v0.1.0/init`), enforcing a PR-first workflow where content only reaches main through peer-reviewed pull requests. |
| [dotnet-strong-name-signing](skills/dotnet-strong-name-signing/SKILL.md) | Generate a strong name key (`.snk`) file for signing .NET assemblies using pure .NET cryptography — no Visual Studio Developer PowerShell or `sn.exe` required. Works in any terminal. Defaults to 1024-bit RSA (matching `sn.exe`), with 2048 and 4096 available as options. |
| [dotnet-strong-name-signing](skills/dotnet-strong-name-signing/SKILL.md) | Generate a strong name key (`.snk`) file for signing .NET assemblies using pure .NET cryptography — no Visual Studio Developer PowerShell or `sn.exe` required. Works in any terminal. Defaults to 1024-bit RSA (matching `sn.exe`), with 2048 and 4096 available as options. |
| [git-remote-release](skills/git-remote-release/SKILL.md) | Generate GitHub release notes by summarizing all commits and pull requests between two Git tags or branches in a remote GitHub repository. Accepts a compare URL or separate owner/repo, previous ref, and current ref values; falls back to comparing the current branch against the upstream default branch when no input is provided. Produces a human-friendly `## What's Changed` summary with optional GitHub alert blocks, a `Sources:` section preserving PR and commit references, and a full changelog compare link. |

### Copyable Install Commands

Expand Down Expand Up @@ -165,10 +167,16 @@ npx skills add https://github.com/codebeltnet/agentic --skill trunk-first-repo

`dotnet-strong-name-signing`

```bash
npx skills add https://github.com/codebeltnet/agentic --skill dotnet-strong-name-signing
```

```bash
npx skills add https://github.com/codebeltnet/agentic --skill dotnet-strong-name-signing
```

`git-remote-release`

```bash
npx skills add https://github.com/codebeltnet/agentic --skill git-remote-release
```

### Why git-visual-commits?

Commit messages are the most-read documentation in any codebase — yet they're usually an afterthought. "fix stuff", "wip", "address PR feedback" tells you nothing six months later. Writing good commits takes discipline, and when you're in flow, it's the first thing that slips.
Expand Down Expand Up @@ -468,8 +476,26 @@ Most repositories start with `git init` followed by committing everything direct
- **Review from day one** — no "we'll add branch protection later" that never happens
- **Clean, meaningful history** — main tells the story of reviewed, approved changes
- **Version-aware branches** — `v0.0.1/spike-auth` vs `v1.0.0/release-prep` signals project maturity at a glance
- **Zero-friction setup** — one skill invocation, not a 10-step checklist

- **Zero-friction setup** — one skill invocation, not a 10-step checklist

### Why git-remote-release?

Writing release notes is tedious. Raw commit logs are too noisy, PR titles often lack context, and the best release notes explain what changed and why it matters — not just what was merged. That gap between "here are the commits" and "here is what this release means for you" is where **git-remote-release** fits.

**git-remote-release** reads all commits and pull requests between two tags or branches in a remote GitHub repository and produces a polished, paste-ready release note.

- **Remote-first workflow** that works entirely through GitHub's API, with no local clone required,
- **Compare URL awareness** where a pasted GitHub compare URL is used to extract the owner, repository, and both tags,
- **Pull request-preferred analysis** that uses rich PR metadata when available and gracefully falls back to raw commits,
- **Default-branch-aware comparisons** that resolve the upstream base and collect only commits on the current branch,
- **Effect-oriented summaries** that explain what users and maintainers can expect from the release, not just what code was merged,
- **Thematic grouping** where related changes are discussed together instead of listed chronologically,
- **GitHub alert blocks** that use `NOTE`, `TIP`, `IMPORTANT`, `WARNING`, and `CAUTION` alerts sparingly and only when the release data supports the attention level,
- **Source preservation** where every release note includes a `Sources:` section with the original PR and commit references,
- **Strict format** that always starts with `## What's Changed` and always ends with the full changelog compare link,
- **No invented claims** so every statement in the summary is backed by the commits and pull requests collected,
- **Read-only operation** that never mutates repository state.

## Repository structure

```
Expand Down
40 changes: 40 additions & 0 deletions skills/git-remote-release/FORMS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
# Parameter Form

Collect input values, present a summary, and ask for confirmation before generating release notes.

## Fields

### compare_url
- **type:** text
- **required:** no
- **prompt:** Do you have a GitHub compare URL? (e.g. `https://github.com/owner/repo/compare/v1.0.0...v1.0.1`) When provided, all other fields are inferred automatically.

### repository
- **type:** text
- **required:** yes (unless compare_url is provided or using default resolution)
- **prompt:** Which GitHub repository? Use `owner/repo` format (e.g. `codebeltnet/agentic`).

### previous_ref
- **type:** text
- **required:** yes (unless compare_url is provided or using default resolution)
- **prompt:** What is the previous tag or branch to compare from? (e.g. `v1.0.0` or `main`)

### current_ref
- **type:** text
- **required:** yes (unless compare_url is provided or using default resolution)
- **prompt:** What is the current tag or branch to compare to? (e.g. `v1.0.1` or `feature/my-branch`)

## Presentation Rules

0. If the user provided no input at all (no URL, no repository, no tags or branches), skip this form entirely and proceed directly to the Default Resolution Behavior defined in `SKILL.md`. Do not prompt for individual fields.
1. If the user provided a compare URL, parse it and present the inferred values:
```
Ready to generate release notes:
Repository: {owner}/{repo}
Previous: {previousRef}
Current: {currentRef}
```
Then ask: "Ready to proceed? (yes / no)"
2. If the user provided separate values, present them in the same summary format, then ask: "Ready to proceed? (yes / no)"
3. If any required value is missing and the user did provide partial input, ask for it individually before presenting the summary.
4. After confirmation, proceed immediately to data collection.
Comment thread
greptile-apps[bot] marked this conversation as resolved.
Loading
Loading