feat: rename package to slash-man and add PyPI publishing infrastructure #12
Conversation
Rename specification files for package rename task, updating prefix from 07 to 09 to reflect correct specification numbering. - Rename directory: 07-spec-rename-to-slash-man -> 09-spec-rename-to-slash-man - Update file headers: 07 -> 09 in all spec files - Update filenames to match new prefix convention
- Updated pyproject.toml package name - Updated version detection fallbacks in code - Updated MCP server name to slash-man-mcp - Verified package builds successfully Related to T1.0 in Spec 09
- Updated Docker image names in README.md - Updated MCP server names in operations.md - Updated Docker examples in GitHub_Branch_Download_Bug.md - Updated MCP server reference in mcp-prompt-support.md - Verified no user-facing references remain Related to T2.0 in Spec 09
- Verified CI workflow uses correct Docker image name - Confirmed all references are repository URLs (preserved) - No package-specific references found requiring updates Related to T3.0 in Spec 09
- All 191 tests pass - Package builds successfully - CLI executes correctly - Version detection works - Pre-commit hooks pass - Updated test expectation for new package name Related to T4.0 in Spec 09
- Update server.py docstring to reflect correct command (uvx slash-man mcp) - Update test_config.toml name from test-slash-command-manager to test-slash-man
Add comprehensive validation report verifying all requirements from spec 09-spec-rename-to-slash-man have been met. Report includes coverage matrix, proof artifact verification, and evidence appendix confirming 100% requirement coverage and successful package rename.
Add comprehensive specification for enabling PyPI distribution of slash-man package, including: - Decision questions document covering authentication, triggers, and workflow integration - Complete specification with goals, user stories, functional requirements, and technical considerations - Detailed implementation tasks broken down into actionable steps The specification covers automated PyPI publishing via GitHub Actions using Trusted Publishing (OIDC), build documentation, package metadata updates, and dev release testing workflow.
- Add new 'Building the Package' section with build and publishing instructions - Document python -m build command and its output (wheel and source distribution) - Include manual publishing instructions with twine upload - Add notes about PyPI credentials and Test PyPI vs Production PyPI Related to T1.0 in Spec 10
Related to T1.0 in Spec 10
- Add publish-to-pypi.yml workflow triggered on release events - Configure Trusted Publishing (OIDC) with id-token: write permission - Publish to Test PyPI and Production PyPI using pypa/gh-action-pypi-publish - Upload build artifacts (.whl and .tar.gz) as GitHub release assets - Follow repository workflow patterns (uv, Python 3.12, frozen dependencies) Related to T2.0 in Spec 10
Related to T2.0 in Spec 10
- Add Apache License 2.0 classifier - Add [project.urls] section with homepage, repository, documentation, and issues URLs - Add topic classifiers for AI, code generators, and build tools - Add Environment :: Console classifier - Verify license field configuration - Build succeeds without metadata warnings Related to T3.0 in Spec 10
- Add dev-release job to ci.yml triggered on pull requests - Gate job behind RUN_DEV_RELEASE_JOBS repository variable - Generate dev prerelease version with SHA-based build metadata using semantic-release - Build package and publish to Test PyPI using Trusted Publishing (OIDC) - Verify version contains dev token and SHA prefix - Follow repository workflow patterns (uv, Python 3.12, frozen dependencies) Related to T4.0 in Spec 10
- Change version_variables to version_toml in .releaserc.toml - version_variables is for Python files, version_toml is for TOML files - Update release.yml comment to reflect correct configuration - Files modified by version_toml are automatically committed by semantic-release Fixes issue where pyproject.toml version was not being updated/committed
- Add build_command to .releaserc.toml to run uv lock --upgrade-package after version update - Add step in dev-release job to update uv.lock after semantic-release updates version - build_command ensures uv.lock is updated and staged for main release workflow - Manual uv lock step ensures uv.lock is updated for dev-release job (uses --no-commit) Fixes issue where uv.lock was not updated when pyproject.toml version changed
….lock - Replace 'Update uv.lock and build package' step with verification step - Use uv lock --check to verify lock file is current before version change - Remove redundant uv lock and git add steps (build_command handles this) - Remove build verification step (CI already verified build works) - build_command handles updating uv.lock with new version
WalkthroughPerforms a project rename from Changes
Sequence Diagram(s)sequenceDiagram
participant PR as PR
participant CI as CI Workflow
participant Dev as Dev-Release Job
participant SemRel as semantic-release
participant Build as Build (wheel/sdist)
participant TestPyPI as TestPyPI
PR->>CI: PR with RUN_DEV_RELEASE_JOBS=true
CI->>Dev: start gated dev-release job
Dev->>Dev: checkout (with tags), setup uv + python
Dev->>SemRel: generate prerelease version (embed PR SHA)
SemRel->>Dev: update pyproject.toml / changelog
Dev->>Dev: run build_command (uv lock upgrade) and stage uv.lock
Dev->>Build: build wheel & sdist -> produce dist/
Dev->>Dev: verify artifacts exist
Dev->>TestPyPI: publish artifacts (OIDC)
TestPyPI-->>Dev: publish result
sequenceDiagram
participant Release as Release Event
participant Publish as Publish-to-PyPI WF
participant Build as Build (wheel/sdist)
participant TestPyPI as TestPyPI
participant PyPI as PyPI
participant GHRel as GitHub Release
Release->>Publish: workflow trigger
Publish->>Publish: checkout, setup uv + python, frozen deps
Publish->>Build: build wheel & sdist
Build->>Publish: produce dist/
Publish->>Publish: verify dist/ artifacts (fail if missing)
Publish->>TestPyPI: publish (OIDC)
TestPyPI-->>Publish: success
Publish->>PyPI: publish (OIDC)
PyPI-->>Publish: success
Publish->>GHRel: upload dist/ assets
GHRel-->>Publish: assets attached
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
- Remove --system flag from uv pip install to work with Ubuntu's externally managed Python - Use uv run for semantic-release command to execute in virtual environment - Remove redundant build package install step (already in dev dependencies)
- Add ref: ${{ github.head_ref }} to checkout step
- Fixes semantic-release error: 'Detached HEAD state cannot match any release groups'
- Allows semantic-release to match branch pattern for dev prereleases
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (13)
docs/specs/09-spec-rename-to-slash-man/09-proofs/09-task-03-proofs.md (1)
1-40: Proof artifacts look consistent; minor maintainability nit on line numbersThe CLI output and conclusions match the intended behavior (repo URLs preserved, Docker image already
slash-man-test). The only thing to watch longer term is the hard‑coded line numbers for other files (e.g., “Line 207”): as workflows evolve those may drift, so consider phrasing proofs in terms of content (“step named X uses imageslash-man-test”) rather than exact line numbers in future updates..github/workflows/publish-to-pypi.yml (1)
15-17: Remove redundant job-level permissions.The job-level permissions at lines 15-17 duplicate the workflow-level permissions at lines 7-9. Job-level permissions should only be specified if they differ from the workflow level.
publish: name: Publish to PyPI runs-on: ubuntu-latest - permissions: - id-token: write - contents: write steps:docs/specs/10-spec-pypi-publishing/AUDIT-REPORT.md (1)
68-68: Minor style: Use proper "GitHub" capitalization in text.Per static analysis hint, the official name is "GitHub" with capital H. The audit text uses "github" in several places (e.g., line 68 context).
docs/specs/09-spec-rename-to-slash-man/09-spec-rename-to-slash-man.md (1)
68-69: Minor style: Capitalize "GitHub" in functional requirements.Per static analysis, the official name is "GitHub" with capital H. Update lines where ".github/" paths appear in functional requirement descriptions.
docs/specs/09-spec-rename-to-slash-man/09-validation-rename-to-slash-man.md (2)
27-35: Avoid brittle references (exact line numbers).Referencing exact source line numbers (e.g., “pyproject.toml:6”) will drift. Prefer symbolic anchors or grep snippets that won’t stale.
43-45: Future-proof metrics phrasing.Hardcoding “191 tests pass” will stale quickly. Prefer “all tests pass” with a sample command output link/screenshot.
pyproject.toml (1)
15-25: Optional: add ‘Python :: 3 :: Only’ classifier.Since requires-python is >=3.12, consider adding “Programming Language :: Python :: 3 :: Only” to classifiers.
docs/specs/10-spec-pypi-publishing/10-spec-pypi-publishing.md (2)
96-101: Terminology: pre-release vs prerelease.Use one variant consistently (recommended: “prerelease” to match semantic-release flags).
62-63: Clarify “environment” wording for OIDC.“Environment: pypi” refers to a GitHub Actions Environment (optional but useful for approvals). Trusted Publishing itself must be enabled separately for BOTH PyPI and TestPyPI projects.
docs/specs/10-spec-pypi-publishing/10-proofs/10-task-02-proofs.md (2)
63-73: Make Test PyPI publish re-run safe.Add skip-existing to the Test PyPI step to prevent failures on workflow retries.
Apply in .github/workflows/publish-to-pypi.yml:
- - name: Publish to Test PyPI - uses: pypa/[email protected] + - name: Publish to Test PyPI + uses: pypa/[email protected] with: pypi-url: https://test.pypi.org/legacy/ packages-dir: dist/ + skip-existing: true
19-26: Add environment configuration to the publish job for guardrails and approvals.The workflow currently lacks an environment configuration for the publish job. Adding
environment: pypiwill enable deployment approvals and auditing for PyPI publishing, a security best practice for production releases.Apply in .github/workflows/publish-to-pypi.yml at the publish job level:
publish: name: Publish to PyPI runs-on: ubuntu-latest + environment: pypi permissions: id-token: write contents: writedocs/specs/10-spec-pypi-publishing/10-tasks-pypi-publishing.md (2)
29-29: Capitalize "Markdown" as a proper noun.Use
Markdowninstead ofmarkdownto follow standard capitalization conventions for the technology name.- [x] 1.2 Create a new "Building the Package" section header with appropriate markdown formatting + [x] 1.2 Create a new "Building the Package" section header with appropriate Markdown formatting- [x] 1.9 Verify markdown formatting is correct and consistent with existing README.md style + [x] 1.9 Verify Markdown formatting is correct and consistent with existing README.md styleAlso applies to: 36-36
43-43: Capitalize "GitHub" consistently as a proper noun.Use
GitHubinstead ofGitHub Actionsorgithubto follow standard naming conventions. The platform name is a proper noun and should be capitalized in all instances.Also applies to: 48-48, 94-94, 101-101, 111-111
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
uv.lockis excluded by!**/*.lock
📒 Files selected for processing (33)
.github/workflows/ci.yml(1 hunks).github/workflows/publish-to-pypi.yml(1 hunks).github/workflows/release.yml(1 hunks).releaserc.toml(2 hunks)README.md(2 hunks)RELEASE_NOTES_v1.0.0.md(0 hunks)docs/GITHUB_METADATA_CHECKLIST.md(0 hunks)docs/GitHub_Branch_Download_Bug.md(0 hunks)docs/mcp-prompt-support.md(1 hunks)docs/operations.md(3 hunks)docs/specs/09-spec-rename-to-slash-man/09-proofs/09-task-01-proofs.md(1 hunks)docs/specs/09-spec-rename-to-slash-man/09-proofs/09-task-02-proofs.md(1 hunks)docs/specs/09-spec-rename-to-slash-man/09-proofs/09-task-03-proofs.md(1 hunks)docs/specs/09-spec-rename-to-slash-man/09-proofs/09-task-04-proofs.md(1 hunks)docs/specs/09-spec-rename-to-slash-man/09-questions-1-rename-to-slash-man.md(1 hunks)docs/specs/09-spec-rename-to-slash-man/09-spec-rename-to-slash-man.md(1 hunks)docs/specs/09-spec-rename-to-slash-man/09-tasks-rename-to-slash-man.md(1 hunks)docs/specs/09-spec-rename-to-slash-man/09-validation-rename-to-slash-man.md(1 hunks)docs/specs/10-spec-pypi-publishing/10-proofs/10-task-01-proofs.md(1 hunks)docs/specs/10-spec-pypi-publishing/10-proofs/10-task-02-proofs.md(1 hunks)docs/specs/10-spec-pypi-publishing/10-proofs/10-task-03-proofs.md(1 hunks)docs/specs/10-spec-pypi-publishing/10-proofs/10-task-04-proofs.md(1 hunks)docs/specs/10-spec-pypi-publishing/10-questions-1-pypi-publishing.md(1 hunks)docs/specs/10-spec-pypi-publishing/10-spec-pypi-publishing.md(1 hunks)docs/specs/10-spec-pypi-publishing/10-tasks-pypi-publishing.md(1 hunks)docs/specs/10-spec-pypi-publishing/AUDIT-REPORT.md(1 hunks)mcp_server/__init__.py(2 hunks)pyproject.toml(3 hunks)server.py(1 hunks)slash_commands/__version__.py(1 hunks)slash_commands/generators.py(1 hunks)test_config.toml(1 hunks)tests/test_version.py(1 hunks)
💤 Files with no reviewable changes (3)
- docs/GitHub_Branch_Download_Bug.md
- docs/GITHUB_METADATA_CHECKLIST.md
- RELEASE_NOTES_v1.0.0.md
🧰 Additional context used
🧬 Code graph analysis (1)
mcp_server/__init__.py (1)
slash_commands/cli.py (1)
mcp(828-883)
🪛 LanguageTool
docs/specs/09-spec-rename-to-slash-man/09-questions-1-rename-to-slash-man.md
[style] ~3-~3: Consider using a less common alternative to make your writing sound more unique and professional.
Context: ...r more options, or add your own notes). Feel free to add additional context under any questi...
(FEEL_FREE_TO_STYLE_ME)
docs/specs/09-spec-rename-to-slash-man/09-spec-rename-to-slash-man.md
[style] ~22-~22: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...consistent with the CLI entry point. As a user, I want to see consistent nami...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~22-~22: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... the CLI entry point. As a user, I want to see consistent naming between the packa...
(REP_WANT_TO_VB)
[uncategorized] ~68-~68: The official name of this software platform is spelled with a capital “H”.
Context: ... package name - The system shall update .github/SECURITY.md if it contains package-spe...
(GITHUB)
[uncategorized] ~69-~69: The official name of this software platform is spelled with a capital “H”.
Context: ...in unchanged) - The system shall update .github/ISSUE_TEMPLATE/config.yml if it contai...
(GITHUB)
docs/specs/10-spec-pypi-publishing/10-questions-1-pypi-publishing.md
[style] ~3-~3: Consider using a less common alternative to make your writing sound more unique and professional.
Context: ...r more options, or add your own notes). Feel free to add additional context under any questi...
(FEEL_FREE_TO_STYLE_ME)
docs/specs/09-spec-rename-to-slash-man/09-validation-rename-to-slash-man.md
[uncategorized] ~33-~33: The official name of this software platform is spelled with a capital “H”.
Context: ... GitHub workflows verified | Verified | .github/workflows/ci.yml uses slash-man-test...
(GITHUB)
[style] ~56-~56: This adverb was used twice in the sentence. Consider removing one of them or replacing them with a synonym.
Context: ...ical/contextual references | Verified | Only repository URLs and directory names rem...
(ADVERB_REPETITION_PREMIUM)
[uncategorized] ~57-~57: The official name of this software platform is spelled with a capital “H”.
Context: ...es) | | Unit 3: GitHub Workflows | CLI: `grep -r "slash-command-manager" .github/ --include=".yml" --include=".yaml" -...
(GITHUB)
[uncategorized] ~58-~58: The official name of this software platform is spelled with a capital “H”.
Context: ...es) | | Unit 3: GitHub Workflows | CLI: `cat .github/workflows/ci.yml | grep "docker build"...
(GITHUB)
[uncategorized] ~91-~91: The official name of this software platform is spelled with a capital “H”.
Context: ... configuration files - Files changed:.github/workflows/ci.yml` (verified, no changes...
(GITHUB)
[uncategorized] ~138-~138: The official name of this software platform is spelled with a capital “H”.
Context: ..._Branch_Download_Bug.md- Changed 8. ✅.github/workflows/ci.yml` - Verified (no change...
(GITHUB)
[uncategorized] ~139-~139: The official name of this software platform is spelled with a capital “H”.
Context: ...ml- Verified (no changes needed) 9. ✅.github/SECURITY.md` - Verified (no changes nee...
(GITHUB)
[uncategorized] ~140-~140: The official name of this software platform is spelled with a capital “H”.
Context: ...d- Verified (no changes needed) 10. ✅.github/ISSUE_TEMPLATE/config.yml` - Verified (...
(GITHUB)
docs/specs/09-spec-rename-to-slash-man/09-tasks-rename-to-slash-man.md
[uncategorized] ~17-~17: The official name of this software platform is spelled with a capital “H”.
Context: ...ect history. - The GitHub workflow file .github/workflows/ci.yml already uses `slash-m...
(GITHUB)
[uncategorized] ~18-~18: The official name of this software platform is spelled with a capital “H”.
Context: ...ed changes. - .github/SECURITY.md and .github/ISSUE_TEMPLATE/config.yml only contain...
(GITHUB)
[uncategorized] ~68-~68: The official name of this software platform is spelled with a capital “H”.
Context: ...les #### 3.0 Proof Artifact(s) - CLI: `grep -r "slash-command-manager" .github/ --include=".yml" --include=".yaml" -...
(GITHUB)
[uncategorized] ~69-~69: The official name of this software platform is spelled with a capital “H”.
Context: ...s demonstrates workflows updated - CLI: cat .github/workflows/ci.yml | grep "docker build"...
(GITHUB)
[uncategorized] ~73-~73: The official name of this software platform is spelled with a capital “H”.
Context: ...dated #### 3.0 Tasks - [x] 3.1 Verify .github/workflows/ci.yml: Check if Docker imag...
(GITHUB)
[uncategorized] ~74-~74: The official name of this software platform is spelled with a capital “H”.
Context: ...ther references exist) - [x] 3.2 Verify .github/SECURITY.md: Confirm it only contains ...
(GITHUB)
[uncategorized] ~75-~75: The official name of this software platform is spelled with a capital “H”.
Context: ...ces that need updating - [x] 3.3 Verify .github/ISSUE_TEMPLATE/config.yml: Confirm it ...
(GITHUB)
[uncategorized] ~76-~76: The official name of this software platform is spelled with a capital “H”.
Context: ... [x] 3.4 Run verification grep: Execute `grep -r "slash-command-manager" .github/ --include=".yml" --include=".yaml" -...
(GITHUB)
docs/specs/10-spec-pypi-publishing/AUDIT-REPORT.md
[uncategorized] ~144-~144: The official name of this software platform is spelled with a capital “H”.
Context: ...ate dev version using semantic-release: `semantic-release -c .releaserc.toml version --as-prerelease --prerelease-token dev --build-metadata ${{ github.sha }} --no-push --no-vcs-release --no-...
(GITHUB)
docs/specs/10-spec-pypi-publishing/10-spec-pypi-publishing.md
[style] ~22-~22: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... and require no manual intervention. As a contributor, I want clear build...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~24-~24: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ... and understand the release process. As a project maintainer, I want to t...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[style] ~26-~26: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ow before affecting production PyPI. As a developer working on a pull request...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[uncategorized] ~66-~66: The official name of this software platform is spelled with a capital “H”.
Context: ...uration Proof Artifacts: - CLI: cat .github/workflows/publish-to-pypi.yml demonstr...
(GITHUB)
[uncategorized] ~93-~93: The official name of this software platform is spelled with a capital “H”.
Context: ...a new job dev-release to the existing .github/workflows/ci.yml workflow - The job sh...
(GITHUB)
[uncategorized] ~97-~97: The official name of this software platform is spelled with a capital “H”.
Context: ...he version generation command shall use --as-prerelease --prerelease-token dev --build-metadata ${{ github.sha }} to create versions like `0.1.0-...
(GITHUB)
[uncategorized] ~106-~106: The official name of this software platform is spelled with a capital “H”.
Context: ...or OIDC Proof Artifacts: - CLI: cat .github/workflows/ci.yml demonstrates `dev-rel...
(GITHUB)
[uncategorized] ~116-~116: Do not mix variants of the same word (‘pre-release’ and ‘prerelease’) within a single text.
Context: ...w and is not modified by this spec 5. Pre-release Testing Workflow - Automated testing ...
(EN_WORD_COHERENCY)
[uncategorized] ~116-~116: Do not mix variants of the same word (‘pre-release’ and ‘prerelease’) within a single text.
Context: ...ncluded via dev release job, but manual pre-release validation workflows are out of scope 6...
(EN_WORD_COHERENCY)
[uncategorized] ~128-~128: The official name of this software platform is spelled with a capital “H”.
Context: ...Workflow Structure: Follow existing .github/workflows/ patterns (see ci.yml and ...
(GITHUB)
[uncategorized] ~154-~154: The official name of this software platform is spelled with a capital “H”.
Context: ...se versions on pull requests: - Uses semantic-release version --as-prerelease --prerelease-token dev --build-metadata ${{ github.sha }} to create versions like `0.1.0-...
(GITHUB)
docs/specs/09-spec-rename-to-slash-man/09-proofs/09-task-03-proofs.md
[uncategorized] ~38-~38: The official name of this software platform is spelled with a capital “H”.
Context: ...slash-man-test) - ✅ All references in .github/ directory are repository URLs - ✅ No ...
(GITHUB)
docs/specs/10-spec-pypi-publishing/10-tasks-pypi-publishing.md
[uncategorized] ~29-~29: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...ackage" section header with appropriate markdown formatting - [x] 1.3 Add build instruct...
(MARKDOWN_NNP)
[uncategorized] ~36-~36: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...the build instructions - [x] 1.9 Verify markdown formatting is correct and consistent wi...
(MARKDOWN_NNP)
[uncategorized] ~43-~43: The official name of this software platform is spelled with a capital “H”.
Context: ...w #### 2.0 Proof Artifact(s) - CLI: cat .github/workflows/publish-to-pypi.yml demonstr...
(GITHUB)
[uncategorized] ~48-~48: The official name of this software platform is spelled with a capital “H”.
Context: ...## 2.0 Tasks - [x] 2.1 Create new file .github/workflows/publish-to-pypi.yml with wor...
(GITHUB)
[uncategorized] ~94-~94: The official name of this software platform is spelled with a capital “H”.
Context: ...g #### 4.0 Proof Artifact(s) - CLI: cat .github/workflows/ci.yml demonstrates new `dev...
(GITHUB)
[uncategorized] ~101-~101: The official name of this software platform is spelled with a capital “H”.
Context: ...ability #### 4.0 Tasks - [x] 4.1 Open .github/workflows/ci.yml and locate the end of...
(GITHUB)
[uncategorized] ~111-~111: The official name of this software platform is spelled with a capital “H”.
Context: ...e step with id: dev-version that runs `semantic-release -c .releaserc.toml version --as-prerelease --prerelease-token dev --build-metadata ${{ github.sha }} --no-push --no-vcs-release --no-...
(GITHUB)
docs/specs/10-spec-pypi-publishing/10-proofs/10-task-02-proofs.md
[uncategorized] ~136-~136: The official name of this software platform is spelled with a capital “H”.
Context: ...tionality ✅ Workflow File Created: .github/workflows/publish-to-pypi.yml exists w...
(GITHUB)
🔇 Additional comments (21)
.releaserc.toml (1)
13-16: No issues identified — the $PACKAGE_NAME variable is a standard python-semantic-release feature.python-semantic-release automatically injects PACKAGE_NAME from the project.name field in pyproject.toml, making the configuration correct as-is. No changes are needed.
docs/specs/10-spec-pypi-publishing/10-proofs/10-task-03-proofs.md (1)
1-116: PyPI metadata proofs are clear and internally consistentThe captured classifiers,
[project.urls]block, and build output line up with the described configuration, and the “no metadata warnings” conclusion is justified. Using concrete build logs and explicit classifier lists makes this a solid, auditable proof artifact.docs/specs/09-spec-rename-to-slash-man/09-questions-1-rename-to-slash-man.md (1)
1-90: Rename decision record is coherent and matches implementationThe questionnaire cleanly documents the key decisions (PyPI name
slash-man, repo name staying asslash-command-manager, code/docs/ Docker updates, testing strategy). Those choices line up with the code and workflow changes in this PR, so this is a helpful source of intent for future maintainers.docs/specs/09-spec-rename-to-slash-man/09-proofs/09-task-04-proofs.md (1)
1-103: Comprehensive post-rename verification looks goodThis proof doc does a nice job covering the full surface (pytest, build artifacts, CLI help/version, pre-commit, and a clean Docker environment). The captured outputs align with the new
slash-manname and give strong evidence that behavior is unchanged aside from naming.docs/specs/10-spec-pypi-publishing/10-questions-1-pypi-publishing.md (1)
1-90: PyPI publishing decisions align with the new workflowsThe selected options (Trusted Publishing, release-triggered separate workflow, Test PyPI → Prod flow, basic build verification) match the implemented CI and
publish-to-pypi.ymlsetup, so this serves as a clear rationale document for the publishing strategy.docs/specs/09-spec-rename-to-slash-man/09-proofs/09-task-01-proofs.md (1)
1-60: Config rename proofs accurately capture the state after the changeThe pyproject name check, code-reference grep, and build output all consistently show the move to
slash-man, with only an expected comment referring to the repo directory name. The “Files Modified” and verification bullets correctly summarize those findings.mcp_server/__init__.py (1)
11-31: Version fallback and MCP name updates correctly track the new package nameSwitching the fallback to
version("slash-man")and renaming the FastMCP app to"slash-man-mcp"are consistent with the pyproject rename. All version references across the codebase (slash_commands/__version__.py,mcp_server/__init__.py, andslash_commands/generators.py) consistently use"slash-man", which matchespyproject.toml..github/workflows/release.yml (1)
71-86: I need to verify the full.releaserc.tomlconfiguration to ensure the semantic-release plugin chain and build_command lifecycle are correctly coordinated with the preflight check.Alignment check passed—no action needed
The preflight
uv lock --checkstep and the.releaserc.tomlbuild_command are properly coordinated. The build_command executes after changelog generation, which means the version is stamped first (viaversion_toml) and thenuv lock --upgrade-packageruns during the build phase, exactly as the workflow comments describe. The implementation is sound and ready as-is..github/workflows/ci.yml (3)
253-257: Clarify whyuv lock --upgrade-package slash-manis needed after semantic-release version change.After semantic-release updates
pyproject.tomlwith the new version,uv lock --upgrade-package slash-manis called. Verify that:
- This step correctly updates
uv.lockto reflect the version inpyproject.toml- The command doesn't introduce unrelated dependency updates
- This is necessary (consider if
uv lockwithout--upgrade-packagewould suffice)Based on the broader context, this appears to be ensuring the lock file includes the updated package version before build. Confirm this is the intended behavior and not a workaround.
259-269: Verify version verification logic handles edge cases correctly.The version verification at lines 261-268 checks for
devsubstring and SHA prefix. Confirm:
- The regex patterns
=~ devand=~ $SHA_SHORTare appropriate- The error messaging is clear if verification fails
- This won't produce false positives (e.g., if version naturally contains "dev" elsewhere)
246-251: The semantic-release command syntax and output format are correct.The
--as-prerelease --prerelease-token dev --build-metadata ${{ github.sha }}, the output will include both the 'dev' token and the full SHA as build metadata (e.g.,0.2.0.dev0+abc123def456...), matching the verification regex expectations at line 264. The variable capture and GITHUB_OUTPUT export work correctly. All flags used are appropriate for semantic-release 10.x..github/workflows/publish-to-pypi.yml (1)
55-64: Confirm intended behavior of publishing to both Test PyPI and Production PyPI.The workflow publishes artifacts to both Test PyPI (lines 55-59) and Production PyPI (lines 61-64) in sequence. This appears intentional (to verify in Test PyPI before Production), but confirm:
- Is this the desired behavior or should it be conditional?
- Should there be a manual approval gate between the two publishes?
- Are Test PyPI and Production PyPI artifacts the same or should they differ?
README.md (2)
253-253: Docker references updated consistently to reflect package rename.The Docker image name has been correctly updated from
slash-command-managertoslash-manacross all usage examples. ✅Also applies to: 256-256, 259-259
285-320: Verified: No duplicate sections found.The verification confirms that only one "## Building the Package" section exists in the README.md file. The documentation structure is correct, and there are no duplicate or conflicting sections.
docs/specs/10-spec-pypi-publishing/AUDIT-REPORT.md (1)
1-50: Audit report is comprehensive and well-structured, but verify recommendations are implemented.The audit document provides detailed analysis of the PyPI publishing spec with clear categorization of issues by severity. However, cross-reference with actual implementation:
- Critical issue about unit numbering (lines 11-39) - verify if spec has been reordered
- Important issues about syntax and artifact handling - verify if .github/workflows/publish-to-pypi.yml implements the recommendations
Specifically verify:
- Does
publish-to-pypi.ymlusesoftprops/action-gh-release@v2as recommended (line 85-89)?- Are unit numbers in the original spec sequential (1,2,3,4) as recommended?
docs/specs/10-spec-pypi-publishing/10-proofs/10-task-04-proofs.md (1)
1-40: Proof artifacts for dev-release job are well-documented and comprehensive.The document provides clear CLI output, YAML validation, and configuration details for the Task 4.0 (Dev Release job). The verification checklist at lines 136-171 covers all major requirements:
- Job creation and trigger conditions ✓
- Semantic-release version generation ✓
- Version verification with dev tag and SHA ✓
- Build and publish steps ✓
- OIDC trusted publishing configuration ✓
However, verify that the job implementation in
.github/workflows/ci.ymlmatches these documented expectations.docs/specs/09-spec-rename-to-slash-man/09-spec-rename-to-slash-man.md (1)
1-50: Package rename specification is comprehensive and well-structured.The spec clearly defines goals, units of work, success metrics, and verification steps for renaming the package from
slash-command-managertoslash-man. The four units of work provide a logical progression:
- Package configuration updates
- Documentation updates
- Workflow and external reference updates
- Verification and testing
The spec aligns well with the implementation visible in this PR. Verify that all success metrics (lines 152-158) have been achieved.
docs/specs/10-spec-pypi-publishing/10-proofs/10-task-01-proofs.md (1)
1-84: Proof artifacts for build documentation task are clearly documented.The proof document outlines the "Building the Package" section added to README.md with:
- Build process documentation ✓
- Wheel and sdist explanation ✓
- Manual publishing instructions with twine ✓
- Test PyPI vs Production PyPI guidance ✓
- Credentials documentation (API token or username/password) ✓
Verify that the actual README.md section matches the expected content outlined in the Configuration section (lines 61-84).
docs/specs/09-spec-rename-to-slash-man/09-proofs/09-task-02-proofs.md (1)
1-40: Proof artifacts for documentation updates follow sound verification approach.The document demonstrates that user-facing references to
slash-command-managerhave been removed from:
- README.md
- docs/operations.md
- docs/GitHub_Branch_Download_Bug.md
- docs/mcp-prompt-support.md
The grep-based verification strategy appropriately distinguishes between unacceptable user-facing references and acceptable repository URL/directory name references. ✓
However, the line numbers provided (e.g., lines 253, 256, 259 for README.md) should be verified against the actual updated files to ensure accuracy.
pyproject.toml (1)
37-41: Confirm repository URL intent.URLs point to the existing “slash-command-manager” repository. If repo rename is not planned (as PR states), this is correct; otherwise update before release.
docs/specs/10-spec-pypi-publishing/10-tasks-pypi-publishing.md (1)
1-118: Well-structured specification document with comprehensive task coverage.The file provides clear, organized documentation of PyPI publishing tasks with well-defined proof artifacts and completion checkpoints. The four main tasks (README build docs, PyPI workflow, metadata updates, and dev-release job) are comprehensive and align with the PR objectives.
| - Screenshot: README.md installation section shows `uv slash-man` commands demonstrates installation instructions updated | ||
| - CLI: `grep -r "slash-command-manager" docs/*.md` shows only historical/contextual references demonstrates user docs updated |
There was a problem hiding this comment.
Use ‘uvx’ for one-shot CLI execution.
Replace “uv slash-man” with “uvx slash-man” in the installation proof text.
🤖 Prompt for AI Agents
In docs/specs/09-spec-rename-to-slash-man/09-tasks-rename-to-slash-man.md around
lines 46 to 47, the installation proof text still uses the old one-shot CLI
invocation "uv slash-man"; update both occurrences to "uvx slash-man" (including
the README/screenshot description and the CLI grep note) so the documentation
shows the new one-shot command; ensure the text and any inline examples are
changed consistently to "uvx slash-man".
| - The workflow shall require `id-token: write` and `contents: read` permissions for OIDC | ||
| - The workflow shall use a PyPI environment named `pypi` for Trusted Publishing configuration | ||
|
|
There was a problem hiding this comment.
Align permissions with stated behavior.
Uploading release assets requires contents: write. Update the requirement (or drop the asset-upload requirement) to avoid confusion.
🤖 Prompt for AI Agents
In docs/specs/10-spec-pypi-publishing/10-spec-pypi-publishing.md around lines 61
to 63, the spec currently requires `id-token: write` and `contents: read` but
the described behavior includes uploading release assets which requires
`contents: write`; update the permissions to `id-token: write` and `contents:
write` (or explicitly remove the asset-upload requirement from the workflow
description if you intend to keep `contents: read`) and ensure the Trusted
Publishing `pypi` environment text and any examples reflect the chosen
permission set.
- Replace pypi-url with repository-url for Test PyPI publishing - Fixes deprecation warning in pypa/gh-action-pypi-publish action
- Use git rev-parse --short HEAD instead of github.sha for shorter build metadata - Add --no-changelog flag to skip changelog generation for dev releases - Remove redundant uv.lock update step (build_command handles this automatically) - Add verification step to ensure uv.lock and pyproject.toml are updated - Add commit_message to .releaserc.toml with [skip ci] to prevent CI loops
There was a problem hiding this comment.
Actionable comments posted: 1
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/ci.yml(1 hunks).releaserc.toml(2 hunks)
🔇 Additional comments (3)
.releaserc.toml (1)
13-16: Verify that$PACKAGE_NAMEenvironment variable is available in semantic-release build_command context.The
build_commandreferences$PACKAGE_NAME, but this is not a standard semantic-release variable. If this variable is undefined, theuv lockcommand may fail or behave unexpectedly.Either confirm that
$PACKAGE_NAMEis set by your CI environment, or simplify the command touv lockto update the entire lock file without requiring a specific package name:build_command = """ - uv lock --upgrade-package "$PACKAGE_NAME" + uv lock git add uv.lock """.github/workflows/ci.yml (2)
285-291: Inconsistency: Test PyPI publish uses token authentication instead of OIDC Trusted Publishing as stated.The PR objectives claim "Security uses PyPI Trusted Publishing (OIDC; no API tokens required)", but line 289 uses
secrets.TEST_PYPI_API_TOKEN. The job correctly requestsid-token: writepermission (line 217), but then authenticates with a password secret instead of using the OIDC token.For consistency and to align with the stated security posture, verify whether Test PyPI supports OIDC and update to use environment variable-based OIDC authentication if available.
If Test PyPI requires token authentication, update the PR objectives or add a comment explaining why OIDC is used for production but not Test PyPI.
244-250: Verify semantic-release command compatibility with combined flags.The
semantic-release versioncommand at line 247 combines--as-prerelease,--prerelease-token dev, and--build-metadataflags. Confirm that this combination produces the intended prerelease version format (e.g.,0.1.0-dev.123+abc1234).Consider adding a comment in the workflow documenting the expected version format for future maintainers.
| - name: Verify uv.lock and pyproject.toml were updated | ||
| run: | | ||
| if ! git diff --exit-code uv.lock pyproject.toml; then | ||
| echo "❌ uv.lock and pyproject.toml were not updated" | ||
| exit 1 | ||
| fi | ||
| echo "✅ uv.lock and pyproject.toml were updated" |
There was a problem hiding this comment.
Critical: Inverted git diff logic will cause dev-release to fail when files ARE updated.
The condition if ! git diff --exit-code uv.lock pyproject.toml evaluates to true when files DIFFER (i.e., were updated), but the error message indicates the opposite intent. This will fail the job when the version update succeeds.
git diff --exit-code returns 0 for no changes and 1 for changes. Remove the ! negation:
- - name: Verify uv.lock and pyproject.toml were updated
+ - name: Verify uv.lock and pyproject.toml are unchanged by dev version
run: |
- if ! git diff --exit-code uv.lock pyproject.toml; then
- echo "❌ uv.lock and pyproject.toml were not updated"
+ if git diff --exit-code uv.lock pyproject.toml; then
+ echo "❌ uv.lock and pyproject.toml were unexpectedly modified"
exit 1
fi
- echo "✅ uv.lock and pyproject.toml were updated"
+ echo "✅ uv.lock and pyproject.toml are unchanged"(Alternatively, if the intent is to verify the files WERE updated, use git diff HEAD to check against the previous commit rather than the working tree.)
🤖 Prompt for AI Agents
.github/workflows/ci.yml around lines 264 to 270: the current check inverts the
git-diff logic by using `if ! git diff --exit-code uv.lock pyproject.toml`,
which causes the job to fail when the files have changed; remove the leading
negation so the condition reads `if git diff --exit-code ...` to fail when there
are differences, or if the goal is to verify that the files were updated
relative to the previous commit, change the check to compare against HEAD (e.g.,
`git diff --exit-code HEAD -- uv.lock pyproject.toml`); update the error/success
messages accordingly.
Why?
This PR enables PyPI distribution of the
slash-manpackage and renames the package fromslash-command-managertoslash-manfor consistency. The changes add complete automated publishing workflows and update package metadata to meet PyPI requirements, making the package installable viapip install slash-mananduvx slash-man.Evidence:
19d3a94throughd6b06d8rename the package and update all references8a15de6througha2b0b07add complete PyPI publishing infrastructure per Spec 1099f6eb6updatespyproject.tomlmetadata for PyPI requirementscb9c654creates the PyPI publishing workflow846a3de,082128a, anda2b0b07fix semantic-release configuration issuesWhat Changed?
Key Changes:
Package Rename:
slash-command-managertoslash-maninpyproject.toml(commit19d3a94)07prefix to09prefix to reflect the changePyPI Publishing Infrastructure:
README.md(commitb6d328f).github/workflows/publish-to-pypi.ymlworkflow for automated publishing on GitHub releases (commitcb9c654)pyproject.tomlmetadata with PyPI-required fields:[project.urls]section with homepage, repository, documentation, and issues linksdev-releasejob to CI workflow for Test PyPI publishing on pull requests (commit1a551a3)RUN_DEV_RELEASE_JOBSrepository variableSemantic-Release Configuration Fixes:
.releaserc.tomlto useversion_tomlinstead ofversion_variablesfor TOML files (commit846a3de)build_commandto ensureuv.lockis updated when version changes (commit082128a)build_commandhandlesuv.lockupdates (commita2b0b07)Files Modified:
pyproject.toml- Package name, metadata, and URLs.github/workflows/publish-to-pypi.yml- New workflow for PyPI publishing.github/workflows/ci.yml- Addeddev-releasejob.github/workflows/release.yml- Simplified workflow withbuild_commandhandling.releaserc.toml- Fixed version configuration and addedbuild_commandREADME.md- Added build documentation sectiondocs/specs/10-spec-pypi-publishing/- Complete specification and task documentationAdditional Notes
slash-man.id-token: writepermission needed.buildpackage for CI workflows (dev dependency).RUN_DEV_RELEASE_JOBSmust be set to'true'to enable dev release job on PRspypienvironment)RUN_DEV_RELEASE_JOBSrepository variable is set to'true'release.publishedevent)docs/specs/10-spec-pypi-publishing/)slash-man(seedocs/specs/09-spec-rename-to-slash-man/)Review Checklist
Summary by CodeRabbit
New Features
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.