submit - SKILL.md Agent Skill

name: submit description: Complete submission workflow - quality checks, commit, PR creation, changelog generation, and final push. Use after finishing implementation work.

Submit Workflow

Automates the post-implementation submission pipeline: quality enforcement, commit, PR creation, changelog, and push.

Parameters

jira_key (optional): JIRA issue key (e.g., BA-1234). Auto-detected from branch name if pattern BA-\d+ exists.
changelog_type (optional): One of breaking, feature, enhance, deprecation, fix, doc, deps, misc, test. If omitted, infer from the most significant change.
changelog_message (optional): One-line English summary for the news fragment. If omitted, generate from PR description.
base_branch (optional): Target branch for PR. Defaults to main.

Workflow

Phase 1: Pre-flight

Detect JIRA key
- Check if user provided jira_key
- Otherwise extract from current branch name (pattern: BA-\d+)
- If not found, ask user
Review changes
- git status to see all changed/untracked files
- git diff and git diff --staged to review content
- git log {base_branch}..HEAD to see existing commits on branch
- Summarize changes to user before proceeding

Phase 2: Quality Enforcement (Local)

MANDATORY - never skip.

Run sequentially, stop on first failure:

pants fmt ::
pants fix ::
pants lint --changed-since=origin/{base_branch}

If fmt or fix produce changes, stage them automatically
If lint fails, fix the issues and re-run
After all pass, continue to next phase

Note: Type checking (pants check) and tests (pants test) are enforced by CI only. Do NOT run them locally — they consume excessive resources when multiple workers run concurrently.

Phase 3: Commit

Stage changes
- git add specific files (avoid -A to prevent accidental inclusion of secrets)
- Never stage .env, credentials, or other sensitive files
Generate commit message
- Use conventional commit style: type(BA-XXXX): description
- Types: fix, feat, refactor, test, doc, ci, chore, perf
- When a JIRA key is available, ALWAYS use it as the conventional commit scope. Never use component names like manager, client, client-sdk as the scope.
- Example: fix(BA-1234): resolve session cleanup race condition
- Keep first line under 80 characters
- Add detailed body if multiple significant changes
Create commit
- Present draft message to user for approval
- Commit with approved message

Phase 4: PR Creation

Push branch
- git push -u origin {branch_name}
Generate PR content
- Title: Conventional commit style with JIRA key as scope
  - Format: type(BA-XXXX): description
  - Example: fix(BA-1234): resolve session cleanup race condition
- Body: Use this template:
```
## Summary
<1-3 bullet points describing what changed and why>

## Test plan
- [ ] <test items>

Resolves BA-XXXX
```

Create PR

gh pr create --title "..." --body "..."

Extract PR number from gh pr create output

Phase 5: Changelog (News Fragment)

Determine changelog type (if not provided)

Map from PR content:
- New functionality → feature
- Bug fix → fix
- Performance/refactoring → enhance
- Breaking API change → breaking
- Test-only change → test
- Documentation → doc
- Dependency update → deps

Valid types (from pyproject.toml):

Type	Category
`breaking`	Breaking Changes
`feature`	Features
`enhance`	Improvements
`deprecation`	Deprecations
`fix`	Fixes
`doc`	Documentation Updates
`deps`	External Dependency Updates
`misc`	Miscellaneous
`test`	Test Updates

Generate changelog message (if not provided)
- Single-line English sentence
- Imperative/commanding form: "Fix XXX", "Add YYY", "Support ZZZ"
- Or complete sentence: "Now it does ZZZ"
- Focus on what the change means to users/developers, not implementation details
Create file
- Path: changes/{pr_number}.{changelog_type}.md
- Content: single-line changelog message
- Show draft to user for approval

Commit and push

git add changes/{pr_number}.{changelog_type}.md
git commit -m "changelog: add news fragment for PR #{pr_number}"
git push

Phase 6: Summary

Report final status:

Submission Complete

  PR:        #{pr_number} - {title}
  URL:       https://github.com/lablup/backend.ai/pull/{pr_number}
  JIRA:      BA-XXXX
  Branch:    {branch_name}
  Changelog: changes/{pr_number}.{changelog_type}.md

Quality checks: All passed
Commits: {count} commit(s)

Error Handling

Quality check failure

Quality check failed at: {step}

Error:
{error_output}

Options:
1. Fix issues and re-run /submit
2. Address specific failures manually

No changes to commit

No changes detected.

Working tree is clean. Nothing to submit.

PR creation failure

PR creation failed: {error}

Possible causes:
- Branch not pushed (will auto-push)
- PR already exists for this branch
- Authentication issue with gh CLI

Check: gh auth status

Branch has no JIRA key

No JIRA issue key found.

Options:
1. Provide JIRA key: /submit BA-1234
2. Create new issue: /jira-issue
3. Continue without JIRA key (not recommended)

Examples

Basic usage (auto-detect everything)

User: /submit
Agent: [Detects BA-1234 from branch, runs quality checks, commits, creates PR, generates changelog]

With explicit JIRA key

User: /submit BA-5678
Agent: [Uses BA-5678, runs full workflow]

With all parameters

User: /submit BA-5678 --type=fix --message="Fix session cleanup race condition when agent disconnects"
Agent: [Uses provided parameters, runs full workflow]

After jira-issue skill

User: /jira-issue → creates BA-9999
User: [implements feature]
User: /submit BA-9999
Agent: [Full submission with BA-9999 reference]

Related Skills

/jira-issue - Create JIRA issue before starting work
/tdd-guide - TDD workflow (run before /submit)

Implementation Notes

Local quality checks (fmt, fix, lint) use --changed-since=origin/{base_branch} to cover all PR changes, not just the last commit
Type checking and tests run in CI only — do not run them locally
Changelog follows towncrier format configured in pyproject.toml
PR number is only available after gh pr create, so changelog is always a second commit
A single PR may have multiple news fragments (e.g., both feature and fix)
News fragment content should be a single-line sentence per changes/README.md guidelines