Post-Task Learning Review
Use this skill near the end of a non-trivial task, after verification and before the final response when possible. Keep the review short. Directly apply qualified maintenance actions instead of merely proposing them. The goal is to keep durable knowledge accurate and discoverable, not to create a task diary.
Core Principle
Maintain before adding. Before adding a new lesson, check whether an existing doc, memory entry, or skill already covers the topic. Prefer update, correction, consolidation, or deletion over appending duplicate or stale knowledge. Treat outdated guidance as a finding: identify what is stale, why it is stale, and replace or remove it.
Project scope first for project knowledge. Codex memory notes help future Codex sessions, but they are outside the current repo and are not visible to other project-scoped agents, collaborators, or deployment workflows. For repo-specific lessons, prefer project docs as the canonical home; use memory only as a cross-session index or supplement. If both are useful, keep project docs actionable and link or summarize the memory-level preference separately.
Treat this skill's activation as authorization to perform safe local maintenance writes within the current task's established scope. Do not ask for separate confirmation merely because the destination is project docs, a permitted memory update, an existing skill, or a new skill. Higher-priority system, developer, and user instructions, filesystem permissions, sensitive-data rules, and external side-effect boundaries still apply. Do not infer permission to commit, push, publish, message other people, or modify production systems.
Decision Rules
| Destination |
Capture when |
Do not capture when |
| Project docs |
The lesson is repo-specific: deployment flow, runtime topology, API contract, troubleshooting path, operational command, accepted architecture decision, or anything future project-scoped agents should share. |
It is a one-off chat detail, raw log dump, temporary workaround, or unrelated to the document's topic. |
| Memory |
The lesson helps future sessions across projects or Codex threads: stable user preference, machine-specific friction, durable cross-repo fact, or recurring correction. |
It contains secrets, private data, unverified guesses, repo-specific knowledge that belongs only in project docs, or facts likely to drift without a verification note. |
| Existing skill |
The workflow already has a clear skill home and the lesson improves future execution. |
The lesson only applies to one project or one bug. |
| New skill |
The workflow repeats across tasks, has clear triggers, and can be described as a reusable procedure. |
It is ordinary coding knowledge, a single bug fix, or lacks a stable trigger. |
Choose an action before choosing a destination:
| Action |
Use when |
| Add |
The lesson is durable and no existing place covers it. |
| Update |
Existing guidance is incomplete, stale, or contradicted by verified facts. |
| Consolidate |
Multiple places repeat the same idea and one canonical place is clearer. |
| Deprecate or remove |
Existing guidance is wrong, misleading, or no longer applicable. |
| No-op |
The lesson is temporary, obvious, unverifiable, or not worth future context. |
Act on a lesson only when at least two are true:
- Future reuse is likely.
- Rediscovery would be costly.
- The lesson changes how a future agent should act.
- The fact is stable, or can be marked as requiring live verification.
- A future reader has a clear lookup path or trigger phrase.
Execution Policy
- Execute qualified Add, Update, Consolidate, and Deprecate or remove actions immediately when the target is local, in scope, and writable.
- For memory, follow the active memory mechanism. If direct edits are prohibited but an update-note mechanism is allowed, write the update note directly. If higher-priority policy explicitly requires per-turn user authorization, report that exact restriction rather than inventing permission.
- For project docs, use progressive disclosure and keep unrelated content untouched.
- For skill changes, use
$skill-creator, validate the changed skill, and keep repository and plugin copies synchronized when both are established sources.
- Do not let an optional publish or sync workflow block the local maintenance write. Commit, push, publication, installation, or external synchronization remains a separate action unless already authorized by the task or repository rules.
Review Workflow
- List at most five candidate lessons from the task.
- Exclude secrets, credentials, tokens, private user data, and raw production data.
- Check the active context and obvious existing docs, memories, or skills before choosing a destination.
- Classify each candidate using the action and destination tables.
- Immediately execute every qualified maintenance action that is permitted and writable.
- Prefer updating or consolidating an existing doc or skill over creating a new file.
- If existing guidance is stale, replace or remove the stale claim and record the verified replacement.
- If a candidate is repo-specific and future project-scoped agents need it, write project docs even when a memory supplement is also useful.
- Verify every write proportionally: inspect the diff, validate a skill, or re-read the updated memory note.
- Report completed changes and any exact higher-priority blocker in the final response.
Output Format
When maintenance was performed, respond with this table:
| Lesson |
Action |
Destination |
Files |
Verification |
If nothing is worth keeping, say:
No durable lesson found. Nothing needs to be added, updated, consolidated, or removed.
Keep the reasoning concise. Report what was changed; do not ask for confirmation unless a higher-priority restriction or genuinely missing decision blocks the write.
1---2name: post-task-learning-review3description: Review a completed or nearly completed non-trivial task and directly maintain durable lessons across project docs, memory, existing skills, or new skills without asking for separate confirmation. Use after complex debugging, deployment, live verification, repo documentation work, repeated workflow discovery, creating or updating a skill, or when the user asks whether anything is worth remembering, updating, or deleting.4---56# Post-Task Learning Review78Use this skill near the end of a non-trivial task, after verification and before the final response when possible. Keep the review short. Directly apply qualified maintenance actions instead of merely proposing them. The goal is to keep durable knowledge accurate and discoverable, not to create a task diary.910## Core Principle1112Maintain before adding. Before adding a new lesson, check whether an existing doc, memory entry, or skill already covers the topic. Prefer update, correction, consolidation, or deletion over appending duplicate or stale knowledge. Treat outdated guidance as a finding: identify what is stale, why it is stale, and replace or remove it.1314Project scope first for project knowledge. Codex memory notes help future Codex sessions, but they are outside the current repo and are not visible to other project-scoped agents, collaborators, or deployment workflows. For repo-specific lessons, prefer project docs as the canonical home; use memory only as a cross-session index or supplement. If both are useful, keep project docs actionable and link or summarize the memory-level preference separately.1516Treat this skill's activation as authorization to perform safe local maintenance writes within the current task's established scope. Do not ask for separate confirmation merely because the destination is project docs, a permitted memory update, an existing skill, or a new skill. Higher-priority system, developer, and user instructions, filesystem permissions, sensitive-data rules, and external side-effect boundaries still apply. Do not infer permission to commit, push, publish, message other people, or modify production systems.1718## Decision Rules1920| Destination | Capture when | Do not capture when |21| --- | --- | --- |22| Project docs | The lesson is repo-specific: deployment flow, runtime topology, API contract, troubleshooting path, operational command, accepted architecture decision, or anything future project-scoped agents should share. | It is a one-off chat detail, raw log dump, temporary workaround, or unrelated to the document's topic. |23| Memory | The lesson helps future sessions across projects or Codex threads: stable user preference, machine-specific friction, durable cross-repo fact, or recurring correction. | It contains secrets, private data, unverified guesses, repo-specific knowledge that belongs only in project docs, or facts likely to drift without a verification note. |24| Existing skill | The workflow already has a clear skill home and the lesson improves future execution. | The lesson only applies to one project or one bug. |25| New skill | The workflow repeats across tasks, has clear triggers, and can be described as a reusable procedure. | It is ordinary coding knowledge, a single bug fix, or lacks a stable trigger. |2627Choose an action before choosing a destination:2829| Action | Use when |30| --- | --- |31| Add | The lesson is durable and no existing place covers it. |32| Update | Existing guidance is incomplete, stale, or contradicted by verified facts. |33| Consolidate | Multiple places repeat the same idea and one canonical place is clearer. |34| Deprecate or remove | Existing guidance is wrong, misleading, or no longer applicable. |35| No-op | The lesson is temporary, obvious, unverifiable, or not worth future context. |3637Act on a lesson only when at least two are true:3839- Future reuse is likely.40- Rediscovery would be costly.41- The lesson changes how a future agent should act.42- The fact is stable, or can be marked as requiring live verification.43- A future reader has a clear lookup path or trigger phrase.4445## Execution Policy4647- Execute qualified Add, Update, Consolidate, and Deprecate or remove actions immediately when the target is local, in scope, and writable.48- For memory, follow the active memory mechanism. If direct edits are prohibited but an update-note mechanism is allowed, write the update note directly. If higher-priority policy explicitly requires per-turn user authorization, report that exact restriction rather than inventing permission.49- For project docs, use progressive disclosure and keep unrelated content untouched.50- For skill changes, use `$skill-creator`, validate the changed skill, and keep repository and plugin copies synchronized when both are established sources.51- Do not let an optional publish or sync workflow block the local maintenance write. Commit, push, publication, installation, or external synchronization remains a separate action unless already authorized by the task or repository rules.5253## Review Workflow54551. List at most five candidate lessons from the task.562. Exclude secrets, credentials, tokens, private user data, and raw production data.573. Check the active context and obvious existing docs, memories, or skills before choosing a destination.584. Classify each candidate using the action and destination tables.595. Immediately execute every qualified maintenance action that is permitted and writable.606. Prefer updating or consolidating an existing doc or skill over creating a new file.617. If existing guidance is stale, replace or remove the stale claim and record the verified replacement.628. If a candidate is repo-specific and future project-scoped agents need it, write project docs even when a memory supplement is also useful.639. Verify every write proportionally: inspect the diff, validate a skill, or re-read the updated memory note.6410. Report completed changes and any exact higher-priority blocker in the final response.6566## Output Format6768When maintenance was performed, respond with this table:6970| Lesson | Action | Destination | Files | Verification |71| --- | --- | --- | --- | --- |7273If nothing is worth keeping, say:7475`No durable lesson found. Nothing needs to be added, updated, consolidated, or removed.`7677Keep the reasoning concise. Report what was changed; do not ask for confirmation unless a higher-priority restriction or genuinely missing decision blocks the write.
nangongwentian-fe