- 📁 references/
- 📄 README.md
- 📄 RESEARCH.md
- 📄 SKILL.md
Commit, push, branch, and manage version control with GitButler. Use for: commit my changes, check what changed, create a PR, push my branch, view diff, create branches, stage files, edit commit history, squash commits, amend commits, undo commits, pull requests, merge, stash work. Replaces git - use 'but' instead of git commit, git status, git push, git checkout, git add, git diff, git branch, git rebase, git stash, git merge. Covers all git, version control, and source control operations.
Create a well-formed git commit from current changes using session history for rationale and summary; use when asked to commit, prepare a commit message, or finalize staged work. --- # Commit ## Goals - Produce a commit that reflects the actual code changes and the session context. - Follow common git conventions (type prefix, short subject, wrapped body). - Include both summary and rationale in the body. ## Inputs - Codex session history for intent and rationale. - `git status`, `git diff`, and `git diff --staged` for actual changes. - Repo-specific commit conventions if documented. ## Steps 1. Read session history to identify scope, intent, and rationale. 2. Inspect the working tree and staged changes (`git status`, `git diff`, `git diff --staged`). 3. Stage intended changes, including new files (`git add -A`) after confirming scope. 4. Sanity-check newly added files; if anything looks random or likely ignored (build artifacts, logs, temp files), flag it to the user before committing. 5. If staging is incomplete or includes unrelated files, fix the index or ask for confirmation. 6. Choose a conventional type and optional scope that match the change (e.g., `feat(scope): ...`, `fix(scope): ...`, `refactor(scope): ...`). 7. Write a subject line in imperative mood, <= 72 characters, no trailing period. 8. Write a body that includes: - Summary of key changes (what changed). - Rationale and trade-offs (why it changed). - Tests or validation run (or explicit note if not run). 9. Append a `Co-authored-by` trailer for Codex using `Codex <[email protected]>` unless the user explicitly requests a different identity. 10. Wrap body lines at 72 characters. 11. Create the commit message with a here-doc or temp file and use `git commit -F <file>` so newlines are literal (avoid `-m` with `\n`). 12. Commit only when the message matches the staged changes: if the staged diff includes unrelated files or the message describes work that isn't staged, fix the index or revise the message
- 📁 .github/
- 📁 demo/
- 📁 hooks/
- 📄 .gitignore
- 📄 .gitleaks.toml
- 📄 install.sh
Hidden layer of structured git notes for agent collaboration. When working in any git repo, check for mycelium notes on objects you touch (files, directories, commits) before acting, and leave notes after meaningful work. Uses git notes directly — helper script available but not required. --- # Mycelium Structured notes attached to git objects via `refs/notes/mycelium`. **Before working on a file, check for its note. After meaningful work, leave a note.** That's the whole contract. How you work, what you build, how you talk to your user — that's your business. Mycelium just asks you to read the breadcrumbs and leave new ones. ## On arrival
明確提及「Agenvoy」時，一律使用此 skill。若使用者說「這個專案」、「專案進度」等模糊詞彙，且對話歷史（不含 summary）中沒有出現其他專案的明確上下文，則視為在詢問 Agenvoy，同樣使用此 skill。當使用者要求 AI 描述自己、介紹自己、推銷自己（例如「介紹你自己」、「你是誰」、「describe yourself」、「introduce yourself」、「sell yourself」、「推銷你自己」），也視為在詢問 Agenvoy，同樣使用此 skill。當目前工作目錄不存在 .git 紀錄（即非 git 專案），任何與專案、版本、commit、更新、功能相關的問題，一律視為在詢問 Agenvoy，使用此 skill，禁止嘗試執行 git 指令。
- 📁 scripts/
- 📄 examples.md
- 📄 reference.md
- 📄 SKILL.md
Control interactive terminal applications like vim, git rebase -i, git add -i, git add -p, apt, rclone config, sudo, w3m, and TUI apps. Can also supervise another CLI LLM (cursor-agent, codex, etc.) - approve or reject its actions by pressing y/n at confirmation prompts. Use when you need to interact with applications that require keyboard input, show prompts, menus, or have full-screen interfaces. Also use when commands fail or hang with errors like "Input is not a terminal" or "Output is not a terminal". Better than application specific hacks such as GIT_SEQUENCE_EDITOR or bypassing interactivity through file use.
Create a well-formed git commit from current changes using session history for rationale and summary; use when asked to commit, prepare a commit message, or finalize staged work. --- # Commit ## Goals - Produce a commit that reflects the actual code changes and the session context. - Follow common git conventions (type prefix, short subject, wrapped body). - Include both summary and rationale in the body. ## Inputs - Codex session history for intent and rationale. - `git status`, `git diff`, and `git diff --staged` for actual changes. - Repo-specific commit conventions if documented. ## Steps 1. Read session history to identify scope, intent, and rationale. 2. Inspect the working tree and staged changes (`git status`, `git diff`, `git diff --staged`). 3. Stage intended changes, including new files (`git add -A`) after confirming scope. 4. Sanity-check newly added files; if anything looks random or likely ignored (build artifacts, logs, temp files), flag it to the user before committing. 5. If staging is incomplete or includes unrelated files, fix the index or ask for confirmation. 6. Choose a conventional type and optional scope that match the change (e.g., `feat(scope): ...`, `fix(scope): ...`, `refactor(scope): ...`). 7. Write a subject line in imperative mood, <= 72 characters, no trailing period. 8. Write a body that includes: - Summary of key changes (what changed). - Rationale and trade-offs (why it changed). - Tests or validation run (or explicit note if not run). 9. Append a `Co-authored-by` trailer for Codex using `Codex <[email protected]>` unless the user explicitly requests a different identity. 10. Wrap body lines at 72 characters. 11. Create the commit message with a here-doc or temp file and use `git commit -F <file>` so newlines are literal (avoid `-m` with `\n`). 12. Commit only when the message matches the staged changes: if the staged diff includes unrelated files or the message describes work that isn't staged, fix the index or revise the message
Use when preparing to commit changes or drafting a git commit message in this repo. --- # Git Commit & Commit Message (SignNow MCP Server) ## Critical rules * **NEVER commit directly to `main` or `master`.** Always work on a dedicated branch. * Do not commit unless **all required checks** pass (see below). * Keep each commit **one logical change** (single change type). * Commit message follows **Conventional Commits**. ## Workflow 0. **Create (or switch to) a feature branch — MANDATORY** * NEVER commit to `main` or `master` directly. * If not already on a feature branch, create one: * `git checkout -b <type>/<short-description>` (e.g., `feat/add-embedded-editor`, `fix/token-refresh`) * Branch naming: `<type>/<short-description>` using the same type vocabulary as commit types. 1. **Check what changed** * `git status -sb` * If changes are mixed, split into separate commits using `git add -p`. 2. **Review staged diff** * Stage what belongs to this commit. * Inspect: `git diff --cached` 3. **Run required checks (must be green)** ```bash pytest tests/unit/ -v ruff check src/ tests/ ruff format --check src/ tests/ ``` * If any command fails, fix the issue and rerun **all** checks. 4. **Compose the commit message** ### Subject format `<type>(<scope>)?: <subject>` ### Subject rules * Imperative mood ("Add", "Fix", "Remove", "Prevent", ...) * No trailing period * Prefer **≤ 72 chars** ### Body (optional) * Explain **why**, not just what. * Wrap lines at ~80 chars. ### Breaking changes (if applicable) * Add `!` after type/scope: `feat!: ...` or `feat(tools)!: ...` * Add footer: * `BREAKING CHANGE: <what breaks and migration notes>` 5. **Commit** * One-liner (no body/footer needed): * `git commit -m "..."` * Otherwise: * `git commit` and write subject + body in editor. 6. **Post-commit sanity** * `git show --stat` * Ensure no accidental files were committed. 7. **Push** * `git push` 8. **Create Pull Request (if none exists)** * After pushing, check whether a PR already exists
Create a well-formed git commit from current changes using session history for rationale and summary; use when asked to commit, prepare a commit message, or finalize staged work. --- # Commit ## Goals - Produce a commit that reflects the actual code changes and the session context. - Follow common git conventions (type prefix, short subject, wrapped body). - Include both summary and rationale in the body. ## Inputs - Session history for intent and rationale. - `git status`, `git diff`, and `git diff --staged` for actual changes. - Repo-specific commit conventions if documented. ## Steps 1. Read session history to identify scope, intent, and rationale. 2. Inspect the working tree and staged changes (`git status`, `git diff`, `git diff --staged`). 3. Stage intended changes, including new files (`git add -A`) after confirming scope. 4. Sanity-check newly added files; if anything looks random or likely ignored (build artifacts, logs, temp files), flag it to the user before committing. 5. If staging is incomplete or includes unrelated files, fix the index or ask for confirmation. 6. Choose a conventional type and optional scope that match the change (e.g., `feat(scope): ...`, `fix(scope): ...`, `refactor(scope): ...`). 7. Write a subject line in imperative mood, <= 72 characters, no trailing period. 8. Write a body that includes: - Summary of key changes (what changed). - Rationale and trade-offs (why it changed). - Tests or validation run (or explicit note if not run). 9. Wrap body lines at 72 characters. 10. Create the commit message with a here-doc or temp file and use `git commit -F <file>` so newlines are literal (avoid `-m` with `\n`). 11. Commit only when the message matches the staged changes: if the staged diff includes unrelated files or the message describes work that isn't staged, fix the index or revise the message before committing. ## Output - A single commit created with `git commit` whose message reflects the session. ## Template Type and scope are examp
