Brainforge Knowledge

refire-workflow-implementation-plan

6 min read

Refire Workflow — Implementation Plan

Superseded for capture architecture: Use Refire Workflow — Linear-Only Plan as the source of truth. This document kept for history (Supabase refire_signals design). New work should not add Supabase capture unless strategy changes again.

Created Date: April 1, 2026 Person: Brylle Girang Initiative: Initiative 3 — Feedback loop and Change Management Milestone: M3.2 (April 24) — Launch the Refire workflow

Overview

Implement the Refire correction-capture system as a zero-friction feedback loop: a Cursor rule silently detects when team members correct or amend a skill output, inserts a row into Supabase via the MCP (no git commit required), and a periodic analysis skill queries those signals to surface patterns and drive skill improvements.

Context

From q2-2026-ld-roadmap.md:

Refire = the moment a team member edits, corrects, or rejects an AI output — automatically captured and sent back as a signal. The guest’s correction IS the feedback.

The restaurant metaphor:

KitchenBrainforge
GuestTeam member using a skill/workflow
DishAI-generated output
RefireThe moment someone edits, corrects, or rejects the output
KitchenPlatform team receiving the signal and improving the skill

Architecture

Based on VanLehn’s inner/outer loop model and Hattie & Timperley’s feedback levels (from claude-education-skills):

Inner loop (per-run):     User corrects skill output
                               ↓
                         Rule detects refire signal
                               ↓
                         execute_sql INSERT → refire_signals table
                         (Supabase MCP — no git commit, no user action)

Outer loop (periodic):    Analysis skill runs execute_sql SELECT
                               ↓
                         Group by skill_name + hattie_level
                               ↓
                         Surface top patterns → skill PRD improvements
                               ↓
                         Feed into Doordash workflow (M3.1) for distribution

Why Supabase over vault markdown: A REFIRE_LOG.md in the repo only exists if the user commits and pushes. Supabase writes are immediate and persistent regardless of git state — which is essential for a zero-friction, implicit capture system.

Detection Signals

The Cursor rule watches for these in the user’s follow-up message after any skill/workflow output:

  • Explicit corrections: “that’s wrong”, “fix this”, “redo”, “actually”, “not quite”, “incorrect”
  • Amendments: “change X to Y”, “instead use”, “can you adjust”, “update this to”
  • Implicit refires: follow-up that contradicts or narrows the prior output; user pastes back AI output with edits

Hattie Classification

Every captured signal is classified into one of three levels (from Hattie & Timperley’s feedback framework):

LevelMeaningExample signal
taskOutput content was wrong”That email subject is incorrect”
processApproach/strategy was wrong”You should have checked Linear first”
self-regulationSkill missed a systematic step”You always forget to include the due date”

This classification makes signals actionable — a task error suggests the skill prompt needs better grounding; a process error suggests the skill’s step sequence is wrong; a self-regulation error suggests a missing checklist item.

Supabase Setup

Project: Internal AI Core — kxzonslnqjsceiublxkf

Same project as team, clients, standup_summaries, and cursor_conversations.

Table: refire_signals

CREATE TABLE public.refire_signals (
  id                      uuid        PRIMARY KEY DEFAULT gen_random_uuid(),
  created_at              timestamptz NOT NULL DEFAULT timezone('utc', now()),
  skill_name              text        NOT NULL,
  signal_type             text        NOT NULL
    CHECK (signal_type IN ('correction', 'amendment', 'redo', 'clarification', 'rejection')),
  hattie_level            text        NOT NULL
    CHECK (hattie_level IN ('task', 'process', 'self-regulation')),
  session_user            text,
  context                 text,
  original_output_summary text,
  correction_summary      text        NOT NULL,
  metadata                jsonb
);

Column Reference

ColumnTypeRequiredDescription
iduuidautoPrimary key
created_attimestamptzautoUTC timestamp of capture
skill_nametextyesSkill or workflow that was refired (e.g. meeting-prep, gtm-ticket-creation)
signal_typetextyesOne of: correction, amendment, redo, clarification, rejection
hattie_leveltextyesOne of: task, process, self-regulation
session_usertextnoEmail or name of the team member — pulled from git config if available
contexttextnoBrief description of what was being done (e.g. “drafting EP update for Eden”)
original_output_summarytextnoOne-sentence summary of what the AI produced before the refire
correction_summarytextyesWhat was corrected, changed, or rejected — the core signal
metadatajsonbnoExtra structured data: workspace path, Linear ticket, client name, etc.

Indexes

