agentsclimarketplace

Agent retrospective

Skill marcozhou26/agent-retrospective/agent-retrospective

Codex skill for reviewing agent failures, avoiding rule bloat, and choosing the smallest verified improvement.

Install
npx -y skills add marcozhou26/agent-retrospective --skill agent-retrospective

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 25 days oldThe repository was created 25 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Diagnose and improve a Codex, Agent, Skill, or workflow after failure, repeated correction, false completion, local symptom fixes, rule stacking, or before promoting any learning into AGENTS.md, SKILL.md, scripts, dependencies, memory, or eval gates. Use when the user asks to review why a task went wrong, why a skill/tool/process still feels broken after one successful run, or how to improve the whole working system instead of adding another isolated rule.

SKILL.md

4.8 KB, 942 tokens by cl100k_base, as published. Nobody here has run it

Agent Workflow Retrospective

Diagnose the working system behind an agent outcome. Do not start by adding a rule. First map the affected surfaces, classify root causes, apply the complexity gate, and propose changes to the right layer.

Default Mode

Use report-only mode by default.

Do not edit AGENTS.md, SKILL.md, scripts, dependencies, hooks, memory files, or project source unless the user explicitly asks for implementation after reviewing the patch plan.

The normal output is a retrospective report with a patch plan, not a patch.

Boundaries

  • If the user wants a product-style diagnosis of one specific skill package, state that this skill only covers system-level retrospective analysis unless the user asks for a dedicated skill review.
  • If the user asks for acceptance testing or a PASS/FAIL result, design the verification plan but do not claim formal acceptance unless real tests are run and evidenced.
  • If the key question is whether an agent-like product satisfies a PRD value contract, include that as a validation surface but keep this skill focused on root cause, fix target, and complexity control.
  • Use this skill when the problem may span rules, skills, workflow order, scripts, dependencies, memory, or validation gates.

Required References

Load these only when needed:

  • Read references/root-cause-taxonomy.md whenever classifying symptoms.
  • Read references/complexity-gate.md before recommending any durable change.
  • Read references/promotion-gates.md before saying where a learning should go.
  • Use references/retrospective-report-template.md for the final report shape.

Workflow

  1. Freeze the task baseline.
    • State the user's original goal.
    • State what actually happened.
    • Separate output existence from requirement coverage.
  2. Reconstruct the failure timeline.
    • Include wrong turns, user corrections, retries, fallbacks, and final working path if one exists.
    • Mark missing evidence instead of inventing it.
  3. Build the system surface map.
    • Rules and standing instructions.
    • Active or expected skills.
    • Workflow steps and handoffs.
    • Scripts, CLIs, MCP tools, and helper commands.
    • Dependencies, versions, auth, network, runtime, or environment state.
    • Memory, baselines, prior scans, indexes, and .learnings/.
    • Validation gates, tests, previews, QA, and completion language.
  4. Classify each symptom.
    • Use the root-cause taxonomy.
    • One symptom may have multiple root causes.
    • Do not collapse everything into instruction_gap.
  5. Apply the complexity gate.
    • Every durable change must show evidence value greater than complexity delta.
    • A rejected change can still appear as a candidate observation.
  6. Decide the correct fix target.
    • Prefer updating an existing rule, skill, workflow, script, or eval over adding a duplicate.
    • Prefer script/tool fixes for mechanical repeated errors.
    • Prefer eval/checklist fixes for false completion.
    • Prefer memory notes for one-line facts.
  7. Produce the report.
    • Use the report template.
    • Include anti-rule-stacking decision, promotion decision, and verification plan.

Hard Rules

  • Do not turn a local symptom into a global rule without root-cause classification.
  • Do not write "be more careful", "check more thoroughly", or similar generic reminders as durable improvements.
  • Do not recommend more than one new long-term rule in a single retrospective; if more are needed, consolidate, update existing rules, or move detail into a skill/reference/script/eval.
  • Do not promote a learning without evidence, a fix target, a verification method, and a complexity offset.
  • If evidence is weak or unavailable, label the item as a hypothesis or candidate observation, not as a patch plan item.

Completion Language

Use layered status honestly:

  • BASIC_OUTPUT_PASS: the retrospective report exists and required sections are filled.
  • REQUIREMENT_COVERAGE_PASS: only after each user-specified requirement for the retrospective has been checked.
  • USER_REQUIREMENT_PASS: only after the user-visible goal and usability expectation are actually satisfied.
  • not_tested: use for any layer not checked.

If only the report was produced, say it is BASIC_OUTPUT_PASS; do not claim the underlying workflow has been fixed.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.