| name | experimental-pr-workflow |
| description | Retroactively create Linear tickets and PRs from untracked commits. Use for commits without tickets, "founder mode", or formalizing experimental work. |
| allowed-tools | Read, Bash, Grep, Glob, Write |
Experimental PR Workflow
When to Use This Skill
Activate this skill when:
- User mentions "founder mode" or references rapid experimentation
- User has made commits without associated tickets
- User asks to "formalize experimental work" or "create ticket for this"
- You detect commits on a feature branch without ticket references
- User asks to "clean up" or "properly document" exploratory work
This skill helps transition from rapid prototyping to proper workflow hygiene.
The Problem This Solves
Sometimes you need to move fast and experiment without the overhead of creating tickets and planning docs first. This is great for exploration, but eventually you need to:
- Document what you built and why
- Create a proper ticket for tracking
- Get the work into a reviewable PR
- Follow the team's standard workflow
This skill handles that transition retroactively.
Core Process
Step 1: Verify Commit Exists
Check recent commits:
git log --oneline -5
If no recent commits, help create one first or review current changes.
Step 2: Understand What Was Built
Gather context from the commit:
git show --stat HEAD
git show HEAD
Analyze the changes:
- What files were modified?
- What functionality was added/changed?
- What problem does this solve?
- What technical decisions were made?
Step 3: Create Ticket (if using a ticket system)
Create a ticket describing the work:
## Problem to Solve
[Describe the user need or pain point from a user perspective]
## Proposed Solution
[Describe what you implemented]
[Explain the technical approach taken]
## Implementation Notes
- [Key file/component modified]
- [Technical decision made]
## References
- Commit: [SHA]
- Branch: [current branch name]
Important: You MUST gather a "Problem to Solve" - don't just document implementation.
Step 4: Create Proper Git Branch
Ensure you're on main first:
git checkout main
Create the new branch with proper naming:
git checkout -b [TICKET-ID]-[description]
Cherry-pick your experimental commit(s):
git cherry-pick [COMMIT_SHA]
Step 5: Push and Create PR
Push the branch to remote:
git push -u origin [BRANCH_NAME]
Create the pull request:
gh pr create --fill
Step 6: Generate PR Description
Hand off to the pr-description-generator skill to create a comprehensive PR description.
Key Principles
1. Problem-First Thinking
Even though the solution is already implemented, focus on articulating the problem clearly.
Bad:
Problem: Need Redis caching
Solution: Added Redis caching
Good:
Problem: Dashboard loads take 3-5 seconds due to repeated database queries.
Users report slow experience especially during peak hours.
Solution: Implemented Redis-based caching for frequently accessed dashboard
data with 5-minute TTL. Reduces response times to under 500ms.
2. Preserve Git History
Always use cherry-pick to move commits to the new branch, never rewrite history with rebase unless absolutely necessary.
3. Clean Transition
The goal is to make it look like proper process was followed:
- Ticket exists and is tracked
- Branch name follows convention
- PR has comprehensive description
- All verification steps are documented
4. Don't Skip Understanding
Even if the code is already written, take time to understand:
- What problem it solves
- Why this approach
- What the tradeoffs are
- How it impacts users
Variations and Edge Cases
Multiple Experimental Commits
git log main..HEAD --oneline
git checkout main
git checkout -b [BRANCH_NAME]
git cherry-pick [FIRST_SHA]^..[LAST_SHA]
Already on Feature Branch (poorly named)
git checkout main
git checkout -b [NEW_BRANCH_NAME]
git cherry-pick main..[OLD_BRANCH_NAME]
git push -u origin [NEW_BRANCH_NAME]
No Ticket System
Skip ticket creation, focus on proper branch naming and PR description.
Success Criteria
You've succeeded when:
- Ticket exists with clear problem statement (if using ticket system)
- Branch name follows team convention
- PR is created and linked to ticket
- PR has comprehensive description
- Commit history is preserved correctly
- Everything is pushed to remote
Notes
- This skill enables fast iteration while maintaining eventual consistency with process
- It's a "get out of jail free" card for exploratory work
- Don't abuse it - proper planning upfront is still better when possible
- The skill automates the tedious cleanup work of formalizing experiments
