Review mode

GOAL: Conduct critical technical reviews of roadmaps, code, and strategies following standard review protocols.

WHEN: Invoke this skill when the user requests a critical review of a roadmap or proposed changes.

NOTE: This skill operates strictly in read-only mode to ensure safety during analysis.

Efficiency directives

• Optimize all operations for agent, token, and context efficiency
• Optimize for minimal output
• Batch operations on file groups, avoid individual file processing
• Target only relevant files
• Reduce token usage

Confirmation directives

After reporting the review decision, use the ask_user tool to offer 4 options:

1. Revise plan - Invoke the prepare-mode skill to address findings
2. Quick build - Invoke the build-mode skill for rapid execution
3. Implement - Invoke the implement-mode skill for thorough

execution

1. Abort - Cancel the workflow and wait for the next instruction

Set the default response based on the review recommendation:

• If recommendation indicates REVISE or REJECT, make option 1 the

default.

• If recommendation indicates APPROVE, make option 2 the default.

Workflow

Step 1: Enforce read-only

• Invoke the readonly-mode skill.
• Capture status (SUCCESS, WARN, ERROR).
• Handle status:

- ERROR: Halt and report. - SUCCESS/WARN: Continue.

Step 2: Perceive

• Read the roadmap, code, or context provided for review.

Step 3: Analyze

• Apply the 6-step reasoning engine:

1. Analyze: Context, objectives, and proposed changes. 2. Evaluate: Risks from Security, QA, and Ops perspectives. 3. Identify: Missing edge cases, logical flaws, and debt. 4. Revise: Understanding based on deep-dive analysis. 5. Incorporate: KBase patterns and project constraints. 6. Retry: If analysis yields insufficient confidence.

• Execute Multi-perspective analysis across five viewpoints:

- Security: Vulnerabilities, permissions, data handling. - QA: Test coverage, testability, regression risks. - Architecture: Design patterns, scalability, maintainability. - Performance: Latency, resource usage, optimization. - DevOps: Deployment, monitoring, infrastructure impact.

Step 4: Critique & assess risk

• Compare against KBase and best practices.
• Re-evaluate the risk level (TRIVIAL, LOW, MEDIUM, HIGH).

Step 5: Report

• Output the structured review decision.

Step 6: Confirmation

• Use the ask_user tool for confirmation with 4 options.
• Await user response before further action.
• DONE

Review report format

Review checklist:

1. Security: [Findings/None]
2. QA: [Findings/None]
3. Architecture: [Findings/None]
4. Performance: [Findings/None]
5. DevOps: [Findings/None]

Risk re-assessment:

• Level: [TRIVIAL/LOW/MEDIUM/HIGH]
• Justification: [Reasoning]

Decision:

• Recommendation: [APPROVE ✅ / REVISE 🔄 / REJECT ❌]
• Blockers: [Critical Issues]
• Concerns: [Moderate Issues]
• Next Steps: [Actionable advice]

Output

Files created/modified:

• None (Read-only operation).
• .gemini_readonly - Ensured at the start.

Status communication:

First line of output indicates user's decision:

• REVISE: user wants to revise the plan - user chose revision
• BUILD: user wants to build the plan - user chose quick build
• IMPLEMENT: user wants to implement the plan - user chose

implementation

• ABORT: user cancelled workflow - user aborted process

Following lines: complete review report text