Initial commit

commands/gh-pages.md

@@ -0,0 +1,163 @@
+---
+description: Create a professional GitHub Pages (index.html) in docs/ to showcase the project
+arguments:
+  - name: theme
+    description: Theme to use for the page (dark or light)
+    required: false
+    default: dark
+---
+
+# GitHub Pages Generator Command
+
+Generate a professional, marketing-focused GitHub Pages documentation site for the current project.
+
+## Objective
+
+Create a professional `index.html` file in the `docs/` directory that serves dual purposes:
+1. **Marketing page**: Attractive showcase of the project with clear value proposition
+2. **Documentation cheatsheet**: Quick reference for features, inputs/outputs, and usage examples
+
+## Theme Inspiration
+
+A theme template will be **automatically injected into the context** when you execute this command. The template is selected based on the `theme` argument:
+
+- **theme=dark** (default): Modern dark theme with gradient accents
+- **theme=light**: Clean light theme with purple gradient
+
+**Important**: The injected template is an inspiration source, not a strict template to copy. Use it to guide the visual style, color palette, and overall aesthetic, but adapt the structure and content to fit the specific project. The goal is to create something that feels similar in style while being tailored to the project's needs.
+
+## Requirements
+
+### Structure & Content
+
+**Note**: Adapt sections based on what's relevant to the project. Not all projects need every section.
+
+1. **Hero Section** (Required)
+   - Project name as main heading with **gradient text** (MUST use CSS gradient)
+   - Clear, concise tagline explaining what the project does
+   - Call-to-action buttons (GitHub repo, documentation, etc.)
+
+2. **Features Section** (Required)
+   - Grid layout showcasing key features
+   - Icons or visual elements for each feature
+   - Brief descriptions (1-2 sentences max)
+
+3. **Usage/Quick Start Section** (Optional - include if project has code examples)
+   - Practical code examples showing real-world usage
+   - Multiple workflow examples if applicable (dev, staging, production)
+   - ALL code examples MUST use syntax highlighting with colored text
+
+4. **Reference Section** (Optional - include if project has inputs/outputs/parameters)
+   - Complete inputs/outputs documentation
+   - Organized in clear categories
+   - Parameter names, descriptions, and defaults
+   - Mark required vs optional parameters clearly
+
+5. **Footer** (Required)
+   - Links to GitHub repo, issues, releases, documentation
+   - Author/creator credit
+
+### Code Highlighting
+
+**CRITICAL**: All code blocks, inline code, and usage examples MUST use colored syntax highlighting:
+
+- Use semantic CSS classes for syntax elements (keywords, strings, variables, comments)
+- Define color schemes in `<style>` that match the chosen theme
+- Examples should be visually distinct and easy to scan
+- Use monospace fonts for all code
+
+### Design Principles
+
+- **Self-contained**: Single HTML file with embedded CSS (no external dependencies)
+- **Responsive**: Mobile-friendly with appropriate media queries
+- **Professional**: Clean, modern design that builds trust
+- **Scannable**: Clear hierarchy, whitespace, and visual structure
+- **Accessible**: Proper semantic HTML, good contrast ratios
+
+### Theme Consistency
+
+- Use the selected theme as visual inspiration, not a strict copy
+- Match the general color palette and aesthetic feel
+- Maintain consistent spacing, typography, and component styling
+- Adapt gradients, borders, shadows to fit the theme aesthetic
+- **CRITICAL**: The project name/logo (h1) MUST always use a gradient effect with `background: linear-gradient(...)` and `background-clip: text`
+
+## Process
+
+1. **Analyze the project**:
+   - Read README.md, action.yml, or relevant configuration files
+   - Identify key features, inputs, outputs, and usage patterns
+   - Understand the target audience and use cases
+
+2. **Study the injected theme template**:
+   - The template has been automatically injected into the context based on the theme argument
+   - Extract color schemes, typography, component patterns as guidance
+   - Note the syntax highlighting approach
+   - Use as inspiration, not as a strict template to copy
+
+3. **Generate content**:
+   - Write clear, benefit-focused copy for features
+   - Create practical, realistic code examples (if relevant)
+   - Document all parameters comprehensively (if the project has inputs/outputs)
+   - Apply colored syntax highlighting to ALL code
+   - Include only sections that make sense for this specific project
+
+4. **Create the file**:
+   - Generate `docs/index.html` in the project root
+   - Ensure all sections are complete and polished
+   - Validate HTML structure and CSS styling
+
+## Output Location
+
+Always create the file at: `docs/index.html` (relative to project root)
+
+If the `docs/` directory doesn't exist, create it first.
+
+## Example Invocation
+
+```
+/common:gh-pages theme=dark
+/common:gh-pages theme=light
+/common:gh-pages
+```
+
+## Important Notes
+
+- Focus on clarity and scannability over verbosity
+- Every code snippet should have colored syntax highlighting
+- Balance marketing appeal with technical accuracy
+- Make it easy for users to find the information they need quickly
+- The page should work standalone (no external JS/CSS dependencies)
+- **The project name/title MUST use a gradient effect** - this is non-negotiable
+- Adapt the structure to fit the project - not every project needs usage examples or reference docs
+- Use theme files as inspiration for style, not as rigid templates to copy exactly
+
+## Encoding Guidelines
+
+**CRITICAL**: To prevent encoding issues in generated HTML files:
+
+1. **Use HTML entities for special characters**:
+   - For emojis in HTML: Use decimal HTML entities (e.g., `&#127919;` for 🎯, `&#9889;` for ⚡, `&#128260;` for 🔔)
+   - For bullet separators: Use `&bull;` instead of the • character
+   - For arrows: Use `&rarr;` for → and `&larr;` for ←
+   - For other special symbols: Use HTML entity equivalents
+
+2. **Always include proper charset**:
+   - Ensure `<meta charset="UTF-8" />` is in the `<head>` section
+
+3. **Common HTML entities to use**:
+   - `&bull;` for bullet points (•)
+   - `&rarr;` for right arrow (→)
+   - `&larr;` for left arrow (←)
+   - `&mdash;` for em dash (—)
+   - `&ndash;` for en dash (–)
+   - `&hellip;` for ellipsis (…)
+   - `&copy;` for copyright (©)
+   - `&trade;` for trademark (™)
+
+4. **For emojis**: Convert to decimal HTML entities using the Unicode code point
+   - Find emoji code point (e.g., U+1F3AF for 🎯)
+   - Convert to decimal: `&#127919;`
+   - Or use hex format: `&#x1F3AF;`
+
+This ensures the HTML file displays correctly across all systems and browsers without encoding corruption.

