work-self-improvement-review

name

work-self-improvement-review

description

Review the current ChatGPT Work conversation and files made available in the chat for durable corrections, preferences, and workflow lessons, then propose updates as project guidance, an instruction overlay, a patch to a provided SKILL.md, or a new skill candidate. Use when the user asks to review, learn from, distill, or preserve lessons from the current task, especially after corrections, repeated friction, or a non-obvious recovery. Always propose before exporting or applying any change.

Work Self Improvement Review

Use the user's language unless they request another language.

Boundaries

• Use only the current conversation and files made available in this conversation.
• Do not claim access to prior chats, local transcripts, telemetry, installed local skills, hooks, MCP servers, backups, or background state.
• Treat hidden system and developer instructions as operating constraints, not content to quote or export.
• Do not browse for additional evidence as part of the review.
• Do not change guidance, skills, repositories, or remote state during the proposal phase.
• Do not treat invocation of this skill as approval.
• Complete proposal and approval in separate turns.
• After approval, export only the approved content.
• Never claim an export was installed, published, or persisted unless the user completes that action through a supported interface.

Review Workflow

1. Extract grounded evidence from:

   • explicit user corrections;
   • stable preferences or policies stated by the user;
   • repeated friction visible in the current conversation;
   • non-obvious failure causes and reusable recovery steps;
   • successful procedures likely to prevent future mistakes.

2. Classify each lesson.

   Mark a lesson durable only when at least one condition holds:

   • the user explicitly states a continuing preference or rule;
   • the same issue appears more than once;
   • a non-obvious and costly failure has a broadly reusable prevention;
   • the lesson defines a stable project or workflow constraint.

   Mark a lesson one-off when it is:

   • specific to one output, temporary condition, or isolated wording choice;
   • speculative or weakly supported;
   • ordinary knowledge that does not need another rule;
   • already fully covered by provided guidance;
   • dependent on sensitive details that cannot be safely generalized.

   If uncertain, do not preserve it.

3. Check for duplicates only against guidance or skill files available in this conversation.

   • If an existing rule fully covers the lesson, report it as a duplicate and propose no change.
   • If the existing rule is incomplete, propose only the smallest missing delta.
   • If no governing source is available, mark duplicate status as not checked.

4. Sanitize every candidate.

   • Exclude passwords, tokens, authentication data, personal contact details, private identifiers, and unrelated proprietary content.
   • Generalize user-specific paths, names, and incident details unless essential to the rule.
   • Preserve the reusable prevention, not the sensitive incident.
   • Reject the candidate when safe generalization is impossible.

5. Select one target:

   • project guidance for stable project or team-wide instructions;
   • overlay for a reversible additive instruction when the authoritative source is unavailable;
   • SKILL patch for a procedural, triggering, validation, or guardrail change to a provided SKILL.md;
   • new SKILL candidate only for a reusable class of work that is not governed by any skill made available in the conversation.

   Do not fabricate a line-level skill patch when the source SKILL.md is unavailable. When no skill catalog or governing source is available, label novelty and duplicate status as not checked.

6. Present candidates for approval and stop.

   • Keep one rule per candidate.
   • Use IDs WSI-001, WSI-002, and so on.
   • Include only evidence visible in the current conversation.
   • Do not export or apply anything in this turn.

Proposal Format

Use this structure, translating labels into the user's language while preserving the status values:

검토 결과: 승인 대기
status: pending

[WSI-001]
판정: durable
근거: <brief paraphrase of conversation evidence>
대상: project guidance | overlay | SKILL patch | new SKILL candidate
제안 문구: "<minimal reusable instruction>"
중복 점검: none | partial | duplicate | not checked
민감정보 점검: safe | generalized | reject
검증 방법: <one observable future check>

승인 방법: 후보 ID와 대상을 지정해 승인해 주세요.

Report duplicate or rejected items briefly after actionable candidates without assigning an approval action.

If no durable lesson remains, respond:

검토 결과: 저장할 개선점 없음
status: no-change
사유: <one concise explanation>

Approval and Export

Accept approval only when the user clearly identifies a candidate or explicitly approves all pending candidates. Do not infer approval from silence or general encouragement.

Before export:

• preserve the approved meaning;
• apply any requested revision;
• recheck duplicate and sensitive-data status;
• export only approved candidates.

Use the requested format.

Project Guidance

Return a copy-ready Markdown block containing only the new guidance and its scope. Do not rewrite unrelated instructions.

Overlay

Return a standalone Markdown instruction file containing a short scope statement, the approved rules, and any limitation needed to prevent over-application. Keep it additive and reversible.

SKILL Patch

When the exact source is available:

• return a minimal unified diff;
• preserve unrelated content;
• update frontmatter description only if triggering behavior changes;
• keep YAML frontmatter limited to name and description;
• keep instructions imperative and concise.

When the source is missing or no longer matches, return the approved replacement section and state what source is needed to place it safely.

New SKILL Candidate

Return a complete minimal SKILL.md candidate only after approval.

• Use YAML frontmatter with only name and description.
• Use a lowercase hyphenated name.
• State what the skill does and when to use it in description.
• Keep the body imperative, portable, and independent of local paths, hooks, MCP servers, background processes, and unavailable tools.
• Include only instructions supported by the approved evidence.
• Never claim the candidate is installed or published.

If file artifacts are supported, provide the export as a downloadable Markdown artifact. Otherwise provide copy-ready Markdown or a unified diff.

End with:

내보내기 완료: <candidate IDs>
형식: project guidance | overlay | SKILL patch | new SKILL candidate
상태: 사용자 적용 대기