Move Python package detection into an explicit setup job so GitHub Actions can plan the release workflow instead of failing before jobs/logs are created.
Constraint: Python release flow is scaffold-only until a real python-packages/* pyproject exists
Rejected: Keeping job-level hashFiles guards | GitHub reported zero-second workflow-file failures with no jobs or logs
Confidence: high
Scope-risk: narrow
Directive: Keep release-please publish work gated behind detected concrete Python package paths
Tested: ruby YAML parse; npm run ci
Not-tested: actual release-please publication because no Python package exists yet
* docs: add Manus.ai GitHub skill import guide
Manus.ai의 'GitHub에서 프로젝트 스킬 가져오기' 기능은 폴더 루트에 SKILL.md(YAML frontmatter name/description 필수)가 있는 디렉토리 URL을 받는다. k-skill의 모든 스킬은 이미 이 포맷을 만족하므로 코드 변경 없이 문서만 추가한다.
- 사용자는 저장소 루트 URL(https://github.com/NomaDamas/k-skill) 대신 개별 스킬 폴더 URL(https://github.com/NomaDamas/k-skill/tree/main/<skill-name>)을 붙여 넣어야 한다.
- 기존 frontmatter(license, metadata.*)는 Manus가 무시하지만 다른 코딩 에이전트와의 호환을 위해 그대로 유지한다.
* feat: add build:manus-bundle for batch .skill upload to Manus.ai
Per-folder GitHub URL import is tedious for 61 skills, so add 'npm run build:manus-bundle' which emits one .skill (ZIP) per skill into dist/manus/, plus a single k-skill-manus-all.zip convenience bundle and an INDEX.md listing. Each archive nests its content under <skill-name>/ to match the public Anthropic skill-creator packager layout.
Manus does NOT support multi-skill bulk import in a single archive (verified against help.manus.im, manus.im/docs, and open.manus.ai API docs). The combined zip is purely a download convenience: users still drag-drop individual .skill files into Manus, but the file picker accepts multiple selections so it's still much faster than pasting 61 GitHub URLs.
- scripts/build-manus-bundle.js: discovers root-level skills (mirrors validate-skills.sh exclusions), shells out to system zip with -X for reproducible archives, excludes node_modules/__pycache__/.DS_Store.
- scripts/test_build_manus_bundle.js: validates discovery, frontmatter parsing, lockstep with validate-skills.sh, and docs coverage.
- scripts/validate-skills.sh: also skip dist/ and .sisyphus/ so the validator stays clean after a build.
- .gitignore: ignore dist/ and .sisyphus/.
- docs/install-manus.md: document both Method A (GitHub URL) and Method B (.skill bundle).
* ci: auto-publish Manus .skill bundle as rolling release on main push
Every push to main that touches a skill folder or the bundler now builds the .skill bundle and publishes it to the GitHub Releases tag 'manus-bundle-latest' (marked prerelease so it does not pollute the Latest release pointer used by the npm release flow).
Users get stable download URLs that always point to the latest build:
- https://github.com/NomaDamas/k-skill/releases/download/manus-bundle-latest/k-skill-manus-all.zip
- https://github.com/NomaDamas/k-skill/releases/download/manus-bundle-latest/INDEX.md
This removes the 'clone the repo and run npm' step for non-developers. The direct-build path remains documented as the developer fallback.
- .github/workflows/manus-bundle.yml: workflow_dispatch + push-to-main with paths filter, uses preinstalled gh CLI (no third-party release action), concurrency-grouped so overlapping pushes do not race on the same tag, --clobber upload to keep asset URLs stable.
- docs/install-manus.md: new 'quick path' section with the rolling-release URLs; existing local-build section reframed as a developer fallback.
- scripts/test_build_manus_bundle.js: 2 new tests pinning the doc URLs and key workflow invariants (trigger branch, build invocation, tag, asset name, prerelease flag, write permission).
- Add workflow_dispatch trigger to release-npm.yml so releases can be
manually re-triggered when the automatic path-based trigger misses.
- Document in CLAUDE.md and AGENTS.md that tests must never assert
.changeset file existence, since changeset version consumes them.
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Recent main-branch release workflow runs were failing before the Version Packages
PR could be created because changesets/action tried to read per-package
CHANGELOG.md files that do not exist in this repo. The repo deliberately
keeps `.changeset/config.json` on `changelog: false`, so disable
`createGithubReleases` to match that model and stop the action from
expecting generated changelog files.
Constraint: Repository package releases intentionally run with `.changeset/config.json` set to `changelog: false`
Constraint: Existing GitHub Actions runs on 2026-03-25, 2026-03-26, and 2026-03-28 failed with ENOENT on missing package CHANGELOG.md files
Rejected: Add per-package CHANGELOG.md generation | unnecessary extra release surface for a repo that intentionally skips changelog files
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: If you later enable Changesets changelog generation, revisit `createGithubReleases` together with package CHANGELOG.md expectations
Tested: npm run ci; npx changeset status; gh run view failed release logs for runs 23547709848, 23602324893, 23687336625
Not-tested: Live post-fix GitHub Actions release run on main
Switch the npm release workflow to use the repository NPM_TOKEN so first
publishes and subsequent Changesets releases can run from GitHub Actions
without package-by-package trusted publisher setup. Add the missing
kakao-bar-nearby changeset so every current public workspace package is in
the release plan once this lands on main.
Constraint: npm trusted publisher setup requires each package to already exist on the registry
Constraint: This repository is expected to add more public npm packages over time
Rejected: Per-package trusted publishers only | too much first-publish operational overhead for each new package
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep NPM_TOKEN scoped to package publish/write needs and preserve Changesets as the single source of release intent
Tested: npm run ci; npx changeset status; npm view checks for current public workspace package publish state
Not-tested: Live GitHub Actions publish against npm registry with the newly stored token
This snapshots the current repository updates as a coherent release-prep
baseline: workspace/package scaffolding, release automation docs and
workflows, refreshed skill/setup documentation, roadmap expansion, and
the README thumbnail polish.
Constraint: Node packages in this repo must use npm workspaces and Changesets for releases
Constraint: Python release automation stays scaffold-only until a real package exists
Rejected: Split the current work into multiple commits | user asked to commit the current changes together
Confidence: medium
Scope-risk: moderate
Reversibility: clean
Directive: Keep release docs, workflows, and package metadata aligned when adding future packages
Tested: npm run ci
Not-tested: GitHub Actions execution on remote after push
