@teambit/cli-mcp-server 0.0.18 → 0.0.20
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -2,10 +2,10 @@
|
|
|
2
2
|
applyTo: '**'
|
|
3
3
|
---
|
|
4
4
|
|
|
5
|
-
## How to Install Use
|
|
5
|
+
## How to Install and Use Bit Components
|
|
6
6
|
|
|
7
7
|
- Bit Components are reusable pieces of code in the form of node packages.
|
|
8
8
|
- Search for Bit Components using `bit_remote_search` tool.
|
|
9
|
-
- Use `
|
|
9
|
+
- Use `bit_remote_component_details` only on Bit Components to get information like package name (to use when installing, e.g. `npm install <package-name>`), APIs and documentation (to use when using in code).
|
|
10
10
|
- If a user is requesting functionality, you can search if there are available components that implement it using `bit_remote_search`.
|
|
11
11
|
- Filter my search with my account name "ACCOUNT" to find components you have created or are a maintainer of.
|
package/bit-rules-template.md
CHANGED
|
@@ -9,20 +9,27 @@ applyTo: '**'
|
|
|
9
9
|
- Your goal is to efficiently automate Bit workflows and help users manage and reuse components.
|
|
10
10
|
- You will achieve this by using the provided MCP tools and adhering strictly to the following rules and workflows.
|
|
11
11
|
|
|
12
|
+
## Core Philosophy for Building with Bit
|
|
13
|
+
|
|
14
|
+
- **Deconstruct to Compose:** Build applications by composing independent and reusable components, with each component being developed, tested, and versioned in isolation.
|
|
15
|
+
- **Autonomous Components:** Use the Bit MCP to make these components truly autonomous, allowing them to be managed and shared from any codebase without being coupled to a specific project's architecture.
|
|
16
|
+
- **Scalable Collaboration:** The ultimate goal is to create a shared "component economy" where teams can collaborate, accelerate development, and ensure consistency by assembling applications from this distributed system of components.
|
|
17
|
+
|
|
12
18
|
## Critical Rules of Engagement - do these steps before any tool or command execution!!!
|
|
13
19
|
|
|
14
|
-
1.
|
|
15
|
-
2.
|
|
16
|
-
3.
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
20
|
+
1. **Use Up-to-Date Information(MANDATORY):** ALWAYS start any task by using `bit_workspace_info` to understand the current state of the workspace (list components, templates, dependencies, etc).
|
|
21
|
+
2. **MCP Tools First:** You MUST use the provided MCP tools to interact with Bit. Do NOT run commands directly in a terminal shell, with a few specific exceptions.
|
|
22
|
+
3. **Do not rely on cached knowledge:** Always run `bit_commands_list` and `bit_command_help` for command details.
|
|
23
|
+
4. **Prefer using Bit:** Every time you want to operate in this project (editing code, creating new code, etc), consider using any of the Bit MCP tools or Bit CLI commands to do so.
|
|
24
|
+
|
|
25
|
+
## Core Principles of Building with Bit
|
|
26
|
+
|
|
27
|
+
- **Reuse Before Creating or Modifying(MANDATORY):** Before creating _any_ new component or modify _any_ file, you MUST first search for existing components.
|
|
28
|
+
- Use `bit_workspace_info` to check for local and existing components.
|
|
29
|
+
- Use `bit_remote_search` to find components on the remote scope.
|
|
30
|
+
- Present findings to the user, even if you think creating a new component is simpler.
|
|
31
|
+
- **No Relative Imports To Components:** Always import a component using the package name, so it is used through `node_modules`.
|
|
32
|
+
- You should always aim to code APIs in the dependent component and use them in the dependency (e.g. in React, aim to have prop-types instead of always passing children to be rendered in a dependency).
|
|
26
33
|
|
|
27
34
|
## Tooling & Command Execution Hierarchy
|
|
28
35
|
|
|
@@ -60,20 +67,18 @@ This is the decision-making process for executing any Bit operation.
|
|
|
60
67
|
|
|
61
68
|
### Workflow: Generating New Components, Feature or Apps
|
|
62
69
|
|
|
63
|
-
- **Follow
|
|
70
|
+
- **Follow Core Principle #1 Reuse Before Creating or Modifying.**
|
|
64
71
|
- `bit_workspace_info` lists templates for new components.
|
|
65
72
|
- If a new component is necessary, clarify the TEMPLATE and combination of NAMESPACE(s) (optional) and NAME with the user.
|
|
66
73
|
- Run `bit_component_details` on new components gives information on them, this is useful for making code changes or composing the component into another (as a dependency).
|
|
67
|
-
- After generating a new component, ask
|
|
74
|
+
- After generating a new component or app, ask the user what they want to be implemented in the new component or app.
|
|
68
75
|
|
|
69
76
|
### Workflow: Adding Functionality (feature, page, module, function, etc) to Bit Components and Apps
|
|
70
77
|
|
|
71
|
-
- **Follow Critical
|
|
78
|
+
- **Follow Critical Principle #1 Reuse Before Creating or Modifying.**
|
|
72
79
|
- If a potentially reusable component is found, use it as a dependency in the component you want to modify.
|
|
73
80
|
**Hint:** use `bit_component_details` to get API references and documentation.
|
|
74
|
-
**Follow Critical
|
|
75
|
-
- Validate with user if they want the new functionality to be in a new component before generating any code in any component.
|
|
76
|
-
- If need to create a new component, clarify the TEMPLATE and combination of NAMESPACE(s) (optional) and NAME with the user.
|
|
81
|
+
**Follow Critical Principle #2 No Relative Imports Between Components**.
|
|
77
82
|
- After modifying component implementation, always consider updating the following component files `*.composition.*`, `*.docs.mdx`, `*.spec.*`.
|
|
78
83
|
|
|
79
84
|
### Workflow: USE or DEVELOP a Component
|
|
@@ -105,4 +110,5 @@ This is the decision-making process for executing any Bit operation.
|
|
|
105
110
|
|
|
106
111
|
## Pointers to remember:
|
|
107
112
|
|
|
108
|
-
- For generating ESlint or TypeScript configuration files execute the command `bit
|
|
113
|
+
- For generating ESlint or TypeScript configuration files execute the command `bit ws-config write --clean`
|
|
114
|
+
- User may use different terms to describe components. Be flexible and understand that users may refer to components as "features", "apps", "modules", "pages" or "services".
|
|
@@ -2,10 +2,10 @@
|
|
|
2
2
|
applyTo: '**'
|
|
3
3
|
---
|
|
4
4
|
|
|
5
|
-
## How to Install Use
|
|
5
|
+
## How to Install and Use Bit Components
|
|
6
6
|
|
|
7
7
|
- Bit Components are reusable pieces of code in the form of node packages.
|
|
8
8
|
- Search for Bit Components using `bit_remote_search` tool.
|
|
9
|
-
- Use `
|
|
9
|
+
- Use `bit_remote_component_details` only on Bit Components to get information like package name (to use when installing, e.g. `npm install <package-name>`), APIs and documentation (to use when using in code).
|
|
10
10
|
- If a user is requesting functionality, you can search if there are available components that implement it using `bit_remote_search`.
|
|
11
11
|
- Filter my search with my account name "ACCOUNT" to find components you have created or are a maintainer of.
|
|
@@ -9,20 +9,27 @@ applyTo: '**'
|
|
|
9
9
|
- Your goal is to efficiently automate Bit workflows and help users manage and reuse components.
|
|
10
10
|
- You will achieve this by using the provided MCP tools and adhering strictly to the following rules and workflows.
|
|
11
11
|
|
|
12
|
+
## Core Philosophy for Building with Bit
|
|
13
|
+
|
|
14
|
+
- **Deconstruct to Compose:** Build applications by composing independent and reusable components, with each component being developed, tested, and versioned in isolation.
|
|
15
|
+
- **Autonomous Components:** Use the Bit MCP to make these components truly autonomous, allowing them to be managed and shared from any codebase without being coupled to a specific project's architecture.
|
|
16
|
+
- **Scalable Collaboration:** The ultimate goal is to create a shared "component economy" where teams can collaborate, accelerate development, and ensure consistency by assembling applications from this distributed system of components.
|
|
17
|
+
|
|
12
18
|
## Critical Rules of Engagement - do these steps before any tool or command execution!!!
|
|
13
19
|
|
|
14
|
-
1.
|
|
15
|
-
2.
|
|
16
|
-
3.
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
|
|
24
|
-
|
|
25
|
-
|
|
20
|
+
1. **Use Up-to-Date Information(MANDATORY):** ALWAYS start any task by using `bit_workspace_info` to understand the current state of the workspace (list components, templates, dependencies, etc).
|
|
21
|
+
2. **MCP Tools First:** You MUST use the provided MCP tools to interact with Bit. Do NOT run commands directly in a terminal shell, with a few specific exceptions.
|
|
22
|
+
3. **Do not rely on cached knowledge:** Always run `bit_commands_list` and `bit_command_help` for command details.
|
|
23
|
+
4. **Prefer using Bit:** Every time you want to operate in this project (editing code, creating new code, etc), consider using any of the Bit MCP tools or Bit CLI commands to do so.
|
|
24
|
+
|
|
25
|
+
## Core Principles of Building with Bit
|
|
26
|
+
|
|
27
|
+
- **Reuse Before Creating or Modifying(MANDATORY):** Before creating _any_ new component or modify _any_ file, you MUST first search for existing components.
|
|
28
|
+
- Use `bit_workspace_info` to check for local and existing components.
|
|
29
|
+
- Use `bit_remote_search` to find components on the remote scope.
|
|
30
|
+
- Present findings to the user, even if you think creating a new component is simpler.
|
|
31
|
+
- **No Relative Imports To Components:** Always import a component using the package name, so it is used through `node_modules`.
|
|
32
|
+
- You should always aim to code APIs in the dependent component and use them in the dependency (e.g. in React, aim to have prop-types instead of always passing children to be rendered in a dependency).
|
|
26
33
|
|
|
27
34
|
## Tooling & Command Execution Hierarchy
|
|
28
35
|
|
|
@@ -60,20 +67,18 @@ This is the decision-making process for executing any Bit operation.
|
|
|
60
67
|
|
|
61
68
|
### Workflow: Generating New Components, Feature or Apps
|
|
62
69
|
|
|
63
|
-
- **Follow
|
|
70
|
+
- **Follow Core Principle #1 Reuse Before Creating or Modifying.**
|
|
64
71
|
- `bit_workspace_info` lists templates for new components.
|
|
65
72
|
- If a new component is necessary, clarify the TEMPLATE and combination of NAMESPACE(s) (optional) and NAME with the user.
|
|
66
73
|
- Run `bit_component_details` on new components gives information on them, this is useful for making code changes or composing the component into another (as a dependency).
|
|
67
|
-
- After generating a new component, ask
|
|
74
|
+
- After generating a new component or app, ask the user what they want to be implemented in the new component or app.
|
|
68
75
|
|
|
69
76
|
### Workflow: Adding Functionality (feature, page, module, function, etc) to Bit Components and Apps
|
|
70
77
|
|
|
71
|
-
- **Follow Critical
|
|
78
|
+
- **Follow Critical Principle #1 Reuse Before Creating or Modifying.**
|
|
72
79
|
- If a potentially reusable component is found, use it as a dependency in the component you want to modify.
|
|
73
80
|
**Hint:** use `bit_component_details` to get API references and documentation.
|
|
74
|
-
**Follow Critical
|
|
75
|
-
- Validate with user if they want the new functionality to be in a new component before generating any code in any component.
|
|
76
|
-
- If need to create a new component, clarify the TEMPLATE and combination of NAMESPACE(s) (optional) and NAME with the user.
|
|
81
|
+
**Follow Critical Principle #2 No Relative Imports Between Components**.
|
|
77
82
|
- After modifying component implementation, always consider updating the following component files `*.composition.*`, `*.docs.mdx`, `*.spec.*`.
|
|
78
83
|
|
|
79
84
|
### Workflow: USE or DEVELOP a Component
|
|
@@ -105,4 +110,5 @@ This is the decision-making process for executing any Bit operation.
|
|
|
105
110
|
|
|
106
111
|
## Pointers to remember:
|
|
107
112
|
|
|
108
|
-
- For generating ESlint or TypeScript configuration files execute the command `bit
|
|
113
|
+
- For generating ESlint or TypeScript configuration files execute the command `bit ws-config write --clean`
|
|
114
|
+
- User may use different terms to describe components. Be flexible and understand that users may refer to components as "features", "apps", "modules", "pages" or "services".
|
|
@@ -1,5 +1,5 @@
|
|
|
1
1
|
;
|
|
2
|
-
import * as overview_0 from '/home/circleci/Library/Caches/Bit/capsules/8891be5ad/teambit.mcp_cli-mcp-server@0.0.
|
|
2
|
+
import * as overview_0 from '/home/circleci/Library/Caches/Bit/capsules/8891be5ad/teambit.mcp_cli-mcp-server@0.0.20/dist/README.docs.mdx';
|
|
3
3
|
|
|
4
4
|
export const compositions = [];
|
|
5
5
|
export const overview = [overview_0];
|
package/package.json
CHANGED
|
@@ -1,12 +1,12 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@teambit/cli-mcp-server",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.20",
|
|
4
4
|
"homepage": "https://bit.cloud/teambit/mcp/cli-mcp-server",
|
|
5
5
|
"main": "dist/index.js",
|
|
6
6
|
"componentId": {
|
|
7
7
|
"scope": "teambit.mcp",
|
|
8
8
|
"name": "cli-mcp-server",
|
|
9
|
-
"version": "0.0.
|
|
9
|
+
"version": "0.0.20"
|
|
10
10
|
},
|
|
11
11
|
"dependencies": {
|
|
12
12
|
"comment-json": "4.2.5",
|
|
@@ -18,19 +18,19 @@
|
|
|
18
18
|
"lodash": "4.17.21",
|
|
19
19
|
"chalk": "4.1.2",
|
|
20
20
|
"@teambit/harmony": "0.4.7",
|
|
21
|
-
"@teambit/cli": "0.0.
|
|
21
|
+
"@teambit/cli": "0.0.1208",
|
|
22
22
|
"@teambit/legacy.constants": "0.0.11",
|
|
23
|
-
"@teambit/logger": "0.0.
|
|
24
|
-
"@teambit/scope.network": "0.0.
|
|
23
|
+
"@teambit/logger": "0.0.1301",
|
|
24
|
+
"@teambit/scope.network": "0.0.52"
|
|
25
25
|
},
|
|
26
26
|
"devDependencies": {
|
|
27
27
|
"@types/fs-extra": "9.0.7",
|
|
28
28
|
"@types/node-fetch": "2.5.12",
|
|
29
29
|
"@types/lodash": "4.14.165",
|
|
30
30
|
"@teambit/harmony.envs.core-aspect-env": "0.0.69",
|
|
31
|
-
"@teambit/component.testing.mock-components": "0.0.
|
|
32
|
-
"@teambit/harmony.testing.load-aspect": "0.0.
|
|
33
|
-
"@teambit/workspace.testing.mock-workspace": "0.0.
|
|
31
|
+
"@teambit/component.testing.mock-components": "0.0.314",
|
|
32
|
+
"@teambit/harmony.testing.load-aspect": "0.0.309",
|
|
33
|
+
"@teambit/workspace.testing.mock-workspace": "0.0.91"
|
|
34
34
|
},
|
|
35
35
|
"peerDependencies": {
|
|
36
36
|
"chai": "4.3.0",
|