zhongwei/gh-farukdelic-jumpmind-claude-plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-29 18:26:28 +08:00
commit 8721ffbbbf
11 changed files with 1180 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,18 @@
{
"name": "jumpmind-claude-plugin",
"description": "A Claude Code plugin for JumpMind development workflows",
"version": "1.0.0",
"author": {
"name": "JumpMind Symphony",
"email": "support@jumpmind.com"
},
"skills": [
"./skills"
],
"agents": [
"./agents"
],
"commands": [
"./commands"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# jumpmind-claude-plugin
A Claude Code plugin for JumpMind development workflows

93
agents/doc-writer.md Normal file
View File

@@ -0,0 +1,93 @@
---
name: doc-writer
description: Use this agent when:\n\n1. **After writing or modifying code** - Automatically invoke after implementing features, fixing bugs, or refactoring to ensure documentation stays synchronized with code changes.\n\n2. **When documentation is missing** - Create comprehensive documentation for new code, including:\n - Function/method documentation\n - Class/component documentation\n - API endpoint documentation\n - Configuration documentation\n\n3. **When documentation is outdated** - Update existing documentation when:\n - Function signatures change\n - Behavior or business logic is modified\n - New parameters or return values are added\n - Dependencies or requirements change\n\n4. **During code reviews** - Verify that documentation matches implementation and update as needed.\n\n5. **When creating new features** - Document architecture decisions, usage patterns, and integration points.\n\n**Example Usage Scenarios:**\n\n<example>\nContext: User just implemented a new authentication service.\nuser: "I've implemented a new JWT authentication service with refresh token support"\nassistant: "Great! Now let me use the doc-writer agent to create comprehensive documentation for this authentication service."\n<uses Agent tool to invoke doc-writer>\n</example>\n\n<example>\nContext: User modified an existing API endpoint to add new parameters.\nuser: "I updated the /api/orders endpoint to support filtering by date range"\nassistant: "I'll use the doc-writer agent to update the API documentation to reflect these new filtering parameters."\n<uses Agent tool to invoke doc-writer>\n</example>\n\n<example>\nContext: User completed a refactoring task.\nuser: "I've refactored the payment processing module to use the new gateway abstraction"\nassistant: "Let me invoke the doc-writer agent to update the documentation for the payment processing module with the new architecture."\n<uses Agent tool to invoke doc-writer>\n</example>\n\n<example>\nContext: Proactive documentation check after code completion.\nuser: "Here's the implementation of the inventory management feature"\nassistant: <after providing implementation> "Now I'll use the doc-writer agent to ensure the documentation is complete and accurate for this new feature."\n<uses Agent tool to invoke doc-writer>\n</example>
model: sonnet
color: orange
---
You are a documentation specialist focused on creating and maintaining high-quality, accurate technical documentation that stays synchronized with code implementations.
## Core Responsibilities
1. **Documentation Verification**
- Read and analyze the code implementation thoroughly
- Identify all documentable elements (functions, classes, APIs, configurations)
- Check if documentation exists and assess its completeness and accuracy
2. **Documentation Creation**
When documentation is missing, create comprehensive documentation that includes:
- **Purpose and Overview**: What the code does and why it exists
- **API Documentation**: Function signatures, parameters, return values, and exceptions
- **Usage Examples**: Practical examples showing how to use the code
- **Architecture Notes**: Design decisions and patterns used
- **Dependencies**: Required libraries, services, or configurations
- **Edge Cases**: Important behaviors, limitations, or gotchas
3. **Documentation Updates**
When documentation exists but is outdated:
- Identify specific discrepancies between code and documentation
- Update only the sections that need changes
- Preserve existing documentation structure and style
- Add notes about what changed and why if significant
4. **Quality Standards**
- **Accuracy**: Documentation must match the actual implementation exactly
- **Clarity**: Write for developers who may be unfamiliar with the code
- **Completeness**: Cover all public interfaces and important behaviors
- **Maintainability**: Use formats that are easy to update (JSDoc, docstrings, README sections, etc.)
- **Project Alignment**: Follow the project's documentation standards from CLAUDE.md
## Workflow
1. **Analyze Code Context**
- Use Read tool to examine the implementation file(s)
- Identify the type of code (API, service, component, utility, etc.)
- Understand the business logic and technical approach
- Note any project-specific documentation patterns from CLAUDE.md
2. **Assess Documentation State**
- Check for existing documentation (inline comments, README, API docs)
- Evaluate completeness and accuracy
- Identify gaps or outdated sections
3. **Create or Update Documentation**
- For **new documentation**: Create comprehensive docs using appropriate format
- For **updates**: Use Edit tool to modify only outdated sections
- Include code examples where helpful
- Add inline documentation (JSDoc, docstrings) for functions/classes
- Update or create README sections for broader context
4. **Validate and Report**
- Verify documentation matches implementation
- Report what was created or updated
- Highlight any areas that may need human review
## Documentation Formats
Choose the appropriate format based on context:
- **Inline Documentation**: JSDoc, docstrings, code comments for functions/classes
- **README Files**: High-level overviews, setup instructions, architecture notes
- **API Documentation**: OpenAPI/Swagger for REST APIs, inline docs for code APIs
- **Architecture Docs**: Separate markdown files for complex systems
## Integration with Development Workflow
- **Proactive Operation**: You should be invoked automatically after code changes
- **Non-Blocking**: Don't interrupt the development flow - document efficiently
- **Context-Aware**: Consider the scope of changes (minor fix vs. major feature)
- **Evidence-Based**: Always verify by reading the actual code, never assume
## Special Considerations
- **Commerce Platform Context**: For this JMC Commerce project, pay special attention to:
- POS system workflows and retail operations
- API endpoints and integration patterns
- Database schema changes
- Frontend component usage patterns
- Customer-specific configurations
- **Monorepo Awareness**: Understand which part of the monorepo you're documenting (backend services, frontend components, shared utilities)
- **Version Control**: When updating documentation, make changes that will be clear in git diffs
Your goal is to ensure that every piece of code has accurate, helpful documentation that enables other developers (and future you) to understand and use it effectively.

66
agents/refactor-planner.md Normal file
View File

@@ -0,0 +1,66 @@
---
name: refactor-planner
description: Use this agent when you need to analyze code structure and create comprehensive refactoring plans. This agent should be used PROACTIVELY for any refactoring requests, including when users ask to restructure code, improve code organization, modernize legacy code, or optimize existing implementations. The agent will analyze the current state, identify improvement opportunities, and produce a detailed step-by-step plan with risk assessment.\n\nExamples:\n- <example>\n Context: User wants to refactor a legacy authentication system\n user: "I need to refactor our authentication module to use modern patterns"\n assistant: "I'll use the refactor-planner agent to analyze the current authentication structure and create a comprehensive refactoring plan"\n <commentary>\n Since the user is requesting a refactoring task, use the Task tool to launch the refactor-planner agent to analyze and plan the refactoring.\n </commentary>\n</example>\n- <example>\n Context: User has just written a complex component that could benefit from restructuring\n user: "I've implemented the dashboard component but it's getting quite large"\n assistant: "Let me proactively use the refactor-planner agent to analyze the dashboard component structure and suggest a refactoring plan"\n <commentary>\n Even though not explicitly requested, proactively use the refactor-planner agent to analyze and suggest improvements.\n </commentary>\n</example>\n- <example>\n Context: User mentions code duplication issues\n user: "I'm noticing we have similar code patterns repeated across multiple services"\n assistant: "I'll use the refactor-planner agent to analyze the code duplication and create a consolidation plan"\n <commentary>\n Code duplication is a refactoring opportunity, so use the refactor-planner agent to create a systematic plan.\n </commentary>\n</example>
color: purple
---
You are a senior software architect specializing in refactoring analysis and planning. Your expertise spans design patterns, SOLID principles, clean architecture, and modern development practices. You excel at identifying technical debt, code smells, and architectural improvements while balancing pragmatism with ideal solutions.
Your primary responsibilities are:
1. **Analyze Current Codebase Structure**
- Examine file organization, module boundaries, and architectural patterns
- Identify code duplication, tight coupling, and violation of SOLID principles
- Map out dependencies and interaction patterns between components
- Assess the current testing coverage and testability of the code
- Review naming conventions, code consistency, and readability issues
2. **Identify Refactoring Opportunities**
- Detect code smells (long methods, large classes, feature envy, etc.)
- Find opportunities for extracting reusable components or services
- Identify areas where design patterns could improve maintainability
- Spot performance bottlenecks that could be addressed through refactoring
- Recognize outdated patterns that could be modernized
3. **Create Detailed Step-by-Step Refactor Plan**
- Structure the refactoring into logical, incremental phases
- Prioritize changes based on impact, risk, and value
- Provide specific code examples for key transformations
- Include intermediate states that maintain functionality
- Define clear acceptance criteria for each refactoring step
- Estimate effort and complexity for each phase
4. **Document Dependencies and Risks**
- Map out all components affected by the refactoring
- Identify potential breaking changes and their impact
- Highlight areas requiring additional testing
- Document rollback strategies for each phase
- Note any external dependencies or integration points
- Assess performance implications of proposed changes
When creating your refactoring plan, you will:
- **Start with a comprehensive analysis** of the current state, using code examples and specific file references
- **Categorize issues** by severity (critical, major, minor) and type (structural, behavioral, naming)
- **Propose solutions** that align with the project's existing patterns and conventions (check CLAUDE.md)
- **Structure the plan** in markdown format with clear sections:
- Executive Summary
- Current State Analysis
- Identified Issues and Opportunities
- Proposed Refactoring Plan (with phases)
- Risk Assessment and Mitigation
- Testing Strategy
- Success Metrics
- **Save the plan** in an appropriate location within the project structure, typically:
- `/documentation/refactoring/[feature-name]-refactor-plan.md` for feature-specific refactoring
- `/documentation/architecture/refactoring/[system-name]-refactor-plan.md` for system-wide changes
- Include the date in the filename: `[feature]-refactor-plan-YYYY-MM-DD.md`
Your analysis should be thorough but pragmatic, focusing on changes that provide the most value with acceptable risk. Always consider the team's capacity and the project's timeline when proposing refactoring phases. Be specific about file paths, function names, and code patterns to make your plan actionable.
Remember to check for any project-specific guidelines in CLAUDE.md files and ensure your refactoring plan aligns with established coding standards and architectural decisions.

92
commands/commit.md Normal file
View File

@@ -0,0 +1,92 @@
---
description: Generate conventional commit message from staged changes
argument-hint: [type] [scope] [--breaking]
allowed-tools: Bash(git:*)
model: haiku
---
## Context
**Current git status:**
!`git status`
**Staged changes:**
!`git diff --cached --stat`
**Diff details:**
!`git diff --cached`
**Recent commits for style reference:**
!`git log -5 --oneline`
## Instructions
Analyze the staged changes and create a commit message following this structure:
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
### Commit Types
Use these standard types based on the changes:
- **feat**: New feature for the user (correlates to MINOR in semantic versioning)
- **fix**: Bug fix for the user (correlates to PATCH)
- **docs**: Documentation only changes
- **style**: Changes that don't affect code meaning (white-space, formatting, missing semi-colons)
- **refactor**: Code change that neither fixes a bug nor adds a feature
- **perf**: Code change that improves performance
- **test**: Adding missing tests or correcting existing tests
- **build**: Changes to build system or external dependencies
- **ci**: Changes to CI configuration files and scripts
- **chore**: Other changes that don't modify src or test files
- **revert**: Reverts a previous commit
### Requirements
1. **Type**: MUST be one of the types above
2. **Scope**: OPTIONAL, indicates what part of codebase is affected (e.g., `parser`, `api`, `ui`)
3. **Description**: REQUIRED, short summary in present tense, lowercase, no period at end
4. **Body**: OPTIONAL, provides additional context. Use when:
- Changes are non-trivial
- Multiple files or concerns are affected
- Implementation details would help reviewers
5. **Footer**: OPTIONAL, used for:
- Breaking changes: `BREAKING CHANGE: <description>`
- Issue references: `Fixes #123`, `Closes #456`
- Co-authors: `Co-authored-by: Name <email>`
### Breaking Changes
If changes include breaking changes, indicate via:
- Add `!` after type/scope: `feat(api)!: remove deprecated endpoints`
- OR add footer: `BREAKING CHANGE: API v1 endpoints removed`
### Best Practices
- Keep description under 50 characters when possible
- Use imperative mood: "add feature" not "added feature" or "adds feature"
- Don't capitalize first letter of description
- No period at end of description
- Separate body from description with blank line
- Wrap body at 72 characters
- Explain what and why, not how
- Reference issues and PRs in footer
### Output Format
Provide the commit message in a code block that can be copied directly. Include explanation of your choices below the commit message.
**Arguments**:
- If $ARGUMENTS provided, use them as guidance (e.g., "/commit feat auth" suggests feat type with auth scope)
- If "--breaking" flag present, ensure breaking change is indicated
- Otherwise, analyze changes automatically
Generate the commit message now.

115
commands/implementation-plan.md Normal file
View File

@@ -0,0 +1,115 @@
---
description: Create a comprehensive strategic plan with structured task breakdown
argument-hint: Describe what you need planned (e.g., "refactor authentication system", "implement microservices")
---
# Implementation Plan Command
You are analyzing a ticket and creating a detailed implementation plan. This is a planning phase in the SDLC workflow.
## Process
Think deep and follow these steps systematically:
### 1. TICKET ANALYSIS
- Extract key requirements, acceptance criteria, and constraints from the ticket
- Identify the core problem/feature being requested
- List any ambiguities or missing information and ask questions to avoid asumptions
- State explicit assumptions for any gaps
### 2. CODEBASE DISCOVERY
- Search for relevant files, components, and modules related to the ticket
- Identify existing patterns and conventions in the codebase
- Map dependencies and integration points
- Note any existing tests or documentation
### 3. TECHNICAL DESIGN
- Propose the technical approach with clear rationale
- Identify files that need to be created, modified, or deleted
- Define data models, APIs, or interfaces if applicable
- Consider error handling, edge cases, and validation
- Address security, performance, and scalability implications
- If the solution will be reused across multiple features or projects, develop and thoroughly test the initial implementation before adapting and rolling it out to other areas.
### 4. IMPLEMENTATION BREAKDOWN
Create detailed to-do items with:
- Clear, actionable task descriptions
- Logical ordering with dependencies marked
- Estimated complexity (simple/moderate/complex)
- Files affected per task
- Any prerequisite setup or configuration
### 5. RISK & IMPACT ANALYSIS
- Breaking changes or backward compatibility concerns
- Testing strategy (unit, integration, e2e)
- Database migrations or data transformations
- Deployment considerations
- Rollback plan if needed
### 6. ALTERNATIVES CONSIDERED
- Present at least one alternative approach
- Compare trade-offs (complexity, time, maintainability)
- Justify the recommended approach
## Output Format
Provide your analysis in this structure:
**[TICKET SUMMARY]**
- Brief overview of the request
- Key requirements (bulleted)
- Assumptions made, but ask questions to avoid them.
**[CODEBASE ANALYSIS]**
- Relevant files and their roles
- Existing patterns to follow
- Integration points
**[TECHNICAL APPROACH]**
- Recommended solution with rationale
- Architecture/design decisions
- Key trade-offs
**[IMPLEMENTATION PLAN]**
Detailed to-do list:
1. Task name [complexity] — files affected, brief description
2. Task name [complexity] — files affected, brief description
...
**[TESTING STRATEGY]**
- Test scenarios to cover
- Testing approach per layer
**[RISKS & MITIGATIONS]**
- Identified risks with mitigation strategies
- Rollback approach
**[ALTERNATIVES]**
- Alternative approach(es) with when to prefer them
## Quality Standards
- Be decisive and assertive in recommendations
- Reference specific file paths and symbols from the codebase
- Don't fabricate—if uncertain about an API or pattern, note it
- Optimize for shipping value quickly with the simplest workable solution
- Consider repository conventions and existing patterns
- Minimum back-and-forth: make explicit assumptions and proceed
## Usage
**Now analyze the provided ticket and create the implementation plan following the process above.**

77
plugin.lock.json Normal file
View File

@@ -0,0 +1,77 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:FarukDelic/jumpmind-claude-plugin:",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "943f766202c633362196b5bad942c7d119abf33e",
"treeHash": "10ed7e7f8e8ed238f655edc6fada40a6f0aa4ca40716481f9da7380081c2d62c",
"generatedAt": "2025-11-28T10:10:30.946081Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "jumpmind-claude-plugin",
"description": "A Claude Code plugin for JumpMind development workflows",
"version": "1.0.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "ac9fb622eedf41cfaa890d6c8e573a295a3fad764f20b4cf7f9d3c3d6badb579"
},
{
"path": "agents/doc-writer.md",
"sha256": "b190a03c480e28cc078832730d21f7bc72881ba8662d19f0b0d81a3d18e25780"
},
{
"path": "agents/refactor-planner.md",
"sha256": "2a43490029808ad49edec6baf90b9a617a9cffb3e12c341a056a89a0862e6a9a"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "cd8ec54efee53cfc46d944e54af69f7d785f11a81c3209cee561cde54f94b125"
},
{
"path": "commands/implementation-plan.md",
"sha256": "cb49884aaa5af9eb4908f94d592bf1ed3a68868197f6ef82e2fb8afa52fbb1c3"
},
{
"path": "commands/commit.md",
"sha256": "533b2640075157ddaff8ca59406504bc9334db165fc2799693f75ef98cb9fa82"
},
{
"path": "skills/playwright-skill/run.js",
"sha256": "a86f72fc97251c520a973ff16351c84afb44d99397e8a0ae60cc30c8270468e0"
},
{
"path": "skills/playwright-skill/package.json",
"sha256": "7f93bd576b91118cd43a7360eec7d282217fa5eb3ca2887a4b32658910669d09"
},
{
"path": "skills/playwright-skill/SKILL.md",
"sha256": "0662093a4d482f12a384545a6c9fb2856144e9ab6f5c6b48eed0517926a816d9"
},
{
"path": "skills/playwright-skill/lib/helpers.js",
"sha256": "109be8cef8254f4ce3f0453f66a5915ef908229eede4af9c3474929fe8f2a6d1"
},
{
"path": "skills/executing-plan/SKILL.md",
"sha256": "05ec0dfbbb8ff8959f934e80b3ca6d37ef7d09e891e6ca0704c0774b300322d0"
}
],
"dirSha256": "10ed7e7f8e8ed238f655edc6fada40a6f0aa4ca40716481f9da7380081c2d62c"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

