archive-and-cleanup-vibe-docs
When to Trigger
Use this skill only after:
- A feature or refactor is fully implemented
- The agent is about to open or finalize a PR
- Temporary documents were created during exploration, planning, or iteration
Do not use during active development.
Inputs
The agent may have access to:
-
Temporary documents such as:
plan*.mdprogress*.mdtask*.md- design notes, brainstorm files, agent logs
-
The final code changes
-
Existing project documentation structure
Core Objective
Transform process artifacts into durable engineering assets, while ensuring:
- PRs remain clean and reviewer-friendly
- Long-term design decisions are preserved
- Temporary documents do not accumulate in the repository
Execution Steps (MANDATORY)
Step 1: Inventory & Classification
Scan all temporary documents produced during the task and classify each into one of the following categories:
-
Durable Design Knowledge
- Architecture decisions
- Key abstractions and boundaries
- Important trade-offs (Why X, not Y)
-
PR-Level Context
- Background needed to understand the change
- Scope clarification
- Explicit non-goals
-
Process Noise
- Daily progress logs
- Task checklists
- Iteration history
- Prompt drafts or agent conversations
Step 2: Knowledge Extraction & Consolidation
2.1 PR Summary (REQUIRED)
Produce a concise, reviewer-oriented summary suitable for a PR description, containing:
- Background (problem being solved)
- Final design decisions (only conclusions)
- Scope and non-scope
- Follow-up items (if any)
⚠️ Do NOT include:
- Chronological progress
- Failed attempts in detail
- Raw task lists
2.2 Architecture / Design Documentation (CONDITIONAL)
If (and only if) durable design knowledge exists:
-
Create or update documentation under one of the following:
docs/architecture/<feature>/docs/decisions/- module-local
docs/
Strongly prefer ADR-style documents:
# ADR-XXX: <Decision Title>
## Context
## Decision
## Consequences
Only extract final decisions, not exploration history.
Step 3: Issue & Follow-up Migration
If any temporary documents contain:
- TODOs
- Deferred ideas
- Known limitations
Then:
- Convert them into GitHub Issues or explicit Follow-up notes
- Remove them from temporary documents
Step 4: Cleanup (MANDATORY)
After successful extraction:
-
Delete all temporary vibe coding documents from the repository, including but not limited to:
- plan files
- progress logs
- task trackers
- brainstorming notes
-
Ensure:
- No references to deleted files remain
- No broken links in docs or PR description
⚠️ Temporary documents must not be committed in the final PR.
Output Requirements
At the end of execution, the agent must produce:
- ✅ A PR-ready summary (text only)
- ✅ Any new or updated durable documentation
- ✅ A clean repository state with all temporary documents removed
Strict Rules
- Never commit raw vibe coding documents
- Never include thinking logs or agent conversations
- Prefer clarity and durability over completeness
- If unsure whether something is durable, exclude it
Mental Model
Temporary docs are raw material. The repository only accepts finished products.
Success Criteria
This skill is successful if:
- A reviewer can understand the PR without reading any temporary documents
- The repository contains only long-lived, intentional documentation
- No vibe coding artifacts remain after merge
More from mkdir700/myskills
decision-log
MANDATORY pre-commit workflow for vibe coding. ALWAYS trigger when user says 'commit', 'git commit', or any commit-related command. Forces diff review and decision log generation BEFORE allowing commit to proceed.
16ai-review-validator
Autonomously validate and execute AI Review suggestions from PR comments. Use when users provide AI Review comments (from GitHub Copilot, CodeRabbit, etc.) that suggest code changes, API migrations, or fixes. The skill verifies suggestions against official docs, tests compilation, calculates confidence scores, and auto-applies changes when verified. Triggers on phrases like "verify this AI Review", "apply this suggestion", "validate AI Review comment", or when users paste AI Review URLs/content.
8codex-plan-reviewer
Cross-model adversarial review loop for markdown plans. Use this skill whenever the user asks to review, validate, or stress-test a markdown plan file using Codex (OpenAI). Triggers on phrases like "review this plan with codex", "let codex check the plan", "adversarial review", "cross-model review", "codex audit", "validate plan", or when the user has a markdown plan and wants a second opinion from a different AI model. Also trigger when the user says "plan review loop", "codex review loop", or references having Codex critique a plan before execution.
2