🌟 [Major]: Process-PSModule v5

.github/copilot-instructions.md

@@ -49,4 +49,11 @@ pwsh -Command "ls -Recurse"
 gh issue create --title "Feature" --body "Description"
 ```
 
+## Other instructions
+
+| Tech | Instruction file |
+|------|------------------|
+| PowerShell | [pwsh.instructions.md](./instructions/pwsh.instructions.md) |
+| Markdown | [md.instructions.md](./instructions/md.instructions.md) |
+
 <!-- MANUAL ADDITIONS END -->

.github/prompts/implement.prompt.md

@@ -83,131 +83,136 @@ $ARGUMENTS
    - Confirm the implementation follows the technical plan
    - Report final status with summary of completed work
 9. Update the constitution:
-   - Read the [Constitution](../../.specify/memory/constitution.md) file.
-   - Read the [constitution prompt](./constitution.prompt.md) for guidance on how to update the constitution.
-   - Update the constitution file with details on what has been implemented in this PR
-   - Document the functionality that was added or changed, remove the sections that are no longer relevant
-   - Ensure the constitution reflects the current state of the codebase
+  - Read the [Constitution](../../.specify/memory/constitution.md) file.
+  - Read the [constitution prompt](./constitution.prompt.md) for guidance on how to update the constitution.
+  - Update the constitution file with details on what has been implemented in this PR
+  - Document the functionality that was added or changed, remove the sections that are no longer relevant
+  - Ensure the constitution reflects the current state of the codebase
 10. Update the CHANGELOG:
-   - **Locate or create CHANGELOG.md** in the repository root
-   - **Add a new entry** for this feature/change following the Keep a Changelog format
-   - **Structure the entry** with:
-     * Version header (use `[Unreleased]` if version isn't determined yet)
-     * Date (current date)
-     * Category sections as applicable:
-       - `### Added` - for new features
-       - `### Changed` - for changes in existing functionality
-       - `### Deprecated` - for soon-to-be removed features
-       - `### Removed` - for now removed features
-       - `### Fixed` - for any bug fixes
-       - `### Security` - for vulnerability fixes
-     * Write entries from the user's perspective, focusing on what changed and why it matters
-     * Include brief usage examples where helpful
-     * Link to the PR or issue: `[#<issue-number>]`
-   - **Keep it concise**: Focus on user-impacting changes, not internal refactoring details
+  - **Locate or create CHANGELOG.md** in the repository root
+  - **Add a new entry** for this feature/change following the Keep a Changelog format
+  - **Structure the entry** with:
+    - Version header (use `[Unreleased]` if version isn't determined yet)
+    - Date (current date)
+    - Category sections as applicable:
+      - `### Added` - for new features
+      - `### Changed` - for changes in existing functionality
+      - `### Deprecated` - for soon-to-be removed features
+      - `### Removed` - for now removed features
+      - `### Fixed` - for any bugfixes
+      - `### Security` - for vulnerability fixes
+    - Write entries from the user's perspective, focusing on what changed and why it matters
+    - Include brief usage examples where helpful
+    - Link to the PR or issue: `[#<issue-number>]`
+  - **Keep it concise**: Focus on user-impacting changes, not internal refactoring details
 11. Final commit and push:
-    - **Stage all implemented changes** including:
-      * All source code files created or modified
-      * Updated tasks.md with completed task markers [X]
-      * Updated CHANGELOG.md
-      * Updated constitution.md
-      * Any configuration or documentation files
-    - **Create a descriptive commit message**:
-      * Use conventional commit format: `<type>(<scope>): <description>`
-      * Types: feat, fix, docs, refactor, test, chore
-      * Include reference to issue: `Fixes #<issue-number>`
-    - **Push the branch** to remote
-    - Verify the push completed successfully
+  - **Stage all implemented changes** including:
+    - All source code files created or modified
+    - Updated tasks.md with completed task markers [X]
+    - Updated CHANGELOG.md
+    - Updated constitution.md
+    - Any configuration or documentation files
+  - **Create a descriptive commit message**:
+    - Use conventional commit format: `<type>(<scope>): <description>`
+    - Types: feat, fix, docs, refactor, test, chore
+    - Include reference to issue: `Fixes #<issue-number>`
+  - **Push the branch** to remote
+  - Verify the push completed successfully
 12. Update PR description with release notes:
-   - **Determine workflow mode and target repository**:
-     - Check if `.fork-info.json` exists in the feature directory (same directory as spec.md)
-     - **If exists** (fork mode):
-       - Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty)
-       - If validation fails, halt and instruct user: "Invalid fork configuration in `.fork-info.json`. Please run `/specify` again with complete fork information: upstream owner, upstream repo."
-       - Use `upstream_owner/upstream_repo` for all GitHub operations
-     - **If not exists** (local mode - default):
-       - Use the current repository (origin) for all GitHub operations
-   - **Determine PR operation**:
-     - If PR already exists for this branch, UPDATE it (description, status, labels)
-     - If no PR exists, CREATE a new one
-   - **Target branch**: The PR must be against the default branch
-   - **PR status**: The PR must not be draft, it should be ready for review
-   - **Retrieve the issue title**: Get the title from the linked GitHub issue (created in `/specify`) from the target repository
-   - **Use the same title for the PR**: Verify the PR title matches the issue title exactly. If they differ, update the PR title to match the issue.
-   - If unable to retrieve the issue title, determine the PR type and icon based on the changes:
-     | Type of change | Icon | Label |
-     |-|-|-|
-     | Docs | 📖 | Docs |
-     | Fix | 🪲 | Fix, Patch |
-     | Security fix | ⚠️ | Fix |
-     | Patch | 🩹 | Patch |
-     | Feature | 🚀 | Minor |
-     | Breaking change | 🌟 | Major |
-   - Fallback PR title format (if issue title unavailable): `<Icon> [Type of change]: <Short description>`
-   - **REPLACE the entire PR description with release notes**:
-     * **IMPORTANT**: Clear the existing PR description completely (including task list) and replace it with the release notes
-     * This ensures the PR description is ready to be used as GitHub Release notes when merged to main
-     * **Opening summary** (1-2 paragraphs):
-       - Start with what was accomplished in user-focused language
-       - Write in past tense: "Added...", "Improved...", "Fixed..."
-       - Focus on the "why" - what problem does this solve or what capability does it enable?
-       - Mention the user impact - who benefits and how?
-       - At the end, add: "Fixes #<issue-number>"
-     * **What's Changed** section:
-       - 3-5 bullet points highlighting key changes from the user's perspective
-       - Focus on capabilities, not implementation details
-       - Example: "✨ Added support for custom templates" not "Created new Template class"
-     * **Usage** section (if applicable):
-       - Brief example showing how to use the new functionality
-       - Keep it minimal - just enough to get started
-       - Use code blocks for commands or code snippets
-     * **Breaking Changes** section (if applicable):
-       - Clear warning about what breaks
-       - Migration guidance for users
-       - What they need to change in their code
-     * **Technical Notes** section (optional, for maintainers):
-       - Brief implementation notes if relevant for reviewers
-       - Dependencies added or updated
-       - Architecture decisions
-     * **Tone and style**:
-       - Professional and concise
-       - Avoid jargon and internal terminology
-       - Write for the end user, not just developers
-       - This description will be used in release notes
-   - **Apply appropriate label(s)** based on the type of change
-   - **Link the PR** to the associated issue
-   - **Update `.fork-info.json`** (if it exists) with the latest PR number (if not already present)
-   **GitHub Integration**: If GitHub tools or integrations are available (such as GitHub MCP Server or other GitHub integrations), use them to update the PR description in the target repository. If not available, provide this fallback command:
-   ```bash
-   # Replace PR description with release notes
-   # If fork: gh pr edit <PR-number> --repo <upstream_owner>/<upstream_repo> --body "<release-note-description>"
-   # If local: gh pr edit <PR-number> --body "<release-note-description>"
-   gh pr edit <PR-number> --body "<release-note-description>"
-   ```
+  - **Determine workflow mode and target repository**:
+    - Check if `.fork-info.json` exists in the feature directory (same directory as spec.md)
+    - **If exists** (fork mode):
+      - Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty)
+      - If validation fails, halt and instruct user: "Invalid fork configuration in `.fork-info.json`. Please run `/specify` again with complete fork information: upstream owner, upstream repo."
+      - Use `upstream_owner/upstream_repo` for all GitHub operations
+    - **If not exists** (local mode - default):
+      - Use the current repository (origin) for all GitHub operations
+  - **Determine PR operation**:
+    - If PR already exists for this branch, UPDATE it (description, status, labels)
+    - If no PR exists, CREATE a new one
+  - **Target branch**: The PR must be against the default branch
+  - **PR status**: The PR must not be draft, it should be ready for review
+  - **Retrieve the issue title**: Get the title from the linked GitHub issue (created in `/specify`) from the target repository
+  - **Use the same title for the PR**: Verify the PR title matches the issue title exactly. If they differ, update the PR title to match the issue.
+  - If unable to retrieve the issue title, determine the PR type and icon based on the changes:
+
+  | Type of change | Icon | Label |
+  |-|-|-|
+  | Docs | 📖 | Docs |
+  | Fix | 🪲 | Fix, Patch |
+  | Security fix | ⚠️ | Fix |
+  | Patch | 🩹 | Patch |
+  | Feature | 🚀 | Minor |
+  | Breaking change | 🌟 | Major |
+
+  - Fallback PR title format (if issue title unavailable): `<Icon> [Type of change]: <Short description>`
+  - **REPLACE the entire PR description with release notes**:
+    - **IMPORTANT**: Clear the existing PR description completely (including task list) and replace it with the release notes
+    - This ensures the PR description is ready to be used as GitHub Release notes when merged to main
+    - **Opening summary** (1-2 paragraphs):
+      - Start with what was accomplished in user-focused language
+      - Write in past tense: "Added...", "Improved...", "Fixed..."
+      - Focus on the "why" - what problem does this solve or what capability does it enable?
+      - Mention the user impact - who benefits and how?
+      - At the end, add: "Fixes #<issue-number>"
+    - **What's Changed** section:
+      - 3-5 bullet points highlighting key changes from the user's perspective
+      - Focus on capabilities, not implementation details
+      - Example: "✨ Added support for custom templates" not "Created new Template class"
+    - **Usage** section (if applicable):
+      - Brief example showing how to use the new functionality
+      - Keep it minimal - just enough to get started
+      - Use code blocks for commands or code snippets
+    - **Breaking Changes** section (if applicable):
+      - Clear warning about what breaks
+      - Migration guidance for users
+      - What they need to change in their code
+    - **Technical Notes** section (optional, for maintainers):
+      - Brief implementation notes if relevant for reviewers
+      - Dependencies added or updated
+      - Architecture decisions
+    - **Tone and style**:
+      - Professional and concise
+      - Avoid jargon and internal terminology
+      - Write for the end user, not just developers
+      - This description will be used in release notes
+  - **Apply appropriate label(s)** based on the type of change
+  - **Link the PR** to the associated issue
+  - **Update `.fork-info.json`** (if it exists) with the latest PR number (if not already present)
+  **GitHub Integration**: If GitHub tools or integrations are available (such as GitHub MCP Server or other GitHub integrations), use them to update the PR description in the target repository. If not available, provide this fallback command:
+
+  ```bash
+  # Replace PR description with release notes
+  # If fork: gh pr edit <PR-number> --repo <upstream_owner>/<upstream_repo> --body "<release-note-description>"
+  # If local: gh pr edit <PR-number> --body "<release-note-description>"
+  gh pr edit <PR-number> --body "<release-note-description>"
+  ```
+
 13. Mark PR as ready for review:
