{"owner":"softprops","repo":"action-gh-release","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# action-gh-release\n\nThis repository is maintained as a small, user-facing GitHub Action with a relatively wide compatibility surface.\nOptimize for stability, reproducibility, and clear user value over broad rewrites.\n\n## Core Rules\n\n- Prefer narrow behavior fixes over structural churn.\n- Reproduce current behavior on `master` before changing code.\n- Treat GitHub platform behavior as distinct from action behavior.\n  If GitHub controls the outcome, prefer docs or clearer errors over brittle workarounds.\n- Do not revive stale PRs mechanically.\n  Reuse the idea if it still has value, but reimplement on top of current `master`.\n- Avoid standalone refactors with no clear user-facing benefit.\n\n## Current Architecture\n\n- `src/main.ts` is the action bootstrap; `src/run.ts` orchestrates config parsing, validation, release creation/update, asset uploads, finalization, and outputs.\n- `src/github.ts` owns release semantics: lookup, create/update/finalize, asset upload, race handling, and GitHub API interaction.\n- `src/util.ts` owns parsing and path normalization.\n- Keep behavior-specific logic in `src/github.ts` or `src/util.ts`; avoid growing `src/main.ts` with ad-hoc feature branches.\n\n## Bug-Fix Workflow\n\n- Reproduce the issue against current `master` first.\n- When available, use the companion consumer harness repo `action-gh-release-test`.\n- Capture exact workflow run URLs and release URLs before claiming a fix.\n- If the issue is really a docs/usage or platform-limit case, document it and close it as such instead of forcing a code change.\n- If a historical issue no longer reproduces on current `master`, prefer a short closeout note that asks the reporter to open a fresh issue if they still see it.\n\n## Feature Triage\n\n- Ship features only when there is clear user value or repeated demand.\n- Small convenience features are fine, but they should stay small.\n- Weak-demand features should not expand parsing complexity, cross-platform ambiguity, or maintenance surface.\n- For old feature PRs:\n  - check whether current `master` already covers the behavior\n  - prefer a tiny docs clarification if the behavior exists but is poorly explained\n  - close stale feature PRs when the idea is obsolete, low-value, or badly shaped for the current codebase\n\n## Contract Sync\n\nWhen behavior changes, keep the external contract in sync:\n\n- update `README.md`\n- update `action.yml`\n- update tests under `__tests__/`\n- regenerate `dist/index.js` with `npm run build`\n\nDocs-only changes do not need `dist/index.js` regeneration.\n\n## Verification\n\nFor code changes, run:\n\n- `npm run fmtcheck`\n- `npm run typecheck`\n- `npm run build`\n- `npm test`\n\nFor behavior changes, also run the relevant external regression workflow(s) in `action-gh-release-test` against the exact ref under test.\n\n## Release and Triage Conventions\n\n- Keep PR labels accurate. Release notes depend on them.\n  - bug fixes: `bug`\n  - docs-only changes: `documentation`\n  - additive features: `feature` or `enhancement`\n  - dependency updates: `dependencies`\n- Follow [RELEASE.md](RELEASE.md) for version bumps, changelog updates, tagging, and release publication.\n- Prefer manual issue/PR closeouts with a short rationale over implicit assumptions.\n- Do not auto-close old PRs or issues through unrelated docs PRs.\n\n## Implementation Preferences\n\n- Preserve the current upload/finalize flow unless there is strong evidence it needs to change.\n- Prefer upload-time semantics over filesystem mutation.\n- Be careful with parsing changes around `files`, path handling, and Windows compatibility.\n- Be careful with race-condition fixes; verify both local tests and consumer-repo concurrency harnesses.\n- Do not assume a refactor is safe just because tests are green. This action’s behavior is heavily shaped by GitHub API edge cases.\n"},"files":{"AGENTS.md":"# action-gh-release\n\nThis repository is maintained as a small, user-facing GitHub Action with a relatively wide compatibility surface.\nOptimize for stability, reproducibility, and clear user value over broad rewrites.\n\n## Core Rules\n\n- Prefer narrow behavior fixes over structural churn.\n- Reproduce current behavior on `master` before changing code.\n- Treat GitHub platform behavior as distinct from action behavior.\n  If GitHub controls the outcome, prefer docs or clearer errors over brittle workarounds.\n- Do not revive stale PRs mechanically.\n  Reuse the idea if it still has value, but reimplement on top of current `master`.\n- Avoid standalone refactors with no clear user-facing benefit.\n\n## Current Architecture\n\n- `src/main.ts` is the action bootstrap; `src/run.ts` orchestrates config parsing, validation, release creation/update, asset uploads, finalization, and outputs.\n- `src/github.ts` owns release semantics: lookup, create/update/finalize, asset upload, race handling, and GitHub API interaction.\n- `src/util.ts` owns parsing and path normalization.\n- Keep behavior-specific logic in `src/github.ts` or `src/util.ts`; avoid growing `src/main.ts` with ad-hoc feature branches.\n\n## Bug-Fix Workflow\n\n- Reproduce the issue against current `master` first.\n- When available, use the companion consumer harness repo `action-gh-release-test`.\n- Capture exact workflow run URLs and release URLs before claiming a fix.\n- If the issue is really a docs/usage or platform-limit case, document it and close it as such instead of forcing a code change.\n- If a historical issue no longer reproduces on current `master`, prefer a short closeout note that asks the reporter to open a fresh issue if they still see it.\n\n## Feature Triage\n\n- Ship features only when there is clear user value or repeated demand.\n- Small convenience features are fine, but they should stay small.\n- Weak-demand features should not expand parsing complexity, cross-platform ambiguity, or maintenance surface.\n- For old feature PRs:\n  - check whether current `master` already covers the behavior\n  - prefer a tiny docs clarification if the behavior exists but is poorly explained\n  - close stale feature PRs when the idea is obsolete, low-value, or badly shaped for the current codebase\n\n## Contract Sync\n\nWhen behavior changes, keep the external contract in sync:\n\n- update `README.md`\n- update `action.yml`\n- update tests under `__tests__/`\n- regenerate `dist/index.js` with `npm run build`\n\nDocs-only changes do not need `dist/index.js` regeneration.\n\n## Verification\n\nFor code changes, run:\n\n- `npm run fmtcheck`\n- `npm run typecheck`\n- `npm run build`\n- `npm test`\n\nFor behavior changes, also run the relevant external regression workflow(s) in `action-gh-release-test` against the exact ref under test.\n\n## Release and Triage Conventions\n\n- Keep PR labels accurate. Release notes depend on them.\n  - bug fixes: `bug`\n  - docs-only changes: `documentation`\n  - additive features: `feature` or `enhancement`\n  - dependency updates: `dependencies`\n- Follow [RELEASE.md](RELEASE.md) for version bumps, changelog updates, tagging, and release publication.\n- Prefer manual issue/PR closeouts with a short rationale over implicit assumptions.\n- Do not auto-close old PRs or issues through unrelated docs PRs.\n\n## Implementation Preferences\n\n- Preserve the current upload/finalize flow unless there is strong evidence it needs to change.\n- Prefer upload-time semantics over filesystem mutation.\n- Be careful with parsing changes around `files`, path handling, and Windows compatibility.\n- Be careful with race-condition fixes; verify both local tests and consumer-repo concurrency harnesses.\n- Do not assume a refactor is safe just because tests are green. This action’s behavior is heavily shaped by GitHub API edge cases.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# action-gh-release\n\nThis repository is maintained as a small, user-facing GitHub Action with a relatively wide compatibility surface.\nOptimize for stability, reproducibility, and clear user value over broad rewrites.\n\n## Core Rules\n\n- Prefer narrow behavior fixes over structural churn.\n- Reproduce current behavior on `master` before changing code.\n- Treat GitHub platform behavior as distinct from action behavior.\n  If GitHub controls the outcome, prefer docs or clearer errors over brittle workarounds.\n- Do not revive stale PRs mechanically.\n  Reuse the idea if it still has value, but reimplement on top of current `master`.\n- Avoid standalone refactors with no clear user-facing benefit.\n\n## Current Architecture\n\n- `src/main.ts` is the action bootstrap; `src/run.ts` orchestrates config parsing, validation, release creation/update, asset uploads, finalization, and outputs.\n- `src/github.ts` owns release semantics: lookup, create/update/finalize, asset upload, race handling, and GitHub API interaction.\n- `src/util.ts` owns parsing and path normalization.\n- Keep behavior-specific logic in `src/github.ts` or `src/util.ts`; avoid growing `src/main.ts` with ad-hoc feature branches.\n\n## Bug-Fix Workflow\n\n- Reproduce the issue against current `master` first.\n- When available, use the companion consumer harness repo `action-gh-release-test`.\n- Capture exact workflow run URLs and release URLs before claiming a fix.\n- If the issue is really a docs/usage or platform-limit case, document it and close it as such instead of forcing a code change.\n- If a historical issue no longer reproduces on current `master`, prefer a short closeout note that asks the reporter to open a fresh issue if they still see it.\n\n## Feature Triage\n\n- Ship features only when there is clear user value or repeated demand.\n- Small convenience features are fine, but they should stay small.\n- Weak-demand features should not expand parsing complexity, cross-platform ambiguity, or maintenance surface.\n- For old feature PRs:\n  - check whether current `master` already covers the behavior\n  - prefer a tiny docs clarification if the behavior exists but is poorly explained\n  - close stale feature PRs when the idea is obsolete, low-value, or badly shaped for the current codebase\n\n## Contract Sync\n\nWhen behavior changes, keep the external contract in sync:\n\n- update `README.md`\n- update `action.yml`\n- update tests under `__tests__/`\n- regenerate `dist/index.js` with `npm run build`\n\nDocs-only changes do not need `dist/index.js` regeneration.\n\n## Verification\n\nFor code changes, run:\n\n- `npm run fmtcheck`\n- `npm run typecheck`\n- `npm run build`\n- `npm test`\n\nFor behavior changes, also run the relevant external regression workflow(s) in `action-gh-release-test` against the exact ref under test.\n\n## Release and Triage Conventions\n\n- Keep PR labels accurate. Release notes depend on them.\n  - bug fixes: `bug`\n  - docs-only changes: `documentation`\n  - additive features: `feature` or `enhancement`\n  - dependency updates: `dependencies`\n- Follow [RELEASE.md](RELEASE.md) for version bumps, changelog updates, tagging, and release publication.\n- Prefer manual issue/PR closeouts with a short rationale over implicit assumptions.\n- Do not auto-close old PRs or issues through unrelated docs PRs.\n\n## Implementation Preferences\n\n- Preserve the current upload/finalize flow unless there is strong evidence it needs to change.\n- Prefer upload-time semantics over filesystem mutation.\n- Be careful with parsing changes around `files`, path handling, and Windows compatibility.\n- Be careful with race-condition fixes; verify both local tests and consumer-repo concurrency harnesses.\n- Do not assume a refactor is safe just because tests are green. This action’s behavior is heavily shaped by GitHub API edge cases.\n","category":"root","tokens":951}]}