feat: add Vibe Code (vibe) as a supported tool target by sirmacik · Pull Request #1861 · dyoshikawa/rulesync

sirmacik · 2026-06-13T20:41:35Z

Intent

Add first-class support for Vibe Code to rulesync so teams can generate and import Vibe's native config from the unified .rulesync/ source of truth. Brings Vibe to parity with peer agentic CLIs (Codex, OpenCode, Cursor) across the feature matrix.

What Changed

New vibe tool target registered in src/types/tool-targets.ts.
Six native feature implementations (+ co-located tests):
- rules → root AGENTS.md (project) / ~/.vibe/AGENTS.md (global)
- ignore → .vibeignore
- mcp → .vibe/config.toml ([[mcp_servers]], TOML)
- permissions → .vibe/config.toml (tools / enabled_tools / disabled_tools)
- subagents → .vibe/agents/*.toml (TOML frontmatter, mirrors codexcli pattern)
- skills → .vibe/skills/ (+ .agents/skills/ alt root, project only)
Wired vibe into all six feature processors, the gitignore registry, README, and docs/reference/supported-tools.md.
MCP and permissions share .vibe/config.toml; both read-merge existing content so neither clobbers the other.

Config / Flags

No new runtime flags. Activated via existing --targets vibe (or *) and --features selectors.
commands and hooks are intentionally not supported (Vibe has no native equivalent) — reflected in the docs matrix.
Permissions mapping is lossy by design: pattern-level ask is unsupported (logged + skipped); canonical edit/write both map to Vibe's write_file.

Impact

Additive only. No change to existing tool targets, output paths, or public APIs.
rulesync generate/import now accept vibe; .gitignore generation emits Vibe paths when the target is selected.

Risks

Shared config.toml between MCP + permissions — mitigated by read-merge; covered by an e2e "preserve MCP config" test.
edit/write → write_file collision — handled: fromRulesyncPermissions merges via the tools accumulator instead of re-reading the original config; regression test added.
Stale Vibe tool filters on regenerate — handled: both enabled_tools and disabled_tools are reconciled for tools rulesync owns, so a changed permission is no longer overridden by leftover filters; regression tests added.
External spec accuracy — ~/.vibe/AGENTS.md and .vibe/config.toml paths rest on Vibe's docs; verify before release.

Validation Plan

Unit: 25 vibe-* tests pass (incl. edit/write merge and stale-filter reconciliation regression tests).
E2E: 22 vibe cases pass across generate + import for all six features (vitest.e2e.config.ts).
tsc --noEmit clean; full suite green.
Pre-merge: pnpm cicheck (code + content) and pnpm dev gitignore to refresh .gitignore.

Rollout / Backout

Rollout: ships in the next release; no migration or user action required — opt-in via --targets vibe.
Backout: revert the branch. No persisted state or schema changes; removal cleanly drops the target with no impact on other tools.

Add first-class support for Vibe Code so teams can generate and import Vibe's native config from the unified .rulesync source of truth. Native implementations across six features: - rules -> AGENTS.md (project) / ~/.vibe/AGENTS.md (global) - ignore -> .vibeignore - mcp -> .vibe/config.toml ([[mcp_servers]], TOML) - permissions -> .vibe/config.toml (tools / enabled_tools / disabled_tools) - subagents -> .vibe/agents/*.toml (TOML frontmatter) - skills -> .vibe/skills/ (+ .agents/skills/ alt root, project only) Wire vibe into all six feature processors, the gitignore registry, README, and docs/reference/supported-tools.md. MCP and permissions share .vibe/config.toml via read-merge so neither clobbers the other. Canonical edit/write permission categories both map to write_file and merge through a shared tools accumulator. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

VibePermissions.fromRulesyncPermissions only added new denies to disabled_tools and never touched enabled_tools, so a prior .vibe/config.toml could keep a stale filter that overrode the current rulesync permissions (e.g. disabled_tools = ["write_file"] surviving a later edit/write -> allow, or a stale enabled_tools allow-list). Clear both enabled_tools and disabled_tools for every tool the current rulesync permissions own before reapplying state, while preserving filters for tools rulesync does not configure. Add regression tests for deny -> allow, stale enabled_tools deny, and unowned-filter preservation. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

CI "Code Quality & Tests" failed on CSpell unknown words introduced by the Vibe target. Add `vibeignore` (the .vibeignore filename) and `devstral` (a Mistral model used in an MCP test fixture) to cspell.json, and rename the subagent test fixture redteam.{md,toml} to security-reviewer.{md,toml} so the file name is self-describing. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

github-actions · 2026-06-13T20:41:43Z

Thank you for your contribution! Unfortunately, this PR has 2431 added lines, which exceeds the limit of 1000 lines for external contributors.

Please split your changes into smaller PRs. See CONTRIBUTING.md for details.

dyoshikawa

This is a clean, complete new-tool implementation — wiring is consistent across tool-targets, all six feature processors, gitignore, the README and docs/reference/supported-tools.md (plus the synced skills copy), and the test-count assertions are updated in lockstep. Happy-path E2E generate+import coverage exists for every supported feature, including the global and MCP-preservation regression cases for permissions and the .agents/skills fallback for skills. Security review found nothing and CI is green, so the code quality isn't the concern here.

The one thing holding this back from merge is external-spec verification. The entire value of this target depends on the file paths and config schemas matching Vibe Code's real behavior, and the PR description itself flags that this needs verifying before release. I left inline notes on the highest-risk spots — the global rules path, and the supportsGlobal claims for MCP/permissions. Could you confirm each path and schema against Vibe's official docs before we merge? In particular, please double-check that Vibe actually reads a user-level ~/.vibe/config.toml; if it only reads the project-level .vibe/config.toml, the global generation would write a file Vibe never loads, and we shouldn't claim global scope in the matrix (per .claude/rules/feature-change-guidelines.md).

One minor maintainability nit beyond the inline comments: MCP and permissions both read-merge .vibe/config.toml and rely on mcp running before permissions in generate.ts (each preserves the other's keys). A short comment in vibe-mcp.ts / vibe-permissions.ts noting that cross-feature dependency would help future maintainers — right now the safety is implicit in the pipeline ordering.

dyoshikawa · 2026-06-15T08:20:32Z

+    if (global) {
+      return {
+        root: {
+          relativeDirPath: ".vibe",


This whole path/convention surface (global ~/.vibe/AGENTS.md here, plus .vibe/config.toml schema, transport names, the tools/enabled_tools/disabled_tools permission schema, the subagent TOML schema, and .vibe/skills + .agents/skills discovery) rests on Vibe Code's actual behavior, which the PR body notes still needs verifying. If any of these diverge from real Vibe behavior the generated output is silently wrong. Could you confirm each against Vibe's official documentation before merge?

dyoshikawa · 2026-06-15T08:20:32Z

+      class: VibeMcp,
+      meta: {
+        supportsProject: true,
+        supportsGlobal: true,


supportsGlobal: true here assumes Vibe reads a user-level ~/.vibe/config.toml. If Vibe only reads the project-level .vibe/config.toml, global generation produces a file Vibe never loads, and the docs matrix shouldn't mark MCP as global-supported (per .claude/rules/feature-change-guidelines.md, global scope should only be claimed when the tool actually reads a user-level config at that path). Please confirm before merge.

dyoshikawa · 2026-06-15T08:20:32Z

+      class: VibePermissions,
+      meta: {
+        supportsProject: true,
+        supportsGlobal: true,


Same global-scope concern as the MCP processor: supportsGlobal: true assumes a user-level ~/.vibe/config.toml exists and is read by Vibe. Please confirm Vibe supports a user-level config before claiming global scope here and in the docs matrix.

dyoshikawa · 2026-06-15T08:20:32Z

+  bash: "bash",
+  read: "read_file",
+  edit: "write_file",
+  write: "write_file",


Both canonical edit and write map to write_file, and write_file imports back as edit, so the round-trip isn't identity — a user who configured write will see it rewritten to edit on the next generate. The merge handles the collision correctly and there's a regression test, so this is fine to ship; just flagging the lossy round-trip for awareness.

dyoshikawa · 2026-06-15T09:29:42Z

@sirmacik Thank you!

sirmacik and others added 3 commits June 13, 2026 20:38

sirmacik marked this pull request as ready for review June 13, 2026 20:42

dyoshikawa reviewed Jun 15, 2026

View reviewed changes

dyoshikawa merged commit 126e945 into dyoshikawa:main Jun 15, 2026
12 checks passed

dyoshikawa mentioned this pull request Jun 16, 2026

chore: release v8.29.0 #1874

Merged

Navigation Menu

Uh oh!

feat: add Vibe Code (vibe) as a supported tool target - #1861

feat: add Vibe Code (vibe) as a supported tool target#1861
dyoshikawa merged 3 commits into
dyoshikawa:mainfrom
sirmacik:feat/vibe-support

sirmacik commented Jun 13, 2026

Uh oh!

github-actions Bot commented Jun 13, 2026

Uh oh!

dyoshikawa left a comment

Uh oh!

dyoshikawa Jun 15, 2026

Uh oh!

dyoshikawa Jun 15, 2026

Uh oh!

dyoshikawa Jun 15, 2026

Uh oh!

dyoshikawa Jun 15, 2026

Uh oh!

Uh oh!

dyoshikawa commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

sirmacik commented Jun 13, 2026

Intent

What Changed

Config / Flags

Impact

Risks

Validation Plan

Rollout / Backout

Uh oh!

github-actions Bot commented Jun 13, 2026

Uh oh!

dyoshikawa left a comment

Choose a reason for hiding this comment

Uh oh!

dyoshikawa Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

dyoshikawa Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

dyoshikawa Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

dyoshikawa Jun 15, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

dyoshikawa commented Jun 15, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants