55ca4d3655
* I've completed the implementation. Here's a summary of the changes made:
## Summary
### Backend (Rust)
1. **`crates/services/src/services/config/versions/v8.rs`**
- Added two new config fields:
- `pr_auto_description_enabled: bool` - defaults to `false`
- `pr_auto_description_prompt: Option<String>` - defaults to `None`
2. **`crates/server/src/routes/task_attempts.rs`**
- Added `auto_generate_description: bool` field to `CreateGitHubPrRequest`
- Added `DEFAULT_PR_DESCRIPTION_PROMPT` constant with the default prompt
- Added `trigger_pr_description_follow_up()` helper function that:
- Gets the custom prompt from config or uses default
- Replaces `{pr_number}` and `{pr_url}` placeholders
- Triggers a follow-up (or initial if no session) coding agent execution
- Modified `create_github_pr()` to call the follow-up trigger after successful PR creation
### Frontend (TypeScript/React)
3. **`frontend/src/components/dialogs/tasks/CreatePRDialog.tsx`**
- Added `autoGenerateDescription` state, initialized from `config.pr_auto_description_enabled`
- Added checkbox to toggle auto-generate PR description
- Included `auto_generate_description` in the API call payload
4. **`frontend/src/pages/settings/GeneralSettings.tsx`**
- Added "Pull Requests" Card section with:
- Checkbox to enable/disable auto-generate by default
- Textarea for custom prompt override
5. **Translation files**
- Added `autoGenerateLabel` to `tasks.json`
- Added `pullRequests` section to `settings.json`
6. **`shared/types.ts`** - Auto-generated with new types
### Key Features
- Toggle in PR creation dialog, defaulting to the global config setting
- Settings page for configuring default behavior and custom prompt
- Placeholders `{pr_number}` and `{pr_url}` for custom prompts
- Uses the same executor profile as the original task attempt
- Graceful error handling (warns but doesn't fail PR creation if follow-up fails)
* Cleanup script changes for task attempt 46e66dfc-f608-47a4-baca-e38399d2da15
* Done! I've updated the placeholder text in `settings.json` to show the actual default prompt. Now users can see exactly what prompt the AI agent will use by default, and they know what they're customizing when they enter a custom prompt.
The placeholder now shows:
```
Update the GitHub PR that was just created with a better title and description.
The PR number is #{pr_number} and the URL is {pr_url}.
Analyze the changes in this branch and write:
1. A concise, descriptive title that summarizes the changes
2. A detailed description that explains:
- What changes were made
- Why they were made (based on the task context)
- Any important implementation details
Use `gh pr edit` to update the PR.
```
I also updated the helper text to mention the placeholder variables (`{pr_number}` and `{pr_url}`) so users know what variables they can use in their custom prompts.
* Cleanup script changes for task attempt 46e66dfc-f608-47a4-baca-e38399d2da15
* Done! Updated the label to "Ask AI agent to generate a better PR description" as requested.
* All done! The refactoring is complete:
**Summary of changes:**
1. **Created `crates/server/src/routes/task_attempts/pr.rs`** - New submodule containing all PR-related code:
- Types: `CreateGitHubPrRequest`, `CreatePrError`, `AttachPrResponse`, `PrCommentsResponse`, `GetPrCommentsError`
- Constants: `DEFAULT_PR_DESCRIPTION_PROMPT`
- Functions: `trigger_pr_description_follow_up`, `create_github_pr`, `attach_existing_pr`, `get_pr_comments`
2. **Updated `crates/server/src/routes/task_attempts.rs`** - Added `pub mod pr;` and updated router to use `pr::` prefix for PR routes
3. **Updated `crates/server/src/bin/generate_types.rs`** - Fixed all paths to reference `pr::` submodule for the PR-related types
Both backend (cargo check) and frontend (TypeScript) compile successfully, and TypeScript types have been regenerated.
* Cleanup script changes for task attempt 46e66dfc-f608-47a4-baca-e38399d2da15
* Done! I've updated the default PR description prompt in both locations:
1. **`crates/server/src/routes/task_attempts/pr.rs`** - Updated `DEFAULT_PR_DESCRIPTION_PROMPT` constant
2. **`frontend/src/i18n/locales/en/settings.json`** - Updated `pullRequests.customPrompt.placeholder`
The changes are:
- Title should now be postfixed with "(Vibe Kanban)"
- Description should include a note at the end: "This PR was written using [Vibe Kanban](https://vibekanban.com)"
* Done! I've updated `pr_auto_description_enabled` to default to `true` in three places:
1. Added `default_pr_auto_description_enabled()` function that returns `true`
2. Updated the `#[serde(default)]` attribute to use this function
3. Updated the `from_v7_config` migration to set it to `true`
4. Updated the `Default` impl to set it to `true`
* All done! I've added i18n translations for the PR auto-description feature to all supported languages:
**settings.json** - Added `pullRequests` section with:
- `title`, `description`
- `autoDescription.label`, `autoDescription.helper`
- `customPrompt.label`, `customPrompt.placeholder`, `customPrompt.helper`
**tasks.json** - Added `autoGenerateLabel` key
Languages updated:
- Spanish (es)
- Japanese (ja)
- Korean (ko)
- Simplified Chinese (zh-Hans)
* Update frontend/src/i18n/locales/en/tasks.json
Co-authored-by: Gabriel Gordon-Hall <gabriel@bloop.ai>
* Done! I've implemented the UX improvement from the PR review:
1. **Moved the auto-generate checkbox** to the top of the form (above title and description)
2. **Added `disabled` prop** to both the title Input and description Textarea when `autoGenerateDescription` is true
3. **Added greyed-out styling** (`opacity-50 cursor-not-allowed`) to visually indicate the fields are disabled
The new field order is:
1. Auto-generate checkbox
2. Title input (disabled when checked)
3. Description textarea (disabled when checked)
4. Base branch selector
5. Draft checkbox
* All done! I've:
1. **Made `DEFAULT_PR_DESCRIPTION_PROMPT` public** in `pr.rs`
2. **Exported the constant to `shared/types.ts`** via `generate_types.rs`:
- Imported the constant from the pr module
- Added code to append `export const DEFAULT_PR_DESCRIPTION_PROMPT = \`...\`;` to the generated types
3. **Updated `GeneralSettings.tsx`** to import and use the constant directly as the placeholder
4. **Removed the duplicate `placeholder` key** from all i18n `settings.json` files (en, es, ja, ko, zh-Hans)
The default prompt is now defined in a single place (the Rust backend) and exported to TypeScript, eliminating duplication across all i18n files.
* Cleanup script changes for task attempt 46e66dfc-f608-47a4-baca-e38399d2da15
* Done! I've implemented the two-step UX for the custom prompt:
1. **Updated `GeneralSettings.tsx`**:
- Replaced the always-visible textarea with a "Use custom prompt" checkbox
- When checked, pre-fills the textarea with `DEFAULT_PR_DESCRIPTION_PROMPT`
- When unchecked, sets `pr_auto_description_prompt` to `null` (reverts to default)
- Textarea only visible when custom prompt is enabled
2. **Updated i18n files** (all 5 languages):
- Replaced `label` with `useCustom` key
- Updated `helper` text to remove "Leave empty to use the default" since that's now handled by the checkbox
- Added translations:
- **en**: "Use custom prompt"
- **es**: "Usar prompt personalizado"
- **ja**: "カスタムプロンプトを使用"
- **ko**: "사용자 정의 프롬프트 사용"
- **zh-Hans**: "使用自定义提示"
* Done! The custom prompt UX has been updated:
- **Textarea is now always visible** showing the current prompt (default or custom)
- **When "Use custom prompt" is unchecked**: textarea shows `DEFAULT_PR_DESCRIPTION_PROMPT` but is disabled/read-only with greyed-out styling
- **When "Use custom prompt" is checked**: textarea becomes editable, pre-filled with the default prompt for customization
This gives users visibility into what prompt will be used even when using the default, while still allowing them to customize it by checking the checkbox.
* Cleanup script changes for task attempt 46e66dfc-f608-47a4-baca-e38399d2da15
* Done! The fix has been applied. Now when the "Use custom prompt" checkbox is checked, users can:
- Clear all the text in the textarea to start from scratch
- The text no longer automatically reverts to the default prompt when emptied
---------
Co-authored-by: Gabriel Gordon-Hall <gabriel@bloop.ai>
Get 10X more out of Claude Code, Gemini CLI, Codex, Amp and other coding agents...
We're hiring!
Overview
AI coding agents are increasingly writing the world's code and human engineers now spend the majority of their time planning, reviewing, and orchestrating tasks. Vibe Kanban streamlines this process, enabling you to:
- Easily switch between different coding agents
- Orchestrate the execution of multiple coding agents in parallel or in sequence
- Quickly review work and start dev servers
- Track the status of tasks that your coding agents are working on
- Centralise configuration of coding agent MCP configs
- Open projects remotely via SSH when running Vibe Kanban on a remote server
You can watch a video overview here.
Installation
Make sure you have authenticated with your favourite coding agent. A full list of supported coding agents can be found in the docs. Then in your terminal run:
npx vibe-kanban
Documentation
Please head to the website for the latest documentation and user guides.
Support
We use GitHub Discussions for feature requests. Please open a discussion to create a feature request. For bugs please open an issue on this repo.
Contributing
We would prefer that ideas and changes are first raised with the core team via GitHub Discussions or Discord, where we can discuss implementation details and alignment with the existing roadmap. Please do not open PRs without first discussing your proposal with the team.
Development
Prerequisites
Additional development tools:
cargo install cargo-watch
cargo install sqlx-cli
Install dependencies:
pnpm i
Running the dev server
pnpm run dev
This will start the backend. A blank DB will be copied from the dev_assets_seed folder.
Building the frontend
To build just the frontend:
cd frontend
pnpm build
Build from source
- Run
build-npm-package.sh - In the
npx-clifolder runnpm pack - You can run your build with
npx [GENERATED FILE].tgz
Environment Variables
The following environment variables can be configured at build time or runtime:
| Variable | Type | Default | Description |
|---|---|---|---|
POSTHOG_API_KEY |
Build-time | Empty | PostHog analytics API key (disables analytics if empty) |
POSTHOG_API_ENDPOINT |
Build-time | Empty | PostHog analytics endpoint (disables analytics if empty) |
BACKEND_PORT |
Runtime | 0 (auto-assign) |
Backend server port |
FRONTEND_PORT |
Runtime | 3000 |
Frontend development server port |
HOST |
Runtime | 127.0.0.1 |
Backend server host |
DISABLE_WORKTREE_ORPHAN_CLEANUP |
Runtime | Not set | Disable git worktree cleanup (for debugging) |
Build-time variables must be set when running pnpm run build. Runtime variables are read when the application starts.
Remote Deployment
When running Vibe Kanban on a remote server (e.g., via systemctl, Docker, or cloud hosting), you can configure your editor to open projects via SSH:
- Access via tunnel: Use Cloudflare Tunnel, ngrok, or similar to expose the web UI
- Configure remote SSH in Settings → Editor Integration:
- Set Remote SSH Host to your server hostname or IP
- Set Remote SSH User to your SSH username (optional)
- Prerequisites:
- SSH access from your local machine to the remote server
- SSH keys configured (passwordless authentication)
- VSCode Remote-SSH extension
When configured, the "Open in VSCode" buttons will generate URLs like vscode://vscode-remote/ssh-remote+user@host/path that open your local editor and connect to the remote server.
See the documentation for detailed setup instructions.