home / skills / tursodatabase / turso / pr-workflow

pr-workflow skill

safe

This skill synthesizes PR workflow guidelines for commits, PRs, CI, security, and dependencies to help teams maintain clean history and focused changes.

npx playbooks add skill tursodatabase/turso --skill pr-workflow

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

1.0 KB

---
name: pr-workflow
description: General guidelines for Commits, formatting, CI, dependencies, security
---
# PR Workflow Guide

## Commit Practices

- **Atomic commits.** Small, focused, single purpose
- **Don't mix:** logic + formatting, logic + refactoring
- **Good message** = easy to write short description of intent

Learn `git rebase -i` for clean history.

## PR Guidelines

- Keep PRs focused and small
- Run relevant tests before submitting
- Each commit tells part of the story

## CI Environment Notes

If running as GitHub Action:
- Max-turns limit in `.github/workflows/claude.yml`
- OK to commit WIP state and push
- OK to open WIP PR and continue in another action
- Don't spiral into rabbit holes. Stay focused on key task

## Security

Never commit:
- `.env` files
- Credentials
- Secrets

## Third-Party Dependencies

When adding:
1. Add license file under `licenses/`
2. Update `NOTICE.md` with dependency info

## External APIs/Tools

- Never guess API params or CLI args
- Search official docs first
- Ask for clarification if ambiguous

Overview

This skill provides a concise PR workflow for contributors to a Rust-based embedded SQL project. It covers commit practices, PR scope, CI notes, dependency handling, and security reminders to keep history readable, reviews fast, and releases reliable. Use it to standardize contribution quality and reduce review friction.

How this skill works

The guidance enforces small, atomic commits and focused pull requests so each change is easy to review and bisect. It specifies CI behavior and limits, rules for adding third-party dependencies, and a strict policy to never commit secrets. Follow the checklist before opening or updating a PR to avoid common pitfalls.

When to use it

Opening a new feature or bugfix PR to the Rust codebase
Preparing commits for a release or backport
Adding or updating third-party crates or licenses
Configuring or debugging CI workflows (GitHub Actions)
Reviewing contributor submissions for quality and security

Best practices

Make commits atomic and single-purpose; use git rebase -i to clean history
Separate logic changes from formatting or refactors into different commits
Keep PRs small and focused; run relevant tests locally before pushing
Never commit .env files, credentials, or secrets; use vaults or CI secrets
When adding deps, add a license entry under licenses/ and update NOTICE.md
Refer to official docs for external APIs/CLIs; ask for clarification instead of guessing

Example use cases

Fix a SQL parsing bug: create a focused branch, implement fix, add unit tests, make an atomic commit, open a short PR
Upgrade a crate: add license file to licenses/, update NOTICE.md, run test matrix in CI, and keep the PR scoped to the upgrade
CI troubleshooting: adjust workflow limits in .github/workflows, push a WIP commit to iterate in Actions without blocking reviewers
Security check: scanning a PR for accidental secrets and refusing merges until secrets are removed

FAQ

Can I push WIP commits or open a WIP PR?

Yes. WIP commits and PRs are acceptable for iterating in CI, but keep work focused and avoid long-lived WIP branches that accumulate unrelated changes.

What do I do when adding a new dependency?

Add the dependency, include its license file under licenses/, update NOTICE.md with the dependency details, and run the test suite across CI targets before merging.