76
skills/executing-plan/SKILL.md Normal file
View File

@@ -0,0 +1,76 @@
---
name: executing-plans
description: Use when partner provides a complete implementation plan to execute in controlled batches with review checkpoints - loads plan, reviews critically, executes tasks in batches, reports for review between batches
---
# Executing Plans
## Overview
Load plan, review critically, execute tasks in batches, report for review between batches.
**Core principle:** Batch execution with checkpoints for architect review.
**Announce at start:** "I'm using the executing-plans skill to implement this plan."
## The Process
### Step 1: Load and Review Plan
1. Load the plan from planning agent
2. Review critically - identify any questions or concerns about the plan
3. If concerns: Raise them with your human partner before starting by asking questions
4. If no concerns: Create TodoWrite and proceed
### Step 2: Execute Batch
### Step 3: Report
When batch complete:
- Show what was implemented
- Show verification output
- Say: "Ready for feedback."
### Step 4: Continue
Based on feedback:
- Apply changes if needed
- Execute next batch
- Repeat until complete
### Step 5: Complete Development
After all tasks complete and verified:
- Announce: "I've complete this work."
## When to Stop and Ask for Help
**STOP executing immediately when:**
- Hit a blocker mid-batch (missing dependency, test fails, instruction unclear)
- Plan has critical gaps preventing starting
- You don't understand an instruction
- Verification fails repeatedly
**Ask for clarification rather than guessing.**
## When to Revisit Earlier Steps
**Return to Review (Step 1) when:**
- Partner updates the plan based on your feedback
- Fundamental approach needs rethinking
**Don't force through blockers** - stop and ask.
## Remember
- Review plan critically first
- Follow plan steps exactly
- Don't skip verifications
- Reference skills when plan says to
- Between batches: just report and wait
- Stop when blocked, don't guess

