verify-debug-mode
Confirm a requested feature change via AERA Debug mode (Debug view, console, logs). Use when validation must happen through Debug UI or when you need to add debug-only probes/commands to make a change observable.
When & Why to Use This Skill
The verify-debug-mode skill empowers Claude to rigorously validate feature implementations and code changes using a specialized Debug environment. It facilitates real-time verification through console logs, diagnostic tools, and UI inspections, ensuring that every modification is observable and functions as intended. By allowing the agent to dynamically add custom debug probes, backend commands, and API endpoints, it bridges the gap between implementation and verification in complex software systems, significantly reducing the risk of undetected regressions.
Use Cases
- Confirming feature success by monitoring specific request IDs, log levels, or module-specific outputs in the Debug Log Viewer.
- Injecting custom backend debug commands into the command catalog to inspect internal service states that are not exposed via the standard UI.
- Developing temporary Debug UI hooks or panels to visualize data changes and state transitions during the development process.
- Automating the capture of diagnostic evidence and acceptance signals in action logs to maintain a verifiable audit trail of development progress.
- Troubleshooting complex issues by adding debug-only probes when existing tools cannot provide the necessary visibility into a specific code path.
| name | verify-debug-mode |
|---|---|
| description | Confirm a requested feature change via AERA Debug mode (Debug view, console, logs). Use when validation must happen through Debug UI or when you need to add debug-only probes/commands to make a change observable. |
Verify via Debug Mode
Intent
- Confirm the change works using Debug mode surfaces.
- Add debug-only probes/commands when existing Debug tools cannot observe the change.
- Always run Debug-mode verification after implementing any feature change or addition.
Workflow
- Define the acceptance signal
- State the exact value, log line, or UI output that proves the change works.
- Prefer a single requestId or timestamp you can filter in logs.
- Enable Debug mode
- Use the top-bar Toggle Debug button (LuminaShell) to enter Debug view.
- Open the Debug Console view (Debug & Diagnostics).
- Use existing Debug tools first
- Debug Console (
src/components/debug/DebugTerminal.tsx)help,health,doctor,list ...,inspect ...,run indicator ...,logs ...,chart snapshot ...
- Debug Logs (
src/components/debug/DebugLogViewer.tsx)- Filter by level, module, requestId
- Backend debug routes (
server/src/routes/debugRoutes.js)
- Capture evidence
- Record the command and output (or log entries) that prove the change works.
- Note the requestId/module used for filtering.
Add probes when Debug mode is missing the signal
- Add a backend debug command
- Update
server/src/services/debugCommands/commandCatalog.js - Implement a handler in
server/src/services/debugCommands/handlers/ - Return short
linesfor console output and optionaldatafor detail.
- Add a debug API endpoint
- Add a route in
server/src/routes/debugRoutes.js - Add a client method in
src/services/api/client.ts
- Add a Debug UI hook
- Add a small panel/button in
src/views/DebugView.tsx - Keep it read-only and only available in Debug view.
- Prefer log probes when possible
- Use
apiClient.debugClientLog(...)withrequestIdand context fields. - Keep logs concise and actionable.
Verification
- Always run a Debug-mode probe after implementing a feature change or addition (no extra prompt).
- Re-run the debug probe and confirm the acceptance signal.
- Log the evidence in
ACTION_LOG.md/ACTION_LOG.jsonl.
Automation pledge
- When the user asks for a feature change or addition, run the Debug-mode probe immediately after the implementation finishes.
- If the Debug-mode signal does not exist, add the minimum probe (command/log/UI) needed and then run it.