superacli 1.1.7 → 1.1.8
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.
- package/CONTRIBUTING.md +270 -0
- package/README.md +64 -1
- package/__tests__/adapter-schema.test.js +251 -86
- package/__tests__/resend-plugin.test.js +109 -82
- package/cli/adapters/process.js +1 -5
- package/cli/plugins-manager.js +3 -3
- package/cli/supercli.js +193 -77
- package/docs/index.html +183 -123
- package/index.html +384 -0
- package/package.json +2 -2
- package/plugins/plugins.json +11 -0
- package/docs/docs.html +0 -224
package/CONTRIBUTING.md
ADDED
|
@@ -0,0 +1,270 @@
|
|
|
1
|
+
# Contributing to supercli
|
|
2
|
+
|
|
3
|
+
Welcome to supercli! We're excited that you're interested in contributing. This guide will help you understand how to contribute effectively.
|
|
4
|
+
|
|
5
|
+
## Introduction
|
|
6
|
+
|
|
7
|
+
supercli is a universal capability router that bridges humans and AI agents to multiple CLI tools, APIs, MCP servers, and workflows. We welcome contributions in many forms:
|
|
8
|
+
|
|
9
|
+
- **Code improvements** - Bug fixes, new features, performance improvements
|
|
10
|
+
- **Documentation** - Improving guides, examples, and API references
|
|
11
|
+
- **Plugin development** - Creating new harnesses for CLI tools
|
|
12
|
+
- **Issue reporting** - Helping us identify and reproduce problems
|
|
13
|
+
- **Community support** - Answering questions and helping others
|
|
14
|
+
|
|
15
|
+
## Getting Started
|
|
16
|
+
|
|
17
|
+
### Prerequisites
|
|
18
|
+
|
|
19
|
+
Before contributing, ensure you have:
|
|
20
|
+
|
|
21
|
+
- [Node.js](https://nodejs.org/) (LTS version recommended)
|
|
22
|
+
- [npm](https://www.npmjs.com/) or [pnpm](https://pnpm.io/)
|
|
23
|
+
- Git for version control
|
|
24
|
+
- Any CLI tools you want to create plugins for
|
|
25
|
+
|
|
26
|
+
### Setting Up Your Development Environment
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
# Fork the repository on GitHub
|
|
30
|
+
# Clone your fork
|
|
31
|
+
git clone https://github.com/YOUR_USERNAME/supercli.git
|
|
32
|
+
cd supercli
|
|
33
|
+
|
|
34
|
+
# Install dependencies
|
|
35
|
+
npm install
|
|
36
|
+
|
|
37
|
+
# Copy environment configuration
|
|
38
|
+
cp .env.example .env
|
|
39
|
+
|
|
40
|
+
# Run tests to verify setup
|
|
41
|
+
npm test
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
### Finding Things to Work On
|
|
45
|
+
|
|
46
|
+
- Check the [Issues](https://github.com/javimosch/supercli/issues) for bugs and feature requests
|
|
47
|
+
- Look for issues tagged with `good first issue` for beginner-friendly contributions
|
|
48
|
+
- Review the [Project Board](https://github.com/javimosch/supercli/projects) for planned work
|
|
49
|
+
- Propose new features by opening a discussion
|
|
50
|
+
|
|
51
|
+
## Issue Reporting
|
|
52
|
+
|
|
53
|
+
### Bug Reports
|
|
54
|
+
|
|
55
|
+
When reporting bugs, include:
|
|
56
|
+
|
|
57
|
+
1. **Clear title** describing the issue
|
|
58
|
+
2. **Steps to reproduce** - Be specific and detailed
|
|
59
|
+
3. **Expected vs actual behavior** - What you expected vs what happened
|
|
60
|
+
4. **Environment details** - OS, Node.js version, supercli version
|
|
61
|
+
5. **Relevant logs** - Error messages, stack traces
|
|
62
|
+
6. **Minimal reproduction** - If possible, a small code snippet that reproduces the issue
|
|
63
|
+
|
|
64
|
+
### Feature Requests
|
|
65
|
+
|
|
66
|
+
For new features:
|
|
67
|
+
|
|
68
|
+
1. **Describe the feature** - What should happen and why it's useful
|
|
69
|
+
2. **Use cases** - Who benefits and how they'll use it
|
|
70
|
+
3. **Alternatives considered** - What other approaches did you consider?
|
|
71
|
+
4. **Implementation suggestions** - If you have ideas, share them
|
|
72
|
+
|
|
73
|
+
### Issue Template Example
|
|
74
|
+
|
|
75
|
+
```markdown
|
|
76
|
+
## Description
|
|
77
|
+
[A clear description of the issue or feature request]
|
|
78
|
+
|
|
79
|
+
## Steps to Reproduce (for bugs)
|
|
80
|
+
1. Run '...'
|
|
81
|
+
2. Execute '...'
|
|
82
|
+
3. See error
|
|
83
|
+
|
|
84
|
+
## Expected Behavior
|
|
85
|
+
[What you expected to happen]
|
|
86
|
+
|
|
87
|
+
## Actual Behavior
|
|
88
|
+
[What actually happened]
|
|
89
|
+
|
|
90
|
+
## Environment
|
|
91
|
+
- OS: [e.g., macOS 14.0]
|
|
92
|
+
- Node.js: [e.g., v20.10.0]
|
|
93
|
+
- supercli: [e.g., v1.2.3]
|
|
94
|
+
|
|
95
|
+
## Additional Context
|
|
96
|
+
[Any other relevant information, logs, or screenshots]
|
|
97
|
+
```
|
|
98
|
+
|
|
99
|
+
## Code Contributions
|
|
100
|
+
|
|
101
|
+
### Branching Strategy
|
|
102
|
+
|
|
103
|
+
- `main` - Stable release branch
|
|
104
|
+
- `feature/*` - New features
|
|
105
|
+
- `fix/*` - Bug fixes
|
|
106
|
+
- `docs/*` - Documentation improvements
|
|
107
|
+
|
|
108
|
+
### Development Workflow
|
|
109
|
+
|
|
110
|
+
```bash
|
|
111
|
+
# Create a feature branch
|
|
112
|
+
git checkout -b feature/my-new-feature
|
|
113
|
+
|
|
114
|
+
# Make your changes
|
|
115
|
+
# Write tests for new functionality
|
|
116
|
+
|
|
117
|
+
# Run tests before committing
|
|
118
|
+
npm test
|
|
119
|
+
|
|
120
|
+
# Commit with clear messages
|
|
121
|
+
git commit -m "feat: add support for new CLI tool X"
|
|
122
|
+
|
|
123
|
+
# Push and create PR
|
|
124
|
+
git push origin feature/my-new-feature
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
### Commit Message Conventions
|
|
128
|
+
|
|
129
|
+
We follow [Conventional Commits](https://www.conventionalcommits.org/):
|
|
130
|
+
|
|
131
|
+
```
|
|
132
|
+
<type>(<scope>): <description>
|
|
133
|
+
|
|
134
|
+
[optional body]
|
|
135
|
+
|
|
136
|
+
[optional footer]
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
**Types:**
|
|
140
|
+
- `feat` - New feature
|
|
141
|
+
- `fix` - Bug fix
|
|
142
|
+
- `docs` - Documentation changes
|
|
143
|
+
- `style` - Code style (formatting, no logic change)
|
|
144
|
+
- `refactor` - Code refactoring
|
|
145
|
+
- `test` - Adding or updating tests
|
|
146
|
+
- `chore` - Maintenance tasks
|
|
147
|
+
|
|
148
|
+
**Examples:**
|
|
149
|
+
```
|
|
150
|
+
feat(plugins): add support for new CLI wrapper
|
|
151
|
+
fix(docker): resolve container listing timeout
|
|
152
|
+
docs(readme): update installation instructions
|
|
153
|
+
```
|
|
154
|
+
|
|
155
|
+
### Pull Request Process
|
|
156
|
+
|
|
157
|
+
1. **Ensure tests pass** - Run `npm test` locally
|
|
158
|
+
2. **Update documentation** - If adding features, update relevant docs
|
|
159
|
+
3. **Follow code style** - Use existing patterns in the codebase
|
|
160
|
+
4. **Write meaningful PR description** - Explain what and why
|
|
161
|
+
5. **Respond to feedback** - Be responsive to review comments
|
|
162
|
+
|
|
163
|
+
### Code Review Guidelines
|
|
164
|
+
|
|
165
|
+
**For reviewers:**
|
|
166
|
+
- Review code for correctness, not style (let linters handle formatting)
|
|
167
|
+
- Test the changes locally when possible
|
|
168
|
+
- Provide constructive, actionable feedback
|
|
169
|
+
- Focus on the code, not the person
|
|
170
|
+
|
|
171
|
+
**For contributors:**
|
|
172
|
+
- Keep PRs focused and reasonably sized
|
|
173
|
+
- Respond to feedback promptly
|
|
174
|
+
- Ask for clarification if feedback is unclear
|
|
175
|
+
|
|
176
|
+
## Documentation Contributions
|
|
177
|
+
|
|
178
|
+
### Where to Find Documentation
|
|
179
|
+
|
|
180
|
+
- `/docs/` - Main documentation directory
|
|
181
|
+
- `/docs/plugins-how-to.md` - Plugin development guide
|
|
182
|
+
- `/docs/skills/` - Skill system documentation
|
|
183
|
+
- `/README.md` - Project overview and quick start
|
|
184
|
+
- Plugin-specific docs in `/plugins/*/README.md`
|
|
185
|
+
|
|
186
|
+
### Documentation Style
|
|
187
|
+
|
|
188
|
+
- Use clear, concise language
|
|
189
|
+
- Include practical examples
|
|
190
|
+
- Keep code snippets up to date
|
|
191
|
+
- Use consistent formatting
|
|
192
|
+
|
|
193
|
+
### Contributing Plugin Documentation
|
|
194
|
+
|
|
195
|
+
When creating or updating plugins:
|
|
196
|
+
|
|
197
|
+
1. Add a `README.md` in the plugin directory
|
|
198
|
+
2. Include installation instructions
|
|
199
|
+
3. Document available commands
|
|
200
|
+
4. Provide usage examples
|
|
201
|
+
5. Reference the upstream CLI documentation
|
|
202
|
+
|
|
203
|
+
## Plugin Development
|
|
204
|
+
|
|
205
|
+
### Want to Create a New Plugin?
|
|
206
|
+
|
|
207
|
+
See our detailed [Plugin Harness Development Guide](docs/plugins-how-to.md) for:
|
|
208
|
+
|
|
209
|
+
- Plugin manifest structure (`plugin.json`)
|
|
210
|
+
- Command wrapping vs passthrough patterns
|
|
211
|
+
- Argument mapping configuration
|
|
212
|
+
- Testing and debugging tips
|
|
213
|
+
|
|
214
|
+
### Quick Plugin Checklist
|
|
215
|
+
|
|
216
|
+
Before submitting a plugin for inclusion:
|
|
217
|
+
|
|
218
|
+
- [ ] Plugin has a valid `plugin.json` manifest
|
|
219
|
+
- [ ] Binary dependency checks are configured
|
|
220
|
+
- [ ] Commands have clear descriptions
|
|
221
|
+
- [ ] JSON output is supported where applicable
|
|
222
|
+
- [ ] Plugin README includes installation and usage instructions
|
|
223
|
+
- [ ] Tests pass (if applicable)
|
|
224
|
+
- [ ] No hardcoded credentials or secrets
|
|
225
|
+
|
|
226
|
+
### Publishing Plugins
|
|
227
|
+
|
|
228
|
+
Once your plugin is ready:
|
|
229
|
+
|
|
230
|
+
```bash
|
|
231
|
+
# Install locally for testing
|
|
232
|
+
supercli plugins install ./path/to/my-plugin
|
|
233
|
+
|
|
234
|
+
# Test functionality
|
|
235
|
+
supercli my-plugin --help
|
|
236
|
+
|
|
237
|
+
# Publish to community registry
|
|
238
|
+
supercli plugins publish ./my-plugin
|
|
239
|
+
```
|
|
240
|
+
|
|
241
|
+
## Community Guidelines
|
|
242
|
+
|
|
243
|
+
### Code of Conduct
|
|
244
|
+
|
|
245
|
+
We are committed to providing a welcoming, inclusive environment. By participating, you agree to:
|
|
246
|
+
|
|
247
|
+
- Be respectful and inclusive
|
|
248
|
+
- Welcome newcomers and help others learn
|
|
249
|
+
- Accept constructive criticism professionally
|
|
250
|
+
- Focus on what's best for the community
|
|
251
|
+
|
|
252
|
+
### Getting Help
|
|
253
|
+
|
|
254
|
+
- **Discussions** - Use GitHub Discussions for questions
|
|
255
|
+
- **Issues** - For bugs and feature requests
|
|
256
|
+
- **Documentation** - Check docs/ before asking
|
|
257
|
+
|
|
258
|
+
### Supporting Others
|
|
259
|
+
|
|
260
|
+
- Answer questions in discussions
|
|
261
|
+
- Help newcomers get started
|
|
262
|
+
- Share your experience and knowledge
|
|
263
|
+
|
|
264
|
+
## License
|
|
265
|
+
|
|
266
|
+
By contributing to supercli, you agree that your contributions will be licensed under the [MIT License](LICENSE).
|
|
267
|
+
|
|
268
|
+
---
|
|
269
|
+
|
|
270
|
+
Thank you for contributing to supercli! Your help makes this project better for everyone.
|
package/README.md
CHANGED
|
@@ -2,6 +2,31 @@
|
|
|
2
2
|
|
|
3
3
|
Discover and execute capabilities across CLIs, APIs, MCP servers, workflows, and custom automations through a single agent-friendly interface.
|
|
4
4
|
|
|
5
|
+
## Why Supercli?
|
|
6
|
+
|
|
7
|
+
### For Humans
|
|
8
|
+
Stop context-switching between CLI tools. supercli gives you one consistent interface to AWS, GitHub, Docker, Kubernetes, and 50+ other platforms—so you spend less time learning syntax and more time solving problems.
|
|
9
|
+
|
|
10
|
+
### For AI Agents
|
|
11
|
+
Access a standardized skill graph where every capability follows predictable input/output envelopes. Discover, compose, and execute workflows with machine-readable metadata that enables reliable automation.
|
|
12
|
+
|
|
13
|
+
### For Supervisors
|
|
14
|
+
Trust that your AI agents have explicit boundaries. Every skill declares its capabilities, inputs, outputs, and safety profile—no hidden behavior. Agents must explicitly opt-in to raw CLI power via passthrough, and every invocation follows predictable error patterns.
|
|
15
|
+
|
|
16
|
+
### Shared Value
|
|
17
|
+
|
|
18
|
+
| Scenario | Direct CLI Approach | Supercli Approach |
|
|
19
|
+
|----------|-------------------|-------------------|
|
|
20
|
+
| Learning a new tool | Read 50-page docs, memorize flags | `supercli skills get <tool>.*` with examples |
|
|
21
|
+
| Cross-tool workflows | Manual context passing between commands | Automatic context propagation |
|
|
22
|
+
| Finding capabilities | Google/search multiple docs sites | `supercli skills search <query>` |
|
|
23
|
+
| Safe automation | Risk of accidental destructive commands | Agent-friendly wrappers with safeguards |
|
|
24
|
+
| Writing scripts | Parse inconsistent text output | Consistent JSON envelopes |
|
|
25
|
+
|
|
26
|
+
**Same command structure everywhere:** `supercli <plugin> <action> ...`
|
|
27
|
+
|
|
28
|
+
Whether you're human or agent, supercli reduces cognitive load through consistent skill invocation patterns while maintaining access to full CLI power via passthrough (`supercli <plugin> -- <raw-args>`).
|
|
29
|
+
|
|
5
30
|
## Terminology
|
|
6
31
|
|
|
7
32
|
- **Capability**: Any executable unit exposed by Supercli (command, OpenAPI operation, MCP tool binding, HTTP integration, workflow step).
|
|
@@ -86,6 +111,30 @@ Traditional CLIs force agents to learn tool-specific syntax. supercli replaces t
|
|
|
86
111
|
- Compose (`supercli plan …`) to build DAGs out of capabilities without writing glue code
|
|
87
112
|
- Delegate execution to the same router regardless of whether the source is a CLI, API, or MCP tool
|
|
88
113
|
|
|
114
|
+
### Safety & Trust for Agents
|
|
115
|
+
|
|
116
|
+
**Why supervisors can trust supercli with AI agents:**
|
|
117
|
+
|
|
118
|
+
- **Explicit Boundaries:** Each skill declares its capabilities, inputs, and outputs—nothing hidden
|
|
119
|
+
- **Consistent Wrappers:** Agent-friendly modes (`--json`, `--silent`) prevent interactive prompts
|
|
120
|
+
- **Audit Trail:** Every invocation logs plugin, action, inputs, and outputs
|
|
121
|
+
- **Opt-In Power:** Full CLI access requires explicit passthrough (`supercli <plugin> -- <raw-args>`)
|
|
122
|
+
- **Predictable Errors:** Standardized error envelopes with machine-readable codes
|
|
123
|
+
- **No Side Effects:** Skills declare whether they're read-only or state-modifying
|
|
124
|
+
|
|
125
|
+
**Agent workflow example:**
|
|
126
|
+
|
|
127
|
+
```bash
|
|
128
|
+
# 1. Find relevant capabilities
|
|
129
|
+
supercli skills search "deployment" --json
|
|
130
|
+
|
|
131
|
+
# 2. Inspect exact requirements
|
|
132
|
+
supercli skills get aws.cfn.deploy --json
|
|
133
|
+
|
|
134
|
+
# 3. Execute with predictable output
|
|
135
|
+
supercli aws cfn deploy --stack-name my-stack --template-file template.yaml --json
|
|
136
|
+
```
|
|
137
|
+
|
|
89
138
|
## Capability Mesh Vision
|
|
90
139
|
|
|
91
140
|
supercli is steadily evolving toward a broader **capability mesh** that provides discovery, routing, execution, composition, and governance across every tool in the stack. Near-term focus areas include:
|
|
@@ -124,6 +173,7 @@ npm install
|
|
|
124
173
|
# Optional local config
|
|
125
174
|
cp .env.example .env
|
|
126
175
|
|
|
176
|
+
# === Human Perspective ===
|
|
127
177
|
# Local CLI usage - Multi-harness routing
|
|
128
178
|
supercli help # List all harnesses
|
|
129
179
|
supercli beads # List beads capabilities
|
|
@@ -143,6 +193,19 @@ supercli plugins list
|
|
|
143
193
|
supercli plugins explore # Browse available plugins
|
|
144
194
|
supercli plugins install commiat # Install community plugin
|
|
145
195
|
|
|
196
|
+
# === Agent Perspective ===
|
|
197
|
+
# Programmatic capability discovery (machine-readable)
|
|
198
|
+
supercli --help-json # Full capability manifest in JSON
|
|
199
|
+
supercli skills list --json # All skills with metadata
|
|
200
|
+
supercli skills search "deployment" --json # Filtered capabilities
|
|
201
|
+
|
|
202
|
+
# Predictable execution with JSON output
|
|
203
|
+
supercli aws sts get-caller-identity --json
|
|
204
|
+
supercli gh issue list --json
|
|
205
|
+
|
|
206
|
+
# Inspect specific capabilities before execution
|
|
207
|
+
supercli skills get aws.cfn.deploy --json
|
|
208
|
+
|
|
146
209
|
# Path B: Server mode (optional, shared backend)
|
|
147
210
|
# Start server (local JSON storage by default; MongoDB optional)
|
|
148
211
|
npm start
|
|
@@ -323,7 +386,7 @@ The dcli community is actively developing plugins for popular CLIs:
|
|
|
323
386
|
- **Monitoring**: datadog, prometheus CLIs
|
|
324
387
|
- Many others based on community requests
|
|
325
388
|
|
|
326
|
-
Want to contribute
|
|
389
|
+
Want to contribute? See [CONTRIBUTING.md](CONTRIBUTING.md) for guidelines on contributing code, documentation, and plugin harnesses.
|
|
327
390
|
|
|
328
391
|
## Output Envelope
|
|
329
392
|
|