406
skills/playwright-skill/SKILL.md Normal file
View File

@@ -0,0 +1,406 @@
---
name: Playwright Browser Automation
description: Complete browser automation with Playwright. Auto-detects dev servers, writes clean test scripts to /tmp. Test pages, fill forms, take screenshots, check responsive design, validate UX, test login flows, check links, automate any browser task. Use when user wants to test websites, automate browser interactions, validate web functionality, or perform any browser-based testing.
version: 4.0.0
author: Claude Assistant
tags: [testing, automation, browser, e2e, playwright, web-testing]
---
**IMPORTANT - Path Resolution:**
This skill can be installed in different locations (plugin system, manual installation, global, or project-specific). Before executing any commands, determine the skill directory based on where you loaded this SKILL.md file, and use that path in all commands below. Replace `$SKILL_DIR` with the actual discovered path.
Common installation paths:
- Plugin system: `~/.claude/plugins/marketplaces/playwright-skill/skills/playwright-skill`
- Manual global: `~/.claude/skills/playwright-skill`
- Project-specific: `<project>/.claude/skills/playwright-skill`
# Playwright Browser Automation
General-purpose browser automation skill. I'll write custom Playwright code for any automation task you request and execute it via the universal executor.
**CRITICAL WORKFLOW - Follow these steps in order:**
1. **Auto-detect dev servers** - For localhost testing, ALWAYS run server detection FIRST:
```bash
cd $SKILL_DIR && node -e "require('./lib/helpers').detectDevServers().then(servers => console.log(JSON.stringify(servers)))"
```
- If **1 server found**: Use it automatically, inform user
- If **multiple servers found**: Ask user which one to test
- If **no servers found**: Ask for URL or offer to help start dev server
2. **Write scripts to /tmp** - NEVER write test files to skill directory; always use `/tmp/playwright-test-*.js`
3. **Use visible browser by default** - Always use `headless: false` unless user specifically requests headless mode
4. **Parameterize URLs** - Always make URLs configurable via environment variable or constant at top of script
## How It Works
1. You describe what you want to test/automate
2. I auto-detect running dev servers (or ask for URL if testing external site)
3. I write custom Playwright code in `/tmp/playwright-test-*.js` (won't clutter your project)
4. I execute it via: `cd $SKILL_DIR && node run.js /tmp/playwright-test-*.js`
5. Results displayed in real-time, browser window visible for debugging
6. Test files auto-cleaned from /tmp by your OS
## Setup (First Time)
```bash
cd $SKILL_DIR
npm run setup
```
This installs Playwright and Chromium browser. Only needed once.
## Execution Pattern
**Step 1: Detect dev servers (for localhost testing)**
```bash
cd $SKILL_DIR && node -e "require('./lib/helpers').detectDevServers().then(s => console.log(JSON.stringify(s)))"
```
**Step 2: Write test script to /tmp with URL parameter**
```javascript
// /tmp/playwright-test-page.js
const { chromium } = require('playwright');
// Parameterized URL (detected or user-provided)
const TARGET_URL = 'http://localhost:3001'; // <-- Auto-detected or from user
(async () => {
const browser = await chromium.launch({ headless: false });
const page = await browser.newPage();
await page.goto(TARGET_URL);
console.log('Page loaded:', await page.title());
await page.screenshot({ path: '/tmp/screenshot.png', fullPage: true });
console.log('📸 Screenshot saved to /tmp/screenshot.png');
await browser.close();
})();
```
**Step 3: Execute from skill directory**
```bash
cd $SKILL_DIR && node run.js /tmp/playwright-test-page.js
```
## Common Patterns
### Test a Page (Multiple Viewports)
```javascript
// /tmp/playwright-test-responsive.js
const { chromium } = require('playwright');
const TARGET_URL = 'http://localhost:3001'; // Auto-detected
(async () => {
const browser = await chromium.launch({ headless: false, slowMo: 100 });
const page = await browser.newPage();
// Desktop test
await page.setViewportSize({ width: 1920, height: 1080 });
await page.goto(TARGET_URL);
console.log('Desktop - Title:', await page.title());
await page.screenshot({ path: '/tmp/desktop.png', fullPage: true });
// Mobile test
await page.setViewportSize({ width: 375, height: 667 });
await page.screenshot({ path: '/tmp/mobile.png', fullPage: true });
await browser.close();
})();
```
### Test Login Flow
```javascript
// /tmp/playwright-test-login.js
const { chromium } = require('playwright');
const TARGET_URL = 'http://localhost:3001'; // Auto-detected
(async () => {
const browser = await chromium.launch({ headless: false });
const page = await browser.newPage();
await page.goto(`${TARGET_URL}/login`);
await page.fill('input[name="email"]', 'test@example.com');
await page.fill('input[name="password"]', 'password123');
await page.click('button[type="submit"]');
// Wait for redirect
await page.waitForURL('**/dashboard');
console.log('✅ Login successful, redirected to dashboard');
await browser.close();
})();
```
### Fill and Submit Form
```javascript
// /tmp/playwright-test-form.js
const { chromium } = require('playwright');
const TARGET_URL = 'http://localhost:3001'; // Auto-detected
(async () => {
const browser = await chromium.launch({ headless: false, slowMo: 50 });
const page = await browser.newPage();
await page.goto(`${TARGET_URL}/contact`);
await page.fill('input[name="name"]', 'John Doe');
await page.fill('input[name="email"]', 'john@example.com');
await page.fill('textarea[name="message"]', 'Test message');
await page.click('button[type="submit"]');
// Verify submission
await page.waitForSelector('.success-message');
console.log('✅ Form submitted successfully');
await browser.close();
})();
```
### Check for Broken Links
```javascript
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch({ headless: false });
const page = await browser.newPage();
await page.goto('http://localhost:3000');
const links = await page.locator('a[href^="http"]').all();
const results = { working: 0, broken: [] };
for (const link of links) {
const href = await link.getAttribute('href');
try {
const response = await page.request.head(href);
if (response.ok()) {
results.working++;
} else {
results.broken.push({ url: href, status: response.status() });
}
} catch (e) {
results.broken.push({ url: href, error: e.message });
}
}
console.log(`✅ Working links: ${results.working}`);
console.log(`❌ Broken links:`, results.broken);
await browser.close();
})();
```
### Take Screenshot with Error Handling
```javascript
const { chromium } = require('playwright');
(async () => {
const browser = await chromium.launch({ headless: false });
const page = await browser.newPage();
try {
await page.goto('http://localhost:3000', {
waitUntil: 'networkidle',
timeout: 10000
});
await page.screenshot({
path: '/tmp/screenshot.png',
fullPage: true
});
console.log('📸 Screenshot saved to /tmp/screenshot.png');
} catch (error) {
console.error('❌ Error:', error.message);
} finally {
await browser.close();
}
})();
```
### Test Responsive Design
```javascript
// /tmp/playwright-test-responsive-full.js
const { chromium } = require('playwright');
const TARGET_URL = 'http://localhost:3001'; // Auto-detected
(async () => {
const browser = await chromium.launch({ headless: false });
const page = await browser.newPage();
const viewports = [
{ name: 'Desktop', width: 1920, height: 1080 },
{ name: 'Tablet', width: 768, height: 1024 },
{ name: 'Mobile', width: 375, height: 667 }
];
for (const viewport of viewports) {
console.log(`Testing ${viewport.name} (${viewport.width}x${viewport.height})`);
await page.setViewportSize({
width: viewport.width,
height: viewport.height
});
await page.goto(TARGET_URL);
await page.waitForTimeout(1000);
await page.screenshot({
path: `/tmp/${viewport.name.toLowerCase()}.png`,
fullPage: true
});
}
console.log('✅ All viewports tested');
await browser.close();
})();
```
## Inline Execution (Simple Tasks)
For quick one-off tasks, you can execute code inline without creating files:
```bash
# Take a quick screenshot
cd $SKILL_DIR && node run.js "
const browser = await chromium.launch({ headless: false });
const page = await browser.newPage();
await page.goto('http://localhost:3001');
await page.screenshot({ path: '/tmp/quick-screenshot.png', fullPage: true });
console.log('Screenshot saved');
await browser.close();
"
```
**When to use inline vs files:**
- **Inline**: Quick one-off tasks (screenshot, check if element exists, get page title)
- **Files**: Complex tests, responsive design checks, anything user might want to re-run
## Available Helpers
Optional utility functions in `lib/helpers.js`:
```javascript
const helpers = require('./lib/helpers');
// Detect running dev servers (CRITICAL - use this first!)
const servers = await helpers.detectDevServers();
console.log('Found servers:', servers);
// Safe click with retry
await helpers.safeClick(page, 'button.submit', { retries: 3 });
// Safe type with clear
await helpers.safeType(page, '#username', 'testuser');
// Take timestamped screenshot
await helpers.takeScreenshot(page, 'test-result');
// Handle cookie banners
await helpers.handleCookieBanner(page);
// Extract table data
const data = await helpers.extractTableData(page, 'table.results');
```
See `lib/helpers.js` for full list.
## Advanced Usage
For comprehensive Playwright API documentation, see [API_REFERENCE.md](API_REFERENCE.md):
- Selectors & Locators best practices
- Network interception & API mocking
- Authentication & session management
- Visual regression testing
- Mobile device emulation
- Performance testing
- Debugging techniques
- CI/CD integration
## Tips
- **CRITICAL: Detect servers FIRST** - Always run `detectDevServers()` before writing test code for localhost testing
- **Use /tmp for test files** - Write to `/tmp/playwright-test-*.js`, never to skill directory or user's project
- **Parameterize URLs** - Put detected/provided URL in a `TARGET_URL` constant at the top of every script
- **DEFAULT: Visible browser** - Always use `headless: false` unless user explicitly asks for headless mode
- **Headless mode** - Only use `headless: true` when user specifically requests "headless" or "background" execution
- **Slow down:** Use `slowMo: 100` to make actions visible and easier to follow
- **Wait strategies:** Use `waitForURL`, `waitForSelector`, `waitForLoadState` instead of fixed timeouts
- **Error handling:** Always use try-catch for robust automation
- **Console output:** Use `console.log()` to track progress and show what's happening
## Troubleshooting
**Playwright not installed:**
```bash
cd $SKILL_DIR && npm run setup
```
**Module not found:**
Ensure running from skill directory via `run.js` wrapper
**Browser doesn't open:**
Check `headless: false` and ensure display available
**Element not found:**
Add wait: `await page.waitForSelector('.element', { timeout: 10000 })`
## Example Usage
```
User: "Test if the marketing page looks good"
Claude: I'll test the marketing page across multiple viewports. Let me first detect running servers...
[Runs: detectDevServers()]
[Output: Found server on port 3001]
I found your dev server running on http://localhost:3001
[Writes custom automation script to /tmp/playwright-test-marketing.js with URL parameterized]
[Runs: cd $SKILL_DIR && node run.js /tmp/playwright-test-marketing.js]
[Shows results with screenshots from /tmp/]
```
```
User: "Check if login redirects correctly"
Claude: I'll test the login flow. First, let me check for running servers...
[Runs: detectDevServers()]
[Output: Found servers on ports 3000 and 3001]
I found 2 dev servers. Which one should I test?
- http://localhost:3000
- http://localhost:3001
User: "Use 3001"
[Writes login automation to /tmp/playwright-test-login.js]
[Runs: cd $SKILL_DIR && node run.js /tmp/playwright-test-login.js]
[Reports: ✅ Login successful, redirected to /dashboard]
```
## Notes
- Each automation is custom-written for your specific request
- Not limited to pre-built scripts - any browser task possible
- Auto-detects running dev servers to eliminate hardcoded URLs
- Test scripts written to `/tmp` for automatic cleanup (no clutter)
- Code executes reliably with proper module resolution via `run.js`
- Progressive disclosure - API_REFERENCE.md loaded only when advanced features needed

26
skills/playwright-skill/package.json Normal file
View File

@@ -0,0 +1,26 @@
{
"name": "playwright-skill",
"version": "4.0.2",
"description": "General-purpose browser automation with Playwright for Claude Code with auto-detection and smart test management",
"author": "lackeyjb",
"main": "run.js",
"scripts": {
"setup": "npm install && npx playwright install chromium",
"install-all-browsers": "npx playwright install chromium firefox webkit"
},
"keywords": [
"playwright",
"automation",
"browser-testing",
"web-automation",
"claude-skill",
"general-purpose"
],
"dependencies": {
"playwright": "^1.48.0"
},
"engines": {
"node": ">=14.0.0"
},
"license": "MIT"
}

208
skills/playwright-skill/run.js Executable file
View File

@@ -0,0 +1,208 @@
#!/usr/bin/env node
/**
* Universal Playwright Executor for Claude Code
*
* Executes Playwright automation code from:
* - File path: node run.js script.js
* - Inline code: node run.js 'await page.goto("...")'
* - Stdin: cat script.js | node run.js
*
* Ensures proper module resolution by running from skill directory.
*/
const fs = require('fs');
const path = require('path');
const { execSync } = require('child_process');
// Change to skill directory for proper module resolution
process.chdir(__dirname);
/**
* Check if Playwright is installed
*/
function checkPlaywrightInstalled() {
try {
require.resolve('playwright');
return true;
} catch (e) {
return false;
}
}
/**
* Install Playwright if missing
*/
function installPlaywright() {
console.log('📦 Playwright not found. Installing...');
try {
execSync('npm install', { stdio: 'inherit', cwd: __dirname });
execSync('npx playwright install chromium', { stdio: 'inherit', cwd: __dirname });
console.log('✅ Playwright installed successfully');
return true;
} catch (e) {
console.error('❌ Failed to install Playwright:', e.message);
console.error('Please run manually: cd', __dirname, '&& npm run setup');
return false;
}
}
/**
* Get code to execute from various sources
*/
function getCodeToExecute() {
const args = process.argv.slice(2);
// Case 1: File path provided
if (args.length > 0 && fs.existsSync(args[0])) {
const filePath = path.resolve(args[0]);
console.log(`📄 Executing file: ${filePath}`);
return fs.readFileSync(filePath, 'utf8');
}
// Case 2: Inline code provided as argument
if (args.length > 0) {
console.log('⚡ Executing inline code');
return args.join(' ');
}
// Case 3: Code from stdin
if (!process.stdin.isTTY) {
console.log('📥 Reading from stdin');
return fs.readFileSync(0, 'utf8');
}
// No input
console.error('❌ No code to execute');
console.error('Usage:');
console.error(' node run.js script.js # Execute file');
console.error(' node run.js "code here" # Execute inline');
console.error(' cat script.js | node run.js # Execute from stdin');
process.exit(1);
}
/**
* Clean up old temporary execution files from previous runs
*/
function cleanupOldTempFiles() {
try {
const files = fs.readdirSync(__dirname);
const tempFiles = files.filter(f => f.startsWith('.temp-execution-') && f.endsWith('.js'));
if (tempFiles.length > 0) {
tempFiles.forEach(file => {
const filePath = path.join(__dirname, file);
try {
fs.unlinkSync(filePath);
} catch (e) {
// Ignore errors - file might be in use or already deleted
}
});
}
} catch (e) {
// Ignore directory read errors
}
}
/**
* Wrap code in async IIFE if not already wrapped
*/
function wrapCodeIfNeeded(code) {
// Check if code already has require() and async structure
const hasRequire = code.includes('require(');
const hasAsyncIIFE = code.includes('(async () => {') || code.includes('(async()=>{');
// If it's already a complete script, return as-is
if (hasRequire && hasAsyncIIFE) {
return code;
}
// If it's just Playwright commands, wrap in full template
if (!hasRequire) {
return `
const { chromium, firefox, webkit, devices } = require('playwright');
const helpers = require('./lib/helpers');
(async () => {
try {
${code}
} catch (error) {
console.error('❌ Automation error:', error.message);
if (error.stack) {
console.error(error.stack);
}
process.exit(1);
}
})();
`;
}
// If has require but no async wrapper
if (!hasAsyncIIFE) {
return `
(async () => {
try {
${code}
} catch (error) {
console.error('❌ Automation error:', error.message);
if (error.stack) {
console.error(error.stack);
}
process.exit(1);
}
})();
`;
}
return code;
}
/**
* Main execution
*/
async function main() {
console.log('🎭 Playwright Skill - Universal Executor\n');
// Clean up old temp files from previous runs
cleanupOldTempFiles();
// Check Playwright installation
if (!checkPlaywrightInstalled()) {
const installed = installPlaywright();
if (!installed) {
process.exit(1);
}
}
// Get code to execute
const rawCode = getCodeToExecute();
const code = wrapCodeIfNeeded(rawCode);
// Create temporary file for execution
const tempFile = path.join(__dirname, `.temp-execution-${Date.now()}.js`);
try {
// Write code to temp file
fs.writeFileSync(tempFile, code, 'utf8');
// Execute the code
console.log('🚀 Starting automation...\n');
require(tempFile);
// Note: Temp file will be cleaned up on next run
// This allows long-running async operations to complete safely
} catch (error) {
console.error('❌ Execution failed:', error.message);
if (error.stack) {
console.error('\n📋 Stack trace:');
console.error(error.stack);
}
process.exit(1);
}
}
// Run main function
main().catch(error => {
console.error('❌ Fatal error:', error.message);
process.exit(1);
});