ship
The `/ship` command automates the code release workflow by running linting and API validation checks, staging changed files with a conventionally formatted commit message, pushing to the current branch, and creating a pull request against the staging branch with a structured description. Use this when ready to submit completed work for review without manually executing each step.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/simstudioai/sim/HEAD/.claude/commands/ship.md -o ~/.claude/commands/ship.mdship.md
# Ship Command You help ship code by creating commits, pushing to the remote branch, and creating PRs in the user's voice. ## Your Task When the user runs `/ship`: 1. **Check git status** - See what files have changed 2. **Generate a commit message** following this format: `type(scope): description` - Types: `fix`, `feat`, `improvement`, `chore` - Scope: short identifier (e.g., `undo-redo`, `api`, `ui`) - Keep it concise 3. **Run pre-ship checks** from the repo root before staging: - `bun run lint` to fix formatting issues - `bun run check:api-validation:strict` to catch boundary contract failures before CI 4. **Stage and commit** the changes with the generated message 5. **Push to origin** using the current branch name 6. **Create a PR** to staging with a description in the user's voice ## Commit Message Format Based on the repo's commit history: ``` fix(scope): description for bug fixes feat(scope): description for new features improvement(scope): description for enhancements chore(scope): description for maintenance ``` ## PR Description Format Use this exact template in the user's voice (concise, bullet points): ```markdown ## Summary - bullet point describing what changed - another bullet point if needed ## Type of Change - [x] Bug fix (or appropriate type) ## Testing Tested manually (or describe testing) ## Checklist - [x] Code follows project style guidelines - [x] Self-reviewed my changes - [ ] Tests added/updated and passing - [x] No new warnings introduced - [x] I confirm that I have read and agree to the terms outlined in the [Contributor License Agreement (CLA)](./CONTRIBUTING.md#contributor-license-agreement-cla) ``` ## PR Creation Command Use this command structure: ```bash gh pr create --base staging --title "COMMIT_MESSAGE" --body "PR_BODY" ``` ## Important Notes - Always confirm the commit message and PR description with the user before executing - The PR should be created against `staging` branch - Keep descriptions concise and in active voice - Match the user's previous PR style: direct, no fluff, bullet points - **DO NOT add "Co-Authored-By" lines to commits** - keep commit messages clean ## User's Voice Characteristics (based on previous PRs) - Short, direct bullet points - No unnecessary explanation - "Tested manually" is acceptable for testing section; include lint and boundary validation results when run - Checkboxes filled in appropriately - No screenshots section unless UI changes
Create a block configuration for a Sim integration with proper subBlocks, conditions, and tool wiring
Add a knowledge base connector for syncing documents from an external source
Add a code-defined table enrichment (registry entry) backed by a provider cascade, ensuring each provider tool has hosted-key support
Add hosted API key support to a tool so Sim provides the key when users don't bring their own. Use when adding hosted keys, BYOK support, hideWhenHosted, or hosted key pricing to a tool or block.
Add a complete integration to Sim (tools, block, icon, registration)
Add a new LLM model to apps/sim/providers/models.ts with specs verified against the provider's live API docs (no hallucination)
Create tool configurations for a Sim integration by reading API docs
Create webhook or polling triggers for a Sim integration