|
1 | 1 | ## High Level Reflections |
2 | | - - Corey Doctorow's books have taught me that [[Interop]] tools like `rulesync` are important because in the age of AI, vendor lock-in is likely to become a serious issue. |
3 | | - - When the pace of AI progress is so fast, the cost of using and maintaining an abstraction layer like `rulesync` is relatively high. It's relatively expensive for me to keep the canonical versions of my configurations in `rulesync`'s formats, because then I can't use the latest features of Claude Code, such as Skills (see also [Support for Claude Skills · Issue #422 · dyoshikawa/rulesync](https://github.com/dyoshikawa/rulesync/issues/422) ), and it's expensive to maintain because then external standards must be painstakingly adapted and mirrored into a centralized configuration. |
4 | | - - In the past couple weeks, as Claude Code Skills emerged, I stopped using `rulesync`, because it wasn't supported yet. |
5 | | - As a result, I have a high-level architectural suggestion. |
6 | | - so I can't keep the current, best versions of my AI Code Configs in rulesync. |
7 | | - |
8 | | - As a result, I've been thinking more about how I can't |
9 | | -- ## Precedent: Claude Code [Plugins](https://code.claude.com/docs/en/plugins-reference) |
10 | | - |
11 | | - Anthropic's Claude Code has the concept of , which enable registering a marketplace of plugins. |
12 | | -- ## AI Marketplaces |
13 | | - |
14 | | - A repository is a "marketplace" which can contain multiple plugins, and each plugin can register commands, sub-agents, skills and hooks. Here are some example marketplaces: |
15 | | - |
16 | | - 1. [ehudhal/claude-code-marketplace](https://github.com/ehudhal/claude-code-marketplace) |
17 | | - 2. [anthropics/skills](https://github.com/anthropics/skills) |
18 | | - 3. [wshobson/agents](https://github.com/wshobson/agents) |
19 | | - 4. [davila7/claude-code-templates: CLI tool for configuring and monitoring Claude Code](https://github.com/davila7/claude-code-templates) |
20 | | - 5. See also github search using GitHub path: `**/.claude-plugin/marketplace.json` |
21 | | -- ## Proposal: Rulesync could support its own marketplaces and plugins |
22 | | -- ### Create [.rulesync/marketplace.jsonc](https://code.claude.com/docs/en/plugin-marketplaces#create-the-marketplace-file) |
23 | | - |
24 | | - ```json |
25 | | - { |
26 | | - "name": "company-tools", |
27 | | - "owner": { |
28 | | - "name": "DevTools Team", |
29 | | - |
30 | | - }, |
31 | | - "plugins": [ |
32 | | - { |
33 | | - "name": "code-formatter", |
34 | | - "source": "./plugins/formatter", |
35 | | - "description": "Automatic code formatting on save", |
36 | | - "version": "2.1.0", |
37 | | - "author": { |
38 | | - "name": "DevTools Team" |
39 | | - } |
40 | | - }, |
41 | | - { |
42 | | - "name": "deployment-tools", |
43 | | - "source": { |
44 | | - "source": "github", |
45 | | - "repo": "company/deploy-plugin" |
46 | | - }, |
47 | | - "description": "Deployment automation tools" |
48 | | - } |
49 | | - ] |
50 | | - } |
51 | | - ``` |
52 | | - |
53 | | - Marketplaces support [expressing the location of their plugins sources in various ways](https://code.claude.com/docs/en/plugin-marketplaces#plugin-sources): |
54 | | - |
55 | | - Relative paths |
56 | | - |
57 | | - ```json |
58 | | - { |
59 | | - "name": "my-plugin", |
60 | | - "source": "./plugins/my-plugin" |
61 | | - } |
62 | | - ``` |
63 | | - |
64 | | - Github repos |
65 | | - |
66 | | - ```json |
67 | | - { |
68 | | - "name": "github-plugin", |
69 | | - "source": { |
70 | | - "source": "github", |
71 | | - "repo": "owner/plugin-repo" |
72 | | - } |
73 | | - } |
74 | | - ``` |
75 | | - |
76 | | - etc |
77 | | -- ### Create |
78 | | - |
79 | | - It's a simple spec. |
80 | | - |
81 | | - First, add a `.claude-plugin/plugin.json` like [claude-code/plugins/agent-sdk-dev/.claude-plugin/plugin.json at main · anthropics/claude-code](https://github.com/anthropics/claude-code/blob/main/plugins/agent-sdk-dev/.claude-plugin/plugin.json) (see also [the plugins.json spec](https://code.claude.com/docs/en/plugins-reference#complete-schema). |
82 | | - |
83 | | - For rulesync, it could be `.rulesync/plugin.jsonc`. |
84 | | - |
85 | | - Next, add folders `./agents/*.md`, `./skills/*.md`, `./commands/*.md`, `./hooks/*.md`, and `./.mcp.json`. |
86 | | - |
87 | | - So, based on [their sample directory structure](https://code.claude.com/docs/en/plugins-reference#standard-plugin-layout), |
88 | | - |
89 | | - ``` |
90 | | - enterprise-plugin/ |
91 | | - ├── .rulesync-plugin/ # Metadata directory |
92 | | - │ └── plugin.json # Required: plugin manifest |
93 | | - ├── commands/ # Default command location |
94 | | - │ ├── status.md |
95 | | - │ └── logs.md |
96 | | - ├── subagents/ # Default agent location |
97 | | - │ ├── security-reviewer.md |
98 | | - │ ├── performance-tester.md |
99 | | - │ └── compliance-checker.md |
100 | | - ├── skills/ # Agent Skills |
101 | | - │ ├── code-reviewer/ |
102 | | - │ │ └── SKILL.md |
103 | | - │ └── pdf-processor/ |
104 | | - │ ├── SKILL.md |
105 | | - │ └── scripts/ |
106 | | - ├── hooks/ # Hook configurations |
107 | | - │ ├── hooks.json # Main hook config |
108 | | - │ └── security-hooks.json # Additional hooks |
109 | | - ├── .mcp.json # MCP server definitions |
110 | | - ├── scripts/ # Hook and utility scripts |
111 | | - │ ├── security-scan.sh |
112 | | - │ ├── format-code.py |
113 | | - │ └── deploy.js |
114 | | - ├── LICENSE # License file |
115 | | - └── CHANGELOG.md # Version history |
116 | | - ``` |
117 | | - |
118 | | - Furthermore |
| 2 | + - Corey Doctorow's books (particularly [[Person/Corey Doctorow/Book/25/Picks & Shovels]] and [[Person/Corey Doctorow/Book/25/Enshittification]]) have taught me that [[Interop]] tools like `rulesync` are important because in the age of AI, vendor lock-in is likely to become a serious issue. [[pandoc]] could serve as an example for how to do an interop tool like `rulesync` |
| 3 | + - But the pace of AI progress is fast. The feature surface area of the underlying tools is exploding. The cost of using and maintaining an abstraction layer like `rulesync` is becoming high. If I keep my canonical [[AI/Coding/Config]]s in `rulesync`'s formats, then I can't easily use the latest features of Claude Code, such as |
| 4 | + - [Support for Claude Skills · Issue #422 · dyoshikawa/rulesync](https://github.com/dyoshikawa/rulesync/issues/422) |
| 5 | + - [Feature request: for claude code slash commands, support passing through claude-code-specific yaml markdown frontmatter keys to the generated command markdown files · Issue #413 · dyoshikawa/rulesync](https://github.com/dyoshikawa/rulesync/issues/413) |
| 6 | + - [Support for Claude Code plugins and Gemini CLI extensions · Issue #382 · dyoshikawa/rulesync](https://github.com/dyoshikawa/rulesync/issues/382) |
| 7 | + - In the past couple weeks, as Claude Code Skills emerged, I stopped primarily using `rulesync` because the latest features can't be represented in rulesync's format yet. |
| 8 | + I have been thinking about [Programmatic API · Issue #377 · dyoshikawa/rulesync](https://github.com/dyoshikawa/rulesync/issues/377), and from the perspective of someone using the tool, maybe it could make sense to optimize for lossless modeling of AI code configs and best effort conversion. |
| 9 | + - ### Proposed rulesync architectural assumptions |
| 10 | + - 1 - **assume users will store AI code configs some AI coding tool's native format**, whether that's cursor, claude code, or any of the many tools that are out there |
| 11 | + - 2 - **optimize rulesync for "lossless conversion" within each tool**. This means that if I store my configs in Claude Code, then if I import into rulesync, then wipe away my `.claude` directory and regenerate from rulesync, every file and folder should work the way it did before. |
| 12 | + - 3 - **make rulesync "best effort" or "lossy" between tools**. The tools are not always going to have feature parity with each other, and the concepts are not going to match. Rulesync would |
| 13 | + - ### Benefits of this approach |
| 14 | + - Even if tool X adds feature Y which hasn't been added as a feature to rulesync, a user can still use feature Y until it's supported for conversion. |
| 15 | + - ### What could this look like? |
| 16 | + - 1 - `rulesync` could assume that one tool is the "parent" from which other code configs are adapted from that source |
119 | 17 | - |
0 commit comments