Factory Reflect

Improve the factory from evidence without turning one incident into universal policy. Never auto-apply a skill change.

Select evidence

Use completed tickets in the current factory root only: plans and discoveries, state transitions, usage, blockers, final work and review session outputs, wrap-up, and existing learnings. Do not search unrelated repositories or private sessions.

Run reflection when the user asks, when a costly failure or correction reveals a general mechanism, or when the same useful pattern appears across tickets. Skip routine success already covered by existing instructions.

Derive candidates

For each candidate learning, record:

• The observed evidence and ticket identifiers.
• The general mechanism, separated from task-specific details.
• The smallest place that can enforce it.
• Expected benefit and budget effect.
• A counterexample showing when it should not apply.

Route the change to deterministic tooling or validation when code can enforce it more reliably. Route stable project facts to .factory/CONTEXT.md or .factory/FACTORY.json. Route decision guidance to the narrowest existing skill. Propose a new skill only when no existing boundary fits.

Write accepted candidates under .factory/learnings/ only when they are reusable. Keep rejected ideas in the session rather than building a permanent backlog of noise.

Evaluate before proposing application

Read references/evaluation.md. Compare the current skill baseline with the candidate using the smallest scenario set capable of exposing the intended improvement and likely regression. Include quality, Output-template validity, test outcome, scope, review rounds, token usage, and cost.

Ask the user which accepted candidates to apply. Only after explicit approval may the relevant skill-authoring workflow edit the skill repository. Validate changed skills and rerun affected evaluations.

Do not commit, publish, or update installed skills automatically.

Output

Return only this template. No recap after it.

## Candidates

### 1. [accept | revise | reject] Short title
**Evidence:** tickets and observations
**Mechanism:** general rule, not the incident
**Route:** skill, CONTEXT.md, FACTORY.json, or tooling
**Evaluation:** quality, Output-template validity, tests, scope, rounds, tokens, cost
**Counterexample:** when this must not apply