菜单
Use when starting new work in this repo, committing, or opening a PR — "start a new feature", "commit this", "open a PR", "what branch should this target". Covers the branch-naming, conventional-commit, and dev→main release flow specific to this repo (semantic-release, squash merge).
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/AmineDjeghri/personal-os-setup --skill ship-feature命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use when adding/debugging a chezmoi run_/run_once_/run_onchange_ script under config/chezmoi/, or when a dotfiles sync script "isn't firing" — "why didn't my script run", "add a script that starts X after sync", "the hyprland/noctalia script isn't triggering". Covers how this app's "apply selected" scopes chezmoi apply to specific targets, and why that means scripts often don't run even though their sibling config file did apply.
Use when adding a new TUI button/action (system action) or a new package-manager backend to personal-os-setup — e.g. "add a button to do X", "support a new package manager", "add a new tab/section". Covers the factory.py section-builder pattern, the managers/_shared.py boilerplate pattern, and the required test additions.
Use when adding/editing documentation pages, or building/previewing/deploying the properdocs (mkdocs) site — "add a doc page", "preview the docs site", "deploy docs", "why isn't my new page showing up". Covers properdocs.yml's docs_dir:. quirk, the exclude-glob trap for new top-level directories, and the auto-generated API reference/example pages.
基于 SOC 职业分类
正在显示 SKILL.md
| name | ship-feature |
| description | Use when starting new work in this repo, committing, or opening a PR — "start a new feature", "commit this", "open a PR", "what branch should this target". Covers the branch-naming, conventional-commit, and dev→main release flow specific to this repo (semantic-release, squash merge). |
This repo drives releases from commit messages via python-semantic-release, so the branch/PR/commit conventions are load-bearing, not stylistic.
⚠️ Committing is local and reversible — fine to do once asked. But git push, opening a PR, and especially anything touching main/release branches are visible-to-others/hard-to-reverse actions: confirm with the user before pushing or opening a PR, even if they already asked for the feature itself. This is the general repo-wide rule from CLAUDE.md § "Safety: always confirm before system-mutating actions", applied to git/GitHub actions specifically.
dev, never main. Naming: feature/your-feature-name or bugfix/your-bug-name.dev → main is a separate promotion PR done later by a maintainer — don't target main directly for feature work.git checkout dev && git pull before branching, to start from a fast-forward-clean base.Conventional Commits, gitmoji prefix optional: [emoji] <type>[(<scope>)][!]: <description>.
| type | release bump |
|---|---|
fix, perf | patch |
feat | minor |
feat! / BREAKING CHANGE: footer | major |
chore, ci, docs, style, refactor, test, build | no release |
Examples: ✨ feat(auth): add GitHub App token rotation, 🐛 fix(llm): handle null response from API. Full type/emoji table and scope list in CONTRIBUTING.md.
Never manually bump the version in pyproject.toml — semantic-release does it on merge. Never create tags manually.
⚠️ commitizen's commit-message check only runs at git's commit-msg hook stage — make pre-commit (pre-commit run --all-files) does not exercise it. Passing make pre-commit gives no signal about whether your commit message itself is well-formed; only a real git commit does. See [[repo-gotchas]].
make test — unit tests only (uv run pytest tests/unit). Safe to run anytime.make pre-commit — installs hooks then runs them on all files (ruff check+format, detect-secrets, check-yaml/json/toml, uv-lock sync). CI runs this exact command, so a local pass means CI's pre-commit job passes. See [[run-tests]] for what make test does not cover (integration tests are destructive — don't run them casually).dev: git merge dev (if already pushed, safe) or git rebase dev (if only local, cleaner history) — either is fine since PR merge always squashes anyway. Re-run make test/make pre-commit after syncing.dev, not main.feat: add new plugin) — all PRs squash-merge, and the PR title becomes the commit message semantic-release evaluates.ci.yml → quality-and-tests.yml) runs make pre-commit then, in parallel, make test plus OS-specific make test-integration jobs (integration-ubuntu, integration-macos — these genuinely install/upgrade real packages on the CI runner, that's expected there, just never run test-integration on your own machine).dev → 🔶 Release — Dev cuts an RC prerelease (v1.1.0-rc.1, incrementing per releasable commit).dev → main; merging that → 🚀 Release — Main cuts the stable release + GitHub Release, and deploys docs only if a release actually happened (an all-docs:/chore: PR won't trigger a docs deploy even if docs content changed — see [[docs-site]]).main↔dev sync conflicts (CHANGELOG.md/pyproject.toml) — that's a maintainer step, not part of a normal feature PR.Full step-by-step with exact git commands: CONTRIBUTING.md § "4.4 Pushing your work" and § "Step-by-step: shipping a feature to production" (note: a few CONTRIBUTING.md claims about local tooling are stale — see [[repo-gotchas]] before trusting it literally).
For test conventions specific to frontend/factory code (never invoke real package managers from a test), see [[add-system-action]] and [[run-tests]].