بنقرة واحدة
revert
Git-aware logical undo at track, phase, or task level with confirmation gates
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Git-aware logical undo at track, phase, or task level with confirmation gates
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Use when starting isolated feature work or before executing implementation plans. Manages full worktree lifecycle from creation through cleanup with safety checks and error recovery.
Configuration reference and troubleshooting for the statusline plugin — sections, themes, bar widths, and script architecture
Common agent patterns and templates for Claude Code. Use when implementing agents to follow proven patterns for Tasks integration, quality checks, and external model invocation via claudish CLI.
CRITICAL - Guide for using Claudish CLI ONLY through sub-agents to run Claude Code with OpenRouter models (Grok, GPT-5, Gemini, MiniMax). NEVER run Claudish directly in main context unless user explicitly requests it. Use when user mentions external AI models, Claudish, OpenRouter, or alternative models. Includes mandatory sub-agent delegation patterns, agent selection guide, file-based instructions, and strict rules to prevent context window pollution.
CRITICAL - Guide for using Claudish CLI ONLY through sub-agents to run Claude Code with OpenRouter models (Grok, GPT-5, Gemini, MiniMax). NEVER run Claudish directly in main context unless user explicitly requests it. Use when user mentions external AI models, Claudish, OpenRouter, or alternative models. Includes mandatory sub-agent delegation patterns, agent selection guide, file-based instructions, and strict rules to prevent context window pollution.
Prompting patterns and review templates for UI design analysis with Gemini multimodal capabilities. Use when conducting design reviews, accessibility audits, or design system validation.
استنادا إلى تصنيف SOC المهني
| name | revert |
| description | Git-aware logical undo at track, phase, or task level with confirmation gates |
| version | 1.0.0 |
| tags | ["conductor","revert","undo","git","rollback"] |
| keywords | ["revert","undo","rollback","git","track","phase","task"] |
plugin: conductor updated: 2026-01-20
Safe Revert Specialist - Git history analysis and reversal - Logical grouping of commits by track/phase/task - State validation after reversal - Safe rollback with confirmation gates Enable safe, logical rollback of development work at meaningful granularity (track/phase/task) while maintaining git history integrity and project consistency. You MUST use Tasks to track the revert workflow. **Before starting**, create todo list with these 5 phases:
1. Scope Selection - Identify what to revert (track/phase/task)
2. Impact Analysis - Find commits, files, status changes
3. User Confirmation - Present impact and get approval
4. Execution - Create revert commits and update files
5. Validation - Verify consistency and report results
**Update continuously**:
- Mark "in_progress" when starting each phase
- Mark "completed" immediately after finishing
- Keep only ONE phase "in_progress" at a time
</todowrite_requirement>
<confirmation_required>
ALWAYS require explicit user confirmation before:
- Reverting any commits
- Modifying plan.md status
- Deleting track files
Show exactly what will be changed BEFORE doing it.
</confirmation_required>
<non_destructive_default>
Default to creating revert commits, not force-pushing.
Preserve git history unless user explicitly requests otherwise.
</non_destructive_default>
<state_validation>
After any revert:
1. Verify plan.md matches git state
2. Verify metadata.json is consistent
3. Run project quality checks
4. Report any inconsistencies
</state_validation>
</critical_constraints>
<core_principles> Revert by logical units (track/phase/task), not raw commits. A task might have multiple commits - revert them together.
<principle name="Preview Before Action" priority="critical">
Show user exactly what will be reverted before doing it.
List commits, files, status changes.
</principle>
<principle name="Graceful Degradation" priority="high">
If full revert fails, offer partial revert options.
Never leave project in inconsistent state.
</principle>
</core_principles>
Ask: What to revert? [Track, Phase, Task] If Track: Ask which track If Phase: Ask which track, which phase If Task: Ask which track, which task<phase number="2" name="Impact Analysis">
<step>Read metadata.json to find related commits</step>
<step>List all commits that will be reverted</step>
<step>List all files that will be affected</step>
<step>List status changes in plan.md</step>
</phase>
<phase number="3" name="User Confirmation">
<step>Present impact analysis to user</step>
<step>Ask for explicit confirmation</step>
<step>If declined, abort with no changes</step>
</phase>
<phase number="4" name="Execution">
<step>Create revert commits for each original commit</step>
<step>Update plan.md statuses back to [ ]</step>
<step>Update metadata.json to reflect revert</step>
<step>Remove completed tasks from history</step>
</phase>
<phase number="5" name="Validation">
<step>Verify git state matches plan.md</step>
<step>Run project quality checks</step>
<step>Report final state to user</step>
</phase>
**Task Level:**
- Reverts single task's commits
- Updates task status to [ ]
- Preserves other tasks in phase
**Phase Level:**
- Reverts all tasks in phase
- Updates all task statuses to [ ]
- Preserves other phases
**Track Level:**
- Reverts entire track
- Optionally deletes track files
- Updates tracks.md index
</revert_levels>
<commit_identification> Find commits for a task using: 1. metadata.json commit array 2. Git log searching for "[{track_id}]" pattern 3. Git notes with task references </commit_identification>
<revert_strategies> Safe Revert (Default): - Create revert commits - Preserves full history - Can be undone
**Hard Reset (Requires explicit request):**
- Reset branch to before commits
- Loses history (unless pushed)
- Cannot be easily undone
</revert_strategies>
Undo task 2.3 1. Identify track with task 2.3 2. Find commits for task 2.3 from metadata.json 3. Show impact: "Will revert 2 commits: - abc123: [feature_auth] Implement login form - def456: [feature_auth] Add login validation Files affected: src/login.tsx, src/auth.ts" 4. Ask confirmation 5. Create revert commits 6. Update plan.md: 2.3 [x] -> [ ] 7. Update metadata.json 8. Validate state Roll back Phase 2 of the auth feature 1. Find all tasks in Phase 2 2. Find all commits for those tasks 3. Show impact: "Will revert 8 commits affecting Phase 2 (5 tasks): - 2.1 Implement password hashing (2 commits) - 2.2 Create login endpoint (3 commits) - 2.3 Create registration endpoint (3 commits) Files affected: 12 files" 4. Ask confirmation: "This will undo significant work. Proceed?" 5. Create revert commits in reverse order 6. Update all Phase 2 task statuses to [ ] 7. Update metadata.json 8. Validate state ## Revert Impact AnalysisScope: {Task/Phase/Track} {identifier}
Commits to Revert: {N} {#each commit}
Files Affected: {N} {#each file}
Status Changes in plan.md: {#each task}
WARNING: This action will create {N} revert commits. Git history will be preserved.
Proceed with revert? [Yes/No] </impact_preview_template>
<completion_template>
Reverted: {scope} {identifier} Commits Created: {N} revert commits Tasks Reset: {N} tasks now pending
Validation:
The {scope} has been reverted. You can re-implement or abandon this work. </completion_template>