Add unique identifier for test_phase3c_walk_recovery.gd
This commit is contained in:
@@ -1,27 +0,0 @@
|
||||
---
|
||||
name: bugfix
|
||||
description: "Executes a bugfix pipeline on one or more gitea issues: Developer -> Tester -> Reviewer"
|
||||
---
|
||||
|
||||
## What I do
|
||||
|
||||
I orchestrate a sequential bugfix and verification pipeline - I will retrieve issues(s) from Gitea (title, body, images, comments, etc...). I will then forward information from the issues to the respective subagents.
|
||||
|
||||
Use gitea-mcp-server to interact with Gitea. Verify that the server is running and accessible.
|
||||
|
||||
If an issue is not provided, ask the user for the issue number(s).
|
||||
|
||||
1. **Developer**: Provides a code fix for each issue.
|
||||
2. **Reviewer**: Audits the code and architectural soundness.
|
||||
3. **Tester**: Runs tests related to the bugfix and determines if new unit tests, integration tests, or end-to-end tests are needed. If so, implement. Verify by running the test suite.
|
||||
|
||||
## Execution Rules
|
||||
|
||||
- Stop and ask the user for clarification if a step fails or is ambiguous.
|
||||
- Use the `@` mention to trigger the respective subagents sequentially.
|
||||
- Pass the context from the previous stage to the next stage to ensure consistency.
|
||||
- Use multiple subagents to handle different aspects of the bugfix process if it will help.
|
||||
|
||||
## When to use me
|
||||
|
||||
Invoke me when you are ready to fix a Gitea issue or multiple issues.
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
name: e2e-repair
|
||||
description: "Runs playwright tests, captures errors, and triggers auto-repair."
|
||||
---
|
||||
|
||||
## Logic
|
||||
|
||||
1. Execute: `npx playwright test [test_file]`
|
||||
2. If Success:
|
||||
- Report success.
|
||||
- Exit.
|
||||
3. If Failure:
|
||||
- Capture output.
|
||||
- Pass logs to @tester agent.
|
||||
- @tester analyzes error and edits file.
|
||||
- Repeat until success or max_retries reached.
|
||||
|
||||
## Safety Guardrails
|
||||
|
||||
- Make use of playwright-cli skills for test execution and repair.
|
||||
- Max Retries: 3 per file.
|
||||
- If the error persists after 3 retries, report: "Repair exhausted: Please review logs."
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
name: feature-pipeline
|
||||
description: "Executes the full dev-to-docs pipeline: Developer -> Tester -> Reviewer -> Writer."
|
||||
---
|
||||
|
||||
## What I do
|
||||
|
||||
I orchestrate a sequential feature implementation and verification pipeline:
|
||||
|
||||
1. **Developer**: Implements the feature based on the spec.
|
||||
2. **Reviewer**: Audits the code and architectural soundness.
|
||||
3. **Tester**: Runs full unit/E2E test suites; repairs failures if found.
|
||||
4. **Writer**: Updates README and API docs based on verified code.
|
||||
|
||||
## Execution Rules
|
||||
|
||||
- Stop and ask the user for clarification if a step fails or is ambiguous.
|
||||
- Use the `@` mention to trigger the respective subagents sequentially.
|
||||
- Pass the context from the previous stage to the next stage to ensure consistency.
|
||||
|
||||
## When to use me
|
||||
|
||||
Invoke me when you are ready to begin a new feature or when the Architect has finished a specification.
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
name: fix-pipeline
|
||||
description: "Diagnoses, fixes, and verifies bugs across Architect, Developer, Tester, and Writer."
|
||||
---
|
||||
|
||||
## What I do
|
||||
|
||||
I resolve bugs by triaging ownership, applying code fixes, and running regression tests:
|
||||
|
||||
1. **Architect (Triage)**: Compares the bug report against existing `specs/` and codebase architecture.
|
||||
- **Spec / Design Defect**: Updates `specs/` and `decisions.md`, then forwards to `@developer`.
|
||||
- **Implementation Defect**: Forwards directly to `@developer` without updating specs.
|
||||
2. **Developer**: Applies surgical code fixes adhering to Godot performance and typing rules.
|
||||
3. **Tester**: Writes a GUT regression test, executes test suites, and verifies the fix (max 2 repair attempts).
|
||||
4. **Writer** (Conditional): Updates README or API docs if external interfaces or setup instructions changed.
|
||||
|
||||
## Execution Rules
|
||||
|
||||
- Default to starting at Step 1 (`@architect`) for triage unless explicitly told `--dev-only`.
|
||||
- Allow `@tester` a maximum of 2 auto-repair attempts for failing test suites before passing back to `@developer`.
|
||||
- Stop and ask the user for clarification if any step fails or is ambiguous.
|
||||
- Pass context from each completed stage to the next stage.
|
||||
@@ -1,25 +1,23 @@
|
||||
---
|
||||
name: spec-pipeline
|
||||
description: "Executes the full dev-to-docs pipeline: Developer -> Tester -> Writer."
|
||||
description: "Lean implementation loop: Architect -> Developer -> User Verification."
|
||||
---
|
||||
|
||||
## What I do
|
||||
## Execution Logic
|
||||
|
||||
I orchestrate a sequential feature implementation and verification pipeline:
|
||||
1. **Phase 1: Architecture (Optional for small edits)**
|
||||
- `@architect` defines signatures, node structures, or spec updates in `specs/[feature-name].md`.
|
||||
- **STOP:** Wait for user approval on design choices before invoking developer.
|
||||
|
||||
1. **Architect**: Explores codebase, asks clarifying questions, and drafts the spec. *Waits for user approval before handoff.*
|
||||
2. **Developer**: Implements the feature based on the spec.
|
||||
3. **Tester**: Runs full unit test suites; repairs failures if found.
|
||||
4. **Writer**: After updating README and API docs, review `docs/tech_debt_and_optimizations.md` for formatting consistency and ensure no duplicate entries exist.
|
||||
2. **Phase 2: Implementation & Engine Validation**
|
||||
- `@developer` updates code and scenes using targeted diffs/snippets.
|
||||
- `@developer` runs headless syntax verification:
|
||||
`& "C:\Godot4\Godot_v4.7.1-stable_win64_console.exe" --headless --check-only --script "res://path/to/script.gd" --path "C:\Godot4\project"`
|
||||
- If static check fails, `@developer` fixes the code immediately.
|
||||
|
||||
## Execution Rules
|
||||
3. **Phase 3: User Hand-off (Stop)**
|
||||
- Present the changes to the user to test inside the Godot Editor.
|
||||
- Do NOT update READMEs or documentation yet.
|
||||
|
||||
- **Architect Gate**: Stop after Phase 3 and wait for user approval on the spec before calling `@developer`.
|
||||
- **Tester Repair Limit**: Allow `@tester` a maximum of 2 auto-repair attempts for failing test suites. If tests still fail after 2 attempts, hand the error context back to `@developer` to fix the underlying implementation.
|
||||
- Stop and ask the user for clarification if any step fails or is ambiguous.
|
||||
- Use `@` mentions to trigger subagents sequentially.
|
||||
- Pass context from each completed stage to the next stage.
|
||||
|
||||
## When to use me
|
||||
|
||||
Invoke me when you are ready to begin a new feature/fix or when the Architect has finished a specification.
|
||||
4. **Phase 4: Documentation (Triggered manually by user)**
|
||||
- Only call `@writer` after the user confirms: _"Feature verified and working."_
|
||||
|
||||
Reference in New Issue
Block a user