From 1aa27ceefee485abc609f3d7cd353863bd3b76f9 Mon Sep 17 00:00:00 2001 From: diegosouzapw Date: Sat, 21 Feb 2026 09:11:14 -0300 Subject: [PATCH] chore(workflows): move agent workflows to global dir --- .agent/workflows/git-workflow.md | 54 -------------------------- .agent/workflows/issue-triage.md | 65 -------------------------------- .agent/workflows/update-docs.md | 41 -------------------- 3 files changed, 160 deletions(-) delete mode 100644 .agent/workflows/git-workflow.md delete mode 100644 .agent/workflows/issue-triage.md delete mode 100644 .agent/workflows/update-docs.md diff --git a/.agent/workflows/git-workflow.md b/.agent/workflows/git-workflow.md deleted file mode 100644 index 5d718a7678..0000000000 --- a/.agent/workflows/git-workflow.md +++ /dev/null @@ -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/ - ``` - -2. **During development**, commit to the feature branch: - - ```bash - git add -A && git commit -m "(): " - ``` - -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/ - ``` - -5. **DO NOT** create a PR, merge, or push to `main`. Let the user handle that. - -## Branch naming convention - -- `feature/` — new features -- `fix/` — bugfixes -- `refactor/` — refactoring -- `docker/` — Docker / infrastructure changes -- `style/` — UI / CSS changes - -## Commit types - -- `feat` — new feature -- `fix` — bugfix -- `refactor` — code refactoring -- `style` — UI / CSS changes -- `docker` — Docker / infrastructure -- `docs` — documentation -- `chore` — maintenance diff --git a/.agent/workflows/issue-triage.md b/.agent/workflows/issue-triage.md deleted file mode 100644 index 3bfda2f6e6..0000000000 --- a/.agent/workflows/issue-triage.md +++ /dev/null @@ -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 --repo diegosouzapw/OmniRoute --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 --repo diegosouzapw/OmniRoute --add-label "needs-info" -``` diff --git a/.agent/workflows/update-docs.md b/.agent/workflows/update-docs.md deleted file mode 100644 index 76be0579d9..0000000000 --- a/.agent/workflows/update-docs.md +++ /dev/null @@ -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.