Learn Lessons
You are a senior software engineer and technical knowledge curator. Your role is to deeply analyze completed work — code changes, a branch diff, or a PR — and extract the coding patterns, architectural decisions, and best practices embedded in that work. You then write those patterns into skills and AGENTS.md so future agents apply the same approach automatically without being re-taught.
The primary focus is how code was written: naming conventions, module structure, TypeScript idioms, error handling patterns, testing approaches, and architectural choices. Agent workflow behaviors (which tools to call, how to sequence file edits) are secondary — capture those only when they reveal a repeatable coding pattern.
Your output is not a report. It is concrete updates to skills and AGENTS.md that encode the patterns found.
When to Use This Skill
Primary use cases — coding patterns
- After implementing a new module, feature, or architectural pattern worth repeating
- When the code introduces a naming convention, file structure, or TypeScript idiom not yet in any skill
- After solving a non-obvious technical problem (error handling, async pattern, type narrowing) the right way
- When a PR review revealed a gap between what was written and the project's preferred style
- When asked to "remember how we did this", "document this pattern", or "make sure future agents do it this way"
Secondary use cases — agent workflow
- After a session with significant back-and-forth or corrections
- After merging or closing a PR, to capture workflow lessons
- When asked to "retrospect", "capture lessons", or "improve agent skills from this work"
- Proactively at the end of a large implementation task before submitting changes
Scope of Analysis
The skill examines one or more of these inputs — use whichever are available:
| Input |
How to Access |
| Session log |
Read the Copilot session debug log at {{VSCODE_TARGET_SESSION_LOG}} (current session) |
| Local changes |
Run git diff HEAD or git diff main to see uncommitted/unmerged changes |
| Branch diff |
Run git log main..HEAD --oneline then git diff main...HEAD |
| Pull request |
Use gh pr view <number> --json title,body,files and gh pr diff <number> |
| Conversation history |
Review the current conversation for retries, corrections, and course changes |
Step-by-Step Workflow
Execute the following phases in strict order.
Phase 1 — Gather Evidence
1.1 Identify the target
Determine what to analyze based on the user's input:
- If a session log path is provided, read that file
- If a PR number is provided, fetch the PR diff and conversation
- If no input is given, default to the current conversation history plus
git diff main...HEAD
1.2 Collect the raw material
Run these commands to gather context:
# Current branch and recent commits
git log main..HEAD --oneline --no-decorate
# Full diff from main
git diff main...HEAD --stat
# Files changed
git diff main...HEAD --name-only
Read the session debug log if available:
# Session log location (substitute actual path)
cat "{{VSCODE_TARGET_SESSION_LOG}}" | head -500
1.3 Read the actual code
For each file changed, read enough content to understand the coding patterns used — not just that a file changed, but how it was written:
- Naming choices (variables, functions, types, files)
- Module and file structure decisions
- TypeScript type patterns (generics, discriminated unions, guards)
- Error handling approach
- Test structure and naming
- Any pattern that deviates from or extends existing conventions
1.4 Read relevant existing skills and AGENTS.md
For each project or domain touched by the changes, read the corresponding skills and AGENTS.md files. This establishes the baseline — what is already documented versus what is new.
Phase 2 — Identify What Went Well
Before looking for gaps, explicitly identify patterns worth reinforcing and repeating. Prioritize coding patterns over agent behaviors. For each one found, record:
- What happened (concrete example from the diff)
- Why it is good (convention followed, elegant solution, pattern that should generalize)
- Where to encode it (which skill or AGENTS.md should carry this forward)
Positive Pattern Checklist
Coding patterns (primary focus)
| # |
Pattern |
Signal to Look For |
| 1 |
Naming convention established |
A new naming pattern used consistently (file names, function names, type names) |
| 2 |
TypeScript idiom applied correctly |
Discriminated unions, type guards, mapped types, or generics used well |
| 3 |
Error handling done right |
Zod at boundaries, typed errors, early returns, no bare catch (e) |
| 4 |
Module structure pattern |
How files, folders, and barrel exports were organized in a new module |
| 5 |
Test structure worth repeating |
How tests were named, arranged, or parameterized |
| 6 |
Architectural decision made |
A deliberate design choice (composition vs. inheritance, service boundary, etc.) |
| 7 |
Reusable abstraction created |
A utility, hook, or helper that solves a class of problems |
| 8 |
Convention applied first-try |
Naming, import order, TypeScript strict rules correct from the start — no corrections needed |
Agent workflow patterns (secondary)
| # |
Pattern |
Signal to Look For |
| 9 |
Skill loaded proactively |
Read the relevant SKILL.md before starting work, not after a mistake |
| 10 |
Validation before completion |
Ran validate-code or tests without being prompted |
| 11 |
Scope respected |
Stayed within the stated project/task scope, no unrelated changes |
| 12 |
Context gathered before implementing |
Read existing code or config before writing new code |
Phase 3 — Identify Gaps and Mistakes
Analyze the evidence for patterns that were missing, applied incorrectly, or corrected after the fact. Prioritize coding gaps over agent workflow issues. For each one found, record:
- What happened (concrete example from the diff or conversation)
- What the correct pattern is (the approach that should have been used)
- Where to document it (which skill or AGENTS.md is the right home)
Coding Gap Checklist (primary focus)
| # |
Gap |
Signal to Look For |
| 1 |
Missing naming convention |
Inconsistent names, abbreviated identifiers where the codebase requires explicit ones, or names corrected after first draft |
| 2 |
Wrong TypeScript pattern |
any used, non-null assertion ! used, or type narrowing done with a cast instead of a guard |
| 3 |
Error handling gap |
Bare catch, swallowed error, or error surfaced as string instead of typed error |
| 4 |
Module structure inconsistency |
New module organized differently from existing modules without a deliberate reason |
| 5 |
Convention applied late |
Naming, import order, or strict TypeScript rule applied only after a correction prompt |
| 6 |
Stale knowledge |
Used an outdated API, command, or pattern that has since changed in the codebase |
| 7 |
Over-engineering |
Added abstractions, helpers, or documentation strings not requested or not needed |
| 8 |
Scope creep |
Changed files outside the stated scope of the task |
Agent Workflow Gap Checklist (secondary)
| # |
Gap |
Signal to Look For |
| 9 |
Skill not consulted |
Jumped to implementation without reading the relevant skill or AGENTS.md |
| 10 |
Missing validation |
Did not run validate-code before declaring completion; skipped tests |
| 11 |
Repeated retries |
Same command or file edit attempted 2+ times with minor variation |
| 12 |
Unsafe operation without backup |
Ran destructive git commands without using the backup-code skill first |
Phase 4 — Classify Each Finding
For each failure pattern and positive pattern found, classify the correct fix location.
Priority order: prefer skills and AGENTS.md. Only fall back to memory for facts that have no better home.
| Fix Type |
Priority |
When to Use |
Target File |
| Existing skill |
1 — preferred |
The skill exists but is missing a step, warning, or reinforcement note |
.github/skills/<name>/SKILL.md |
| New skill |
1 — preferred |
A repeatable multi-step workflow has no skill yet |
.github/skills/<new-name>/SKILL.md |
| AGENTS.md |
2 — preferred |
A short rule must be always-visible to every agent in this workspace |
AGENTS.md or <project>/AGENTS.md |
| Memory |
3 — last resort |
A highly specific fact with no natural skill home, or a personal cross-workspace preference |
/memories/*.md or /memories/repo/*.md |
Phase 5 — Apply Updates
For each finding classified in Phase 4, make the change.
For skill updates
(adding a coding pattern, warning, or reinforcement to an existing skill):
- Coding patterns go in the most specific domain skill — TypeScript patterns →
write-typescript, React patterns → write-react, NestJS patterns → the relevant NestJS skill, etc.
- If no domain skill covers the pattern, add it to the project's
AGENTS.md under the relevant section, or create a new skill
- When documenting a positive pattern, add a
> ✅ **Best practice:** ... callout
- When documenting a gap or mistake, add a
> ⚠️ **Warning:** ... callout
- Keep examples concrete — include a short before/after code snippet when it clarifies the pattern
- Prefer inserting into an existing phase or section over creating a new one
- Keep each
SKILL.md focused and under 512 lines. Treat 512 lines as a hard cap when updating any skill.
- If a skill is near or over the limit, refactor details into sibling reference markdown files and keep
SKILL.md as the concise entry point.
- Split reference files by specific aspect so they are easy to load selectively (for example: workflow steps, troubleshooting, examples, edge cases).
- Store extracted docs under
references/ in the same skill folder and link them from the relevant section in SKILL.md.
- When adding new content to an oversized skill, perform the refactor first, then add the new guidance.
Skill File Size Refactor Pattern
Use this pattern whenever a skill is becoming too large:
- Keep discovery-critical content in
SKILL.md (frontmatter, when-to-use triggers, concise workflow outline).
- Move deep, single-topic details into
references/<aspect>.md files.
- Add short links in
SKILL.md to each reference file from the matching section.
- Ensure each reference file has a narrow purpose (one aspect per file) instead of one large catch-all document.
- Re-check the line count and keep
SKILL.md under 512 lines after the refactor.
For new skills
(a repeatable workflow not yet covered):
- Follow the agent-skills instructions template precisely
- Place at
.github/skills/<name>/SKILL.md
- Write a keyword-rich
description field — this is the primary discovery surface
- Include a step-by-step workflow, not just a description
For AGENTS.md updates
(always-visible workspace rules):
- Add to the most relevant existing section
- Keep entries to one or two sentences — AGENTS.md is context-critical and must stay concise
- Use AGENTS.md only for rules too short or too universal to justify a full skill
For memory updates
(last resort — only when no skill or AGENTS.md is appropriate):
- Keep entries short — single bullet points or key-value facts
- Group related facts in the same file; create new files only when the topic is distinct
- Use the memory tool's
str_replace command to update existing entries
Phase 6 — Validate and Summarize
6.1 Verify all changes compile and link correctly
For any modified skill files:
# Check no broken relative links in the skill
grep -oP '\[.*?\]\(\K[^)]+' .github/skills/<name>/SKILL.md
# Verify SKILL.md stays under the hard cap
wc -l .github/skills/<name>/SKILL.md
6.2 Run spell check on modified files
Use the spell-check skill if any cspell errors are reported.
6.3 Produce a summary
Output a concise retrospective report:
## Lessons Learned — <date>
### Session / Changes Analyzed
- <brief description of what was analyzed>
### What Went Well — Reinforce These
| # | Pattern | Reinforcement Applied |
| - | ------- | --------------------- |
| 1 | <pattern> | Added ✅ callout to skill X / Added memory note / etc. |
### What Could Be Improved — Fix These
| # | Pattern | Severity | Fix Applied |
| - | ------- | -------- | ----------- |
| 1 | <pattern> | high/medium/low | Updated skill X / Added memory note / etc. |
### Changes Made
- `<file path>`: <one-line description of what changed>
### Recommendations for Next Session
- <actionable suggestion for the next agent>
Decision Guide: When NOT to Update
Not every mistake warrants a permanent change. Skip updating when:
- The mistake was a one-off caused by ambiguous user input (not a systematic gap)
- The correct behavior is already documented somewhere the agent should have read
- The fix would be so specific it helps only this exact scenario (no generalization value)
When in doubt, prefer a memory note over a skill update — it is lower overhead and easier to remove.
References
1---2name: learn-lessons3description: Retrospective skill that analyzes a coding agent session, a set of local changes, or a branch/pull request, then extracts reusable coding patterns, architectural decisions, and best practices — and writes them into skills and AGENTS.md so future agents apply the same patterns automatically. Primary use: capturing HOW code was written (naming, structure, TypeScript idioms, module patterns, error handling), not just what the agent did. Use when asked to "learn from this session", "capture patterns from this PR", "remember how we did this", "document this approach", "improve skills from this work", or "make sure future agents do it this way".4license: MIT5---6
7# Learn Lessons
8
9You are a senior software engineer and technical knowledge curator. Your role is to deeply analyze completed work — code changes, a branch diff, or a PR — and extract the **coding patterns, architectural decisions, and best practices** embedded in that work. You then write those patterns into skills and AGENTS.md so future agents apply the same approach automatically without being re-taught.
10
11The primary focus is **how code was written**: naming conventions, module structure, TypeScript idioms, error handling patterns, testing approaches, and architectural choices. Agent workflow behaviors (which tools to call, how to sequence file edits) are secondary — capture those only when they reveal a repeatable coding pattern.
12
13Your output is not a report. It is **concrete updates to skills and AGENTS.md** that encode the patterns found.
14
15## When to Use This Skill
16
17### Primary use cases — coding patterns
18
19- After implementing a new module, feature, or architectural pattern worth repeating
20- When the code introduces a naming convention, file structure, or TypeScript idiom not yet in any skill
21- After solving a non-obvious technical problem (error handling, async pattern, type narrowing) the right way
22- When a PR review revealed a gap between what was written and the project's preferred style
23- When asked to "remember how we did this", "document this pattern", or "make sure future agents do it this way"
24
25### Secondary use cases — agent workflow
26
27- After a session with significant back-and-forth or corrections
28- After merging or closing a PR, to capture workflow lessons
29- When asked to "retrospect", "capture lessons", or "improve agent skills from this work"
30- Proactively at the end of a large implementation task before submitting changes
31
32## Scope of Analysis
33
34The skill examines one or more of these inputs — use whichever are available:
35
36| Input | How to Access |
37| ----- | ------------- |
38| **Session log** | Read the Copilot session debug log at `{{VSCODE_TARGET_SESSION_LOG}}` (current session) |
39| **Local changes** | Run `git diff HEAD` or `git diff main` to see uncommitted/unmerged changes |
40| **Branch diff** | Run `git log main..HEAD --oneline` then `git diff main...HEAD` |
41| **Pull request** | Use `gh pr view <number> --json title,body,files` and `gh pr diff <number>` |
42| **Conversation history** | Review the current conversation for retries, corrections, and course changes |
43
44## Step-by-Step Workflow
45
46Execute the following phases in strict order.
47
48---
49
50### Phase 1 — Gather Evidence
51
52#### 1.1 Identify the target
53
54Determine what to analyze based on the user's input:
55
56- If a session log path is provided, read that file
57- If a PR number is provided, fetch the PR diff and conversation
58- If no input is given, default to the current conversation history plus `git diff main...HEAD`
59
60#### 1.2 Collect the raw material
61
62Run these commands to gather context:
63
64```bash
65# Current branch and recent commits
66git log main..HEAD --oneline --no-decorate
67
68# Full diff from main
69git diff main...HEAD --stat
70
71# Files changed
72git diff main...HEAD --name-only
73```
74
75Read the session debug log if available:
76
77```bash
78# Session log location (substitute actual path)
79cat "{{VSCODE_TARGET_SESSION_LOG}}" | head -500
80```
81
82#### 1.3 Read the actual code
83
84For each file changed, read enough content to understand the coding patterns used — not just that a file changed, but _how_ it was written:
85
86- Naming choices (variables, functions, types, files)
87- Module and file structure decisions
88- TypeScript type patterns (generics, discriminated unions, guards)
89- Error handling approach
90- Test structure and naming
91- Any pattern that deviates from or extends existing conventions
92
93#### 1.4 Read relevant existing skills and AGENTS.md
94
95For each project or domain touched by the changes, read the corresponding skills and AGENTS.md files. This establishes the baseline — what is already documented versus what is new.
96
97---
98
99### Phase 2 — Identify What Went Well
100
101Before looking for gaps, explicitly identify **patterns worth reinforcing and repeating**. Prioritize coding patterns over agent behaviors. For each one found, record:
102
103- **What happened** (concrete example from the diff)
104- **Why it is good** (convention followed, elegant solution, pattern that should generalize)
105- **Where to encode it** (which skill or AGENTS.md should carry this forward)
106
107#### Positive Pattern Checklist
108
109### Coding patterns (primary focus)
110
111| # | Pattern | Signal to Look For |
112| - | ------- | ------------------ |
113| 1 | **Naming convention established** | A new naming pattern used consistently (file names, function names, type names) |
114| 2 | **TypeScript idiom applied correctly** | Discriminated unions, type guards, mapped types, or generics used well |
115| 3 | **Error handling done right** | Zod at boundaries, typed errors, early returns, no bare `catch (e)` |
116| 4 | **Module structure pattern** | How files, folders, and barrel exports were organized in a new module |
117| 5 | **Test structure worth repeating** | How tests were named, arranged, or parameterized |
118| 6 | **Architectural decision made** | A deliberate design choice (composition vs. inheritance, service boundary, etc.) |
119| 7 | **Reusable abstraction created** | A utility, hook, or helper that solves a class of problems |
120| 8 | **Convention applied first-try** | Naming, import order, TypeScript strict rules correct from the start — no corrections needed |
121
122### Agent workflow patterns (secondary)
123
124| # | Pattern | Signal to Look For |
125| - | ------- | ------------------ |
126| 9 | **Skill loaded proactively** | Read the relevant SKILL.md before starting work, not after a mistake |
127| 10 | **Validation before completion** | Ran `validate-code` or tests without being prompted |
128| 11 | **Scope respected** | Stayed within the stated project/task scope, no unrelated changes |
129| 12 | **Context gathered before implementing** | Read existing code or config before writing new code |
130
131---
132
133### Phase 3 — Identify Gaps and Mistakes
134
135Analyze the evidence for patterns that were missing, applied incorrectly, or corrected after the fact. Prioritize coding gaps over agent workflow issues. For each one found, record:
136
137- **What happened** (concrete example from the diff or conversation)
138- **What the correct pattern is** (the approach that should have been used)
139- **Where to document it** (which skill or AGENTS.md is the right home)
140
141#### Coding Gap Checklist (primary focus)
142
143| # | Gap | Signal to Look For |
144| - | --- | ------------------ |
145| 1 | **Missing naming convention** | Inconsistent names, abbreviated identifiers where the codebase requires explicit ones, or names corrected after first draft |
146| 2 | **Wrong TypeScript pattern** | `any` used, non-null assertion `!` used, or type narrowing done with a cast instead of a guard |
147| 3 | **Error handling gap** | Bare `catch`, swallowed error, or error surfaced as `string` instead of typed error |
148| 4 | **Module structure inconsistency** | New module organized differently from existing modules without a deliberate reason |
149| 5 | **Convention applied late** | Naming, import order, or strict TypeScript rule applied only after a correction prompt |
150| 6 | **Stale knowledge** | Used an outdated API, command, or pattern that has since changed in the codebase |
151| 7 | **Over-engineering** | Added abstractions, helpers, or documentation strings not requested or not needed |
152| 8 | **Scope creep** | Changed files outside the stated scope of the task |
153
154#### Agent Workflow Gap Checklist (secondary)
155
156| # | Gap | Signal to Look For |
157| - | --- | ------------------ |
158| 9 | **Skill not consulted** | Jumped to implementation without reading the relevant skill or AGENTS.md |
159| 10 | **Missing validation** | Did not run `validate-code` before declaring completion; skipped tests |
160| 11 | **Repeated retries** | Same command or file edit attempted 2+ times with minor variation |
161| 12 | **Unsafe operation without backup** | Ran destructive git commands without using the `backup-code` skill first |
162
163---
164
165### Phase 4 — Classify Each Finding
166
167For each failure pattern **and** positive pattern found, classify the **correct fix location**.
168
169Priority order: prefer skills and AGENTS.md. Only fall back to memory for facts that have no better home.
170
171| Fix Type | Priority | When to Use | Target File |
172| -------- | -------- | ----------- | ----------- |
173| **Existing skill** | 1 — preferred | The skill exists but is missing a step, warning, or reinforcement note | `.github/skills/<name>/SKILL.md` |
174| **New skill** | 1 — preferred | A repeatable multi-step workflow has no skill yet | `.github/skills/<new-name>/SKILL.md` |
175| **AGENTS.md** | 2 — preferred | A short rule must be always-visible to every agent in this workspace | `AGENTS.md` or `<project>/AGENTS.md` |
176| **Memory** | 3 — last resort | A highly specific fact with no natural skill home, or a personal cross-workspace preference | `/memories/*.md` or `/memories/repo/*.md` |
177
178---
179
180### Phase 5 — Apply Updates
181
182For each finding classified in Phase 4, make the change.
183
184### For skill updates
185
186(adding a coding pattern, warning, or reinforcement to an existing skill):
187
188- **Coding patterns go in the most specific domain skill** — TypeScript patterns → `write-typescript`, React patterns → `write-react`, NestJS patterns → the relevant NestJS skill, etc.
189- If no domain skill covers the pattern, add it to the project's `AGENTS.md` under the relevant section, or create a new skill
190- When documenting a positive pattern, add a `> ✅ **Best practice:** ...` callout
191- When documenting a gap or mistake, add a `> ⚠️ **Warning:** ...` callout
192- Keep examples concrete — include a short before/after code snippet when it clarifies the pattern
193- Prefer inserting into an existing phase or section over creating a new one
194- Keep each `SKILL.md` focused and under 512 lines. Treat 512 lines as a hard cap when updating any skill.
195- If a skill is near or over the limit, refactor details into sibling reference markdown files and keep `SKILL.md` as the concise entry point.
196- Split reference files by specific aspect so they are easy to load selectively (for example: workflow steps, troubleshooting, examples, edge cases).
197- Store extracted docs under `references/` in the same skill folder and link them from the relevant section in `SKILL.md`.
198- When adding new content to an oversized skill, perform the refactor first, then add the new guidance.
199
200### Skill File Size Refactor Pattern
201
202Use this pattern whenever a skill is becoming too large:
203
2041. Keep discovery-critical content in `SKILL.md` (frontmatter, when-to-use triggers, concise workflow outline).
2052. Move deep, single-topic details into `references/<aspect>.md` files.
2063. Add short links in `SKILL.md` to each reference file from the matching section.
2074. Ensure each reference file has a narrow purpose (one aspect per file) instead of one large catch-all document.
2085. Re-check the line count and keep `SKILL.md` under 512 lines after the refactor.
209
210### For new skills
211
212(a repeatable workflow not yet covered):
213
214- Follow the [agent-skills instructions](../../../.github/instructions/agent-skills.instructions.md) template precisely
215- Place at `.github/skills/<name>/SKILL.md`
216- Write a keyword-rich `description` field — this is the primary discovery surface
217- Include a step-by-step workflow, not just a description
218
219### For AGENTS.md updates
220
221(always-visible workspace rules):
222
223- Add to the most relevant existing section
224- Keep entries to one or two sentences — AGENTS.md is context-critical and must stay concise
225- Use AGENTS.md only for rules too short or too universal to justify a full skill
226
227### For memory updates
228
229(last resort — only when no skill or AGENTS.md is appropriate):
230
231- Keep entries short — single bullet points or key-value facts
232- Group related facts in the same file; create new files only when the topic is distinct
233- Use the memory tool's `str_replace` command to update existing entries
234
235### Phase 6 — Validate and Summarize
236
237#### 6.1 Verify all changes compile and link correctly
238
239For any modified skill files:
240
241```bash
242# Check no broken relative links in the skill
243grep -oP '\[.*?\]\(\K[^)]+' .github/skills/<name>/SKILL.md
244
245# Verify SKILL.md stays under the hard cap
246wc -l .github/skills/<name>/SKILL.md
247```
248
249#### 6.2 Run spell check on modified files
250
251Use the `spell-check` skill if any `cspell` errors are reported.
252
253#### 6.3 Produce a summary
254
255Output a concise retrospective report:
256
257```markdown
258## Lessons Learned — <date>
259
260### Session / Changes Analyzed
261- <brief description of what was analyzed>
262
263### What Went Well — Reinforce These
264
265| # | Pattern | Reinforcement Applied |
266| - | ------- | --------------------- |
267| 1 | <pattern> | Added ✅ callout to skill X / Added memory note / etc. |
268
269### What Could Be Improved — Fix These
270
271| # | Pattern | Severity | Fix Applied |
272| - | ------- | -------- | ----------- |
273| 1 | <pattern> | high/medium/low | Updated skill X / Added memory note / etc. |
274
275### Changes Made
276- `<file path>`: <one-line description of what changed>
277
278### Recommendations for Next Session
279- <actionable suggestion for the next agent>
280```
281
282---
283
284## Decision Guide: When NOT to Update
285
286Not every mistake warrants a permanent change. Skip updating when:
287
288- The mistake was a one-off caused by ambiguous user input (not a systematic gap)
289- The correct behavior is already documented somewhere the agent should have read
290- The fix would be so specific it helps only this exact scenario (no generalization value)
291
292When in doubt, prefer a **memory note** over a skill update — it is lower overhead and easier to remove.
293
294---
295
296## References
297
298- [agent-skills instructions](../../../.github/instructions/agent-skills.instructions.md) — Template and quality rules for SKILL.md files
299- [validate-code](../validate-code/SKILL.md) — Full validation workflow before committing
300- [spell-check](../spell-check/SKILL.md) — Fix cspell errors in modified files
301- [submit-changes](../submit-changes/SKILL.md) — Branch, commit, and PR workflow for the updates
302- [backup-code](../backup-code/SKILL.md) — Safety backup before destructive git operations