-    - **Determine target repository** (same logic as step 12):
-      - Check if `.fork-info.json` exists in the feature directory
-      - If it exists and validated, use `upstream_owner/upstream_repo`
-      - If it doesn't exist, use the current repository (origin)
-    - **Remove 'Implementing' label** from the linked issue and the PR in the target repository
-    - **Mark PR as ready for review** (no longer draft)
-    - **After updates**: Ensure `.fork-info.json` (if it exists) has both issue and PR numbers stored
-    **GitHub Integration**: If GitHub tools are available, update labels and PR status automatically in the target repository. If not available, use:
-    ```bash
-    # Mark PR as ready for review
-    # If fork: gh pr ready <PR-number> --repo <upstream_owner>/<upstream_repo>
-    # If local: gh pr ready <PR-number>
-    gh pr ready <PR-number>
+  - **Determine target repository** (same logic as step 12):
+    - Check if `.fork-info.json` exists in the feature directory
+    - If it exists and validated, use `upstream_owner/upstream_repo`
+    - If it doesn't exist, use the current repository (origin)
+  - **Remove 'Implementing' label** from the linked issue and the PR in the target repository
+  - **Mark PR as ready for review** (no longer draft)
+  - **After updates**: Ensure `.fork-info.json` (if it exists) has both issue and PR numbers stored
+  **GitHub Integration**: If GitHub tools are available, update labels and PR status automatically in the target repository. If not available, use:
+
+  ```bash
+  # Mark PR as ready for review
+  # If fork: gh pr ready <PR-number> --repo <upstream_owner>/<upstream_repo>
+  # If local: gh pr ready <PR-number>
+  gh pr ready <PR-number>
 
