positron-issue-creator
This skill should be used when drafting GitHub issues for the Positron repository. It provides workflows for searching duplicates, selecting appropriate labels, gathering complete context through questioning, and writing terse, fluff-free issues that precisely describe what is needed or wrong. The skill prepares issues for manual submission by the user. Use this skill when the user asks to draft or prepare an issue for Positron.
What this skill does
# Positron Issue Creator
## Purpose
This skill guides the drafting of high-quality GitHub issues for the Positron IDE repository. It ensures issues are:
- Thoroughly checked for duplicates before drafting
- Properly labeled for efficient triage
- Written with complete, specific information
- Free of unnecessary fluff and filler
- Actionable by the development team
- Ready for manual submission by the user
## When to Use This Skill
Use this skill when:
- User explicitly asks to draft, create, file, or report an issue
- User describes a bug or feature request that should be tracked
- Drafting documentation or improvement requests
- User says "can you draft an issue for..." or similar
Do NOT use this skill for:
- Intake rotation duties (use `positron-intake-rotation` instead)
- Responding to existing issues
- General Positron development tasks
## GitHub Access Policy
**Read operations (ALLOWED):**
- Search for existing issues and discussions via `gh` CLI
- Fetch repository labels via `gh` CLI
- View issue details for duplicate checking
- Read any public repository information
**Write operations (NOT ALLOWED):**
- Creating issues directly via `gh issue create`
- Commenting on issues
- Modifying labels on existing issues
- Any other GitHub write operations
**Instead:** Prepare issues in markdown files or clipboard-ready format for manual user submission.
## Core Workflow
**Important:** This skill prepares issues for manual submission. It does NOT automatically create GitHub issues. The user maintains full control over submitting to GitHub.
Follow this workflow for every issue drafting request:
### 1. Gather Complete Context
Before drafting anything, ensure all necessary information is available. Use iterative questioning if needed.
**For Bug Reports, obtain:**
- Positron version (Help > About or specific build number)
- Operating system and version
- Session details (R/Python version)
- Exact steps to reproduce
- Expected vs. actual behavior
- Error messages (from UI, Output panel, or Developer Console)
- Screenshots if relevant
**For Feature Requests, obtain:**
- Clear description of the desired feature
- Use case (why it's needed, what problem it solves)
- Proposed behavior (how it should work)
- Any related issues or examples from other tools
**Ask specific questions** when information is missing:
- "What Positron version are you using? Check Help > About"
- "What's the exact error message displayed?"
- "What did you expect to happen vs. what actually happened?"
- "Can you provide the specific steps to reproduce this?"
**Never make assumptions.** If unclear, ask rather than guess.
### 2. Search for Duplicates
Use `scripts/search_duplicates.sh` to search for existing issues and discussions:
```bash
cd /path/to/positron/.claude/skills/positron-issue-creator
./scripts/search_duplicates.sh "keywords from issue"
```
**Review results carefully:**
- Check both open and closed issues
- Look at discussions as well
- Consider variations of the search terms
**Present findings to user:**
- Show all potentially related issues
- Highlight any that seem very similar
- Ask user to confirm whether these are duplicates
- For uncertain matches, explicitly ask: "Is this the same issue as #1234?"
**If duplicate found:**
- Inform user that issue already exists
- Provide link to existing issue
- Suggest they add a comment or ๐ reaction if they want to track it
- Do NOT create new issue
**If no duplicates:**
- Proceed to drafting the issue
- Reference any related issues in the draft
### 3. Select Appropriate Labels
Use `scripts/fetch_labels.sh` to retrieve current repository labels:
```bash
cd /path/to/positron/.claude/skills/positron-issue-creator
./scripts/fetch_labels.sh
```
**Choose labels based on:**
**Area labels** (select 1-2):
- `area: console` - Console/REPL functionality
- `area: notebook` - Jupyter notebook integration
- `area: editor` - Text editor functionality
- `area: plots` - Plot viewer and visualization
- `area: data-explorer` - Data viewer and explorer
- `area: connections` - Database connections
- `area: help` - Help pane and documentation
- `area: ui` - General UI/UX issues
- Review full list from `fetch_labels.sh` for complete options
**Type label** (select 1):
- `Bug` - Something doesn't work as intended
- `Feature Request` - New capability or enhancement
- `Documentation` - Documentation improvements
- `Performance` - Works but too slowly
**Other considerations:**
- Avoid adding priority labels (set during triage)
- Don't add status labels (will be set by team)
- Multiple area labels are acceptable if issue spans components
### 4. Draft the Issue
Use the templates in `references/issue_templates.md` as starting points, but adapt to the specific issue.
**Load templates when needed:**
- Bug reports: Reference bug report structure
- Feature requests: Reference feature request structure
- Hybrid cases: Adapt as appropriate
**Follow writing guidelines from `references/writing_guidelines.md`:**
**Core principles:**
1. **Be terse** - Every word serves a purpose
2. **Be fluff-free** - No apologies, preambles, or unnecessary politeness
3. **Be specific** - Exact versions, precise steps, concrete details
4. **Be direct** - Get to the point immediately
**Title guidelines:**
- Bug: `[Component] fails when [condition]`
- Feature: `Add [feature] to [component]`
- Complete sentence that tells the full story
- Scannable and searchable
**Body structure:**
1. **What** - The issue itself (1 sentence)
2. **Why** - Impact/context (1-2 sentences if not obvious)
3. **How** - Steps or proposed solution (bullet points)
4. **Details** - System info, errors, screenshots (as needed)
**Example bug report:**
```markdown
Title: Console freezes when printing dataframes with 100k+ rows
The console becomes unresponsive when printing large dataframes.
## Steps to reproduce
1. Create dataframe: `df = pd.DataFrame({'a': range(100000)})`
2. Print it: `print(df)`
3. Console freezes, UI becomes unresponsive
## System details
- Positron 2024.10.0 Build 123
- macOS 14.5
- Python 3.11.6
## Error messages
Developer Console shows: "Maximum call stack size exceeded"
```
**Example feature request:**
```markdown
Title: Add keyboard shortcut to insert markdown cell in notebooks
Currently inserting markdown cells requires clicking the dropdown menu.
Keyboard shortcut would improve notebook authoring workflow.
## Proposed behavior
- Add keyboard shortcut (e.g., Cmd+M or Ctrl+M)
- Should work when focus is in notebook
- Should insert cell below current cell
## Context
Similar to Jupyter's 'M' key in command mode. Notebook workflows
frequently alternate between code and markdown cells.
```
**Common anti-patterns to avoid:**
- Unnecessary background or preambles
- Vague descriptions ("it doesn't work", "sometimes crashes")
- Combining multiple unrelated issues
- Apologetic or overly polite language
- Missing concrete details (exact versions, error messages)
- Long-winded explanations when concise ones suffice
**Review checklist before presenting:**
- [ ] Title is complete and specific
- [ ] Body starts with the core issue
- [ ] Reproduction steps are clear (for bugs)
- [ ] System details included (for bugs)
- [ ] Error messages are exact quotes
- [ ] No unnecessary fluff
- [ ] Each sentence adds value
- [ ] Single, focused topic
- [ ] Appropriate labels selected
### 5. Present Draft to User
Show the complete drafted issue including:
- Title
- Full body text
- Proposed labels
Ask user: "Does this accurately capture the issue? Would you like any changes before I create it?"
**Allow for iteration:**
- User may want to adjust wording
- May remember additional details
- May want to emphasize different aspects
Make requested changes and show updated draft.
### 6. Prepare Issue for Manual Submission
Once user approves the draft, offer options for how they want to use it:
**Ask the user:** "How would you like me to prepare this issue?"
- **Option 1Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing โ use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.