retro-workspace

retro-workspace

A SKILL for CLI / Scout that extracts reusable knowledge from incidents and conversations and reflects it into the design assets and automation assets of the current workspace / repository with minimal diffs. In VS Code, use the prompt with the same name. Keep judgment and flow self-contained within this SKILL, and do not delegate to other skills / prompts.

When to Use

• Use: after resolving a bug / when it recurs / when a workspace design gap is found
• Use: when you find an improvement that should be promoted to a safer, more reproducible, or faster script / task / helper than the existing procedure
• Use: .github/**、AGENTS.md, reflecting into repo-specific instructions / prompts / agents / hooks, scripts, and tasks
• Do not use: typos only / environment-specific issues only / ~/.copilot personal assets / VS Code User Data assets / private skills repository の .github/skills/**(in any case, hand off to the retro workflow for that scope)

Input

At least one of: error log / Git diff / conversation history / terminal history. If none, request it and stop.

Workspace detection (determining the reflection target)

CLI / Scout cannot always obtain the VS Code active workspace. Determine the reflection target before extracting knowledge.

1. If the user or host context explicitly specifies a workspace path: use that folder as the reflection target regardless of whether a repo marker exists. Do not override it with CWD or a candidate external new project
2. If there is no explicit workspace path: if CWD or one of its parents has .git / .github/ / AGENTS.md , use that repo root as the reflection target
3. No workspace: do not create any file or folder; confirm with the user
   • Present options: (a) do not reflect, hand off (present only the knowledge) / (b) specify an existing different folder
   • Do not create or propose a new project folder unless the user has specified the creation location themselves

Mode

• The default is safe-auto. If the workspace scope is clear and the change is a small-to-medium update to existing assets, you may reflect it without confirmation
• review-only / 確認だけ / dry-run / プレビュー Only when
• Confirm only unclear scope, new privileges/destinations/visibility/defaults, destructive deletion or uncertain sensitive data. Bounded fixes need no reapproval; code/hooks widening permissions still do.

Scope Gate

• is explicitly specified, stop at presenting the proposed changes AGENTS.md、.github/**Limit reflection targets to
• , and repo-specific scripts / tasks / helpers /memories/** Do not reflect secrets / credentials / personal information / customer information / local absolute paths / machine-specific values /
• User Data / ~/.copilot Stop as scope mismatch for
• .github/skills/** Do not edit directly; if it is suitable for a SKILL, propose it and stop

Edit Rules

• Prefer integration into existing files over new files, and consider in the order of削除 → 統合 → 分離 → 追加 , suspect excessive responsibilities first
• Before writing a new rule, check whether the same judgment is already implemented in scripts / generated artifacts / existing assets. A rule that contradicts the implementation will cause the next run to break the correct assets
• Use an isolated clean checkout for authorized Git mutations; preserve unrelated dirty, avoid blanket staging/autostash, and group owning-scope edits. Refresh ledger IDs before appending and verify uniqueness after an authorized commit. Do not add unrequested commits/pushes.
• For an explicitly authorized push, fetch, inspect the permitted ahead range and integrate behind/divergence in the clean execution checkout first; never use force or stale tracking refs.
• After moving a multi-paragraph Markdown section, verify heading order, exactly one occurrence of the moved heading and its first content line, and git diff --check; delete-plus-insert moves can otherwise leave an omission or duplicate.
• The primary purpose of compression is the minimum information an AI can judge from, with human readability secondary
• Compress redundant explanations, but keep source URLs and non-obvious procedures
• Do not repeat the same Learning / Evidence / Impact in different words; group it as one point per block
• AGENTS.md と .github/copilot-instructions.md For entry files such as
• Prioritize script / task conversion when reusability, verifiability, and a narrow scope of impact are all present

Execution steps

0. Pre-Flight Inventory

Before starting knowledge extraction, inventory the candidate destinations for reflection. Which .instructions.md / tasks.json / scripts/ / AGENTS.md is likely to be the recipient, and what scope gate applies, should be checked first. This defines the scope early and prevents scattered reflection across multiple files and duplication with existing assets.

1. Knowledge extraction

• Preferentially pick up design principles, workflows, context, automation improvements, and making repeated instructions into defaults
• Do not turn a single negative observation ("that feature does not exist") into a rule. Confirm after ruling out authentication state, extension activation, and mode, and if it cannot be fully ruled out, leave it with the observation conditions attached
• Create Learning / Evidence / Impact for each item

2. Drafting changes

• Priority: Impact x Recurrence (P1/P2/P3)
• First check whether it can be integrated into existing workspace assets
• If script / task conversion is appropriate, prefer existing runners or script directories
• When handling actual screens in reports/HTML, explicitly separate actual UI screenshots from generated evidence views, and mask the posting destination, user, channel, and URL surroundings for shared screens such as Teams/chat before reflecting them
• In the entry file, consider compression before addition, andAGENTS.md と .github/copilot-instructions.md do not break the role differences of
• In safe-auto, reflect with the minimal diff, and only leave it as a proposal for review-only and when the Gate is stopped

3. Reflection + approval when necessary

• Edit with safe-auto
• Only when the conditions requiring confirmation apply, present the target, reason, and impact, and reflect after approval

3.5. Bloat check (after reflection)

After reflection, if there are DRY violations, redundant expressions, or duplicate definitions, compress, delete, or separate them.

Next Candidates

List up to three scoped read-only follow-ups: dirty authoring/private-push/distribution gaps. Use the owning workflow, honor holds/visibility, and never widen scope or execute suggestions.

Example Report

# Retro: [Title]

- Target workspace: <repo root | ユーザー指定フォルダ | handoff>
- Learnings: ...
- Changes: ...
- Gate: pass / stop reason

Stop: no knowledge / user refusal / Gate failure / handoff-required / review-only / workspace undetermined