mirror of https://github.com/penpot/penpot.git synced 2026-09-17 01:16:13 +00:00

Andrey Antukh fbfef42145 ♻️ Move skills and plans to .agents for cross-tool use

.agents is the shared home that opencode, Claude Code (through the
.claude/skills symlink) and Codex all read, so the skills and the
saved plans now live there instead of .opencode:

- .opencode/skills moved to .agents/skills (24 files, no content
  changes).
- .opencode/plans moved to .agents/plans; the .gitignore entry
  follows, so plans stay untracked.
- .claude/skills symlink retargeted to ../.agents/skills.
- planner, make-a-plan and review-plan updated to the new plans path;
  new .agents/README.md documents every skill with when-to-use
  examples and links to each SKILL.md.
- workflow/creating-issues memory: create-issue path updated.

opencode discovers .agents/skills natively, so .opencode needs no
reciprocal link.

AI-assisted-by: omen-alpha

2026-09-08 19:40:38 +00:00

3.0 KiB

Raw Blame History

name, description

name	description
resolve-git-conflicts	Conflict resolution flow — understand the local git conflicts, present a resolution plan, and resolve them after the user approves it. Never continues the rebase. Use it when the repo has unresolved conflicts (rebase, merge, cherry-pick) or the user asks to resolve them.

Resolve Git Conflicts

Resolve conflicts in the local repository. The user handles finishing the rebase themselves — you must never run git rebase --continue, git rebase --skip, git merge --continue, or anything similar.

When to use

The repository has unresolved conflicts — during a rebase, merge, or cherry-pick — whether the user asks about them or not.
The user asks to resolve conflicts, in any phrasing: "fix the merge conflicts", "resolve these", "what's conflicting here?".

Phase 1 — Understand the problem (read-only)

Run git status to detect the conflict state (rebase, merge, cherry-pick, etc.) and list conflicted files.
For each conflicted (unmerged) file, understand the situation without modifying anything:
- Read the file and identify the conflict markers (<<<<<<<, =======, >>>>>>>).
- Inspect both sides — git show <ours>:<file> and git show <theirs>:<file> — plus git log/git show on the commits involved to understand intent.
- Identify what each side changed and why, and how they should be combined.

Phase 2 — Present the resolution plan

Present a clear plan to the user before touching any file. For each conflicted file, state:
- What each side changed and why.
- Your proposed resolution and the reasoning behind it.
- How the two sides are combined (both additive → merge; both modify the same code → keep the semantically correct version, merging intent from both sides when clear from code and context).
Ask the user only when genuinely unclear. Do not ask about anything you can determine yourself from the code, commit messages, or context. Only decisions that are not determinable and change the outcome (e.g. conflicting product decisions, which side to discard) warrant a question. Collect all such questions together in an "Open Questions" section at the end of the plan, so the user has full context to answer them properly.
Wait for the user to accept the plan (and answer any open questions) before editing, staging, or otherwise modifying anything.

Phase 3 — Execute

Resolve each conflicted file by editing the file to the agreed merged content and removing all conflict markers.

Phase 4 — Stage and verify

Stage every resolved file with git add <file>. Do not stage unrelated untracked files unless clearly part of the resolution.
Verify no conflict markers remain (search for <<<<<<< / >>>>>>> in resolved files) and that git status shows no unmerged paths.

Phase 5 — Report

Briefly report the conflict state, how each conflicted file was resolved (and any answers received to open questions), and stop — do not run git rebase --continue or any other continuation command.

3.0 KiB Raw Blame History