github/penpot
1
0
Fork 0
mirror of https://github.com/penpot/penpot.git synced 2026-06-18 05:12:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/main' into staging

Browse Source
This commit is contained in:
Andrey Antukh 2026-06-17 19:13:16 +02:00
commit fe9598f96c
4 changed files with 111 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

89
.opencode/skills/create-pr/SKILL.md
View File

@ -1,28 +1,33 @@
---
name: create-pr
description: Create a GitHub PR following Penpot conventions, with a concise engineer-focused description
description: Create or update a GitHub PR following Penpot conventions, with a concise engineer-focused description
---
# Create Pull Request
# Pull Request (Create or Update)
Create a GitHub PR with proper title format and a concise description that explains reasoning, not implementation details.
Create or update a GitHub PR with proper title format and a concise description that explains reasoning, not implementation details.
## When to Use
- Opening a new pull request
- The user asks to create a PR
- Updating an existing PR's title or description
- The user asks to create or update a PR
- Code changes are ready and committed
## Workflow
## Conventions
### 1. Verify Prerequisites
All PR conventions (title format, body structure, writing principles, what NOT to include) are documented in `mem:workflow/creating-prs`. This skill covers the procedure only.
## Workflow A: Creating a New PR
### A1. Verify Prerequisites
```bash
git branch --show-current
git log --oneline main..HEAD
```
### 2. Check if Branch is Pushed
### A2. Check if Branch is Pushed
```bash
BRANCH=$(git branch --show-current)
@ -36,13 +41,13 @@ fi
**If the branch is not pushed, STOP here and ask the user to push it. The LLM does not have push permissions.**
### 3. Create PR Body
### A3. Create PR Body
Write to `/tmp/pr-body.md` to avoid shell quoting issues:
Write the body to `/tmp/pr-body.md` using the template from `mem:workflow/creating-prs` (Description Body section):
```bash
cat > /tmp/pr-body.md << 'EOF'
**Note:** This PR was created with AI assistance.
**Note:** This PR was created with AI assistance as part of the Penpot MCP self-improvement initiative.
## What
@ -58,24 +63,62 @@ cat > /tmp/pr-body.md << 'EOF'
EOF
```
### 4. Create the PR
Follow title and description format from `mem:workflow/creating-prs` and `mem:workflow/creating-commits`.
### A4. Create the PR
```bash
gh pr create --base main --project "Main" --title "<title>" --body-file /tmp/pr-body.md
```
### 5. What NOT to Include
---
- ❌ List of files changed (visible in diff)
- ❌ Testing steps (CI handles this)
- ❌ Screenshots unless UI-visible
- ❌ Migration notes unless breaking changes
- ❌ Regression fixes introduced during the PR (they're part of the development process, not the feature)
## Workflow B: Updating an Existing PR
## Key Principles
Use this when a PR already exists and you need to change its title or description (or both).
- **Write for humans.** The diff shows what changed. The description explains why.
- **Be concise.** Focus on reasoning: What was the problem? Why did it happen? How did you solve it?
- **Skip the obvious.** Don't explain what `git diff` already shows.
### B1. Find the PR Number
```bash
BRANCH=$(git branch --show-current)
gh pr list --head "$BRANCH" --state open --json number --jq '.[0].number'
```
If the result is empty, there is no open PR for this branch — use Workflow A instead.
If multiple PRs match, pick the first one (typically there should only be one).
### B2. Determine What to Update
- **Title only:** use `--title "<new title>"`
- **Description (body) only:** write to `/tmp/pr-body.md` and use `--body-file /tmp/pr-body.md`
- **Both title and description:** supply both flags
### B3. Prepare Description (if updating)
Use the same template from `mem:workflow/creating-prs`:
```bash
cat > /tmp/pr-body.md << 'EOF'
**Note:** This PR was created with AI assistance as part of the Penpot MCP self-improvement initiative.
## What
<one paragraph: the problem or feature, user-facing impact>
## Why
<root cause or motivation, why this change was necessary>
## How
<high-level approach, key technical decisions>
EOF
```
### B4. Update the PR
```bash
gh pr edit <NUMBER> --title "<title>" --body-file /tmp/pr-body.md
```
Omit either flag if only one field is being updated.
**The LLM has permissions to edit PRs. No push required.**

2
.serena/memories/workflow/creating-commits.md
View File

@ -15,7 +15,7 @@ automatically pull the identity from the local git config `user.name` and `user.
Body explaining what changed and why.
Co-authored-by: <You (the LLM)>
Co-authored-by: model-name <model-name@penpot.app>
```
## Commit Type Emojis

40
.serena/memories/workflow/creating-prs.md
View File

@ -12,7 +12,7 @@ PR titles follow commit title conventions:
See `mem:workflow/creating-commits` for emoji codes. Squash merge uses the PR title as the final commit subject, so title format matters.
## Description
## Description Body
Include concise sections covering:
- what changed and why;
@ -21,12 +21,42 @@ Include concise sections covering:
- testing performed and residual risk;
- breaking changes or migration notes, if any.
PR descriptions are expected to start with:
PR descriptions follow this structure:
> **Note:** This PR was created with AI assistance as part of the Penpot MCP self-improvement initiative.
```markdown
**Note:** This PR was created with AI assistance as part of the Penpot MCP self-improvement initiative.
## What
<one paragraph: the problem or feature, user-facing impact>
## Why
<root cause or motivation, why this change was necessary>
## How
<high-level approach, key technical decisions>
```
The "Note:" line is required at the top. Adjust if this is a manual (non-AI) PR.
## Writing Principles
- **Write for humans.** The diff shows what changed. The description explains why.
- **Be concise.** Focus on reasoning: What was the problem? Why did it happen? How did you solve it?
- **Skip the obvious.** Don't explain what `git diff` already shows.
### What NOT to Include
- ❌ List of files changed (visible in diff)
- ❌ Testing steps (CI handles this)
- ❌ Screenshots unless UI-visible
- ❌ Migration notes unless breaking changes
- ❌ Regression fixes introduced during the PR (they're part of the development process, not the feature)
## Before Opening
- Follow `mem:workflow/creating-commits` for changelog expectations.
- Follow `mem:workflow/creating-commits` for commits
- Run the focused tests/lints appropriate to touched modules.
- Do not force-push during review unless the maintainer workflow explicitly asks for it.
- Do not force-push during review unless the maintainer workflow explicitly asks for it.

14
docs/user-guide/first-steps/troubleshooting-webgl.njk
View File

@ -1,18 +1,20 @@
---
title: Troubleshooting WebGL
order: 5
desc: Diagnose and fix common WebGL issues in Penpot with browser, GPU, and system checks so you can open the workspace canvas correctly.
desc: Diagnose and fix common WebGL issues in Penpot, enable WebGL rendering (Beta), and troubleshoot browser, GPU, and system checks.
---
<h1 id="troubleshooting-webgl">Troubleshooting WebGL</h1>
<div class="advice">
<h3>Availability note</h3>
<p>WebGL renderer is currently not available yet in Penpot production (<code>design.penpot.app</code>).</p>
<p>Right now, this renderer is available only in <strong>testing environments</strong>. It is planned for an upcoming release and should be available soon.</p>
<h3>WebGL rendering (Beta)</h3>
<p>Since <strong>Penpot 2.16</strong>, optional <strong>WebGL rendering (Beta)</strong> is available on <code>design.penpot.app</code> and self-hosted instances. It is <strong>off by default</strong>.</p>
<p>Turn it on from <strong>Your account → Settings</strong> or <strong>Workspace → Main menu → Preferences</strong> when you want a faster canvas for complex files.</p>
<p>In this beta, WebGL applies to the <strong>design workspace canvas</strong> only. View mode and exports still use the legacy renderer, so some visual differences are expected. If the beta gets in your way, you can switch back to the legacy renderer at any time.</p>
<p>For what is in scope today, what we are prioritizing next, and known visual differences, read <a href="https://community.penpot.app/t/whats-next-for-the-penpot-webgl-renderer/10627" target="_blank">What's next for the Penpot WebGL renderer</a> on the Penpot Community.</p>
</div>
<p class="main-paragraph">Penpot uses WebGL to render the design canvas. If WebGL is unavailable, Penpot cannot open the workspace canvas correctly.</p>
<p class="main-paragraph">When WebGL rendering (Beta) is enabled, Penpot uses WebGL to render the design workspace canvas. If WebGL is unavailable in your browser, Penpot cannot use that renderer and the workspace canvas may not open correctly.</p>
<p>Sometimes WebGL appears enabled in your browser, but Penpot still cannot create a graphics context. This is usually related to browser settings, GPU acceleration, drivers, or temporary GPU overload.</p>
@ -96,8 +98,10 @@ desc: Diagnose and fix common WebGL issues in Penpot with browser, GPU, and syst
<p>If this is your setup, collect diagnostics and contact support.</p>
<h2>If the issue persists</h2>
<p>If WebGL rendering (Beta) is blocking your work, turn it off in <strong>Your account → Settings</strong> or <strong>Workspace → Preferences</strong> and continue on the legacy renderer while you report the issue.</p>
<p>Please share:</p>
<ul>
<li>Whether WebGL rendering (Beta) is enabled or disabled.</li>
<li>Browser and version.</li>
<li>Operating system and version.</li>
<li>Result from <a href="https://get.webgl.org/" target="_blank">https://get.webgl.org</a>.</li>