From bd5b457d3548966759c0be39497ab8cf8cba6cbd Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Wed, 20 May 2026 11:35:43 +0000 Subject: [PATCH] docs: fix uninstall label list, outdated testing section, broken publishing link MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three documentation bugs caught during routine doc review: 1. README.md § Uninstall: listed `in-progress` (non-existent label) instead of `agent-team:reviewed`, and used an ambiguous prose format. Replaced with explicit `gh label delete` commands matching the seven labels that `install-agent-team` actually creates. 2. CONTRIBUTING.md § Testing: claimed "there is no automated test harness", which has been false since the three-tier `tests/` suite was added. Updated to document the tier-2/1 commands to run before every PR and the tier-3 opt-in E2E tests to run before releases. 3. CONTRIBUTING.md § Publishing: pointed to a non-existent `README.md#publishing` anchor. Replaced with the actual three steps (version bump, GitHub Release, registry listings). Co-Authored-By: Claude Sonnet 4.6 --- CONTRIBUTING.md | 28 ++++++++++++++++++++++------ README.md | 12 +++++++++++- 2 files changed, 33 insertions(+), 7 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1c2721e..d5a906e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -74,14 +74,28 @@ Edit the relevant `SKILL.md` or data file. Test by running the skill locally wit ## Testing -There is no automated test harness for skills — they are instruction sets interpreted by Claude Code, not code with unit tests. The validation steps are: +The repo has a three-tier automated test suite in [`tests/`](tests/README.md). Run fast tests before opening a PR: + +```bash +./tests/run-tests.sh # tier-2 invariants + tier-1 skill tests (~5 min) +./tests/run-tests.sh --verbose +``` + +| Tier | When to run | Cost | +|---|---|---| +| **2** (invariants) | Always — CI runs it on every PR. Filesystem/grep assertions, no Claude invocation. | <1 s | +| **1** (skill tests) | Always — CI runs it on every PR. Headless Claude prompts that assert skill behavior. | ~4–5 min, burns modest tokens | +| **3** (E2E, opt-in) | Before releases or when touching catalog/`*.md` workflow sources. Runs a real pipeline or provisions a throwaway repo. | 20–35 min, real wall-time | + +Run tier-3 explicitly via `./tests/test-e2e.sh` (pipeline) or `./tests/test-e2e-install-workflow.sh` / `./tests/test-e2e-install-agent-team.sh` (skill install surfaces). See [`tests/README.md`](tests/README.md) for full usage. + +Additional manual validation steps (no automated equivalent): 1. **Load the plugin**: `claude --plugin-dir .` — confirm no startup errors. -2. **Run the skill manually**: invoke `/discover-workflows` or `/install-workflow` and walk through the flow. -3. **Validate lock files** (if you changed `.lock.yml` files): `gh aw validate` — safe, does not recompile. -4. **Check grep counts** (if you applied the OAuth tweak): see [skills/install-workflow/auth.md](skills/install-workflow/auth.md#step-4--verify-the-tweak-shape). +2. **Validate lock files** (if you changed `.lock.yml` files): `gh aw validate` — safe, does not recompile. +3. **Check grep counts** (if you applied the OAuth tweak): see [skills/install-workflow/auth.md](skills/install-workflow/auth.md#step-4--verify-the-tweak-shape). -Never test by committing untested changes to `main`. The installed workflows run on push to `main`, so a broken install skill or a bad `.lock.yml` will trigger a live workflow run. +Never commit untested changes to `main`. The installed workflows run on push to `main`, so a broken skill or bad `.lock.yml` will trigger a live workflow run. ## Workflow files @@ -112,4 +126,6 @@ Branch naming conventions: ## Publishing (maintainers only) -See the [Publishing section of the README](README.md#publishing) for the steps to submit the plugin to the Claude plugin registry. +1. Bump the version in `.claude-plugin/plugin.json` (`"version"` field). Keep `marketplace.json` in sync if the description changes. +2. Create a GitHub Release tagged `v` — the release body becomes the changelog entry. +3. The plugin is listed on [claude-plugins.dev](https://claude-plugins.dev) and [ClaudePluginHub](https://claudepluginhub.com). Update the listing on each registry if the description, homepage, or marketplace URL changed. diff --git a/README.md b/README.md index e18e51a..16b1c05 100644 --- a/README.md +++ b/README.md @@ -80,7 +80,17 @@ To remove workflows this plugin installed into your target repo: - `gh aw remove ` for each installed workflow (deletes both the `.md` source and the compiled `.lock.yml`), then commit the deletion. - `gh secret delete CLAUDE_CODE_OAUTH_TOKEN` — or `ANTHROPIC_API_KEY`, whichever path you used — to unset the auth secret. -- For `agent-team` specifically, also delete the seven labels: `gh label delete agent-team` plus `gh label delete state:` for each of `plan-needed`, `impl-needed`, `review-needed`, `done`, `blocked`, and `in-progress`. +- For `agent-team` specifically, also delete the seven labels: + + ```bash + gh label delete agent-team + gh label delete state:plan-needed + gh label delete state:impl-needed + gh label delete state:review-needed + gh label delete state:done + gh label delete state:blocked + gh label delete agent-team:reviewed + ``` Nothing else is persisted — the plugin writes only to your target repo (under user approval) and holds no local state outside Claude Code's own plugin directory.