📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
+1
-1
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "agentic-bundle-oss-maintainer",
|
||||
"version": "14.6.0",
|
||||
"version": "15.1.0",
|
||||
"description": "Editorial \"OSS Maintainer\" bundle for Claude Code from Agentic Awesome Skills.",
|
||||
"author": {
|
||||
"name": "sickn33 and contributors",
|
||||
|
||||
+3
-3
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "aasb-oss-maintainer",
|
||||
"version": "14.6.0",
|
||||
"version": "15.1.0",
|
||||
"description": "Install the \"OSS Maintainer\" editorial skill bundle from Agentic Awesome Skills.",
|
||||
"author": {
|
||||
"name": "sickn33 and contributors",
|
||||
@@ -19,8 +19,8 @@
|
||||
"skills": "./skills/",
|
||||
"interface": {
|
||||
"displayName": "OSS Maintainer",
|
||||
"shortDescription": "Maintainer & OSS · 8 curated skills",
|
||||
"longDescription": "For shipping clean changes in public repositories. Covers Commit, Create PR, and 6 more skills.",
|
||||
"shortDescription": "Maintainer & OSS · 10 curated skills",
|
||||
"longDescription": "For shipping clean changes in public repositories. Covers Commit, Create Branch, and 8 more skills.",
|
||||
"developerName": "sickn33 and contributors",
|
||||
"category": "Maintainer & OSS",
|
||||
"capabilities": [
|
||||
|
||||
+119
@@ -0,0 +1,119 @@
|
||||
---
|
||||
name: create-branch
|
||||
description: Create a git branch following Sentry naming conventions. Use when asked to "create a branch", "new branch", "start a branch", "make a branch", "switch to a new branch", or when starting new work on the default branch.
|
||||
argument-hint: '[optional description of the work]'
|
||||
risk: critical
|
||||
source: community
|
||||
---
|
||||
|
||||
# Create Branch
|
||||
|
||||
Create a git branch with the correct type prefix and a descriptive name following Sentry conventions.
|
||||
|
||||
## When to Use
|
||||
- You need to create a new git branch that follows the repository's naming convention.
|
||||
- You are starting a new piece of work from the default branch and need help classifying it as `feat`, `fix`, `docs`, or another branch type.
|
||||
- You want the branch name proposed from either the task description or the current local diff.
|
||||
|
||||
## Step 1: Get the Username Prefix
|
||||
|
||||
Run `gh api user --jq .login` to get the GitHub username.
|
||||
|
||||
If the command fails (e.g. not authenticated), ask the user for their preferred prefix.
|
||||
|
||||
## Step 2: Determine the Branch Description
|
||||
|
||||
**If `$ARGUMENTS` is provided**, use it as the description of the work.
|
||||
|
||||
**If no arguments**, check for local changes:
|
||||
|
||||
```bash
|
||||
git diff
|
||||
git diff --cached
|
||||
git status --short
|
||||
```
|
||||
|
||||
- **Changes exist**: read the diff content to understand what the work is about and generate a description.
|
||||
- **No changes**: ask the user what they are about to work on.
|
||||
|
||||
## Step 3: Classify the Type
|
||||
|
||||
Pick the type from this table based on the description:
|
||||
|
||||
| Type | Use when |
|
||||
| --------- | --------------------------------------------------------------------- |
|
||||
| `feat` | New user-facing functionality |
|
||||
| `fix` | Broken behavior now works |
|
||||
| `ref` | Same behavior, different structure |
|
||||
| `chore` | Deps, config, version bumps, updating existing tooling — no new logic |
|
||||
| `perf` | Same behavior, faster |
|
||||
| `style` | CSS, formatting, visual-only |
|
||||
| `docs` | Documentation only |
|
||||
| `test` | Tests only |
|
||||
| `ci` | CI/CD config |
|
||||
| `build` | Build system |
|
||||
| `meta` | Repo metadata changes |
|
||||
| `license` | License changes |
|
||||
|
||||
When unsure: `feat` for new things (including new scripts, skills, or tools), `ref` for restructuring existing things, `chore` only when updating/maintaining something that already exists.
|
||||
|
||||
## Step 4: Generate and Propose
|
||||
|
||||
Build the branch name as `<username>/<type>/<short-description>`.
|
||||
|
||||
Rules for `<short-description>`:
|
||||
|
||||
- Kebab-case, lowercase
|
||||
- 3 to 6 words, concise but clear
|
||||
- Describe the change, not file names
|
||||
- Only use ASCII letters, digits, and hyphens — no spaces, dots, colons, tildes, or other git-forbidden characters
|
||||
|
||||
Present it to the user and ask if they want to use it, modify it, or change the type.
|
||||
|
||||
### Examples
|
||||
|
||||
| Work description | Branch name |
|
||||
| ------------------------------------------ | ------------------------------------------- |
|
||||
| Dropdown menu not closing on outside click | `priscila/fix/dropdown-not-closing-on-blur` |
|
||||
| Adding search to conversations page | `priscila/feat/add-search-to-conversations` |
|
||||
| Restructuring drawer components | `priscila/ref/simplify-drawer-components` |
|
||||
| Updating test fixtures | `priscila/chore/update-test-fixtures` |
|
||||
| Bumping @sentry/react to latest version | `priscila/chore/bump-sentry-react` |
|
||||
| Adding a new agent skill | `priscila/feat/add-create-branch-skill` |
|
||||
|
||||
## Step 5: Create the Branch
|
||||
|
||||
Once confirmed, detect the current and default branch:
|
||||
|
||||
```bash
|
||||
git branch --show-current
|
||||
git remote | grep -qx origin && echo origin || git remote | head -1
|
||||
git symbolic-ref refs/remotes/<remote>/HEAD 2>/dev/null | sed 's|refs/remotes/<remote>/||' | tr -d '[:space:]'
|
||||
```
|
||||
|
||||
If `symbolic-ref` fails, fall back to `git branch --list main master`: use the one that exists; if both or neither exist, ask the user.
|
||||
|
||||
If `git branch --show-current` is empty (detached HEAD), show the current commit (`git rev-parse --short HEAD`) and ask whether to branch from it or switch to the default branch first.
|
||||
|
||||
Otherwise, if the current branch is not the default branch, warn the user and ask whether to branch from the current branch or switch to the default branch first.
|
||||
|
||||
If the user wants to switch to the default branch, handle any uncommitted changes appropriately (offer to stash them if present), then run `git checkout <default-branch>`. On any failure, restore stashed changes if applicable and stop.
|
||||
|
||||
Before creating the branch, check that the name doesn't already exist locally or on the remote (`git show-ref`). If it does, ask the user to choose a different name.
|
||||
|
||||
Create the branch:
|
||||
|
||||
```bash
|
||||
git checkout -b <branch-name>
|
||||
```
|
||||
|
||||
Restore any stashed changes after the branch is created.
|
||||
|
||||
## References
|
||||
|
||||
- [Sentry Branch Naming](https://develop.sentry.dev/sdk/getting-started/standards/code-submission/#branch-naming)
|
||||
|
||||
## Limitations
|
||||
- Use this skill only when the task clearly matches the scope described above.
|
||||
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
|
||||
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
|
||||
+4
-4
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: create-pr
|
||||
description: Alias for sentry-skills:pr-writer. Use when users explicitly ask for "create-pr" or reference the legacy skill name. Redirects to the canonical PR writing workflow.
|
||||
description: Alias for pr-writer. Use when users explicitly ask for "create-pr" or reference the legacy skill name. Redirects to the canonical PR writing workflow.
|
||||
risk: unknown
|
||||
source: community
|
||||
---
|
||||
@@ -11,12 +11,12 @@ This skill name is kept for compatibility.
|
||||
|
||||
## When to Use
|
||||
- The user explicitly asks for `create-pr` or refers to the legacy skill name.
|
||||
- You need to redirect pull request creation work to the canonical `sentry-skills:pr-writer` workflow.
|
||||
- You need to redirect pull request creation work to the canonical `pr-writer` workflow.
|
||||
- The task is specifically about writing or updating a pull request rather than general git operations.
|
||||
|
||||
Use `sentry-skills:pr-writer` as the canonical skill for creating and editing pull requests.
|
||||
Use the available `pr-writer` skill as the canonical workflow for creating and editing pull requests. If the client requires qualified skill names, use the qualifier for the plugin that supplied this skill rather than assuming an external namespace.
|
||||
|
||||
If invoked via `create-pr`, run the same workflow and conventions documented in `sentry-skills:pr-writer`.
|
||||
If invoked via `create-pr`, run the same workflow and conventions documented in `pr-writer`.
|
||||
|
||||
## Limitations
|
||||
- Use this skill only when the task clearly matches the scope described above.
|
||||
|
||||
+1
-11
@@ -20,9 +20,8 @@ Master advanced Git techniques to maintain clean history, collaborate effectivel
|
||||
- Clarify goals, constraints, and required inputs.
|
||||
- Apply relevant best practices and validate outcomes.
|
||||
- Provide actionable steps and verification.
|
||||
- If detailed examples are required, open `resources/implementation-playbook.md`.
|
||||
|
||||
## Use this skill when
|
||||
## When to Use
|
||||
|
||||
- Cleaning up commit history before merging
|
||||
- Applying specific commits across branches
|
||||
@@ -405,15 +404,6 @@ git reflog
|
||||
git branch recovered-branch abc123
|
||||
```
|
||||
|
||||
## Resources
|
||||
|
||||
- **references/git-rebase-guide.md**: Deep dive into interactive rebase
|
||||
- **references/git-conflict-resolution.md**: Advanced conflict resolution strategies
|
||||
- **references/git-history-rewriting.md**: Safely rewriting Git history
|
||||
- **assets/git-workflow-checklist.md**: Pre-PR cleanup checklist
|
||||
- **assets/git-aliases.md**: Useful Git aliases for advanced workflows
|
||||
- **scripts/git-clean-branches.sh**: Clean up merged and stale branches
|
||||
|
||||
## Limitations
|
||||
- Use this skill only when the task clearly matches the scope described above.
|
||||
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
|
||||
|
||||
+195
@@ -0,0 +1,195 @@
|
||||
---
|
||||
name: pr-writer
|
||||
description: "Create pull requests following Sentry's engineering practices."
|
||||
risk: unknown
|
||||
source: community
|
||||
---
|
||||
|
||||
# PR Writer
|
||||
|
||||
Create pull requests following Sentry's engineering practices.
|
||||
|
||||
**Requires**: GitHub CLI (`gh`) authenticated and available.
|
||||
|
||||
## When to Use
|
||||
- You are ready to open a pull request and need a structured description based on the committed branch diff.
|
||||
- You want the PR body to capture what changed, why it changed, and any reviewer context.
|
||||
- You are using GitHub CLI and need a repeatable PR-writing workflow rather than writing the description ad hoc.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before creating a PR, ensure all changes are committed. If there are uncommitted changes, run the available `commit` skill first to commit them properly.
|
||||
|
||||
```bash
|
||||
# Check for uncommitted changes
|
||||
git status --porcelain
|
||||
```
|
||||
|
||||
If the output shows any uncommitted changes (modified, added, or untracked files that should be included), invoke the available `commit` skill before proceeding. If the client requires qualified skill names, use the qualifier for the plugin that supplied this skill.
|
||||
|
||||
## Process
|
||||
|
||||
### Step 1: Verify Branch State
|
||||
|
||||
```bash
|
||||
# Detect the default branch — note the output for use in subsequent commands
|
||||
gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'
|
||||
```
|
||||
|
||||
```bash
|
||||
# Check current branch and status (substitute the detected branch name above for BASE)
|
||||
git status
|
||||
git log BASE..HEAD --oneline
|
||||
```
|
||||
|
||||
Ensure:
|
||||
- All changes are committed
|
||||
- Branch is up to date with remote
|
||||
- Changes are rebased on the base branch if needed
|
||||
|
||||
### Step 2: Analyze Changes
|
||||
|
||||
Review what will be included in the PR:
|
||||
|
||||
```bash
|
||||
# See all commits that will be in the PR (substitute detected branch name for BASE)
|
||||
git log BASE..HEAD
|
||||
|
||||
# See the full diff
|
||||
git diff BASE...HEAD
|
||||
```
|
||||
|
||||
Understand the scope and purpose of all changes before writing the description.
|
||||
|
||||
### Step 3: Write the PR Description
|
||||
|
||||
Use this structure for PR descriptions (ignoring any repository PR templates):
|
||||
|
||||
```markdown
|
||||
<brief description of what the PR does>
|
||||
|
||||
<why these changes are being made - the motivation>
|
||||
|
||||
<alternative approaches considered, if any>
|
||||
|
||||
<any additional context reviewers need>
|
||||
```
|
||||
|
||||
**Do NOT include:**
|
||||
- "Test plan" sections
|
||||
- Checkbox lists of testing steps
|
||||
- Redundant summaries of the diff
|
||||
|
||||
**Do include:**
|
||||
- Clear explanation of what and why
|
||||
- Links to relevant issues or tickets
|
||||
- Context that isn't obvious from the code
|
||||
- Notes on specific areas that need careful review
|
||||
|
||||
### Step 4: Create the PR
|
||||
|
||||
```bash
|
||||
gh pr create --draft --title "<type>(<scope>): <description>" --body "$(cat <<'EOF'
|
||||
<description body here>
|
||||
EOF
|
||||
)"
|
||||
```
|
||||
|
||||
**Title format** follows commit conventions:
|
||||
- `feat(scope): Add new feature`
|
||||
- `fix(scope): Fix the bug`
|
||||
- `ref: Refactor something`
|
||||
|
||||
## PR Description Examples
|
||||
|
||||
### Feature PR
|
||||
|
||||
```markdown
|
||||
Add Slack thread replies for alert notifications
|
||||
|
||||
When an alert is updated or resolved, we now post a reply to the original
|
||||
Slack thread instead of creating a new message. This keeps related
|
||||
notifications grouped and reduces channel noise.
|
||||
|
||||
Previously considered posting edits to the original message, but threading
|
||||
better preserves the timeline of events and works when the original message
|
||||
is older than Slack's edit window.
|
||||
|
||||
Refs SENTRY-1234
|
||||
```
|
||||
|
||||
### Bug Fix PR
|
||||
|
||||
```markdown
|
||||
Handle null response in user API endpoint
|
||||
|
||||
The user endpoint could return null for soft-deleted accounts, causing
|
||||
dashboard crashes when accessing user properties. This adds a null check
|
||||
and returns a proper 404 response.
|
||||
|
||||
Found while investigating SENTRY-5678.
|
||||
|
||||
Fixes SENTRY-5678
|
||||
```
|
||||
|
||||
### Refactor PR
|
||||
|
||||
```markdown
|
||||
Extract validation logic to shared module
|
||||
|
||||
Moves duplicate validation code from the alerts, issues, and projects
|
||||
endpoints into a shared validator class. No behavior change.
|
||||
|
||||
This prepares for adding new validation rules in SENTRY-9999 without
|
||||
duplicating logic across endpoints.
|
||||
```
|
||||
|
||||
## Issue References
|
||||
|
||||
Reference issues in the PR body:
|
||||
|
||||
| Syntax | Effect |
|
||||
|--------|--------|
|
||||
| `Fixes #1234` | Closes GitHub issue on merge |
|
||||
| `Fixes SENTRY-1234` | Closes Sentry issue |
|
||||
| `Refs GH-1234` | Links without closing |
|
||||
| `Refs LINEAR-ABC-123` | Links Linear issue |
|
||||
|
||||
## Guidelines
|
||||
|
||||
- **One PR per feature/fix** - Don't bundle unrelated changes
|
||||
- **Keep PRs reviewable** - Smaller PRs get faster, better reviews
|
||||
- **Explain the why** - Code shows what; description explains why
|
||||
- **Mark WIP early** - Use draft PRs for early feedback
|
||||
|
||||
## Editing Existing PRs
|
||||
|
||||
If you need to update a PR after creation, use `gh api` instead of `gh pr edit`:
|
||||
|
||||
```bash
|
||||
# Update PR description
|
||||
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f body="$(cat <<'EOF'
|
||||
Updated description here
|
||||
EOF
|
||||
)"
|
||||
|
||||
# Update PR title
|
||||
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER -f title='new: Title here'
|
||||
|
||||
# Update both
|
||||
gh api -X PATCH repos/{owner}/{repo}/pulls/PR_NUMBER \
|
||||
-f title='new: Title' \
|
||||
-f body='New description'
|
||||
```
|
||||
|
||||
Note: `gh pr edit` is currently broken due to GitHub's Projects (classic) deprecation.
|
||||
|
||||
## References
|
||||
|
||||
- [Sentry Code Review Guidelines](https://develop.sentry.dev/engineering-practices/code-review/)
|
||||
- [Sentry Commit Messages](https://develop.sentry.dev/engineering-practices/commit-messages/)
|
||||
|
||||
## Limitations
|
||||
- Use this skill only when the task clearly matches the scope described above.
|
||||
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
|
||||
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.
|
||||
Reference in New Issue
Block a user