CREATE INDEX idx_refire_signals_skill_name   ON public.refire_signals (skill_name);
CREATE INDEX idx_refire_signals_created_at   ON public.refire_signals (created_at);
CREATE INDEX idx_refire_signals_hattie_level ON public.refire_signals (hattie_level);
CREATE INDEX idx_refire_signals_signal_type  ON public.refire_signals (signal_type);

RLS Policies

ALTER TABLE public.refire_signals ENABLE ROW LEVEL SECURITY;
CREATE POLICY "Enable read access for all users" ON public.refire_signals FOR SELECT USING (true);
CREATE POLICY "Enable insert for all users"      ON public.refire_signals FOR INSERT WITH CHECK (true);

Example INSERT (what the rule fires)

INSERT INTO public.refire_signals
  (skill_name, signal_type, hattie_level, session_user, context, original_output_summary, correction_summary)
VALUES
  ('meeting-prep', 'correction', 'task', 'brylle@brainforge.ai',
   'drafting EP update for Eden',
   'Generated weekly standup summary with wrong ticket counts',
   'User corrected: ticket count was 3 completed, not 5');

No file write. No commit. No user prompt.

Key Analysis Queries (used by the analysis skill)

-- Top refired skills (last 30 days)
SELECT skill_name, COUNT(*) AS refire_count
FROM refire_signals
WHERE created_at >= now() - interval '30 days'
GROUP BY skill_name
ORDER BY refire_count DESC
LIMIT 10;
 
-- Breakdown by Hattie level per skill
SELECT skill_name, hattie_level, COUNT(*) AS count
FROM refire_signals
GROUP BY skill_name, hattie_level
ORDER BY skill_name, count DESC;
 
-- Recent corrections for a specific skill
SELECT created_at, signal_type, hattie_level, context, correction_summary
FROM refire_signals
WHERE skill_name = 'meeting-prep'
ORDER BY created_at DESC
LIMIT 20;
 
-- Weekly trend
SELECT date_trunc('week', created_at) AS week, COUNT(*) AS signals
FROM refire_signals
GROUP BY week
ORDER BY week DESC;

Files to Create

1. knowledge/platform/supabase/migrations/20260401000000_refire_signals_schema.sql

Migration file tracked in the repo (same pattern as 20260314000000_cursor_history_schema.sql). Contains the full DDL above. Applied once via Supabase MCP apply_migration with project_id: 'kxzonslnqjsceiublxkf'.

2. .cursor/rules/refire-feedback.mdc

Detection and silent logging rule. Instructs the agent to:

  • After any turn that produces a skill/workflow output, monitor the user’s next message for refire signals
  • If a signal is detected: silently call execute_sql (Supabase MCP) with an INSERT into refire_signals
  • Classify hattie_level from signal context (task = wrong content, process = wrong approach, self-regulation = missed systematic step)
  • Do NOT notify the user, do NOT ask for confirmation, continue responding normally
  • Identify session_user from git config email when available

3. knowledge/people/learning-development/refire-log/README.md

Team-facing reference doc. Covers what Refire is, where data lives, column reference, Hattie level guide, link to analysis skill, and key queries for ad-hoc lookups.

4. .cursor/skills/refire-analysis/SKILL.md

On-demand or weekly analysis skill that:

  • Queries refire_signals via execute_sql (top refired skills, Hattie breakdown, recent corrections per skill)
  • Applies VanLehn outer loop: pattern → diagnosis → response action
  • Outputs: top 3 skills to improve, one concrete suggestion per skill keyed to Hattie level
  • Optionally creates a Linear ticket for high-frequency patterns (> N refires on same skill in past 30 days)

Draws on:

  • formative-assessment-loop-designer.md (VanLehn outer loop pattern analysis)
  • feedback-quality-analyser.md (Hattie & Timperley classification framework)

Key Design Decisions

  • Zero git dependency: Supabase INSERT via MCP is immediate and durable — no commit, no push, no user action needed.
  • Silent by default: Contrast with .cursor/rules/gtm-agent-feedback-prompt.mdc (explicit opt-in). Refire is always-on and invisible to the user.
  • Human in the loop for improvements: The analysis skill surfaces patterns and recommends; a human (Brylle + Platform Team) applies skill changes. No automated skill rewriting.
  • Migration tracked in repo: The DDL lives in knowledge/platform/supabase/migrations/ so schema changes are version-controlled, even though the data lives in Supabase.
  • Ties to Doordash (M3.1): Improvements found via analysis are distributed to the team through the Doordash workflow, closing the full loop.

Success Metric

OKR: 100% of active delivery team utilizes the Refire workflow

  • Owner: Brylle + Platform Team
  • Target date: June 30, 2026
  • Proxy metric: ≥1 refire signal captured per active team member per week by end of Q2

Graph View

Backlinks