pre-phase-briefing

Assembles phase-start context by reviewing retrospectives and verifying codebase reality before planning.

Updated May 31, 2026
One-click install
npx skills add https://github.com/AlexanderNarbaev/agi --skill pre-phase-briefing-alexandernarbaev
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pre-phase-briefing
Source: https://github.com/AlexanderNarbaev/agi/tree/main/.opencode/skills/pre-phase-briefing
Command: npx skills add https://github.com/AlexanderNarbaev/agi --skill pre-phase-briefing-alexandernarbaev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Starting a new project phase without reviewing past lessons or verifying what already exists in the codebase leads to repeated mistakes, duplicated work, and plans built on false assumptions. This Skill enforces a mandatory briefing and reality-check protocol before any spec, plan, or implementation begins. ## Core Features & Use Cases - Retrospective Briefing: Reads previous phase retrospectives from .swarm/evidence/retro-* bundles, extracting lessons learned, top rejection reasons, and persistent user directives before any new phase starts. - Codebase Reality Check: Fans out asynchronous read-only explorer lanes (up to 8 per batch) that verify whether every referenced file, module, function, or config surface exists, its current state, and whether plan assumptions are accurate. - Hard Settlement Gate: Blocks spec finalization, plan generation, and implementation-agent dispatch until all lanes settle and a REALITY CHECK report classifies every reference as NOT STARTED, PARTIALLY DONE, ALREADY COMPLETE, or ASSUMPTION INCORRECT. - Use Case: Before planning Phase 3 of a multi-phase refactor, the architect reviews Phase 2's retrospective, dispatches 3 explorer lanes to verify 12 referenced modules, and discovers one assumption is outdated — correcting the plan before any code is written. ## Quick Start Run the pre-phase briefing protocol to review prior retrospectives and verify all codebase references before starting the next phase.

Frequently Asked Questions about pre-phase-briefing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify codebase assumptions before writing an implementation plan?

Enumerate every file, module, and function the plan references, partition them into disjoint explorer lanes, and dispatch the lanes asynchronously. Each lane reports existence, current state, and assumption accuracy, which you synthesize into a reality report before planning.

What is a codebase reality check in AI-assisted planning?

A codebase reality check verifies that every item a spec or plan references actually exists and matches assumptions before work begins. References are classified as NOT STARTED, PARTIALLY DONE, ALREADY COMPLETE, or ASSUMPTION INCORRECT to prevent duplicated or misdirected work.

How many parallel explorer lanes should I dispatch for code verification?

Scale lanes to the referenced surface: one lane for a single file or area, two to four for a typical phase, and up to eight per batch for large surfaces. Lanes must be non-overlapping and together cover every referenced item.

Can I skip the reality check for a greenfield project?

Yes, the protocol includes a greenfield exemption: if the work is a new project with no existing codebase references, the reality check is skipped. The retrospective briefing, however, remains a hard requirement for all phases.

What happens if an explorer lane fails or times out?

A missing, failed, or timed-out lane is treated as an explicit coverage gap, not a pass. The affected references are marked BLOCKED or SKIPPED_WITH_REASON and must be resolved before any spec finalization or implementation dispatch proceeds.