-    # Remove Implementing label from issue
-    # If fork: gh issue edit <issue-number> --repo <upstream_owner>/<upstream_repo> --remove-label "Implementing"
-    # If local: gh issue edit <issue-number> --remove-label "Implementing"
-    gh issue edit <issue-number> --remove-label "Implementing"
+  # Remove Implementing label from issue
+  # If fork: gh issue edit <issue-number> --repo <upstream_owner>/<upstream_repo> --remove-label "Implementing"
+  # If local: gh issue edit <issue-number> --remove-label "Implementing"
+  gh issue edit <issue-number> --remove-label "Implementing"
 
-    # Remove Implementing label from PR
-    # If fork: gh pr edit <PR-number> --repo <upstream_owner>/<upstream_repo> --remove-label "Implementing"
-    # If local: gh pr edit <PR-number> --remove-label "Implementing"
-    gh pr edit <PR-number> --remove-label "Implementing"
-    ```
+  # Remove Implementing label from PR
+  # If fork: gh pr edit <PR-number> --repo <upstream_owner>/<upstream_repo> --remove-label "Implementing"
+  # If local: gh pr edit <PR-number> --remove-label "Implementing"
+  gh pr edit <PR-number> --remove-label "Implementing"
+  ```
 
 Note: This command assumes a complete task breakdown exists in tasks.md. If tasks are incomplete or missing, suggest running `/tasks` first to regenerate the task list.

.github/workflows/Build-Docs.yml

@@ -44,6 +44,7 @@ jobs:
       - name: Checkout Code
         uses: actions/checkout@v5
         with:
+          persist-credentials: false
           fetch-depth: 0
 
       - name: Download module artifact

.github/workflows/Build-Module.yml

@@ -30,6 +30,9 @@ jobs:
     steps:
       - name: Checkout Code
         uses: actions/checkout@v5
+        with:
+          persist-credentials: false
+          fetch-depth: 0
 
       - name: Build module
         uses: PSModule/Build-PSModule@v4

.github/workflows/Build-Site.yml

@@ -44,6 +44,7 @@ jobs:
       - name: Checkout Code
         uses: actions/checkout@v5
         with:
+          persist-credentials: false
           fetch-depth: 0
 
       - name: Install-PSModuleHelpers