Factory Lookback
Experimental workflow for auditing recurring feedback, telemetry, errors, and brittle...
Install
npx skills add BuilderIO/skills --skill factory-lookback -g -a claude-code -y- Repository
- BuilderIO/skills4.6k
- Category
- Engineering
- Updated
- 7d ago
- License
- MIT
- Context cost
- Lightabout 945 tokens
- Runs scripts
- No, instructions only
What it does
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.
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
- Confirm the configured sources, scope, time window, comparison period, and output policy before querying. Use only connected sources the host can read.
- 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.
- 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.
- 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.
