mirror of
https://github.com/diegosouzapw/OmniRoute.git
synced 2026-08-03 05:45:04 +03:00
chore(workflows): move agent workflows to global dir
This commit is contained in:
diegosouzapw
@@ -1,54 +0,0 @@
|
||||
---
|
||||
description: Git workflow — NEVER commit directly to main. Always use feature branches.
|
||||
---
|
||||
|
||||
# Git Workflow
|
||||
|
||||
## ⚠️ CRITICAL RULE: NEVER commit directly to `main`
|
||||
|
||||
## Steps
|
||||
|
||||
1. **Before starting any work**, create a feature branch from `main`:
|
||||
|
||||
```bash
|
||||
git checkout main && git pull origin main
|
||||
git checkout -b feature/<feature-name>
|
||||
```
|
||||
|
||||
2. **During development**, commit to the feature branch:
|
||||
|
||||
```bash
|
||||
git add -A && git commit -m "<type>(<scope>): <description>"
|
||||
```
|
||||
|
||||
3. **Before pushing**, verify the build passes:
|
||||
|
||||
```bash
|
||||
npm run build
|
||||
```
|
||||
|
||||
4. **When the feature is complete and verified**, push the branch and STOP:
|
||||
|
||||
```bash
|
||||
git push origin feature/<feature-name>
|
||||
```
|
||||
|
||||
5. **DO NOT** create a PR, merge, or push to `main`. Let the user handle that.
|
||||
|
||||
## Branch naming convention
|
||||
|
||||
- `feature/<name>` — new features
|
||||
- `fix/<name>` — bugfixes
|
||||
- `refactor/<name>` — refactoring
|
||||
- `docker/<name>` — Docker / infrastructure changes
|
||||
- `style/<name>` — UI / CSS changes
|
||||
|
||||
## Commit types
|
||||
|
||||
- `feat` — new feature
|
||||
- `fix` — bugfix
|
||||
- `refactor` — code refactoring
|
||||
- `style` — UI / CSS changes
|
||||
- `docker` — Docker / infrastructure
|
||||
- `docs` — documentation
|
||||
- `chore` — maintenance
|
||||
@@ -1,65 +0,0 @@
|
||||
---
|
||||
description: How to respond to GitHub issues with insufficient information
|
||||
---
|
||||
|
||||
# GitHub Issue Triage — Requesting More Information
|
||||
|
||||
When analyzing a GitHub issue and the provided information is insufficient to diagnose or implement a fix, follow these steps:
|
||||
|
||||
## 1. Identify Missing Information
|
||||
|
||||
Check if the issue contains:
|
||||
|
||||
- [ ] Clear description of the problem or feature
|
||||
- [ ] Steps to reproduce (for bugs)
|
||||
- [ ] Error messages / logs
|
||||
- [ ] Environment details (OS, version, deployment method)
|
||||
- [ ] Expected vs actual behavior
|
||||
- [ ] Screenshots (if UI-related)
|
||||
|
||||
## 2. Draft a Response (in English)
|
||||
|
||||
Use this template structure, adapting to what's specifically missing:
|
||||
|
||||
```markdown
|
||||
Thanks for reporting this issue! 🙏
|
||||
|
||||
To help us investigate and fix this, could you please provide some more details?
|
||||
|
||||
1. **Environment**: What OS are you running? How did you install OmniRoute (npm global, Docker, from source)?
|
||||
2. **Steps to Reproduce**: What exact steps lead to this issue?
|
||||
3. **Error Logs**: Can you share the full server logs? (Check the terminal or `logs/application/app.log`)
|
||||
4. **Expected vs Actual**: What did you expect to happen, and what actually happened?
|
||||
5. **Screenshots**: If this is a UI issue, a screenshot would be very helpful.
|
||||
|
||||
This information will help us reproduce and fix the issue more quickly. Thank you!
|
||||
```
|
||||
|
||||
## 3. Adapt the Template
|
||||
|
||||
- Remove items that are already provided in the issue
|
||||
- Add domain-specific questions based on the issue type:
|
||||
- **OAuth/Auth issues**: Ask for provider name, auth flow used, token errors
|
||||
- **Multi-account issues**: Ask how many accounts, which providers, dashboard screenshots
|
||||
- **Startup/crash issues**: Ask for full startup logs, OS version, Node.js version
|
||||
- **UI rendering issues**: Ask for browser name, screen resolution, screenshots
|
||||
- **API issues**: Ask for request/response examples, curl commands used
|
||||
|
||||
## 4. Post the Response
|
||||
|
||||
// turbo
|
||||
Post the response as a comment on the GitHub issue using the GitHub CLI:
|
||||
|
||||
```bash
|
||||
gh issue comment <ISSUE_NUMBER> --repo diegosouzapw/OmniRoute --body "<RESPONSE_BODY>"
|
||||
```
|
||||
|
||||
If `gh` CLI is not available, provide the response text to the user to post manually.
|
||||
|
||||
## 5. Add Labels (optional)
|
||||
|
||||
If applicable, add a `needs-info` label:
|
||||
|
||||
```bash
|
||||
gh issue edit <ISSUE_NUMBER> --repo diegosouzapw/OmniRoute --add-label "needs-info"
|
||||
```
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
description: How to automatically summarize recent changes and update README and CHANGELOG
|
||||
---
|
||||
|
||||
# Update Documentation and Changelog Workflow
|
||||
|
||||
When asked to run the `/update-docs` workflow or summarize recent changes into the documentation, follow these steps:
|
||||
|
||||
## 1. Gather Recent Work Context
|
||||
|
||||
1. **Review Task History**: Check the current `task.md`, `walkthrough.md`, and any `implementation_plan.md` in the agent's brain directory to understand exactly what features, bug fixes, and architectural changes were recently made.
|
||||
2. **Identify Key Features**: Group the changes into logical categories:
|
||||
- **New Features** (e.g. new settings, new endpoints, new UI components)
|
||||
- **Bug Fixes** (e.g. layout fixes, crash resolutions, cross-platform fixes)
|
||||
- **Security/Performance** (e.g. auth gating, new optimizations)
|
||||
|
||||
## 2. Update the CHANGELOG.md
|
||||
|
||||
1. If `CHANGELOG.md` does not exist in the root directory, create it.
|
||||
2. Under the `## [Unreleased]` section (or create a new version header if releasing):
|
||||
- Add a `### Added` section for new features.
|
||||
- Add a `### Fixed` section for bug fixes.
|
||||
- Summarize the recent work into bullet points, referencing GitHub issue numbers if applicable (e.g. `Fix Windows server startup crash (Issue #98)`).
|
||||
|
||||
## 3. Update README.md (and translated versions like README_pt-BR.md)
|
||||
|
||||
1. **Main Features List**: If a notable new feature was added (like a new security setting or API option), add it to the feature list section.
|
||||
2. **Configuration/Settings**: If any new environment variables or dashboard settings were introduced, document them in the configuration or usage sections so users know how to enable them.
|
||||
3. If there are translated versions of the README (like Portuguese), ensure those are updated equivalently.
|
||||
|
||||
## 4. Update Technical Docs (docs/ directory)
|
||||
|
||||
1. Use `list_dir` to inspect the `docs/` folder.
|
||||
2. Determine which technical documents need updates. For example:
|
||||
- If an API changed, update `docs/API_REFERENCE.md` or similar.
|
||||
- If security settings changed, update `docs/SECURITY.md` or `docs/CONFIGURATION.md`.
|
||||
3. Read the relevant files, update their content using `replace_file_content`, and briefly explain how the new feature works under the hood.
|
||||
|
||||
## 5. Verify the Updates
|
||||
|
||||
Ensure all markdown files are properly formatted and no existing sections were accidentally deleted. Present the changes to the user showing which files were updated.
|
||||
Reference in New Issue
Block a user