Analyze failed sessions and propose skill repairs

Why use this

1. Repeated session failures may point to a weak instruction, missing capability or unsuitable task rather than one simple defect. Automatically rewriting a skill from a few corrections can overfit those examples and damage behaviour that already works.

2. This job could organize failure evidence into narrowly scoped repair proposals and comparison criteria. Separating diagnosis, candidate edits and evaluation decisions would let maintainers judge whether a change addresses the cause without expanding authority or altering protected material.

Why an agent / simpler alternative

Useful judgment

Cluster error patterns and connect them to specific skill instructions while preserving alternative explanations.

Simpler alternative

Use an issue log and a manual patch when one reproducible failure has a clear cause.

Unsuitable when

The analysis requires unauthorized session data or modifying protected bundled instructions.

Proposed inputs

1. Name

   Authorized failure samples

   Owner

   System owner

   Minimum scope

   Redacted errors, corrections and relevant task context

   Quality check

   Exclude credentials and separate user feedback from untrusted content.

2. Name

   Editable skill scope

   Owner

   Maintainer

   Minimum scope

   Owned skill versions, protected paths and expected behaviours

   Quality check

   Confirm which instructions may be proposed for change.

Access and setup — proposed or unknown

Proposed minimum

1. Inspect supplied logs and editable-skill copies; generate candidate diffs without applying them.

Compatibility unknowns

1. Unknown: log schema, evaluation tooling, version support and local data access.

External actions requiring approval

1. Modifying skills, running evolutionary jobs, scheduling repairs or expanding persistent access.

Expected deliverable and review checks

Proposed artifact

Repair proposal with failure evidence, candidate diff, regression risks and an unexecuted comparison plan.

Critical checks

1. The proposed edit is traceable to a repeated or reproducible issue.

2. Protected material and unrelated permissions remain outside the diff.

Missing output evidence

No new run or output inspection in this editorial layer; see linked source-specific limits.

Failure signals and proposed responses

1. Signal

   A single user correction becomes a universal instruction.

   Why it matters

   The change may solve one case while breaking valid alternatives.

   Proposed response

   Retain the contextual condition and seek counterexamples before recommending a broad rule.

2. Signal

   A repair adds tool permissions to bypass an error.

   Why it matters

   The system could gain unnecessary authority instead of fixing the underlying issue.

   Proposed response

   Treat access separately and propose the least-privileged diagnostic change.

Effort and cost — unknown

Setup work

1. Define editable scope and balanced evaluation examples.

Ongoing review

1. Review regression evidence and retain rollback versions.

Unknowns

1. Unknown: evaluation costs, log quality and repair effectiveness.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Synthetic logs include one recurring parsing error and one isolated preference correction; the candidate diff touches a protected file.

Acceptance checks

1. Only the recurring pattern supports a general repair proposal.

2. The protected-file change is rejected before evaluation.

Stop conditions

1. Unauthorized logs, protected edits or broader access would be required.

Limits

1. A comparison plan is not evidence of improvement; skill changes require scoped review and separately authorized evaluation.