github/sim
1
0
Fork 0
mirror of https://github.com/simstudioai/sim.git synced 2026-01-09 15:07:55 -05:00
Code Issues Packages Projects Releases Wiki Activity

chore: added code of conduct, security guidelines. updated issue templates, CONTRIBUTING, README

Browse Source
This commit is contained in:
Waleed Latif
2025-03-16 15:20:27 -07:00
parent 7017cd4629
commit 622e05a430
7 changed files with 211 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files

115
.github/CODE_OF_CONDUCT.md vendored Normal file
View File

@@ -0,0 +1,115 @@
# Code of Conduct - Sim Studio
## Our Pledge
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to make participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behaviour that contributes to a positive environment for our
community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologising to those affected by our mistakes,
and learning from the experience
* Focusing on what is best not just for us as individuals, but for the
overall community
Examples of unacceptable behaviour include:
* The use of sexualised language or imagery, and sexual attention or advances
* Trolling, insulting or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email
address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a
professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying and enforcing our standards of
acceptable behaviour and will take appropriate and fair corrective action in
response to any behaviour that they deem inappropriate,
threatening, offensive, or harmful.
Project maintainers have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, and will
communicate reasons for moderation decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official e-mail address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behaviour may be
reported to the community leaders responsible for enforcement at <waleed@simstudio.ai>.
All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behaviour deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behaviour was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series
of actions.
**Consequence**: A warning with consequences for continued behaviour. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or
permanent ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behaviour.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behaviour, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within
the community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant](https://contributor-covenant.org/), version
[1.4](https://www.contributor-covenant.org/version/1/4/code-of-conduct/code_of_conduct.md) and
[2.0](https://www.contributor-covenant.org/version/2/0/code_of_conduct/code_of_conduct.md),
and was generated by [contributing.md](https://contributing.md/generator).

455
.github/CONTRIBUTING.md vendored Normal file
View File

@@ -0,0 +1,455 @@
# Contributing to Sim Studio
Thank you for your interest in contributing to Sim Studio! Our goal is to provide developers with a powerful, user-friendly platform for building, testing, and optimizing agentic workflows. We welcome contributions in all forms—from bug fixes and design improvements to brand-new features.
> **Project Overview:**
> Sim Studio is a monorepo containing the main application (`sim/`) and documentation (`docs/`). The main application is built with Next.js (app router), ReactFlow, Zustand, Shadcn, and Tailwind CSS. Please ensure your contributions follow our best practices for clarity, maintainability, and consistency.
---
## Table of Contents
- [How to Contribute](#how-to-contribute)
- [Reporting Issues](#reporting-issues)
- [Pull Request Process](#pull-request-process)
- [Commit Message Guidelines](#commit-message-guidelines)
- [Local Development Setup](#local-development-setup)
- [License](#license)
- [Adding New Blocks and Tools](#adding-new-blocks-and-tools)
- [Local Storage Mode](#local-storage-mode)
- [Standalone Build](#standalone-build)
---
## How to Contribute
We strive to keep our workflow as simple as possible. To contribute:
1. **Fork the Repository**
Click the **Fork** button on GitHub to create your own copy of the project.
2. **Clone Your Fork**
```bash
git clone https://github.com/<your-username>/sim.git
```
3. **Create a Feature Branch**
Create a new branch with a descriptive name:
```bash
git checkout -b feat/your-feature-name
```
Use a clear naming convention to indicate the type of work (e.g., `feat/`, `fix/`, `docs/`).
4. **Make Your Changes**
Ensure your changes are small, focused, and adhere to our coding guidelines.
5. **Commit Your Changes**
Write clear, descriptive commit messages that follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#specification) specification. This allows us to maintain a coherent project history and generate changelogs automatically. For example:
- `feat(api): add new endpoint for user authentication`
- `fix(ui): resolve button alignment issue`
- `docs: update contribution guidelines`
6. **Push Your Branch**
```bash
git push origin feat/your-feature-name
```
7. **Create a Pull Request**
Open a pull request against the `main` branch on GitHub. Please provide a clear description of the changes and reference any relevant issues (e.g., `fixes #123`).
---
## Reporting Issues
If you discover a bug or have a feature request, please open an issue in our GitHub repository. When opening an issue, ensure you:
- Provide a clear, descriptive title.
- Include as many details as possible (steps to reproduce, screenshots, etc.).
- **Tag Your Issue Appropriately:**
Use the following labels to help us categorize your issue:
- **active:** Actively working on it right now.
- **bug:** Something isn't working.
- **design:** Improvements & changes to design & UX.
- **discussion:** Initiate a discussion or propose an idea.
- **documentation:** Improvements or updates to documentation.
- **feature:** New feature or request.
> **Note:** If you're uncertain which label to use, mention it in your issue description and we'll help categorize it.
---
## Pull Request Process
Before creating a pull request:
- **Ensure Your Branch Is Up-to-Date:**
Rebase your branch onto the latest `main` branch to prevent merge conflicts.
- **Follow the Guidelines:**
Make sure your changes are well-tested, follow our coding standards, and include relevant documentation if necessary.
- **Reference Issues:**
If your PR addresses an existing issue, include `refs #<issue-number>` or `fixes #<issue-number>` in your PR description.
Our maintainers will review your pull request and provide feedback. We aim to make the review process as smooth and timely as possible.
---
## Commit Message Guidelines
We follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#specification) standard. Your commit messages should have the following format:
```
<type>[optional scope]: <description>
```
- **Types** may include:
- `feat` – a new feature
- `fix` – a bug fix
- `docs` – documentation changes
- `style` – code style changes (formatting, missing semicolons, etc.)
- `refactor` – code changes that neither fix a bug nor add a feature
- `test` – adding or correcting tests
- `chore` – changes to tooling, build process, etc.
- `high priority` – a high priority feature or fix
- `high risk` – a high risk feature or fix
- `improvement` – an improvement to the codebase
_Examples:_
- `feat[auth]: add social login integration`
- `fix[ui]: correct misaligned button on homepage`
- `docs: update installation instructions`
Using clear and consistent commit messages makes it easier for everyone to understand the project history and aids in automating changelog generation.
---
## Local Development Setup
To set up your local development environment:
### Option 1: Using Docker (Recommended)
Docker provides a consistent development environment with all dependencies pre-configured.
1. **Clone the Repository:**
```bash
git clone https://github.com/<your-username>/sim.git
cd sim
```
2. **Start the Docker Environment:**
```bash
docker compose up -d
```
Or use the convenience script which handles environment setup and migrations:
```bash
chmod +x scripts/start_simstudio_docker.sh
./scripts/start_simstudio_docker.sh
```
This will:
- Start a PostgreSQL database container
- Build and run the Next.js application with hot-reloading
- Set up all necessary environment variables
- Apply database migrations automatically
3. **View Logs:**
```bash
docker compose logs -f simstudio
```
4. **Make Your Changes:**
- Edit files in your local directory
- Changes will be automatically reflected thanks to hot-reloading
### Option 2: Using VS Code / Cursor Dev Containers
Dev Containers provide a consistent and easy-to-use development environment:
1. **Prerequisites:**
- Visual Studio Code
- Docker Desktop
- [Remote - Containers](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) extension for VS Code
2. **Setup Steps:**
- Clone the repository:
```bash
git clone https://github.com/<your-username>/sim.git
cd sim
```
- Open the project in VS Code
- When prompted, click "Reopen in Container" (or press F1 and select "Remote-Containers: Reopen in Container")
- Wait for the container to build and initialize
- The development environment will be set up in the `sim/` directory
3. **Start Developing:**
- All dependencies and configurations are automatically set up
- Use the provided aliases (like `sim-start`) to run common commands
- Your changes will be automatically hot-reloaded
4. **GitHub Codespaces:**
- This setup also works with GitHub Codespaces if you prefer development in the browser
- Just click "Code" → "Codespaces" → "Create codespace on main"
### Option 3: Manual Setup
If you prefer not to use Docker or Dev Containers:
1. **Clone the Repository:**
```bash
git clone https://github.com/<your-username>/sim.git
cd sim/sim
```
2. **Install Dependencies:**
- Using NPM:
```bash
npm install
```
3. **Set Up Environment:**
- Copy `.env.example` to `.env`
- Configure database connection and other required authentication variables
4. **Set Up Database:**
- You need a PostgreSQL instance running
- Run migrations:
```bash
npm run db:push
```
5. **Run the Development Server:**
- With NPM:
```bash
npm run dev
```
6. **Make Your Changes and Test Locally.**
---
## License
This project is licensed under the MIT License. By contributing, you agree that your contributions will be licensed under the MIT License as well.
---
## Adding New Blocks and Tools
Sim Studio is built in a modular fashion where blocks and tools extend the platform's functionality. To maintain consistency and quality, please follow the guidelines below when adding a new block or tool.
### Where to Add Your Code
- **Blocks:** Create your new block file under the `/sim/blocks/blocks` directory.
- **Tools:** Create your new tool file under the `/sim/tools` directory.
In addition, you will need to update the registries:
- **Block Registry:** Update the blocks index (usually `/sim/blocks/index.ts`) to include your new block.
- **Tool Registry:** Update the tools registry (`/sim/tools/index.ts`) to add your new tool.
### How to Create a New Block
1. **Create a New File:**
Create a file for your block (e.g., `newBlock.ts`) in the `/sim/blocks/blocks` directory.
2. **Create a New Icon:**
Create a new icon for your block in the `/sim/components/icons.tsx` file.
3. **Define the Block Configuration:**
Your block should export a constant of type `BlockConfig`. For example:
```typescript:/sim/blocks/blocks/newBlock.ts
import { SomeIcon } from '@/components/icons'
import { BlockConfig } from '../types'
// Define response type if needed
interface NewBlockResponse {
output: {
// Define expected output here
result: string
}
}
export const NewBlock: BlockConfig<NewBlockResponse> = {
type: 'new',
name: 'New Block',
description: 'Description of the new block',
longDescription: 'A more detailed description of what this block does and how to use it.',
category: 'tools',
bgColor: '#123456',
icon: SomeIcon,
// If this block requires OAuth authentication
provider: 'new-service',
// Define subBlocks for the UI configuration
subBlocks: [
{
id: 'apiKey',
title: 'API Key',
type: 'short-input',
layout: 'full',
placeholder: 'Enter your API key',
},
{
id: 'query',
title: 'Query',
type: 'long-input',
layout: 'full',
placeholder: 'Enter your search query',
},
{
id: 'model',
title: 'Model',
type: 'dropdown',
layout: 'half',
options: ['model-1', 'model-2', 'model-3'],
},
],
}
```
4. **Register Your Block:**
Import and add your block to the blocks registry (`/sim/blocks/index.ts`) in the appropriate index file so it appears in the workflow builder.
```typescript:/sim/blocks/index.ts
import { NewBlock } from './blocks/newBlock'
export const blocks = [
// ... existing blocks
NewBlock,
]
export const blocksByType: Record<string, BlockConfig> = {
// ... existing blocks by type
new: NewBlock,
}
```
5. **Test Your Block:**
Ensure that the block displays correctly in the UI and that its functionality works as expected.
### How to Create a New Tool
1. **Create a New Directory:**
For tools with multiple related functions, create a directory under `/sim/tools` (e.g., `/sim/tools/newService`).
2. **Create Tool Files:**
Create files for your tool functionality (e.g., `read.ts`, `write.ts`) in your tool directory.
3. **Create an Index File:**
Create an `index.ts` file in your tool directory that imports and exports all tools with appropriate prefixes:
```typescript:/sim/tools/newService/index.ts
import { readTool } from './read'
import { writeTool } from './write'
export const newServiceReadTool = readTool
export const newServiceWriteTool = writeTool
```
4. **Define the Tool Configuration:**
Your tool should export a constant of type `ToolConfig`. For example:
```typescript:/sim/tools/newService/read.ts
import { ToolConfig, ToolResponse } from '../types'
interface NewToolParams {
apiKey: string
query: string
}
interface NewToolResponse extends ToolResponse {
output: {
result: string
}
}
export const readTool: ToolConfig<NewToolParams, NewToolResponse> = {
id: 'new_service_read',
name: 'New Service Reader',
description: 'Description for the new tool',
version: '1.0.0',
// OAuth configuration (if applicable)
provider: 'new-service', // ID of the OAuth provider
additionalScopes: ['https://api.newservice.com/read'], // Required OAuth scopes
params: {
apiKey: {
type: 'string',
required: true,
description: 'API key for authentication',
},
query: {
type: 'string',
required: true,
description: 'Query to search for',
},
},
request: {
url: 'https://api.example.com/query',
method: 'POST',
headers: (params) => ({
'Content-Type': 'application/json',
Authorization: `Bearer ${params.apiKey}`,
}),
body: (params) => JSON.stringify({ query: params.query }),
},
transformResponse: async (response: Response) => {
const data = await response.json()
return {
success: true,
output: { result: data.result },
}
},
transformError: (error) => {
return error.message || 'An error occurred while processing the tool request'
},
}
```
5. **Register Your Tool:**
Update the tools registry in `/sim/tools/index.ts` to include your new tool. Import from your tool's index.ts file:
```typescript:/sim/tools/index.ts
import { newServiceReadTool, newServiceWriteTool } from './newService'
// ... other imports
export const tools: Record<string, ToolConfig> = {
// ... existing tools
new_service_read: newServiceReadTool,
new_service_write: newServiceWriteTool,
}
```
6. **Test Your Tool:**
Ensure that your tool functions correctly by making test requests and verifying the responses.
### Guidelines & Best Practices
- **Code Style:** Follow the project's ESLint and Prettier configurations. Use meaningful variable names and small, focused functions.
- **Documentation:** Clearly document the purpose, inputs, outputs, and any special behavior for your block/tool.
- **Error Handling:** Implement robust error handling and provide user-friendly error messages.
- **Testing:** Add unit or integration tests to verify your changes when possible.
- **Commit Changes:** Update all related components and registries, and describe your changes in your pull request.
Happy coding!
---
Thank you for taking the time to contribute to Sim Studio. We truly appreciate your efforts and look forward to collaborating with you!

47
.github/ISSUE_TEMPLATE/bug_report.md vendored
View File

@@ -1,39 +1,26 @@
---
name: Bug report
about: Report any issues with the platform
title: ''
labels: ['🐛 bug']
about: Create a report to help us improve
title: "[BUG]"
labels: bug
assignees: ''
---
Found a bug? Please fill out the sections below. 👍
**Describe the bug**
A clear and concise description of what the bug is.
### Issue Summary
**To Reproduce**
Steps to reproduce the behavior:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
A summary of the issue. This needs to be a clear detailed-rich summary.
**Expected behavior**
A clear and concise description of what you expected to happen.
### Steps to Reproduce
**Screenshots**
If applicable, add screenshots to help explain your problem.
1. (for example) Went to ...
2. Clicked on...
3. ...
Any other relevant information. For example, why do you consider this a bug and what did you expect to happen instead?
### Actual Results
- What's happening right now that is different from what is expected
### Expected Results
- This is an ideal result that the system should get after the tests are performed
### Technical details
- Browser version, screen recording, console logs, network requests: You can make a recording with [Bird Eats Bug](https://birdeatsbug.com/).
- Node.js version
- Anything else that you think could be an issue.
### Evidence
- How was this tested? This is quite mandatory in terms of bugs. Providing evidence of your testing with screenshots or/and videos is an amazing way to prove the bug and a troubleshooting chance to find the solution.
**Additional context**
Add any other context about the problem here.

31
.github/ISSUE_TEMPLATE/feature_request.md vendored
View File

@@ -1,28 +1,19 @@
---
name: Feature request
about: Suggest a feature or idea
title: ''
labels: ['✨ feature']
about: Suggest an idea for this project
title: "[REQUEST]"
labels: feature
assignees: ''
---
### Describe the solution you'd like
**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
<!--
Provide a clear and concise description of what you want to happen.
-->
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
### Describe alternatives you've considered
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
<!--
Let us know about other solutions you've considered, tried or researched.
-->
### Additional context
<!--
Is there anything else you can add about the proposal?
You might want to link to related issues here, if you haven't already.
-->
---
**Additional context**
Add any other context or screenshots about the feature request here.

53
.github/PULL_REQUEST_TEMPLATE.md vendored
View File

@@ -1,30 +1,43 @@
## What does this PR do?
# Pull Request Template
- Fixes #XXXX (GitHub issue number)
## Description
<!-- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. -->
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context.
## Mandatory Tasks (DO NOT REMOVE)
Fixes # (issue)
- [ ] I have self-reviewed the code (A decent size PR without self-review might be rejected).
- [ ] I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
- [ ] I confirm automated tests are in place that prove my fix is effective or that my feature works.
## Type of change
## How should this be tested?
Please delete options that are not relevant.
<!-- Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. Write details that help to start the tests -->
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] Documentation update
- [ ] Security enhancement
- [ ] Performance improvement
- [ ] Code refactoring (no functional changes)
- Are there environment variables that should be set?
- What are the minimal test data to have?
- What is expected (happy path) to have (input and output)?
- Any other important info that could help to test that PR
## How Has This Been Tested?
## Checklist
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration.
<!-- Remove bullet points below that don't apply to you -->
## Checklist:
- I haven't read the [contributing guide](https://github.com/simstudioai/sim-studio/blob/main/CONTRIBUTING.md)
- My code doesn't follow the style guidelines of this project
- I haven't commented my code, particularly in hard-to-understand areas
- I haven't checked if my changes generate no new warnings
- I haven't checked if my changes generate no new errors
- [ ] My code follows the style guidelines of this project
- [ ] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] My changes generate no new warnings
- [ ] I have added tests that prove my fix is effective or that my feature works
- [ ] Any dependent changes have been merged and published in downstream modules
- [ ] I have updated version numbers as needed (if needed)
## Security Considerations:
- [ ] My changes do not introduce any new security vulnerabilities
- [ ] I have considered the security implications of my changes
## Additional Information:
Any additional information, configuration or data that might be necessary to reproduce the issue or use the feature.

26
.github/SECURITY.md vendored Normal file
View File

@@ -0,0 +1,26 @@
# Security Policy
## Supported Versions
| Version | Supported |
| ------- | ------------------ |
| 0.1.x | :white_check_mark: |
## Reporting a Vulnerability
We take the security of Sim Studio seriously. If you believe you've found a security vulnerability, please follow these steps:
1. **Do not disclose the vulnerability publicly** or to any third parties.
2. **Email us directly** at security@simstudio.ai with details of the vulnerability.
3. **Include the following information** in your report:
- Description of the vulnerability
- Steps to reproduce
- Potential impact
- Any suggestions for mitigation
4. We will acknowledge receipt of your vulnerability report within 48 hours and provide an estimated timeline for a fix.
5. Once the vulnerability is fixed, we will notify you and publicly acknowledge your contribution (unless you prefer to remain anonymous).