diff --git a/prompts/guides/jira.md b/prompts/guides/jira.md deleted file mode 100644 index 91776c3..0000000 --- a/prompts/guides/jira.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -targets: ['*'] -description: 'Guidelines for searching and creating JIRA tickets in AG products' ---- - -# JIRA Guide - -This guide covers working with JIRA tickets in AG products (Charts and Grid). - -**Product scope**: AG Charts (for AG Grid, change component to "Grid" and prefix to "[Grid]"). - -## Quick Reference - -- **Search**: Project `AG`, Component `Charts`, Status `Needs Review` for review -- **Summary prefix**: `[Charts]` or `[Grid]` -- **Required fields**: Summary, Description, Component, Track - -## Creating Tickets - -Use the `jira-create` skill for guided ticket creation. It will: - -1. Help you choose the right ticket type -2. Load the appropriate template -3. Guide you through required fields - -## Required Fields - -| Field | API Name | Format | -| ----------- | ------------------- | -------------------------------------- | -| Project | `projectKey` | `"AG"` | -| Type | `issueTypeName` | `"Bug"` or `"Task"` | -| Summary | `summary` | `"[Charts] Title"` or `"[Grid] Title"` | -| Description | `description` | See templates | -| Component | `components` | `[{"name": "Charts"}]` (ID: 11061) | -| Track | `customfield_10501` | See track values below | - -## Track Values (`customfield_10501`) - -| Value | ID | Use For | -| --------------- | ----- | ---------------------- | -| Bug | 10401 | Bug fixes | -| Feature Request | 10400 | New features | -| Improvement | 10403 | Enhancements | -| Housekeeping | 10404 | Tech-debt, refactoring | -| Doc change | 10402 | Documentation updates | - -Format: `[{"value": "Bug"}]` or `[{"id": "10401"}]` - -## Description Formatting - -- Use plain numbered lists: `1. Item` (not `#` wiki markup) -- Indent sub-items with 4 spaces: ` 1. Sub-item` -- **End numbered items with periods** -- Bold: `**text**` -- Code: backticks -- URLs: `[text](url)` for clickability -- Empty sections: Just `N/A` -- No comments - all info in description - -## Bug Tickets - -**Template**: `templates/jira-bug-template.md` - -**Additional fields:** - -- `versions` (Affects Version): `[{"name": "31.0.0"}]` -- Priority: `{"name": "Medium"}` (default for bugs) - -**Version testing**: Test in browser (not code analysis). Charts v9 = Grid v31 (offset +22). - -When creating bug tickets, test affected versions **from the browser** (not by analysing code): - -1. Use the reproduction Plunker and change AG Charts version -2. Binary search versions to find when the bug was introduced -3. Set `versions` field to earliest affected version - -## Feature/Task Tickets - -**Template**: `templates/jira-template.md` - -Sections: Requirements, Problem, Use cases, API Design, Breaking changes, Acceptance criteria. - -## Troubleshooting - -### Discovering Required Fields - -```javascript -mcp__atlassian__getJiraIssueTypeMetaWithFields({ - cloudId: '1565837d-d6d1-4228-bcb2-4cb74df700f2', - projectIdOrKey: 'AG', - issueTypeId: '10105', // Task -}); -``` - -### Common Errors - -- **"Track is required"**: Add `customfield_10501` -- **"Components is required"**: Add `components` array -- **Unknown field IDs**: Use metadata API above - -## Related - -- Create tickets: `skills/jira-create/SKILL.md` -- Estimate tickets: `skills/estimate-jira/SKILL.md` -- Bug template: `templates/jira-bug-template.md` -- Feature template: `templates/jira-template.md` diff --git a/prompts/guides/rulesync.md b/prompts/guides/rulesync.md index 76a66d5..ce3a7cc 100644 --- a/prompts/guides/rulesync.md +++ b/prompts/guides/rulesync.md @@ -65,7 +65,7 @@ Files in `.rulesync/` are either simple files, or symlinks to files in other loc | Source | Purpose | Examples | | ----------------------------- | --------------------------------------------------------------- | ----------------------------------- | | `.rulesync/` | Repo-specific rules + symlink-based inclusion of shared content | `ag-charts.md`, `ag-grid.md` | -| `external/ag-shared/prompts/` | Cross-repo shared content | `code-reviewer.md`, `jira.md` | +| `external/ag-shared/prompts/` | Cross-repo shared content | `code-reviewer.md` | | `external/prompts/` | Repo-private shared content | `spruce-example.md`, `visual-qa.md` | ## Frontmatter Requirements @@ -146,7 +146,6 @@ ln -s ../../external/prompts/agents/visual-qa.md visual-qa.md ln -s ../../external/ag-shared/prompts/guides/code-quality.md code-quality.md # From .rulesync/skills/ (NOTE: skills use directory symlinks, not file symlinks) -ln -s ../../external/ag-shared/prompts/skills/estimate-jira/ estimate-jira ln -s ../../external/prompts/skills/spruce-example/ spruce-example ``` diff --git a/prompts/skills/estimate-jira/SKILL.md b/prompts/skills/estimate-jira/SKILL.md deleted file mode 100644 index d13abf6..0000000 --- a/prompts/skills/estimate-jira/SKILL.md +++ /dev/null @@ -1,554 +0,0 @@ ---- -targets: ['*'] -name: estimate-jira -description: Estimate complexity, effort, and risks for JIRA tickets, features, or projects. Generates structured reports with time estimates, dependencies, risk analysis, and known unknowns. Use when user asks to "estimate", "size", or "analyze complexity" of work items. ---- - -# JIRA Ticket Estimation Skill - -This skill provides structured complexity and effort estimation for JIRA tickets, features, or projects. It produces consistent, professional estimation reports that include complexity levels, time estimates, dependency analysis, risk assessment, and identification of unknowns. - -## When to Use This Skill - -Activate this skill when the user requests: - -- "Estimate this JIRA ticket" -- "Analyze complexity of [ticket/feature]" -- "What's the effort for this project?" -- "Size this feature" -- "How long will this take?" -- "What are the risks for this work?" - -## Prerequisites - -- User provides JIRA ticket content (markdown format preferred) -- Access to repository codebase for dependency analysis -- Understanding of project architecture (consult `CLAUDE.md` or `.claude/rules/technology-stack.md` if needed) - -## Workflow - -### Step 0: Load Required Documentation - -**Read these files FIRST before any analysis:** - -1. `guides/jira.md` - JIRA conventions and patterns -2. `.claude/rules/technology-stack.md` (in target repo) - Architecture constraints and patterns -3. `CLAUDE.md` - Repository conventions and build requirements - -**After reading, confirm you understand:** - -- [ ] Repository structure and key packages -- [ ] Build and test commands -- [ ] Architectural constraints (e.g., zero runtime dependencies) - -### Step 1: Gather and Analyze Ticket Information - -**Complete ALL before proceeding:** - -- [ ] Receive JIRA ticket content from user (markdown format) -- [ ] Extract key requirements, acceptance criteria, and constraints -- [ ] Identify the primary affected areas (packages/files) -- [ ] Note what information is present vs. missing in the ticket - -**Initial Analysis Questions:** - -- What type of work is this? (bug fix, new feature, refactoring, docs, etc.) -- Which packages are affected? (community, enterprise, types, website, etc.) -- Are there related tickets or dependencies mentioned? -- Is the scope well-defined or vague? - -### Step 2: Identify Ambiguities and Implementation Choices - -**CRITICAL: Do NOT proceed to estimation without completing this step.** - -**Analyze for ambiguities in these areas:** - -1. **Technical Approach** - - - Are there multiple valid implementation strategies? - - Is the desired architecture/pattern specified? - - Are performance requirements defined? - -2. **Scope Boundaries** - - - Is the feature scope clearly bounded? - - Are edge cases and error handling specified? - - Is backward compatibility required? - -3. **Integration Points** - - - How should this integrate with existing systems? - - Are framework wrappers (React/Angular/Vue) affected? - - Are there public API changes? - -4. **Testing & Quality** - - - What level of test coverage is expected? - - Are visual regression tests needed? - - Should benchmarks be added/updated? - -5. **Documentation** - - Is documentation required? - - Are examples needed? - - Should migration guides be written? - -**For each significant ambiguity identified:** - -- [ ] Document the ambiguity clearly -- [ ] List the possible implementation choices -- [ ] Note how each choice impacts time/complexity/risk -- [ ] **USE AskUserQuestion tool** to get clarification before proceeding - -**Use the AskUserQuestion tool to present ambiguities:** - -Present 1-4 ambiguities at once using the AskUserQuestion tool with this structure: - -- **question**: Clear question about the ambiguity (e.g., "How should the 'xy' mode work visually?") -- **header**: Short label (max 12 chars) (e.g., "Dual-axis UI") -- **options**: 2-4 implementation choices with: - - **label**: Concise option name (e.g., "Two Navigators") - - **description**: Impact explanation (e.g., "Show both X-axis (bottom) and Y-axis (right) navigators - 20% more complexity, clearer UI") -- **multiSelect**: false (user should pick one approach) - -**Example usage:** - -```typescript -AskUserQuestion({ - questions: [ - { - question: "How should the 'xy' mode work visually?", - header: 'Dual-axis UI', - multiSelect: false, - options: [ - { - label: 'Two Separate Navigators', - description: - 'Show both X-axis (bottom) and Y-axis (right) navigators simultaneously - +20% complexity, clearer UI', - }, - { - label: 'Integrated Navigator', - description: 'Single unified UI component - High complexity, unclear UX, needs design work', - }, - { - label: 'Not Supported', - description: "Only allow 'x' or 'y', defer 'xy' to future ticket - -30% complexity, simpler scope", - }, - ], - }, - { - question: 'Should Y-axis navigator position be configurable?', - header: 'Position', - multiSelect: false, - options: [ - { - label: 'Configurable (left/right)', - description: - 'Add navigator.position option - +10% complexity, flexible but may overlap Y-axis labels', - }, - { - label: 'Right Side Only', - description: 'Always on right to avoid conflicts - Baseline complexity, simpler but less flexible', - }, - ], - }, - ], -}); -``` - -**After receiving answers:** - -- Document the chosen approach in a summary -- Adjust estimate based on selected options -- Include decisions in the "Implementation Decisions" section of the report - -### Step 3: Investigate Codebase Dependencies and Complexity - -**Use the Explore agent for thorough codebase analysis:** - -- [ ] Identify all affected files and packages -- [ ] Analyze existing similar implementations for patterns -- [ ] Check for dependencies on other systems/modules -- [ ] Look for related tests that need updating -- [ ] Search for documentation that needs changes - -**Key Investigation Areas:** - -1. **Core Implementation** - - - Where is the main logic located? - - How complex is the existing code in that area? - - Are there similar features to reference? - -2. **Type System** - - - Will `ag-charts-types` need updates? - - Are there complex type definitions involved? - - Will this affect public API surface? - -3. **Testing Surface** - - - How many test files are affected? - - Are image snapshots needed? - - Will this need E2E tests? - -4. **Documentation & Examples** - - - How many doc pages need updates? - - Are new examples required? - - Will framework variants be generated? - -5. **Build Dependencies** - - Which packages need rebuilding? - - Are there circular dependency risks? - - Will this affect build performance? - -### Step 4: Generate Structured Estimation Report - -**Use this exact template for consistency:** - ---- - -## Estimation Report: [Ticket ID/Feature Name] - -**Date:** [Current date] -**Estimator:** Claude Code -**Ticket Summary:** [Brief 1-2 sentence summary] - ---- - -## Executive Summary - -| Metric | Value | -| ---------------- | ------------------------------------ | -| **Total Effort** | [X-Y days] ([X-Y hours]) | -| **Complexity** | [Low \| Medium \| High \| Very High] | -| **Risk Level** | [Low \| Medium \| High] | -| **Confidence** | [Low \| Medium \| High] | - -**Key Highlights:** - -- [1-2 sentence summary of main implementation work] -- [Major scope decision or constraint] -- [Top risk or concern if applicable] - ---- - -### 1. Estimated Complexity Level - -**Overall Complexity: [Low | Medium | High | Very High]** - -**Rationale:** - -- [Explanation of complexity drivers] -- [Why this level was chosen] - -**Complexity Breakdown:** - -- Implementation: [Low/Medium/High] -- Testing: [Low/Medium/High] -- Documentation: [Low/Medium/High] -- Integration: [Low/Medium/High] - ---- - -### 2. Estimated Time Effort - -**Total Estimate: [X-Y days] for a single developer** - -**Confidence Level: [Low | Medium | High]** - -**Breakdown:** - -- **Investigation & Design:** [X hours/days] - - - Understanding requirements - - Design decisions - - Spike work if needed - -- **Core Implementation:** [X hours/days] - - - Primary code changes - - Type definitions - - Public API updates - -- **Testing:** [X hours/days] - - - Unit tests - - E2E tests (if applicable) - - Visual regression tests (if applicable) - - Benchmark updates (if applicable) - -- **Documentation:** [X hours/days] - - - Doc page updates/creation - - Example creation - - Migration guides (if applicable) - -- **Review & Iteration:** [X hours/days] - - Code review feedback - - Test failures - - Bug fixes - -**Assumptions:** - -- [List key assumptions affecting the estimate] -- [e.g., "Assuming developer is familiar with canvas rendering"] -- [e.g., "Assuming no major architectural changes needed"] - ---- - -### 3. Dependencies, Gaps & Missing Information - -**External Dependencies:** - -- [List dependencies on other teams/tickets] -- [Any blocked/blocking items] - -**Information Gaps:** - -- [What's not specified in the ticket] -- [Questions that remain unanswered] -- [Areas needing clarification from stakeholders] - -**Implicit Scope (not explicitly mentioned):** - -- [Tasks likely required but not stated] -- [e.g., "Framework wrapper updates"] -- [e.g., "Locale string additions"] - -**Out of Scope (confirm with stakeholder):** - -- [Items that might be expected but should be separate] -- [e.g., "Performance optimization beyond basic implementation"] - ---- - -### 4. Top 3 Highest Risk Aspects - -#### Risk #1: [Description] - -**Category:** [Known Unknown | Technical Complexity | Integration Risk | etc.] - -**Details:** - -- [What makes this risky] -- [Potential impact] - -**Mitigation:** - -- [How to reduce this risk] - ---- - -#### Risk #2: [Description] - -**Category:** [Known Unknown | Technical Complexity | Integration Risk | etc.] - -**Details:** - -- [What makes this risky] -- [Potential impact] - -**Mitigation:** - -- [How to reduce this risk] - ---- - -#### Risk #3: [Description] - -**Category:** [Known Unknown | Technical Complexity | Integration Risk | etc.] - -**Details:** - -- [What makes this risky] -- [Potential impact] - -**Mitigation:** - -- [How to reduce this risk] - ---- - -### 5. Overall Risk Level - -**Risk Assessment: [Low | Medium | High]** - -**Justification:** - -- [Overall risk analysis] -- [Factors contributing to risk level] -- [Known unknowns summary] - -**Risk Factors:** - -- **Technical Risk:** [Low/Medium/High] - [Why] -- **Schedule Risk:** [Low/Medium/High] - [Why] -- **Integration Risk:** [Low/Medium/High] - [Why] -- **Requirement Risk:** [Low/Medium/High] - [Why] - -**Confidence in Estimate:** - -- [High/Medium/Low confidence and why] -- [What would increase confidence] - ---- - -### Recommended Next Steps - -1. [Immediate action item] -2. [Pre-implementation research needed] -3. [Stakeholder clarifications required] - ---- - -## Implementation Decisions (Confirmed) - -Based on stakeholder clarification on [date]: - -1. **[Decision Area 1]**: [Chosen approach] ([Option letter]) -2. **[Decision Area 2]**: [Chosen approach] ([Option letter]) -3. **[Decision Area 3]**: [Chosen approach] ([Option letter]) - -_Note: Include this section only if significant implementation choices were clarified during estimation._ - ---- - -**End of Report** - ---- - -## Completion Checklist - -**Cannot mark estimation complete until ALL checked:** - -- [ ] User provided JIRA ticket content -- [ ] All significant ambiguities identified and clarified with user -- [ ] Codebase investigation completed using Explore agent -- [ ] All sections of estimation report filled out -- [ ] Complexity level justified with rationale -- [ ] Time estimate includes breakdown and assumptions -- [ ] Top 3 risks identified with mitigation strategies -- [ ] Overall risk level assessed -- [ ] Report reviewed for completeness and accuracy - -## Critical Rules - -1. **NEVER skip ambiguity clarification** - If implementation choices significantly impact estimates, you MUST ask the user before proceeding using the **AskUserQuestion tool**. Better to pause for clarification than provide misleading estimates. Present options with their complexity/time impacts clearly described. - -2. **Always use AskUserQuestion tool for ambiguities** - Do not use ad-hoc text conversation for clarifying implementation choices. Use the structured AskUserQuestion tool to present 1-4 ambiguities at once with clear options and impact descriptions. - -3. **Always use Explore agent for codebase analysis** - Do not attempt complex codebase navigation manually. The Explore agent is optimized for this task. - -4. **Be honest about uncertainty** - If confidence is low, say so clearly. Include what information would increase confidence. - -5. **Consider the full scope** - Don't forget testing, documentation, review iterations, and framework wrappers. These often represent 40-50% of total effort. - -6. **Account for unknowns** - Known unknowns should increase time estimates and risk levels proportionally. - -7. **Use ranges, not point estimates** - Give ranges (e.g., "3-5 days") to reflect uncertainty, especially for complex work. - -8. **Document assumptions explicitly** - Every estimate is based on assumptions. State them clearly so they can be validated. - -## Failure Handling - -### Problem: Insufficient ticket information - -**Solution:** - -- Request more details from user -- List specific information needed -- Provide estimate with large uncertainty range if user cannot provide more details - -### Problem: Cannot find relevant code areas - -**Solution:** - -- Use Explore agent with broader search patterns -- Ask user for hints about where code might be located -- Document this as a "known unknown" in the report - -### Problem: Multiple valid implementation approaches with vastly different complexity - -**Solution:** - -- Use the AskUserQuestion tool to present each approach as an option -- Include complexity/time impact in each option's description -- Provide recommendation in one option's description if applicable -- Let user select their preferred approach through the structured interface -- Document chosen approach in the "Implementation Decisions" section - -### Problem: Estimate exceeds reasonable time (e.g., >2 weeks for single person) - -**Solution:** - -- Consider if work should be broken into multiple tickets -- Highlight this in the risk assessment -- Recommend creating sub-tasks or phases -- Discuss with user about scope reduction options - -## Estimation Calibration Data Points - -**Use these baseline estimates for common AG Charts work items:** - -### Series Implementation - -- **New series type** (extending AbstractBarSeries, CartesianSeries, etc.): **10 days / 2 weeks** - - Includes: Core implementation, type definitions, rendering logic, theme integration - - Includes: Unit tests, visual regression tests, documentation page, framework examples - - Examples: Overlapping bar/column series, timeline series, quadrant chart - - Does NOT include: Highly complex rendering algorithms, advanced interactions beyond standard - -### Annotation Implementation - -- **New annotation type**: **15-20 days (3-4 weeks)** - - Includes: Core annotation class, rendering, drag/resize interactions, type definitions - - Includes: Comprehensive testing (unit, E2E, visual regression), documentation, examples - - Examples: Text annotations, shape annotations, measurement tools - - Complexity drivers: Drag/drop interactions, resize handles, connection points, styling system - -### Other Common Work Items - -- **Simple bug fix** (isolated, clear root cause): 0.5-1 day -- **Complex bug fix** (requires investigation, multiple areas): 2-3 days -- **New chart option** (simple property, minimal logic): 1-2 days -- **Event/callback addition**: 2-4 days (depending on complexity) -- **Performance optimization**: 3-5 days (investigation + implementation) -- **Breaking API change**: Add 20-30% for migration guide, backward compatibility testing - -**Adjustment Guidelines:** - -- **Add 20-30%** if implementation requires deep integration with multiple systems -- **Add 30-50%** if feature has significant unknowns or unclear requirements -- **Add 40-60%** for enterprise features requiring licensing checks, advanced theming -- **Reduce by 20-30%** only if leveraging substantial existing infrastructure with minimal changes - -## Related Documentation - -- [JIRA Guide](../../guides/jira.md) - JIRA conventions -- [JIRA Create Skill](../jira-create/SKILL.md) - Creating JIRA tickets -- Technology Stack: `.claude/rules/technology-stack.md` (in target repo) -- Testing Guide: `.claude/rules/testing.md` (in target repo) -- Documentation Guide: `.claude/rules/docs-pages.md` (in target repo) -- Code Quality Guide: `.claude/rules/code-quality.md` (in target repo) - -## Example Usage - -**When the user says:** - -- "Estimate AG-12345" -- "How complex is this feature?" -- "Size this ticket for me" -- "What's the effort for implementing [feature]?" -- "Analyze the risks for this work" - -**This skill will:** - -1. Request the JIRA ticket content (if not already provided) -2. Analyze the requirements and identify ambiguities -3. Clarify implementation choices with you -4. Investigate the codebase thoroughly -5. Generate a comprehensive estimation report with all requested sections -6. Highlight risks, unknowns, and areas of complexity - -**The output will always follow the structured report format** to ensure consistency across all estimates. diff --git a/prompts/skills/jira-create/SKILL.md b/prompts/skills/jira-create/SKILL.md deleted file mode 100644 index 86da341..0000000 --- a/prompts/skills/jira-create/SKILL.md +++ /dev/null @@ -1,150 +0,0 @@ ---- -targets: ['*'] -name: jira-create -description: Create JIRA tickets following AG project conventions. Guides you through bug reports, feature requests, and tech-debt tickets with proper formatting and required fields. Use when user asks to "create a JIRA", "file a bug", or "write up a ticket". ---- - -# JIRA Ticket Creation Skill - -This skill guides you through creating properly formatted JIRA tickets for AG Charts (and AG Grid - patterns are similar, just change component to "Grid"). - -## When to Use This Skill - -Activate this skill when the user requests: - -- "Create a JIRA ticket for this bug" -- "File a bug report" -- "Write up a feature request" -- "Create a tech-debt ticket" -- "Log this issue in JIRA" - -## Prerequisites - -- Access to Atlassian MCP server for JIRA creation -- Clear understanding of the issue or feature to document - -## Workflow - -### Step 0: Determine Ticket Type - -Ask the user which type of ticket they need: - -| Type | Track Value | Use When | -| --------------- | ------------------- | ------------------------------------------- | -| **Bug** | `"Bug"` | Something is broken or behaving incorrectly | -| **Feature** | `"Feature Request"` | New capability requested | -| **Improvement** | `"Improvement"` | Enhancement to existing feature | -| **Tech-debt** | `"Housekeeping"` | Refactoring, cleanup, infrastructure | -| **Docs** | `"Doc change"` | Documentation updates only | - -### Step 1: Load Appropriate Template - -**Based on ticket type, read the relevant template:** - -- **Bug tickets**: Read `templates/jira-bug-template.md` -- **Feature/Improvement/Tech-debt/Docs**: Read `templates/jira-template.md` - -For detailed field values and formatting rules, read `guides/jira.md`. - -### Step 2: Gather Information - -**For Bug tickets, collect:** - -- [ ] Reproduction URL (Plunker, CodeSandbox, etc.) -- [ ] Steps to reproduce (numbered list) -- [ ] Actual vs Expected behaviour -- [ ] Affected versions (test from end-user perspective in browser) -- [ ] Root cause analysis (if known) - -**For Feature/Improvement tickets, collect:** - -- [ ] Requirements statement (what, not how) -- [ ] Current behaviour and problem -- [ ] Use cases -- [ ] API design (if applicable) -- [ ] Acceptance criteria - -**For Tech-debt tickets, collect:** - -- [ ] Context (why this work is needed) -- [ ] Problem statement -- [ ] Proposed solution -- [ ] Acceptance criteria - -### Step 3: Create the Ticket - -Use the `mcp__atlassian__createJiraIssue` tool with this structure: - -```json -{ - "cloudId": "1565837d-d6d1-4228-bcb2-4cb74df700f2", - "projectKey": "AG", - "issueTypeName": "Bug|Task", - "summary": "[Charts] Clear, concise title", - "description": "Formatted description from template", - "additional_fields": { - "components": [{ "name": "Charts" }], - "priority": { "name": "Medium" }, - "customfield_10501": [{ "value": "Bug|Feature Request|Improvement|Housekeeping|Doc change" }] - } -} -``` - -**For bug tickets, also include:** - -```json -{ - "additional_fields": { - "versions": [{ "name": "31.0.0" }] - } -} -``` - -## Required Fields Reference - -| Field | API Name | Required | Notes | -| --------------- | ------------------- | -------- | ---------------------------------------------- | -| Project | `projectKey` | Yes | Always `"AG"` | -| Issue Type | `issueTypeName` | Yes | `"Bug"` or `"Task"` | -| Summary | `summary` | Yes | Start with `[Charts]` or `[Grid]` | -| Description | `description` | Yes | Use template format | -| Component | `components` | Yes | `[{"name": "Charts"}]` or `[{"name": "Grid"}]` | -| Track | `customfield_10501` | Yes | See track values above | -| Priority | `priority` | No | Defaults to Medium | -| Affects Version | `versions` | No | Required for bugs | -| Labels | `labels` | No | Use `["tech-debt"]` for tech-debt tickets | - -## Completion Checklist - -**Cannot mark complete until ALL checked:** - -- [ ] Correct ticket type selected -- [ ] Template format followed -- [ ] All required fields populated -- [ ] Summary starts with `[Charts]` or `[Grid]` -- [ ] Track field set correctly -- [ ] For bugs: Affects Version included -- [ ] URLs formatted as markdown links - -## Critical Rules - -1. **Always use templates** - Don't improvise description formats -2. **Test bugs in browser** - Not by analysing code -3. **Format URLs as markdown links** - `[text](url)` for clickability -4. **End numbered items with periods** - JIRA formatting requirement -5. **No comments** - Put all information in the description - -## Product Notes - -This skill is designed for **AG Charts**. For **AG Grid** tickets: - -- Change component to `[{"name": "Grid"}]` -- Change summary prefix to `[Grid]` -- Version offset: Grid version = Charts version + 22 - -## Related Documentation - -- Full field reference: `guides/jira.md` -- Bug template: `templates/jira-bug-template.md` -- Feature template: `templates/jira-template.md` -- Estimation skill: `skills/estimate-jira/SKILL.md` diff --git a/prompts/skills/plunker/SKILL.md b/prompts/skills/plunker/SKILL.md deleted file mode 100644 index 2ce5ae1..0000000 --- a/prompts/skills/plunker/SKILL.md +++ /dev/null @@ -1,523 +0,0 @@ ---- -targets: ['*'] -name: plunker -description: 'Create and manage Plunker (plnkr.co) examples for AG Charts. Use when working with plnkr.co URLs, creating shareable code demos, forking existing plunks, or troubleshooting Plunker structure issues.' -context: fork ---- - -# Plunker Guide - -This guide covers working with Plunker for creating and sharing code examples. - -## Framework Preference - -**Always create plunkers in vanilla JavaScript unless:** - -- The user explicitly requests a specific framework (Angular, React, Vue) -- The bug/feature is framework-specific and cannot be reproduced in vanilla JS - -**When given a framework example (e.g., Angular) for a bug:** - -1. Convert it to vanilla JS before using or creating a repro -2. Only keep the framework version if the issue is framework-specific - -**Rationale:** - -- Vanilla JS examples are simpler and load faster -- They work without framework dependencies or build systems -- Easier to debug and share -- Framework wrappers are thin - most bugs reproduce in vanilla JS - -## Table of Contents - -1. [Plunker API Reference](#plunker-api-reference) - Core API operations -2. [AG Charts Example Structure](#ag-charts-example-structure) - Specific requirements for AG Charts demos - ---- - -## Plunker API Reference - -### Reading a Plunk - -Fetch any public plunk's content: - -```bash -curl -s 'https://api.plnkr.co/plunks/{plunkId}' -``` - -Response structure: - -```json -{ - "id": "U7l3QaCV6qeYyqnt", - "description": "Example Title", - "tags": ["tag1", "tag2"], - "files": { - "main.js": { - "content": "// file content here", - "filename": "main.js" - } - } -} -``` - -### Getting an Access Token - -Required for creating/updating plunks: - -```bash -curl -s -c /tmp/plnk-cookies.txt 'https://plnkr.co/edit/' > /dev/null -TOKEN=$(grep 'plnkr.access_token' /tmp/plnk-cookies.txt | awk '{print $7}') -``` - -**Notes:** - -- The `plnkr.access_token` cookie is a JWT that works as a Bearer token -- Tokens expire - get a fresh one before each API session -- Cookie-based auth does NOT work - must use Bearer token - -### Creating a New Plunk - -```bash -curl -s -X POST 'https://api.plnkr.co/v2/plunks' \ - -H 'Content-Type: application/json' \ - -H "Authorization: Bearer $TOKEN" \ - -d @payload.json -``` - -Payload structure: - -```json -{ - "title": "My Example", - "tags": ["tag1", "tag2"], - "entries": [ - { "type": "file", "pathname": "index.html", "content": "..." }, - { "type": "file", "pathname": "main.js", "content": "..." } - ] -} -``` - -**Important:** - -- Use `entries` array (not `files` object) -- Each entry needs `type: "file"`, `pathname`, and `content` -- Do NOT use `description` field (use `title` instead) - -Response includes: - -```json -{ - "id": "newPlunkId", - "token": "privateToken123", - "created_at": "2026-01-15T..." -} -``` - -Resulting URL: `https://plnkr.co/edit/{id}?open=main.js` - -### Fork, Edit, and Save Workflow - -Plunker doesn't have a direct "fork" API. Instead, read the original, modify, and create a new plunk: - -#### Step 1: Read the Original Plunk - -```bash -# Get the plunk content -PLUNK_ID="U7l3QaCV6qeYyqnt" -curl -s "https://api.plnkr.co/plunks/$PLUNK_ID" > /tmp/original.json -``` - -#### Step 2: Get Access Token - -```bash -curl -s -c /tmp/plnk-cookies.txt 'https://plnkr.co/edit/' > /dev/null -TOKEN=$(grep 'plnkr.access_token' /tmp/plnk-cookies.txt | awk '{print $7}') -``` - -#### Step 3: Modify and Create New Plunk - -```bash -node -e " -const fs = require('fs'); -const original = JSON.parse(fs.readFileSync('/tmp/original.json', 'utf8')); - -// Modify the content as needed -let mainJs = original.files['main.js'].content; -mainJs = mainJs.replace('oldValue', 'newValue'); - -// Build the new plunk payload -const payload = { - title: original.description + ' (Fork)', - tags: original.tags, - entries: Object.entries(original.files).map(([pathname, file]) => ({ - type: 'file', - pathname, - content: pathname === 'main.js' ? mainJs : file.content - })) -}; - -fs.writeFileSync('/tmp/fork-payload.json', JSON.stringify(payload)); -" - -# Create the forked plunk -curl -s -X POST 'https://api.plnkr.co/v2/plunks' \ - -H 'Content-Type: application/json' \ - -H "Authorization: Bearer $TOKEN" \ - -d @/tmp/fork-payload.json -``` - -#### Complete One-Liner Example - -```bash -PLUNK_ID="U7l3QaCV6qeYyqnt" && \ -curl -s "https://api.plnkr.co/plunks/$PLUNK_ID" > /tmp/original.json && \ -curl -s -c /tmp/plnk-cookies.txt 'https://plnkr.co/edit/' > /dev/null && \ -TOKEN=$(grep 'plnkr.access_token' /tmp/plnk-cookies.txt | awk '{print $7}') && \ -node -e " -const fs = require('fs'); -const original = JSON.parse(fs.readFileSync('/tmp/original.json', 'utf8')); - -// Your modifications here -let mainJs = original.files['main.js'].content; -// mainJs = mainJs.replace(...); - -const payload = { - title: original.description + ' (Fork)', - tags: original.tags, - entries: Object.entries(original.files).map(([pathname, file]) => ({ - type: 'file', - pathname, - content: pathname === 'main.js' ? mainJs : file.content - })) -}; -fs.writeFileSync('/tmp/fork-payload.json', JSON.stringify(payload)); -" && \ -curl -s -X POST 'https://api.plnkr.co/v2/plunks' \ - -H 'Content-Type: application/json' \ - -H "Authorization: Bearer $TOKEN" \ - -d @/tmp/fork-payload.json | jq '{id, url: ("https://plnkr.co/edit/" + .id + "?open=main.js")}' -``` - -### Manual Creation via Website - -1. Go to https://plnkr.co/edit/ -2. Create files by clicking the "+" button -3. Paste content into each file -4. Run to verify it works -5. Save (creates a permanent URL) -6. Copy URL - format: `https://plnkr.co/edit/{plunkId}?open=main.js` - -### Form POST Method - -The AG Charts website creates Plunkers by POSTing a form: - -``` -POST https://plnkr.co/edit/?preview&open={fileToOpen} -``` - -With hidden inputs: - -- `tags[0]`, `tags[1]`, etc. -- `private` = true -- `description` = "Example title" -- `files[index.html]` = HTML content -- `files[main.js]` = JavaScript content - -Implementation: `external/ag-website-shared/src/components/plunkr/utils/plunkr.ts` - -### API Limitations - -- **No true fork endpoint** - Create a new plunk with modified content instead -- **No update without token** - You can only update plunks you created (using the private `token` from creation response) -- **Cookie auth doesn't work** - Always use Bearer token authorization - ---- - -## AG Charts Example Structure - -This section covers the specific file structure and content needed for AG Charts demos on Plunker. - -**CRITICAL**: Follow this exact structure to match website-generated Plunkers. - -### Required Files - -1. `index.html` - HTML structure with inline styles -2. `main.js` - Chart configuration and creation -3. `ag-example-styles.css` - Base styles plus framework styles -4. `package.json` - Dependencies -5. `data.js` (optional) - Data if not inline - -### index.html - -```html - - - AG Charts Example - Demo Name - - - - - - - -
- - - - - -``` - -**Key points:** - -- Include `` to prevent indexing -- Include the inline `