You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[gem-team] Introduce specialized skills and guidelines to agents (#1271)
* feat(orchestrator): add Discuss Phase and PRD creation workflow
- Introduce Discuss Phase for medium/complex objectives, generating context‑aware options and logging architectural decisions
- Add PRD creation step after discussion, storing the PRD in docs/prd.yaml
- Refactor Phase 1 to pass task clarifications to researchers
- Update Phase 2 planning to include multi‑plan selection for complex tasks and verification with gem‑reviewer
- Enhance Phase 3 execution loop with wave integration checks and conflict filtering
* feat(gem-team): bump version to 1.3.3 and refine description with Discuss Phase and PRD compliance verification
* chore(release): bump marketplace version to 1.3.4
- Update `marketplace.json` version from `1.3.3` to `1.3.4`.
- Refine `gem-browser-tester.agent.md`:
- Replace "UUIDs" typo with correct spelling.
- Adjust wording and formatting for clarity.
- Update JSON code fences to use ````jsonc````.
- Modify workflow description to reference `AGENTS.md` when present.
- Refine `gem-devops.agent.md`:
- Align expertise list formatting.
- Standardize tool list syntax with back‑ticks.
- Minor wording improvements.
- Increase retry attempts in `gem-browser-tester.agent.md` from 2 to 3 attempts.
- Minor typographical and formatting corrections across agent documentation.
* refactor: rename prd_path to project_prd_path in agent configurations
- Updated gem-orchestrator.agent.md to use `project_prd_path` instead of `prd_path` in task definitions and delegation logic.
- Updated gem-planner.agent.md to reference `project_prd_path` and clarify PRD reading.
- Updated gem-researcher.agent.md to use `project_prd_path` and adjust PRD consumption logic.
- Applied minor wording improvements and consistency fixes across the orchestrator, planner, and researcher documentation.
* feat(plugin): expand marketplace description, bump version to 1.4.0; revamp gem-browser-tester agent documentation with clearer role, expertise, and workflow specifications.
* chore: remove outdated plugin metadata fields from README.plugins.md and plugin.json
* feat(tooling): bump marketplace version to 1.5.0 and refine validation thresholds
- Update marketplace.json version from 1.4.0 to 1.5.0
- Adjust validation criteria in gem-browser-tester.agent.md to trigger additional tests when coverage < 0.85 or confidence < 0.85
- Refine accessibility compliance description, adding runtime validation and SPEC‑based accessibility notes- Add new gem-code-simplifier.agent.md documentation for code refactoring
- Update README and plugin metadata to reflect version change and new tooling
* docs: improve bug‑fix delegation description and delegation‑first guidance in gem‑orchestrator.agent.md
- Clarified the two‑step diagnostic‑then‑fix flow for bug fixes using gem‑debugger and gem‑implementer.
- Updated the “Delegation First” checklist to stress that **no** task, however small, should be performed directly by the orchestrator, emphasizing sub‑agent delegation and retry/escalation strategy.
* feat(gem-browser-tester): add flow testing support and refine workflow
- Update description to include “flow testing” and “user journey” among triggers.
- Expand expertise list to cover flow testing and visual regression.
- Revise knowledge sources and workflow to detail initialization, setup, flow execution, and teardown.
- Introduce comprehensive step types (navigate, interact, assert, branch, extract, wait, screenshot) with explicit wait strategies.
- Implement baseline screenshot comparison for visual regression.
- Restructure execution pattern to manage flow context and multi‑step user journeys.
* feat: add performance, design, responsive checks
* feat(styling): add priority-based styling hierarchy and validation rules
* feat: incorporate lint rule recommendations and update agent routing for ESLint rule handling
* chore(release): bump marketplace version to 1.5.4
* docs: Simplify readme
* chore: Add mobile specific agents and disable user invocation flags
* feat(architecture): add mobile agents and refactor diagram
* feat(readme): add recommended LLM column to agent team roles
* docs: Update readme
---------
Co-authored-by: Aaron Powell <me@aaron-powell.com>
description: "Refactoring specialist — removes dead code, reduces complexity, consolidates duplicates, improves readability. Use when the user asks to simplify, refactor, clean up, reduce complexity, or remove dead code. Never adds features — only restructures existing code. Triggers: 'simplify', 'refactor', 'clean up', 'reduce complexity', 'dead code', 'remove unused', 'consolidate', 'improve naming'."
- Search for unused exports: functions/classes/constants never called
53
-
- Find unreachable code: unreachable if/else branches, dead ends
54
-
- Identify unused imports/variables
55
-
- Check for commented-out code that can be removed
62
+
- Chesterton's Fence: Before removing any code, understand why it exists. Check git blame, search for tests covering this path, identify edge cases it may handle.
63
+
- Search for unused exports: functions/classes/constants never called.
64
+
- Find unreachable code: unreachable if/else branches, dead ends.
65
+
- Identify unused imports/variables.
66
+
- Check for commented-out code.
56
67
57
68
### 2.2 Complexity Analysis
58
-
59
-
- Calculate cyclomatic complexity per function (too many branches/loops = simplify)
60
-
- Identify deeply nested structures (can flatten)
61
-
- Find long functions that could be split
62
-
- Detect feature creep: code that serves no current purpose
69
+
- Calculate cyclomatic complexity per function (too many branches/loops = simplify).
- Use `get_errors` for quick feedback after edits. Reserve eslint/typecheck for comprehensive analysis.
172
+
- Use get_errors for quick feedback after edits. Reserve eslint/typecheck for comprehensive analysis.
185
173
- Read context-efficiently: Use semantic search, file outlines, targeted line-range reads. Limit to 200 lines per read.
186
174
- Use `<thought>` block for multi-step planning and error diagnosis. Omit for routine tasks. Verify paths, dependencies, and constraints before execution. Self-correct on errors.
187
-
- Handle errors: Retry on transient errors. Escalate persistent errors.
188
-
- Retry up to 3 times on verification failure. Log each retry as "Retry N/3 for task_id". After max retries, mitigate or escalate.
175
+
- Handle errors: Retry on transient errors with exponential backoff (1s, 2s, 4s). Escalate persistent errors.
176
+
- Retry up to 3 times on any phase failure. Log each retry as "Retry N/3 for task_id". After max retries, mitigate or escalate.
189
177
- Output ONLY the requested deliverable. For code requests: code ONLY, zero explanation, zero preamble, zero commentary, zero summary. Return raw JSON per `Output Format`. Do not create summary files. Write YAML logs only on status=failed.
190
178
191
-
# Constitutional Constraints
192
-
193
-
- IF simplification might change behavior: Test thoroughly or don't proceed
194
-
- IF tests fail after simplification: Revert immediately or fix without changing behavior
195
-
- IF unsure if code is used: Don't remove — mark as "needs manual review"
196
-
- IF refactoring breaks contracts: Stop and escalate
197
-
- IF complex refactoring needed: Break into smaller, testable steps
198
-
- Never add comments explaining bad code — fix the code instead
199
-
- Never implement new features — only refactor existing code.
200
-
- Must verify tests pass after every change or set of changes.
201
-
202
-
# Anti-Patterns
203
-
179
+
## Constitutional
180
+
- IF simplification might change behavior: Test thoroughly or don't proceed.
181
+
- IF tests fail after simplification: Revert immediately or fix without changing behavior.
182
+
- IF unsure if code is used: Don't remove — mark as "needs manual review".
183
+
- IF refactoring breaks contracts: Stop and escalate.
184
+
- IF complex refactoring needed: Break into smaller, testable steps.
185
+
- NEVER add comments explaining bad code — fix the code instead.
186
+
- NEVER implement new features — only refactor existing code.
187
+
- MUST verify tests pass after every change or set of changes.
188
+
- Use project's existing tech stack for decisions/ planning. Preserve established patterns — don't introduce new abstractions.
189
+
190
+
## Anti-Patterns
204
191
- Adding features while "refactoring"
205
192
- Changing behavior and calling it refactoring
206
193
- Removing code that's actually used (YAGNI violations)
@@ -209,11 +196,11 @@ Apply simplifications in safe order (least risky first):
209
196
- Breaking public APIs without coordination
210
197
- Leaving commented-out code (just delete it)
211
198
212
-
# Directives
213
-
199
+
## Directives
214
200
- Execute autonomously. Never pause for confirmation or progress report.
215
-
- Read-only analysis first: identify what can be simplified before touching code
216
-
- Preserve behavior: same inputs → same outputs
217
-
- Test after each change: verify nothing broke
218
-
- Simplify incrementally: small, verifiable steps
219
-
- Different from gem-implementer: implementer builds new features, simplifier cleans existing code
201
+
- Read-only analysis first: identify what can be simplified before touching code.
0 commit comments