@willbooster/agent-skills 1.28.4 → 1.28.5

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@willbooster/agent-skills",
3
- "version": "1.28.4",
3
+ "version": "1.28.5",
4
4
  "description": "A collection of agent skills for WillBooster Inc.",
5
5
  "repository": {
6
6
  "type": "git",
@@ -48,7 +48,7 @@
48
48
  "@typescript/native-preview": "7.0.0-dev.20260518.1",
49
49
  "@willbooster/oxfmt-config": "1.2.2",
50
50
  "@willbooster/oxlint-config": "1.4.6",
51
- "@willbooster/wb": "13.19.3",
51
+ "@willbooster/wb": "13.19.4",
52
52
  "build-ts": "17.1.15",
53
53
  "conventional-changelog-conventionalcommits": "9.3.1",
54
54
  "lefthook": "2.1.6",
@@ -1,5 +1,6 @@
1
1
  1. Check the CI (GitHub Actions) results using the `check-pr-ci` skill.
2
- 2. If any workflow fails, pull the latest remote changes, resolve the issues, commit, push, and return to step 1. Otherwise, proceed to the next step.
2
+ 2. If any workflow fails, pull the latest remote changes, investigate the root cause of the issues, resolve the issues, commit, push, and return to step 1. Otherwise, proceed to the next step.
3
+ - If this is a `wbfy` application branch, investigate the root cause to determine whether the failure is related to `wbfy`. If needed, fix `wbfy` itself as described in the `wbfy` skill.
3
4
  3. Fetch unresolved review threads using the `manage-pr-review-threads` skill.
4
5
  4. Review each unresolved thread and decide whether it requires a code or documentation change. Treat every review claim as unverified until you confirm it with concrete evidence from the current codebase, a local reproduction, or official documentation. Do not make changes just because a reviewer asserted them; make changes only after the evidence shows the comment is valid. Ignore only comments that are clearly outdated, incorrect, out of scope, or intentionally declined with solid reasoning.
5
6
  5. If there are valid review comments to address, make only the changes supported by the evidence from step 4, commit, push, and then return to step 1.
@@ -1,5 +1,6 @@
1
1
  1. Check the CI (GitHub Actions) results using the `check-pr-ci` skill.
2
- 2. If any workflow fails, pull the latest remote changes, resolve the issues, commit, push, and return to step 1. Otherwise, proceed to the next step.
2
+ 2. If any workflow fails, pull the latest remote changes, investigate the root cause of the issues, resolve the issues, commit, push, and return to step 1. Otherwise, proceed to the next step.
3
+ - If this is a `wbfy` application branch, investigate the root cause to determine whether the failure is related to `wbfy`. If needed, fix `wbfy` itself as described in the `wbfy` skill.
3
4
  3. Fetch unresolved review threads using the `manage-pr-review-threads` skill.
4
5
  4. Review each unresolved thread to determine if it requires code or documentation changes. Treat every review claim as unverified until you confirm it with concrete evidence from the current codebase, a local reproduction, or official documentation. Do not make changes just because a reviewer asserted them; make changes only after the evidence shows the comment is valid.
5
6
  5. Address valid review comments by updating the code. For invalid comments, add explanatory comments to the code detailing why the existing implementation is necessary.
@@ -8,7 +8,7 @@ allowed-tools: Bash(bun:*), Bash(gh:*), Bash(git:*), Bash(yarn:*)
8
8
 
9
9
  1. If the current branch is `main`, create and switch to a new branch based on the latest remote `main` branch.
10
10
  - Ensure the new branch is derived from the latest remote `main` branch to prevent merge conflicts when opening a pull request.
11
- 2. Make sure .env files define NEXT_PUBLIC_BASE_URL correctly, as `wbfy` uses this environment variable to generate configuration files.
11
+ 2. Add or fix `NEXT_PUBLIC_BASE_URL` only if app code, tests, or existing Playwright config require a public app origin; Playwright alone is not enough.
12
12
  3. Update `~/ghq/github.com/WillBooster/shared/packages/wbfy` (a git repository) to the latest `main` branch.
13
13
  4. Run `yarn start <root_path_of_target_repo>` in `~/ghq/github.com/WillBooster/shared/packages/wbfy`.
14
14
  5. Run `yarn verify` or `bun verify` in the target repository (not within the `wbfy` directory).