pre-phase-briefing

Reviews prior retrospectives and validates referenced codebase items before planning a phase.

437|45|Updated Jan 27, 2026
One-click install
npx skills add https://github.com/ZaxbyHub/opencode-swarm --skill pre-phase-briefing
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pre-phase-briefing
Source: https://github.com/ZaxbyHub/opencode-swarm/tree/main/.opencode/skills/pre-phase-briefing
Command: npx skills add https://github.com/ZaxbyHub/opencode-swarm --skill pre-phase-briefing

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Starting a new project phase without reviewing past lessons or validating codebase assumptions leads to repeated mistakes, wasted work, and plans that do not align with actual existing code.

Core Features & Use Cases

  • Retrospective Review: Automatically pulls and internalizes lessons learned and persistent user directives from prior phase retrospectives or historical project bundles to avoid repeating past errors across phases and projects.
  • Codebase Reality Checks: Runs asynchronous, fanned-out validation of all code, module, and configuration references in a plan to confirm existence, current state, and alignment with assumptions before any work begins.
  • Use Case: For a multi-phase software refactor, use this skill to carry forward lessons from prior failed test runs and catch incorrect assumptions about existing service configurations before writing the new phase plan.

Quick Start

Use the pre-phase-briefing skill to review the previous phase's retrospective and verify all code references in your new phase plan before starting any work.

Frequently Asked Questions about pre-phase-briefing

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

FAQPage Schema
What are pre-phase checks in software development and why do they matter?

Pre-phase checks are mandatory validation steps that review prior phase retrospectives and verify codebase references against their actual current state before planning begins. They prevent repeating past mistakes and planning work against incorrect codebase assumptions in multi-phase software development workflows.

How do I validate codebase assumptions before starting a new project phase?

You validate codebase assumptions by running asynchronous, fanned-out reality verification on all code, module, and configuration references in your plan. This confirms the existence and current state of referenced items, hard gating downstream planning work until all reference validations are complete.

Can I carry forward lessons learned from previous phase retrospectives into new phases?

Yes, retrospective review automatically pulls and internalizes lessons learned and persistent user directives from prior phase retrospectives or historical project bundles. This ensures past errors are not repeated across phases and projects in multi-phase software development workflows.

What is the best way to catch incorrect assumptions about existing service configurations before writing a phase plan?

The best way is to perform codebase reality checks that run asynchronous, fanned-out validation of all configuration references in a plan. This confirms existence, current state, and alignment with assumptions before any work begins, hard gating downstream planning until validations are complete.

Does this phase planning workflow require any external dependencies or components?

No, this phase planning workflow has zero external dependencies or components. It operates independently to assemble mandatory pre-phase context, fan out codebase reality verification, and hard gate downstream planning work until all reference validations are complete.

When should I not use automated codebase reality verification in agent workflows?

You should not use automated codebase reality verification for single-phase projects or workflows that do not require review of prior phase retrospectives. It is specifically designed for multi-phase software development workflows requiring validation of all referenced codebase items against their actual current state.