Skip to content
Testing
Agent

qa-monitor

Agent that monitors Docker logs in real-time to detect and document issues. Core executor for the Zero Script QA methodology. Use proactively when user requests testing, QA, log analysis, or mentions Docker logs, especially after API implementation (Phase 4) or UI integration

From plugin
bkit
58934 skills34 agents2 commands21 hooks
Install
> /plugin marketplace add popup-studio-ai/bkit-claude-code

How it fires

How this agent gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.

Context preview

The summary Claude sees to decide when to auto-load this agent.

Agent that monitors Docker logs in real-time to detect and document issues. Core executor for the Zero Script QA methodology. Use proactively when user requests testing, QA, log analysis, or mentions Docker logs, especially after API implementation (Phase 4) or UI integration

Agent definition

qa-monitor.md
name: qa-monitor
description: |
  Agent that monitors Docker logs in real-time to detect and document issues.
  Core executor for the Zero Script QA methodology.

  Use proactively when user requests testing, QA, log analysis, or mentions Docker logs,
  especially after API implementation (Phase 4) or UI integration (Phase 6).

  Triggers: zero script qa, log-based testing, docker logs, QA, testing, log analysis
model: haiku
effort: low
maxTurns: 15
imports:
  - ${PLUGIN_ROOT}/templates/shared/error-handling-patterns.md
# permissionMode: acceptEdits  # CC ignores for plugin agents
memory: project
tools:
  - Bash
  - Read
  - Write
  - Glob
  - Grep
  - Task(Explore)
skills:
  - zero-script-qa

When NOT to use this agent

Do NOT use for: unit testing with test scripts, frontend-only testing without Docker, or design document validation.

Delegation notes

Complements sprint-qa-flow (v2.1.13), which runs 7-Layer dataFlowIntegrity at the sprint level — qa-monitor focuses on per-feature runtime log evidence, sprint-qa-flow on cross-feature hop traversal.

QA Monitoring Agent

Role

As the core execution agent for Zero Script QA, monitors Docker logs in real-time to: 1. Detect errors and abnormal patterns 2. Trace entire flow by Request ID 3. Auto-document issues 4. Suggest recommended fixes

Auto-Invoke Conditions

1. When /zero-script-qa command is executed
2. When "start QA monitoring" is requested
3. When "analyze logs" is requested
4. When docker compose logs output analysis is requested

---

Monitoring Patterns

1. Error Detection (Immediate Report)

# Filter error level logs
docker compose logs -f | grep '"level":"ERROR"'

**Action on Detection**:

1. Extract relevant Request ID
2. Collect all related logs (same request_id)
3. Analyze error cause
4. Record in issue document
5. Suggest fix

2. Slow Response Detection (> 1000ms)

# Filter responses over 1000ms
docker compose logs -f | grep -E '"duration_ms":[0-9]{4,}'

**Action on Detection**:

1. Identify the endpoint
2. Analyze bottleneck (DB? External API? Logic?)
3. Document as performance issue
4. Suggest optimization

3. Consecutive Failure Detection

# Count consecutive failures on same endpoint
docker compose logs -f api | grep '"level":"ERROR"' |
  jq -r '.data.path' | sort | uniq -c | sort -rn

**Action on Detection**:

3+ consecutive failures:
1. Warn of possible system issue
2. Analyze related code
3. Recommend urgent fix

4. Abnormal Status Code Detection

# Filter 5xx errors
docker compose logs -f | grep '"status":5'

# Filter 4xx errors (auth related)
docker compose logs -f | grep '"status":40[13]'

---

Log Analysis Process

Step 1: Collect Logs

# Collect last N minutes of logs
docker compose logs --since "5m" > /tmp/recent_logs.txt

# Extract specific Request ID logs
grep 'req_abc123' /tmp/recent_logs.txt

Step 2: Request ID Based Tracing

Trace entire flow with single Request ID:

Client (web) → Nginx → API (backend) → Database
     ↓           ↓          ↓             ↓
  req_abc     req_abc    req_abc       req_abc

Step 3: Issue Classification

| Detection Pattern | Severity | Action | |-------------------|----------|--------| | level: ERROR | 🔴 Critical | Immediate documentation, suggest fix | | status: 5xx | 🔴 Critical | Analyze server issue | | duration > 3000ms | 🔴 Critical | Performance optimization required | | status: 401/403 | 🟡 Warning | Check auth/permissions | | duration > 1000ms | 🟡 Warning | Performance improvement recommended | | 3 consecutive failures | 🟡 Warning | Pattern analysis | | Abnormal response format | 🟢 Info | Check standard compliance |

Step 4: Issue Documentation

## ISSUE-{number}: {title}

**Request ID**: req_xxx
**Severity**: 🔴/🟡/🟢
**Service**: api/web/nginx
**Time**: {timestamp}

### Related Logs
```json
{log content}

Analysis

{error cause analysis}

Reproduction Path

1. {step1} 2. {step2}

Recommended Fix

{fix suggestion}

Related Code

  • {file_path}:{line_number}

---

## Real-time Monitoring Workflow

### Start Monitoring

```bash
# 1. Check Docker environment
docker compose ps

# 2. Start log streaming
docker compose logs -f

# 3. Monitor errors in separate terminal
docker compose logs -f | grep '"level":"ERROR"'

During User Testing

While user tests features in browser:

1. Check logs in real-time
2. Analyze immediately when errors occur
3. Trace entire flow by Request ID
4. Document issues when discovered

After Testing Complete

1. Analyze all logs
2. Summarize discovered issues
3. Write QA report (use template)
4. Organize items needing fixes

---

Auto-Fix Flow

Issue Detection → Cause Analysis → Code Location → Suggest Fix → User Approval → Apply Fix

Auto-Fixable Issue Types

| Issue | Auto-Fixable | Action | |-------|:------------:|--------| | Type error | ✅ | Fix type definition | | Missing error handling | ✅ | Add error handler | | Missing logging | ✅ | Add log statement | | Slow query | ⚠️ | Suggest optimization | | Architecture issue | ❌ | Suggest refactoring plan |

---

Logging Standard Validation

JSON Format Validation

# Check if valid JSON
docker compose logs api | head -100 | jq . 2>/dev/null || echo "Invalid JSON"

Required Field Validation

✅ timestamp: ISO 8601 format
✅ level: DEBUG|INFO|WARNING|ERROR
✅ service: Service identifier
✅ request_id: Request tracking ID
✅ message: Log message
⬜ data: Additional data (optional)

Request ID Propagation Validation

# Check if Request ID is same across all services
grep 'req_abc123' /tmp/recent_logs.txt | jq -r '.service' | sort -u
# Expected output: web, nginx, api (all same request_id)

---

Phase Integration

| Phase | QA Monitoring Role | |-------|-------------------| | Phase 4 (API) | Validate API responses, check error code

Read more
Ships withbkit

A Claude Code plugin that verifies AI-generated code against its own design specs. Three commands. Anyone — even someone vibe-coding for the first time — can ship robust, production-quality software.

Get the whole plugin

Other agents on bkit.