@abarcenas/ai-workflow-template 1.1.0

package/.github/skills/context-map/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: context-map
+description: "Generate a map of all files relevant to a task before making changes"
+---
+
+# Context Map
+
+Before implementing any changes, analyze the codebase and create a context map.
+
+## Task
+
+{{task_description}}
+
+## Instructions
+
+1. Search the codebase for files related to this task
+2. Identify direct dependencies (imports/exports)
+3. Find related tests
+4. Look for similar patterns in existing code
+
+## Output Format
+
+```markdown
+## Context Map
+
+### Files to Modify
+
+| File         | Purpose     | Changes Needed |
+| ------------ | ----------- | -------------- |
+| path/to/file | description | what changes   |
+
+### Dependencies (may need updates)
+
+| File        | Relationship                 |
+| ----------- | ---------------------------- |
+| path/to/dep | imports X from modified file |
+
+### Test Files
+
+| Test         | Coverage                     |
+| ------------ | ---------------------------- |
+| path/to/test | tests affected functionality |
+
+### Reference Patterns
+
+| File            | Pattern           |
+| --------------- | ----------------- |
+| path/to/similar | example to follow |
+
+### Risk Assessment
+
+- [ ] Breaking changes to public API
+- [ ] Database migrations needed
+- [ ] Configuration changes required
+```
+
+Do not proceed with implementation until this map is reviewed.

package/.github/skills/conventional-commit/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: conventional-commit
+description: "Prompt and workflow for generating conventional commit messages using a structured XML format. Guides users to create standardized, descriptive commit messages in line with the Conventional Commits specification, including instructions, examples, and validation."
+---
+
+### Instructions
+
+```xml
+	<description>This file contains a prompt template for generating conventional commit messages. It provides instructions, examples, and formatting guidelines to help users write standardized, descriptive commit messages in accordance with the Conventional Commits specification.</description>
+```
+
+### Workflow
+
+**Follow these steps:**
+
+1. Run `git status` to review changed files.
+2. Run `git diff` or `git diff --cached` to inspect changes.
+3. Stage your changes with `git add <file>`.
+4. Construct your commit message using the following XML structure.
+5. After generating your commit message, Copilot will automatically run the following command in your integrated terminal (no confirmation needed):
+
+```bash
+git commit -m "type(scope): description"
+```
+
+6. Just execute this prompt and Copilot will handle the commit for you in the terminal.
+
+### Commit Message Structure
+
+```xml
+<commit-message>
+	<type>feat|fix|docs|style|refactor|perf|test|build|ci|chore|revert</type>
+	<scope>()</scope>
+	<description>A short, imperative summary of the change</description>
+	<body>(optional: more detailed explanation)</body>
+	<footer>(optional: e.g. BREAKING CHANGE: details, or issue references)</footer>
+</commit-message>
+```
+
+### Examples
+
+```xml
+<examples>
+	<example>feat(parser): add ability to parse arrays</example>
+	<example>fix(ui): correct button alignment</example>
+	<example>docs: update README with usage instructions</example>
+	<example>refactor: improve performance of data processing</example>
+	<example>chore: update dependencies</example>
+	<example>feat!: send email on registration (BREAKING CHANGE: email service required)</example>
+</examples>
+```
+
+### Validation
+
+```xml
+<validation>
+	<type>Must be one of the allowed types. See <reference>https://www.conventionalcommits.org/en/v1.0.0/#specification</reference></type>
+	<scope>Optional, but recommended for clarity.</scope>
+	<description>Required. Use the imperative mood (e.g., "add", not "added").</description>
+	<body>Optional. Use for additional context.</body>
+	<footer>Use for breaking changes or issue references.</footer>
+</validation>
+```
+
+### Final Step
+
+```xml
+<final-step>
+	<cmd>git commit -m "type(scope): description"</cmd>
+	<note>Replace with your constructed message. Include body and footer if needed.</note>
+</final-step>
+```

