Factory Lookback

---
name: factory-lookback
description: >-
  Experimental workflow for auditing recurring feedback, telemetry, errors,
  and brittle delivery paths to find systemic fixes. Use for periodic or
  requested cross-source lookbacks, not routine single-item intake.
category: engineering-method
source: BuilderIO/skills
---

# Factory Lookback

Read `.agent-factory/config.yaml` and apply the optional
`skill_prompts.factory-lookback` entry as additional project guidance. Use this
workflow when asked to look back across a bounded period or when an enabled
`workflows.lookback` automation runs. Its purpose is to find patterns that
normal item-by-item flows keep missing or fixing only temporarily.

## Build a bounded evidence set

1. Confirm the configured sources, scope, time window, comparison period, and
   output policy before querying. Use only connected sources the host can read.
2. Enumerate the full configured range, follow every page or cursor, and record
   source filters, dates, counts, and unavailable or truncated sources. Do not
   report a complete lookback when coverage is partial.
3. Include relevant feedback, analytics or telemetry, runtime errors,
   recurring CI or review failures, repeated recovery attempts, replies to
   earlier information requests, and prior fixes marked shipped or verified
   when those records are available.
4. Cluster records by underlying symptom and affected boundary, not wording
   alone. Keep event counts, affected users or sessions, time range, versions,
   and distinct source links separate; do not infer identity or impact from
   unstable identifiers.

## Find the systemic cause

For each recurring cluster, trace representative reports to their original
source and inspect prior dispositions, commits, tests, and release evidence.
Check whether the symptom recurred after a claimed fix, appeared through a
sibling caller, or escaped because the normal workflow lacked a signal, owner,
verification step, or recovery path.

For a report previously held for more information, inspect the full source
thread for new replies. Re-triage the original report with the new details and
check whether the normal fix flow now has enough evidence to proceed. Keep the
item open when the answer is still incomplete; do not treat a reply as a fix or
as permission for another action.

Reproduce a representative current case when possible. Trace related callers
and surfaces to the shared boundary that can explain the evidence. Prefer one
verified correction at that boundary over a pile of caller-specific patches.
Separate confirmed causes from hypotheses, and state what evidence would
disprove each proposed explanation.

## Change and verify

Recommend only by default. Prepare a fix locally only when `workflows.lookback.implement` allows it and the user asked for it in this conversation; publishing needs the user's GO. A recurring pattern is evidence for
investigation, not automatic permission to edit code or take an external
action. Keep reply, issue closure, PR approval, merge, deployment, and
notification under their own configured policies.

When implementation is allowed, make the smallest systemic fix that addresses
the confirmed cause. Add or update a regression check at the boundary, exercise
the representative failure and relevant sibling paths, and inspect the same
signals again after the fix. A test, merge, or “fixed” label alone does not
prove that the live recurrence stopped.

## Report

For each pattern, report:

- the source links, date range, query coverage, counts, and impact evidence;
- prior fixes or dispositions and whether the symptom returned;
- information requests, answers received, and whether they changed the
  evidence or next step;
- confirmed cause, alternatives still uncertain, and the shared boundary;
- recommended or completed systemic change, regression proof, and remaining
  rollout or live-verification work;
- independent reply, close, publish, approval, merge, deployment, and notify
  decisions, plus any exact human decision required.

Do not treat unavailable telemetry or an incomplete history as evidence that a
pattern does not exist.

## AOS safety rules

- Configuration lives in `.agent-factory/config.yaml`. If it is missing, stop and
  ask the user; never create it or guess sources.
- Nothing in the config can open the AOS GO gate. `git push`, `gh pr merge`,
  `gh release create` and every external write (reply, comment, approval, close,
  status change, notification) need the user's literal GO for that exact action.
  Prepare the change or draft text, show it, and stop.
- Scheduled or unattended runs are read-only. Report; do not act.
- Connectors are whatever the host already exposes. Do not install or register
  integrations or MCP servers.