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
-
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.
-
Classify each lesson.
Mark a lesson
durableonly 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-offwhen 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.
-
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.
-
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.
-
Select one target:
project guidancefor stable project or team-wide instructions;overlayfor a reversible additive instruction when the authoritative source is unavailable;SKILL patchfor a procedural, triggering, validation, or guardrail change to a providedSKILL.md;new SKILL candidateonly 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.mdis unavailable. When no skill catalog or governing source is available, label novelty and duplicate status asnot checked. -
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:
text검토 결과: 승인 대기 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:
text검토 결과: 저장할 개선점 없음 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
descriptiononly if triggering behavior changes; - keep YAML frontmatter limited to
nameanddescription; - 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
nameanddescription. - 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:
text내보내기 완료: <candidate IDs> 형식: project guidance | overlay | SKILL patch | new SKILL candidate 상태: 사용자 적용 대기


