Skip to content
Execution v1.0

FG-0501 Design Meetings

Description

Conduct structured planning sessions before building. Design Meetings follow a consistent format: present the problem, propose a solution, identify questions, make decisions, and get approval before writing code. This prevents the common failure mode of agents building the wrong thing quickly. The meeting format forces alignment between human intent and agent execution before resources are invested.

Implementation

Before any non-trivial build task, conduct a structured design session: (1) Problem statement: what are we solving? (2) Proposed approach: how will we solve it? (3) Open questions: what don't we know? (4) Decisions: resolve the questions. (5) Approval: human confirms the approach. Document the outcome. Begin building only after approval.

Success Indicators

  • Non-trivial tasks start with a design meeting, not code
  • Rework decreases because alignment happens before building
  • Design decisions are documented for future reference
  • The team spends more time building the right thing and less time rebuilding

Failure Modes

  • Design meetings for trivial tasks: overhead without value
  • Design meetings that don't produce decisions: just discussion
  • Skipping design meetings under time pressure: the exact time they're most needed
  • Design meeting outcomes not documented: decisions lost

Sub-Methods 3

FG-0501.001 Problem Statement Protocol

Begin every design meeting with a clear, concise problem statement: what are we solving, who is it for, and what does success look like? The problem statement prevents scope drift during the meeting and provides a decision filter for proposals. If a proposed solution doesn't address the problem statement, it's out of scope.

FG-0501.002 Decision Documentation Format

Document every design meeting outcome in a structured format: problem, proposals considered, decision made, rationale, and open items. This creates a decision record that can be referenced when questions arise later. The format should be fast to write and fast to scan.

FG-0501.003 Approval Gate Enforcement

No building begins until the design meeting produces explicit human approval. The approval is substantive: the human must confirm they understand and endorse the proposed approach. If the human has questions, the meeting continues. The approval gate prevents the most expensive failure: building the wrong thing quickly.