메뉴
Spectra git and release workflows: conventional commits, branches, PRs, version bumps, release tags, merge conflicts, changelog. Use for commit, branch, PR, release, version.txt, squash merge, cherry-pick, or git status/diff questions.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Serena MCP Tools — Semantic code analysis and editing with clangd for C++20 and Python
Use for any question about a codebase, its architecture, file relationships, or project content — especially when graphify-out/ exists, where the question should be treated as a graphify query first. Turns any input (code, docs, papers, images, videos) into a persistent knowledge graph with god nodes, community detection, and query/path/explain tools.
Drives a live Spectra instance via the embedded MCP automation server (default http://127.0.0.1:8765/mcp). Use for smoke tests, screenshots, UI commands, figure/series setup, and visual debugging after builds — whenever validating rendering without writing a harness.
Spectra Agent Skill Set
Plan, design, and implement Spectra C++/GLSL/Python changes. Use when breaking down a feature, making architecture decisions before coding, or writing/fixing source in src/, include/spectra/, shaders, tests, or python/.
Fix or edit Spectra GitHub Actions (.github/workflows). Use for CI failures, new matrix jobs, golden/sanitizer jobs, release.yml, lavapipe/xvfb setup, or masking vs root-cause CI fixes.
| name | git-manager |
| description | Spectra git and release workflows: conventional commits, branches, PRs, version bumps, release tags, merge conflicts, changelog. Use for commit, branch, PR, release, version.txt, squash merge, cherry-pick, or git status/diff questions. |
Repo: danlil240/Spectra · default branch: main (stable, demo-ready) · version: version.txt (semver) · release: push v<version> tag → release.yml
Commits: Conventional — feat|fix|refactor|test|docs|ci|perf|chore: description (≤72 chars subject)
main for normal work (exceptions: user explicitly asks, or trivial docs-only).main, amend published commits, or --no-verify unless user asks.git status + git stash list.release/<version>; tag main only after merge; push tag separately: git push origin v<version>.| User says | Do |
|---|---|
| commit my changes | branch off main → commit → push → open PR |
| open a PR | commit if needed → push branch → gh pr create to main |
| bump version | release/<ver> → update version.txt → PR |
| release version X | merge bump PR → tag vX on main → push tag |
| merge the PR | check CI → gh pr merge --squash --delete-branch if safe |
git status && git diff --stat
git fetch origin && git pull --rebase origin main # if on main, branch first
git switch -c <type>/<short-slug> # feat|fix|refactor|docs|ci|release
git add -p # or specific files
git commit -m "<type>: <description>"
git push -u origin HEAD
gh pr create --base main --title "<type>: <description>" --body "$(cat <<'EOF'
## Summary
- What / why
## Testing
- [ ] `cmake --build build -j$(nproc)`
- [ ] `ctest --test-dir build -LE gpu --output-on-failure`
EOF
)"
Branch names: <type>/<short-slug> (e.g. fix/lavapipe-icd-discovery)
Work committed on main locally: git switch -c <branch> → push → PR → git switch main && git reset --hard origin/main (only if safe).
After a PR is squash-merged into main, delete the remote PR branch and clean up the local branch.
Preferred command:
gh pr merge --squash --delete-branch
## Output
```text
Action: <what>
Command: <exact>
Result: PASS/FAIL or one line
Next: <step or done>
Details: hotfix, squash, cherry-pick, changelog, conflict resolution → references/git-manager-reference.md