package/.github/skills/create-readme/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: create-readme
+description: "Create a README.md file for the project"
+---
+
+## Role
+
+You're a senior expert software engineer with extensive experience in open source projects. You always make sure the README files you write are appealing, informative, and easy to read.
+
+## Task
+
+1. Take a deep breath, and review the entire project and workspace, then create a comprehensive and well-structured README.md file for the project.
+2. Take inspiration from these readme files for the structure, tone and content:
+   - https://raw.githubusercontent.com/Azure-Samples/serverless-chat-langchainjs/refs/heads/main/README.md
+   - https://raw.githubusercontent.com/Azure-Samples/serverless-recipes-javascript/refs/heads/main/README.md
+   - https://raw.githubusercontent.com/sinedied/run-on-output/refs/heads/main/README.md
+   - https://raw.githubusercontent.com/sinedied/smoke/refs/heads/main/README.md
+3. Do not overuse emojis, and keep the readme concise and to the point.
+4. Do not include sections like "LICENSE", "CONTRIBUTING", "CHANGELOG", etc. There are dedicated files for those sections.
+5. Use GFM (GitHub Flavored Markdown) for formatting, and GitHub admonition syntax (https://github.com/orgs/community/discussions/16925) where appropriate.
+6. If you find a logo or icon for the project, use it in the readme's header.

package/.github/skills/editorconfig/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: editorconfig
+description: "Generates a comprehensive and best-practice-oriented .editorconfig file based on project analysis and user preferences."
+---
+
+## 📜 MISSION
+
+You are an **EditorConfig Expert**. Your mission is to create a robust, comprehensive, and best-practice-oriented `.editorconfig` file. You will analyze the user's project structure and explicit requirements to generate a configuration that ensures consistent coding styles across different editors and IDEs. You must operate with absolute precision and provide clear, rule-by-rule explanations for your configuration choices.
+
+## 📝 DIRECTIVES
+
+1.  **Analyze Context**: Before generating the configuration, you MUST analyze the provided project structure and file types to infer the languages and technologies being used.
+2.  **Incorporate User Preferences**: You MUST adhere to all explicit user requirements. If any requirement conflicts with a common best practice, you will still follow the user's preference but make a note of the conflict in your explanation.
+3.  **Apply Universal Best Practices**: You WILL go beyond the user's basic requirements and incorporate universal best practices for `.editorconfig` files. This includes settings for character sets, line endings, trailing whitespace, and final newlines.
+4.  **Generate Comprehensive Configuration**: The generated `.editorconfig` file MUST be well-structured and cover all relevant file types found in the project. Use glob patterns (`*`, `**.js`, `**.py`, etc.) to apply settings appropriately.
+5.  **Provide Rule-by-Rule Explanation**: You MUST provide a detailed, clear, and easy-to-understand explanation for every single rule in the generated `.editorconfig` file. Explain what the rule does and why it's a best practice.
+6.  **Output Format**: The final output MUST be presented in two parts:
+    - A single, complete code block containing the `.editorconfig` file content.
+    - A "Rule-by-Rule Explanation" section using Markdown for clarity.
+
+## 🧑‍💻 USER PREFERENCES
+
+- **Indentation Style**: Use spaces, not tabs.
+- **Indentation Size**: 2 spaces.
+
+## 🚀 EXECUTION
+
+Begin by acknowledging the user's preferences. Then, proceed directly to generating the `.editorconfig` file and the detailed explanation as per the specified output format.
+
+### Example Output Structure:
+
+Here is the `.editorconfig` file tailored to your project:
+
+```editorconfig
+# .editorconfig
+
+# Top-most EditorConfig file
+root = true
+
+[*]
+indent_style = space
+indent_size = 2
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[*.md]
+trim_trailing_whitespace = false
+```
+
+### Rule-by-Rule Explanation
+
+- `root = true`: This is a best practice that stops the EditorConfig search in the current directory. Without it, EditorConfig would continue searching parent directories, which could lead to unexpected behavior.
+- `[*]`: This is a universal glob pattern that applies the following rules to ALL files in the project.
+- `indent_style = space`: As requested, this sets the indentation to use spaces instead of tabs.
+- `indent_size = 2`: As requested, this sets the indentation size to 2 spaces.
+- `end_of_line = lf`: This standardizes line endings to Line Feed (LF), which is the standard for macOS, Linux, and modern Windows (WSL), preventing issues with version control systems.
+- `charset = utf-8`: This sets the character encoding to UTF-8, the universal standard, ensuring files can be read and written correctly across all systems.
+- `trim_trailing_whitespace = true`: This automatically removes any whitespace characters at the end of lines, which keeps the code clean and avoids unnecessary diffs in version control.
+- `insert_final_newline = true`: This ensures that every file ends with a single newline character, a POSIX standard that prevents certain scripting and concatenation issues.
+- `[*.md]`: This glob pattern applies specific rules only to Markdown files.
+- `trim_trailing_whitespace = false`: This overrides the universal setting for Markdown files. It's disabled because trailing whitespace can be significant in Markdown (e.g., for creating hard line breaks).