commands/hello.md

@@ -0,0 +1,8 @@
+---
+description: Greet the user with a personalized message
+---
+
+# Hello Command
+
+Greet the user warmly and ask how you can help them today. Make the greeting personal and encouraging.
+Don't forget to tell your name and that you are an helpful coding assistant

commands/issue.md

@@ -0,0 +1,82 @@
+---
+description: Create a PR to fix the current GitHub issue
+---
+
+# GitHub Issue to PR Command
+
+Transform the current GitHub issue into a pull request. This command is designed to work with the `claude-code-action` GitHub Action where issue context is automatically provided.
+
+## Objective
+
+1. Treat the issue description and comments as the implementation request
+2. Implement all necessary changes to address the issue
+3. Create a pull request using the `gh` CLI with proper formatting
+
+## Comment Priority
+
+When reviewing the issue context, prioritize information in this order:
+
+1. **First comment (issue description)** - This is the PRIMARY requirement and most important source of truth
+2. **Comments from the repository owner** - Highest priority as they have final authority on requirements and direction
+3. **Follow-up comments from the issue author** - High priority, often contains clarifications or additional requirements
+4. **Comments from other users** - Lower priority but still useful for additional context and edge cases
+
+## Process
+
+1. **Understand the requirements**:
+
+   - Focus primarily on the first comment (issue description) as the main request
+   - Give highest priority to comments from the repository owner
+   - Review follow-up comments from the issue author for clarifications
+   - Consider comments from other users as supplementary context
+   - Identify what needs to be fixed or implemented
+   - Plan the necessary changes
+
+2. **Implement the solution**:
+
+   - Make all necessary code changes to address the issue
+   - Follow existing code patterns and conventions
+   - Ensure changes fully address the requirements
+
+3. **Create the pull request**:
+   - Create a new branch for the changes (if needed)
+   - Commit all changes with a descriptive commit message
+   - Push the branch to remote
+   - Create PR using `gh pr create` with the following body format:
+
+```markdown
+## Summary
+
+[Brief 1-2 sentence summary of what was changed and why]
+
+## Changes
+
+- [Specific change 1]
+- [Specific change 2]
+- [Specific change 3]
+
+Fixes #<issue_number>
+```
+
+**IMPORTANT**: Do NOT add any footer text like "Generated with Claude Code" or "Co-Authored-By: Claude" to the PR body or commit messages. Keep the PR body clean and professional with only the content shown above.
+
+4. **Output**:
+   - Display the URL of the newly created pull request
+
+## Example Invocation
+
+```
+/common:issue
+```
+
+## Important Notes
+
+- **CRITICAL**: You MUST create the pull request using `gh pr create` command - this is a mandatory step that cannot be skipped or deferred
+- **CRITICAL**: The branch name **must** be `jd/issue-####/<brief-title-of-the-pr>`, if branch already exists, append an incremental number, ex: `-#` to make it unique
+- The PR body **must** include `Fixes #<issue_number>` to auto-link and auto-close the issue
+- Changes should fully address all requirements mentioned in the issue
+- The PR summary should be concise but informative (1-2 sentences)
+- All changes must be committed and pushed before creating the PR
+- Follow the repository's existing commit and PR conventions
+- Use `gh pr create` to create the pull request (not manual git operations)
+- **YOU ARE ALLOWED** to "Modify files in the .github/workflows directory" and create PR using `gh`

commands/readme.md

@@ -0,0 +1,36 @@
+---
+description: Create / Update a professional README
+arguments:
+  - name: folder_path
+    description: The folder path where the README.md should be created/updated
+    required: false
+    default: repository root
+---
+
+# README Command
+
+Create or update a professional README.md file.
+
+## Usage
+
+```
+/common:readme
+/common:readme folder_path=./path/to/folder
+/common:readme folder_path=plugins/common
+```
+
+## Instructions
+
+1. If the `folder_path` argument is provided, use that as the target directory. Otherwise, use the repository root.
+2. Analyze the contents of the specified folder to understand the project structure and purpose.
+3. Create or update the README.md file in that folder with:
+   - Clear project title and description
+   - Installation instructions (if applicable)
+   - Usage examples
+   - Key features
+   - Project structure overview
+   - Any other relevant sections based on the folder contents
+4. Ensure the README is well-formatted using proper markdown syntax.
+5. Keep it brief and to the point
+6. DO NOT use emoji unless it is relevant (like ✅, ❌, 🟢, 🔴, etc.)
+7. NO code of conduct and NO contributing