Prompt file imported from vasja34/z00z (.github/prompts/gsd-review-context.prompt.md). Copyright stays with the author.

Review Context

Review and fix the context markdown generated by the plan-context prompt.

Input

• current_context: full or relative path to the markdown document.
• review_goal: (optional) short primary description of the task or section the context must cover.

If current_context is missing or ambiguous, stop and resolve that first.

Mission

Read current_context and review_goal as a crypto analyst and context reviewer.

Be critical, constructive, and objective. Focus on critical blockers, obvious execution mistakes, and context ambiguity before style-level concerns. Own the review end to end: inspect, triage, fix, re-check, and finish only when the context is either operationally sound or blocked by an explicitly stated open decision.

Verify whether the context has any ordering mistakes, dependency gaps, weak validation gates, rollout hazards, unresolved blockers, missing implementation anchors, or consistency problems.

Fix all found issues directly in current_context in YOLO mode.

[!Warning] Execution order, dependency safety, and gate correctness come before stylistic cleanup. A readable context is still unacceptable if it can be executed in the wrong order.

Required Review Scope

Verify all of the following:

• execution order correctness;
• dependency integrity;
• phase boundary clarity;
• context-goal coverage;
• clarity of what exactly must be implemented;
• clarity of how the work must be implemented on top of the current codebase;
• validation gate completeness;
• parallelization safety;
• blocker and rollback handling;
• correctness of file, crate, module, API, and trait integration guidance;
• quality of cryptographic rules and implementation nuance coverage;
• quality of pseudocode, diagrams, and critical-path sketches when needed;
• completeness of unit-test and integration-test planning;
• consistency with the intended architecture;
• document quality for execution and acceptance use.

Required Review Process

1. Read the full current_context before editing.
2. Study the existing codebase before approving concrete file targets, APIs, traits, code sketches, or structural recommendations.
3. Run the /crypto-architect skill and treat its output as mandatory review evidence, not as optional guidance.
4. Run the /security-audit skill and treat its output as mandatory review evidence, not as optional guidance.
5. Extract the concrete cryptographic risks, invariants, misuse cases, and required corrections from /crypto-architect and /security-audit before deciding whether the context is sound.
6. Review every phase, gate, dependency, diagram, and integration anchor.
7. Triage findings by severity: execution correctness, dependency integrity, validation safety, cryptographic risk, and source ambiguity first; minor wording issues last.
8. Identify vague ordering, missing prerequisites, unsafe parallelization, weak rollback guidance, incomplete acceptance flow, and weak implementation detail.
9. Check that the context can be executed without guessing what must happen next, where the changes belong, or how they fit the current codebase.
10. Verify that each major context-goal element, constraint, or requirement is covered by at least one concrete phase or step.
11. Verify that phases have measurable completion criteria and explicit outputs when relevant.
12. Rewrite weak sections so the document defines one clear operational path.
13. Add or fix Mermaid diagrams when the current sequence or dependency graph is still ambiguous.
14. Strengthen or add missing notes for crates, files, APIs, traits, cryptographic nuances, pseudocode, and tests when they are required for correct execution.
15. If a referenced file, module, or API target cannot be verified from the current codebase, relabel it explicitly as proposed rather than as an existing fact.
16. Use the /doublecheck skill in one-shot mode on the full review evidence, including corrected context content and the findings derived from /crypto-architect and /security-audit.
17. Extract all verifiable claims and run the full three-layer verification pipeline.
18. Resolve or explicitly report every material issue raised by /doublecheck before treating the review as complete.
19. Edit current_context directly until all found in-scope issues are resolved and the final review position is consistent with both skill outputs.

[!Tip] Use Mermaid only when it removes real ambiguity in sequencing, rollback, or dependency flow. Prefer a single precise diagram over multiple decorative ones.

Key Attention Points

The review must explicitly verify all of the following when relevant:

• whether the context states what exactly must be implemented;
• whether it explains how the work must be implemented on top of the current codebase;
• whether the work is split into the right phases;
• whether each phase explains its intent and implementation scope;
• whether the right crates, files, and modules are targeted;
• whether the context integrates with existing modules, types, traits, and APIs;
• whether cryptographic rules, invariants, and implementation nuances are captured correctly;
• whether pseudocode or structured code sketches are present for critical paths;
• whether Mermaid diagrams clarify sequence, dependencies, or verifier/write paths when needed;
• whether API or trait changes are explicit where required;
• whether unit-test and integration-test coverage is planned clearly.

Review Rules

• Review the document itself, not implementation code.
• The /crypto-architect , /security-audit and /doublecheck steps are mandatory execution gates, not recommendations.
• Do not present a final review verdict, approval, or completion claim unless both skill runs were executed and their material findings were incorporated.
• Build the review, fixes, and final judgment on the results of both skill runs.
• If either skill is unavailable, incomplete, or returns unresolved material risk, fail closed and report the exact blocker instead of soft-approving the context.
• Preserve the intended architecture unless the context is inconsistent or incorrect.
• Replace vague sequencing with explicit step order and gate rules.
• Keep the text concise, but do not leave operational gaps.
• Prefer exact phase names, gate names, and dependency statements when the document can define them.
• Do not silently resolve material ambiguity in the context or its source constraints; label it as an assumption, blocker, or open decision.
• Make reasonable assumptions only when they do not materially change execution order or architecture.
• Base corrections on the existing codebase before allowing any new structure.
• Do not approve duplicated code paths or parallel abstractions when the current codebase can be extended.
• Before accepting a new structure, verify that no suitable existing structure already exists with a different signature.
• State clearly which crate and file each important change belongs to when the context is missing that information.

Mandatory Context

You must read and follow these files before and during the review:

• .github/requirements/Z00Z_DESIGN_FOUNDATION.md
• .github/copilot-instructions.md

All requirements in those files must be satisfied.

Completion Criteria

Completion requires all of these:

• current_context was reviewed end to end;
• /crypto-architect was run and its material findings were integrated into the review and fixes;
• /security-audit was run and its material findings were integrated into the review and fixes;
• /doublecheck was run on the review evidence and all material verification issues were resolved or explicitly blocked;
• all found in-scope issues were fixed in the original document;
• the execution path is explicit from start to finish;
• validation gates and dependency rules are clear where needed;
• codebase integration guidance is explicit where needed;
• test, API, and cryptographic planning is explicit where needed;
• document-level ambiguities that can be fixed were removed;
• any remaining material ambiguity is explicitly labeled as an assumption, blocker, or open decision.

Output Style

• Give short, direct updates.
• Present findings first.
• Prefer evidence-backed findings with exact context or codebase references.
• State which file was reviewed and fixed.
• State what was fixed in current_context.
• If no substantive issues are found, state that explicitly.
• State whether any source ambiguity could not be resolved from the document context.

Non-Negotiable Rules

• Do not leave found context issues unresolved.
• Do not keep gray-zone sequencing when the document can prescribe one correct flow.
• Do not switch into implementation code changes.
• Do not review only parts of the document; review the full input file.
• Do not waste time on low-value nitpicks while critical context issues remain.
• Do not approve a greenfield design when the current codebase can be evolved.
• Do not approve duplicated abstractions, types, or code paths.
• Follow all instructions above without exception.

Example Invocation

/gsd-review-context current_context=specs/014-z00z-storage/jmt-migration-spec.md review_goal="Plan the sequential implementation context for one migration section"