Skip to content

Commit 30b7788

Browse files
maor-rozenfeldmaor-rozenfeld
committed
Add AGENTS.md
1 parent ac34158 commit 30b7788

3 files changed

Lines changed: 170 additions & 198 deletions

File tree

‎.cursor/rules/coding-guidelines.mdc‎

Lines changed: 0 additions & 135 deletions
This file was deleted.

‎.junie/guidelines.md‎

Lines changed: 1 addition & 63 deletions
Original file line numberDiff line numberDiff line change
@@ -1,63 +1 @@
1-
# Guidelines for Junie
2-
3-
This document provides guidelines for contributing to the OpenOps project, focusing on pull requests and commit practices.
4-
5-
## Pull Request Guidelines
6-
7-
### Size and Scope
8-
9-
- **Prefer small PRs**: Keep pull requests focused on a single feature, bug fix, or improvement.
10-
- **Small commits**: Break down your work into logical, small commits that each represent a complete change.
11-
- **One change per PR**: The PR should only contain changes related to the issue, with no unrelated modifications.
12-
13-
### Naming and Formatting
14-
15-
- **Use imperative mood** for PR titles and commit messages (e.g., "Add feature" not "Added feature" or "Adding feature").
16-
- **PR title requirements** (as defined in `.github/prlint.json`):
17-
- Must start with a capital letter and a real word (e.g., "Add GO support")
18-
- Must have at least three words
19-
- Must use imperative mood (e.g., "Fix bug" not "Fixed bug" or "Fixing bug")
20-
21-
### Creating Pull Requests
22-
23-
1. **Use GitHub CLI to create a draft PR**:
24-
```bash
25-
# Create a draft PR
26-
gh pr create --draft --title "Add feature name" --body "Fixes #12345"
27-
```
28-
29-
2. **Reference issues**:
30-
- Reference a GitHub issue in the PR body (e.g., "Fixes #12345")
31-
- Reference a Linear issue if one was mentioned (e.g., "Fixes OPS-1234")
32-
- If no relevant issue exists, create a GitHub issue first:
33-
```bash
34-
# Create a GitHub issue
35-
gh issue create --title "Issue title" --body "Issue description"
36-
```
37-
38-
3. **Follow the PR template**:
39-
- Provide a clear description of the changes
40-
- Complete the testing checklist
41-
- Include visual changes if applicable
42-
43-
## Commit Guidelines
44-
45-
- **Use imperative mood** in commit messages (e.g., "Fix bug" not "Fixed bug")
46-
- **Keep commits small and focused** on a single change
47-
- **Write descriptive commit messages** that explain what the change does and why
48-
- **Follow this format** for commit messages:
49-
```
50-
Short summary in imperative mood (under 50 chars)
51-
52-
More detailed explanation if necessary. Wrap at around 72
53-
characters. Explain what and why, not how (the code shows that).
54-
55-
Fixes #issue_number
56-
```
57-
58-
## Additional Resources
59-
60-
- [CONTRIBUTING.md](../CONTRIBUTING.md): General contribution guidelines
61-
- [.github/pull_request_template.md](../.github/pull_request_template.md): PR template
62-
- [.github/prlint.json](../.github/prlint.json): PR linting rules
63-
- [docs.openops.com](https://docs.openops.com): Official OpenOps documentation
1+
See AGENTS.md in root folder.

‎AGENTS.md‎

Lines changed: 169 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,169 @@
1+
## General Principles
2+
3+
- Follow existing code style and patterns in the repository
4+
- Write clear, self-documenting code with descriptive variable and function names
5+
- Include comments for complex logic or non-obvious behavior
6+
- Always write tests for new functionality and changes
7+
- Update documentation for user-facing changes
8+
- Do not introduce new dependencies without discussion
9+
10+
11+
## Structure
12+
13+
The repository is using nx, with the source code under the "packages" directory.
14+
Use nx to run tests (e.g. npx nx test server-shared).
15+
Run "npx nx lint" before committing.
16+
17+
## Code Style
18+
19+
### Formatting
20+
21+
- **Indentation:** 2 spaces (TypeScript/JavaScript, shell scripts)
22+
- **Line length:** 100–120 characters preferred
23+
- **Braces:** Required for all control blocks, even single-line
24+
- **Spacing:**
25+
- One space between keywords and parentheses: `if (condition) {`
26+
- No trailing whitespace
27+
- Newline at end of file
28+
- **Linting:** Use ESLint as configured in each package
29+
- **Formatting:** Follow Prettier rules if configured
30+
- Respect `.editorconfig`, `.eslintrc`, `.prettierrc`, and other config files
31+
32+
### Naming Conventions
33+
34+
- **Variables/Functions:** `camelCase`
35+
- **Classes/Types:** `PascalCase`
36+
- **Constants:** `UPPER_SNAKE_CASE`
37+
- **Files:** Lowercase with hyphens (e.g., `user-profile.ts`)
38+
39+
### Comments
40+
41+
- Explain _why_ something is done, not _what_ (the code should be self-explanatory)
42+
- Use `TODO:` for actionable technical debt
43+
- Document public functions, classes, and modules
44+
45+
## TypeScript/JavaScript
46+
47+
### General Guidelines
48+
49+
- Use types and interfaces where appropriate
50+
- Prefer `const` over `let` or `var`
51+
- Prefer arrow functions for callbacks and functional components
52+
- Use explicit return types for exported functions
53+
54+
### Example
55+
56+
```typescript
57+
export function getUserProfile(userId: string): UserProfile {
58+
if (!userId) {
59+
throw new Error('User ID required');
60+
}
61+
// TODO: Replace with real data source
62+
return { id: userId, name: 'Sample User' };
63+
}
64+
```
65+
66+
## Frontend Guidelines
67+
68+
### Project Structure
69+
70+
- Use the `react-ui` package for main application logic
71+
- Place pure, reusable components in the `ui-components` package, documented in Storybook
72+
- Place and write tests in a separate `tests` folder
73+
74+
### Tech Stack
75+
76+
- **React 18**
77+
- **Zustand** for state management
78+
- **react-query v5** for data fetching
79+
- **shadcn** for UI components
80+
- **Axios** (use existing wrapper in `api.ts`), use `qs` package for query strings
81+
82+
### Best Practices
83+
84+
- Follow best practices for React hooks
85+
- Prefer small, composable components
86+
- Extract helper functions where possible
87+
- Do not make breaking changes to existing code interfaces (component props, names) without discussion
88+
- Ensure compliance with strict linter setups (including Sonar)
89+
- Use `cn` utility to group Tailwind classnames:
90+
91+
```tsx
92+
<div
93+
className={cn(
94+
'absolute bottom-[-20px] left-1/2 -translate-x-1/2',
95+
'w-[118px] h-[24px] flex items-center justify-center',
96+
'font-satoshi font-medium text-xs text-blueAccent-500',
97+
'border border-solid border-blueAccent-500 rounded-[4px]',
98+
'bg-background-800',
99+
{
100+
'pt-2': !someVar
101+
}
102+
)}
103+
>
104+
{t('Sample output data')}
105+
</div>
106+
```
107+
108+
## Testing
109+
110+
- Use Jest for testing
111+
- Place unit tests in a `tests` folder alongside the code
112+
- Run tests using Nx commands:
113+
114+
```bash
115+
nx test react-ui
116+
nx test ui-components
117+
nx test-unit server-api
118+
nx test engine
119+
nx lint react-ui
120+
```
121+
122+
## Git Workflow
123+
124+
### Commits
125+
126+
- Use imperative mood (e.g., "Fix bug" not "Fixed bug" or "Fixing bug")
127+
- Keep commits small and focused on a single change
128+
- Write descriptive commit messages that explain what and why, not how
129+
130+
**Commit message format:**
131+
132+
```
133+
Short summary in imperative mood (under 50 chars)
134+
135+
More detailed explanation if necessary. Wrap at around 72
136+
characters. Explain what and why, not how (the code shows that).
137+
138+
Fixes #issue_number
139+
```
140+
141+
### Pull Requests
142+
143+
#### Size and Scope
144+
145+
- Keep PRs focused on a single feature, bug fix, or improvement
146+
- Break down work into logical, small commits
147+
- Only include changes related to the issue, no unrelated modifications
148+
149+
#### Title Requirements
150+
151+
- Must start with a capital letter and a real word
152+
- Must have at least three words
153+
- Must use imperative mood (e.g., "Add GO support" not "Added GO support")
154+
155+
#### Reference an issue
156+
157+
All PRs must reference a linear issue in their body.
158+
159+
Examples:
160+
- Fixes OPS-100.
161+
- Resolves OPS-101.
162+
- Part of CI-102.
163+
164+
## Additional Resources
165+
166+
- [CONTRIBUTING.md](./CONTRIBUTING.md) - General contribution guidelines
167+
- [.github/pull_request_template.md](./.github/pull_request_template.md) - PR template
168+
- [.github/prlint.json](./.github/prlint.json) - PR linting rules
169+
- [docs.openops.com](https://docs.openops.com) - Official OpenOps documentation

0 commit comments

Comments
 (0)