**Version:** 1.0.0
/plugin marketplace add nguyenthienthanh/aura-frog/plugin install aura-frog@aurafrogworkflow/Version: 1.0.0
Purpose: Reject current phase and restart with feedback
Trigger: User types /workflow:reject <reason> at approval gate
/workflow:reject <reason>
Examples:
/workflow:reject Need to add more test cases for edge scenarios
/workflow:reject Architecture should use different state management approach
/workflow:reject Missing accessibility considerations in design
User types /workflow:reject <reason>
ā
Agent BRAINSTORMS feedback:
- Analyze suggestion
- Consider alternatives
- Present options with pros/cons
ā
User chooses approach
ā
Agent reworks deliverables
ā
Show new approval gate
User types /workflow:reject must do: <reason>
ā
Skip brainstorming
ā
Agent directly implements feedback
ā
Show new approval gate
Force phrases: "must do:", "just do:", "work like that", "I insist"
See: rules/feedback-brainstorming.md
// Update workflow state
const state = loadWorkflowState();
const currentPhase = state.current_phase;
state.phases[currentPhase] = {
...state.phases[currentPhase],
status: 'rejected',
rejected_at: new Date().toISOString(),
rejection_reason: userFeedback,
retry_count: (state.phases[currentPhase].retry_count || 0) + 1,
};
saveWorkflowState(state);
// Restart phase with feedback
console.log(`\nš Phase ${currentPhase} rejected. Restarting with feedback...\n`);
console.log(`Feedback: ${userFeedback}\n`);
// Agent reads feedback and reworks
await executePhase(currentPhase, { feedback: userFeedback });
User: /workflow:reject Should use Redux instead of Zustand
Agent Response:
š¤ I hear your feedback: Use Redux instead of Zustand.
Before I switch, let me consider:
**Current context:**
- Project already uses Zustand (src/stores/)
- Team is familiar with Zustand patterns
- Bundle size: Zustand 2KB vs Redux 7KB
**Options I see:**
**Option A: Switch to Redux** (your suggestion)
- Pros: More ecosystem, great devtools, middleware
- Cons: More boilerplate, migration effort, larger bundle
**Option B: Stay with Zustand**
- Pros: Already set up, simpler API, smaller bundle
- Cons: Less middleware options
**Option C: Zustand + middleware** (hybrid)
- Pros: Keep simplicity, add persistence/devtools
- Cons: Additional setup
Which approach would you prefer? (A/B/C)
š” Tip: Say "must do: Redux" to skip discussion next time.
User: /workflow:reject must do: use Redux instead of Zustand
Agent Response:
ā
Got it! Implementing Redux as requested.
š Restarting Phase 2 with Redux architecture...
[Directly implements Redux without discussion]
User: /workflow:reject Missing edge cases for empty input
Agent Response:
š¤ Good catch! Adding edge cases for empty input.
Quick thought: Should I also add edge cases for:
- Null/undefined values?
- Whitespace-only input?
- Max length exceeded?
Or just empty string handling?
(Say "just empty" or "all of them")
User: /workflow:reject Tests are not covering error scenarios properly
Agent Response:
š Phase 5a rejected. Restarting with feedback...
Feedback: Tests are not covering error scenarios properly
Adding error scenario tests:
- API timeout handling
- Network error handling
- Validation error handling
- Concurrent request handling
[Adds 12 new test cases]
To prevent infinite loops:
const MAX_REJECTIONS_PER_PHASE = 3;
if (phase.retry_count >= MAX_REJECTIONS_PER_PHASE) {
console.warn(`
ā ļø WARNING: Phase ${currentPhase} rejected ${MAX_REJECTIONS_PER_PHASE} times
This phase has been rejected multiple times.
Consider:
1. Providing more specific feedback
2. Modifying requirements instead of rejecting
3. Scheduling a discussion to clarify expectations
Would you like to:
a) Continue anyway (override limit)
b) Modify phase deliverables instead
c) Cancel workflow
`);
}
Updates workflow-state.json:
{
"phases": {
"2": {
"name": "Technical Planning",
"status": "rejected",
"rejected_at": "2025-11-24T15:30:00Z",
"rejection_reason": "Should use Zustand instead of local state",
"retry_count": 1,
"attempts": [
{
"attempt": 1,
"completed_at": "2025-11-24T15:25:00Z",
"rejected_at": "2025-11-24T15:30:00Z",
"reason": "Should use Zustand instead of local state"
}
]
}
}
}
/workflow:reject Need to add error handling for API timeout scenarios
/workflow:reject Architecture should separate business logic from UI components
/workflow:reject Test coverage should include boundary conditions (0, max values)
/workflow:reject This is wrong
/workflow:reject Do it better
/workflow:reject Not good enough
Be specific! Agent needs clear guidance to improve.
After rejection:
Skip brainstorming: Use "must do:", "just do:", or "work like that"
Status: Active command
Related: workflow:approve, workflow:modify, workflow:status