Run guarded Git workflows with ak:git

Use ak:git when you want AgentKit to perform a defined Git delivery operation with conventional commits, a staged secret scan, remote-aware comparisons, and explicit merge gates. The Skill can change local history and remote repository state, so choose the operation deliberately and review its scope first.

Choose ak:git for delivery operations

Use ak:git when

• You want current changes staged and committed.
• You explicitly want commits pushed to the current remote branch.
• You want a pull request created from a remote branch diff.
• You want one remote branch merged into another and pushed.
• You want a GitHub pull request merged only after readiness checks, then its target-branch CI watched to completion.

Choose another workflow when

• You only need status or a diff. Use ordinary read-only Git commands or the relevant project-status workflow.
• You need code review before delivery. Use ak:code-review.
• You need implementation or a bug fix. Use ak:cook or the fix workflow before invoking Git delivery.
• You are unsure which files belong in the change. Resolve ownership and scope before staging everything.

Prepare the project and runtime

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the runtime and scope you are using.
• Open the intended Git repository and read its branch, commit, review, and merge conventions.
• Review git status, unrelated work, the active branch, remotes, and the operation's exact source and target branches.
• Confirm gh authentication and repository permission before pr or merge-pr.
• Decide whether push, pull-request creation, merge, auto-merge, or follow-up fixes are authorized. A commit request alone does not authorize them.

Run the Skill

/ak:git cm

/ak:git cm

$ak:git cm

With no argument, the Skill presents an operation chooser. Explicit operations are:

merge-pr requires a PR number or URL. The other branch arguments use the documented defaults when omitted.

Understand commit and push behavior

1. The Skill stages the working tree. cm and cp use git add -A, so tracked, untracked, and deleted paths in the repository can enter the staged set.
2. The Skill summarizes the staged diff. It reports file and line changes and classifies paths by code, tests, documentation, configuration, or dependencies.
3. The Skill scans staged content. A keyword and credential-pattern scan blocks the commit when it detects a possible secret.
4. The Skill decides commit boundaries. Mixed types or scopes are split; small changes with one type and scope can remain a single commit.
5. The Skill writes conventional commits. Messages use type(scope): description, imperative wording, and no AI attribution.
6. The Skill pushes only in the selected workflow. cp pushes after the commit. A rejected push is reported rather than silently rewritten.

Understand pull-request and merge behavior

Pull request

The pr workflow fetches the remote, ensures the source branch is available on the remote, and builds the PR from origin/<target>...origin/<source>. It creates a conventional title under 72 characters plus summary and test-plan sections through gh pr create.

The shipped ak:git declaration also includes a native stacked-PR workflow for dependent branches. It treats the public-preview gh stack surface as an external boundary, so availability and behavior there remain controlled outside AgentKit. Rely on this workflow only where the installed Skill declares it; do not infer support for another Skill version or runtime projection.

Branch merge

The merge workflow updates the target branch, merges only the committed and pushed remote source branch with --no-ff, and pushes the target. Conflicts or rejected pushes remain visible for manual resolution.

GitHub PR merge

The workflow first probes GraphQL availability. Readiness reads use native gh pr commands when available and REST fallbacks when GraphQL is blocked. This adaptive path does not make every GitHub operation GraphQL-free: native gh pr merge and auto-merge enablement still rely on GraphQL.

The merge-pr workflow:

1. Checks readiness. The PR must be open, mergeable, free of requested changes, allowed by branch policy, and not have red CI.
2. Selects a merge method. It follows project instructions, recent merged PRs, repository settings, then defaults to a merge commit.
3. Uses the available merge path. With GraphQL available, pending checks may use --auto. The REST fallback cannot enable auto-merge; it polls until checks are terminal-green, refuses non-green results, and then merges through REST. Red checks and conflicts stop either path.
4. Waits for the actual merge. Native auto-merge is polled before post-merge work begins; a wait beyond 30 minutes is reported as a blocker.
5. Watches target-branch CI. Runs for the merge commit are watched to a conclusion.
6. Handles deterministic failures. A repository-fixable post-merge failure can start a separate follow-up fix branch and normal PR flow. External blockers or the same failure after three attempts stop the workflow.
7. Verifies completion. It reports the PR, merge SHA, method, CI results, follow-up fixes, and closes a uniquely matched plan record when applicable.

Keep authority and safety with you

Important gates:

• A possible secret blocks commit creation. Remove or ignore the material and rerun the scan; do not bypass the warning.
• Push requires an explicit push-capable operation. A plain commit does not authorize push.
• Force push is never allowed to main, master, production, or release branches. A feature-branch force push still requires an explicit request and warning because it rewrites history.
• Destructive recovery or branch deletion requires confirmation.
• Protected-branch rules, required review, and red CI are not bypassed.
• GitHub operations require network access, gh authentication, and repository permission. The source defines no separate service price.

The built-in pattern scan is a commit gate, not proof that staged content is secret-free. Apply the repository's dedicated security tooling when required.

Verify the result

Expected evidence includes:

• The staged file count and added and removed lines.
• The security-scan result and any blocked paths.
• Each commit SHA and conventional message.
• The branch and commit hashes pushed, when requested.
• The pull-request URL and remote comparison for pr.
• The source, target, and resulting merge commit for merge.
• The PR URL, merge method and SHA, watched CI conclusions, and any follow-up fixes for merge-pr.

Troubleshoot safely

Know the current limits

• Commit splitting uses path and size heuristics; review the proposed boundaries for semantic correctness.
• Remote comparisons exclude unpushed work by design.
• The secret scan can flag harmless text or miss secrets outside its patterns.
• merge-pr can observe and react to repository CI but cannot bypass external outages, missing permissions, required review, or branch protection.
• Cursor slash invocation is user-verified evidence, not proof of agent or GitHub-tool parity.
• Release evidence establishes the ak:git operations and gates described here; do not infer parity with another Skill version or runtime projection.