🚀 [Feature]: Add settings control of repository linter

.github/prompts/implement.prompt.md

@@ -15,7 +15,7 @@ $ARGUMENTS
 **Workflow Modes**: This command supports two modes:
 
 - **Local (default)**: Work with the current repository (origin). No special configuration needed.
-- **Fork**: Contribute to an upstream repository. Reads `.fork-info.json` created by `/specify`.
+- **Fork**: Contribute to an upstream repository. Detected via `git remote -v`.
 
 **Iteration Support**: This command supports iterative implementation — you can run it multiple times to complete remaining tasks, fix issues, or add refinements. Task completion state is tracked in `tasks.md` with `[X]` markers.
 
@@ -25,11 +25,14 @@ $ARGUMENTS
 
 1. **Set Implementing label immediately**
    - **Determine target repository**:
-     - Check if `.fork-info.json` exists in the feature directory.
-     - If it exists:
-       - Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty).
-       - Use `upstream_owner/upstream_repo` for all GitHub operations.
-     - If it doesn't exist, use the current repository (origin).
+     - Run `git remote -v` to check configured remotes
+     - **If `upstream` remote exists**: Fork mode
+       - Parse the upstream URL to extract owner and repo name
+       - Example: `upstream https://github.com/PSModule/Utilities.git` → owner: `PSModule`, repo: `Utilities`
+       - Use `upstream_owner/upstream_repo` for all GitHub operations
+     - **If only `origin` remote exists**: Origin mode
+       - Parse the origin URL to extract owner and repo name
+       - Use `origin_owner/origin_repo` for all GitHub operations
    - Get the issue number associated with the current feature branch.
    - **Add `Implementing` label** to the issue and PR immediately in the target repository.
    - **Remove `Planning` label** from the issue and PR.
@@ -158,7 +161,6 @@ $ARGUMENTS
 
     * Remove `Implementing` label.
     * Ensure PR is not draft.
-    * Sync `.fork-info.json` with issue + PR numbers.
 
     **Fallback commands:**
 

.github/prompts/plan.prompt.md

@@ -12,19 +12,22 @@ $ARGUMENTS
 
 **Workflow Modes**: This command supports two modes:
 - **Local (default)**: Work with the current repository (origin). No special configuration needed.
-- **Fork**: Contribute to an upstream repository. Reads `.fork-info.json` created by `/specify`.
+- **Fork**: Contribute to an upstream repository. Detected via `git remote -v`.
 
 **Iteration Support**: This command detects whether you're creating a new plan or updating an existing one based on the presence of plan.md in the feature directory.
 
 Given the implementation details provided as an argument, do this:
 
 1. **Set Planning label immediately**:
    - **Determine target repository**:
-     - Check if `.fork-info.json` exists in the feature directory
-     - If it exists:
-       - Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty)
+     - Run `git remote -v` to check configured remotes
+     - **If `upstream` remote exists**: Fork mode
+       - Parse the upstream URL to extract owner and repo name
+       - Example: `upstream https://github.com/PSModule/Utilities.git` → owner: `PSModule`, repo: `Utilities`
        - Use `upstream_owner/upstream_repo` for all GitHub operations
-     - If it doesn't exist, use the current repository (origin)
+     - **If only `origin` remote exists**: Origin mode
+       - Parse the origin URL to extract owner and repo name
+       - Use `origin_owner/origin_repo` for all GitHub operations
    - Get the issue number associated with the current feature branch
    - **Add 'Planning' label** to the issue immediately in the target repository
    - **Remove 'Specification' label** from the issue
@@ -82,13 +85,14 @@ Given the implementation details provided as an argument, do this:
 
 8. Create or update a Pull Request:
    - **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."
+     - Run `git remote -v` to check configured remotes
+     - **If `upstream` remote exists** (fork mode):
+       - Parse the upstream URL to extract owner and repo name
+       - Example: `upstream https://github.com/PSModule/Utilities.git` → owner: `PSModule`, repo: `Utilities`
        - Use `upstream_owner/upstream_repo` for all GitHub operations
-     - **If not exists** (local mode - default):
-       - Use the current repository (origin) for all GitHub operations
+     - **If only `origin` remote exists** (local mode - default):
+       - Parse the origin URL to extract owner and repo name
+       - Use `origin_owner/origin_repo` for all GitHub operations
    - **Determine PR operation** (create vs update):
      - If PR already exists for this branch, UPDATE it
      - If no PR exists, CREATE a new one
@@ -119,18 +123,6 @@ Given the implementation details provided as an argument, do this:
      * **Version/change level label**: Based on the type of change: `Major`, `Minor`, `Patch`, `Fix`, or `Docs`
      * **Phase label**: `Planning` (to indicate current phase)
    - Link the PR to the associated issue
-   - **After PR creation**: Update `.fork-info.json` (if it exists) with the PR number:
-     ```json
-     {
-       "is_fork": true,
-       "upstream_owner": "...",
-       "upstream_repo": "...",
-       "detected_from": "user_input",
-       "created_at": "...",
-       "issue_number": <issue-number>,
-       "pr_number": <pr-number>
-     }
-     ```
 
    **GitHub Integration**: If GitHub tools or integrations are available (such as GitHub MCP Server or other GitHub integrations), use them to create/update the PR and manage labels automatically in the target repository. If not available, provide these fallback commands with the correct repository:
    ```bash

.github/prompts/pr.prompt.md

@@ -0,0 +1,118 @@
+---
+description: Create a pull request with a release note style description, appropriate title, and labels based on the change type.
+---
+
+# PR
+
+The user input to you can be provided directly by the agent or as a command argument - you **MUST** consider it before proceeding with the prompt (if not empty).
+
+## User input
+
+$ARGUMENTS
+
+**Purpose**: Create or update a pull request with a release note style description and title, automatically applying the appropriate labels based on the change type specified.
+
+## Supported Change Types
+
+| Type | Icon | Labels | Description |
+|------|------|--------|-------------|
+| Major | 🌟 | `Major` | Breaking changes that affect compatibility |
+| Minor | 🚀 | `Minor` | New features or enhancements |
+| Patch | 🩹 | `Patch` | Small fixes or improvements |
+| Fix | 🪲 | `Fix`, `Patch` | Bug fixes |
+| Docs | 📖 | `Docs` | Documentation changes only |
+
+## Execution Steps
+
+1. **Detect repository mode**:
+   - Run `git remote -v` to check configured remotes.
+   - **If `upstream` remote exists**: Fork mode - use upstream owner/repo for all GitHub operations
+   - **If only `origin` remote exists**: Origin mode - use origin owner/repo for all GitHub operations
+   - Parse the URLs to extract owner and repo name: `https://github.com/<owner>/<repository>.git`.
+   - If in doubt, ask the user to clarify which repository to target.
+
+2. **Determine the change type**:
+   1. Parse the user input to identify the change type (Major, Minor, Patch, Fix, or Docs)
+   2. If nothing is provided, evaluate the code changes to infer the type:
+     - **Major**: Changes that break backward compatibility (e.g., removing public APIs, changing method signatures)
+     - **Minor**: New features or enhancements that do not break existing functionality
+     - **Patch**: Bug fixes or small improvements that do not add new features
+     - **Fix**: Specifically for bug fixes
+     - **Docs**: Only documentation changes
+
+3. **Get current branch information**:
+   - Determine the current branch name
+   - Verify there are changes to commit (if uncommitted changes exist, stage and commit them first)
+   - Push the branch to remote if not already pushed.
+
+4. **Retrieve linked issue information** (if available):
+   - Attempt to find the GitHub issue number associated with the current branch
+   - If found, retrieve the issue title from the target repository
+   - Use the issue title as the PR title (with appropriate icon prefix)
+   - If no issue is found, ask the user to provide one of the following:
+     - the number of the issue to link to the PR
+     - if a new issue should be raised for this PR
+     - Stop if the user cannot provide either of these.
+
+5. **Generate PR title**:
+   - **If issue title retrieved**: Use format `<Icon> <Issue Title>`
+   - Examples:
+     - `🚀 Add support for custom module templates`
+     - `🪲 [Fix]: Resolve null reference in parameter validation`
+     - `📖 [Docs]: Update installation guide with prerequisites`
+
+6. **Generate release note style description**:
+   - Start with a concise summary paragraph describing **what changes for the user** of the code
+   - Focus on user-facing impact, not implementation details
+   - Use present tense and active voice
+   - Structure:
+     * **Leading paragraph**: Clear summary of the change and its benefit to users
+     * **If issue linked**: Add `- Fixes #<issue-number>` after the leading paragraph
+     * **Optional additional context**: Briefly explain why this change was needed
+     * **What's Changed**: Bullet points of key changes (user-facing)
+   - Keep it concise - this should read like a release note entry
+   - DO NOT add a title or heading before the leading paragraph
+   - Avoid implementation details unless necessary for understanding
+
+7. **Create or update the pull request**:
+   - **Check if PR already exists** for this branch in the target repository
+   - **If PR exists**: Update the title, description, and labels
+   - **If PR does not exist**: Create a new PR
+   - Set PR to target the default branch (main/master)
+   - Open as a **draft PR** (or keep as draft if updating)
+   - **Use GitHub MCP tools** to perform these operations:
+     ```
+     # Create PR (if not exists)
+     mcp_github_github_create_pull_request
+
+     # Update PR (if exists)
+     mcp_github_github_update_pull_request
+
+     # Add labels to PR
+     mcp_github_github_add_labels_to_issue (PRs are issues in GitHub API)
+     ```
+
+8. **Apply labels to the PR**:
+   - Add the **change type label** based on the type specified (Major, Minor, Patch, Fix, or Docs)
+   - For Fix type, add both `Fix` and `Patch` labels
+   - If currently in a feature workflow phase (e.g., Planning, Implementation), also apply that phase label
+   - Use GitHub MCP to add labels in the target repository
+
+9. **Confirm completion**:
+   - Display the PR URL to the user
+   - Summarize the PR title, type, and labels applied
+   - If in fork mode, remind the user that the PR was created in the upstream repository
+
+**Example Usage**:
+- `/PR` - Create a PR for the current changes
+- `/PR Minor` - Create a PR for a new feature
+- `/PR Fix` - Create a PR for a bug fix
+- `/PR Docs` - Create a PR for documentation changes
+- `/PR Major` - Create a PR for breaking changes
+- `/PR Patch` - Create a PR for small improvements
+
+**Notes**:
+- This command commits and pushes changes if there are uncommitted changes
+- The PR is always created as a draft to allow for review before marking as ready
+- Labels can be manually adjusted after PR creation if needed
+- The description should be written from the user's perspective, focusing on impact not implementation

.github/prompts/specify.prompt.md

@@ -12,38 +12,23 @@ $ARGUMENTS
 
 **Workflow Modes**: This command supports two modes:
 - **Local (default)**: Work with the current repository (origin). No special configuration needed.
-- **Fork**: Contribute to an upstream repository. Requires explicit declaration with upstream owner/repo information.
+- **Fork**: Contribute to an upstream repository. Automatically detected via `git remote -v`.
 
 **Iteration Support**: This command detects whether you're creating a new feature or refining an existing one based on your current branch.
 
 The text the user typed after `/specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `$ARGUMENTS` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
 
 Given that feature description, do this:
 
-1. **Check for fork contribution**: Analyze the user input for mentions of contributing to a fork or upstream repository. Look for phrases like:
-   - "fork contribution"
-   - "contributing to upstream"
-   - "fork of [owner/repo]"
-   - "upstream repo [owner/repo]"
-   - Any explicit mention of working on a fork
-
-   If detected, extract the upstream repository information (owner/repo).
-
-   **If fork contribution is detected but information is incomplete**, prompt the user:
-
-   ```text
-   Fork contribution detected. Please provide the following information:
-   - Upstream organization/owner name (e.g., "microsoft", "PSModule")
-   - Upstream repository name (e.g., "vscode", "PSModule")
-   - Git remote name for upstream (optional, defaults to "upstream")
-
-   Example: "upstream owner: PSModule, upstream repo: Utilities"
-   ```
-
-   Wait for user response and re-parse the input before proceeding. Required fields:
-   - `upstream_owner` (string, non-empty)
-   - `upstream_repo` (string, non-empty)
-   - `upstream_remote` (string, optional, defaults to "upstream")
+1. **Detect repository mode**:
+   - Run `git remote -v` to check configured remotes
+   - **If `upstream` remote exists**: Fork mode detected
+     - Parse the upstream URL to extract owner and repo name
+     - Example: `upstream https://github.com/PSModule/Utilities.git` → owner: `PSModule`, repo: `Utilities`
+     - Inform user: "Fork contribution detected. Issues and PRs will target `<upstream_owner>/<upstream_repo>`"
+   - **If only `origin` remote exists**: Origin mode (default)
+     - Parse the origin URL to extract owner and repo name
+     - Use `origin_owner/origin_repo` for all GitHub operations
 
 2. Analyze the feature description and generate a concise, descriptive branch name:
    - Extract the core concept/action from the description (2-4 words maximum)
@@ -62,29 +47,9 @@ Given that feature description, do this:
 - If you're already on a feature branch (starts with 3 digits like `001-`, `002-`, etc.), you'll stay on that branch to iterate on the existing feature.
 - This allows you to refine specifications without creating multiple branches for the same feature.
 
-4. **Store fork information (if detected in step 1)**:
-   - If the user indicated this is a fork contribution, create a `.fork-info.json` file in the feature directory (same location as SPEC_FILE)
-   - **Validate required fields before creating**:
-     - `upstream_owner` must be non-empty string
-     - `upstream_repo` must be non-empty string
-     - If validation fails, return to step 1 for clarification
-   - The file should contain:
-     ```json
-     {
-       "is_fork": true,
-       "upstream_owner": "<extracted-owner>",
-       "upstream_repo": "<extracted-repo>",
-       "upstream_remote": "<extracted-remote-or-upstream>",
-       "detected_from": "user_input",
-       "created_at": "<ISO8601-timestamp>"
-     }
-     ```
-   - This file will be used by `/plan` and `/implement` commands to create issues and PRs in the correct repository
-   - If fork information was detected, inform the user: "Fork contribution detected. Issues and PRs will target `<upstream_owner>/<upstream_repo>`"
-
-5. Load [`.specify/templates/spec-template.md`](../../.specify/templates/spec-template.md) to understand required sections.
-
-6. **Write or update the specification**:
+4. Load [`.specify/templates/spec-template.md`](../../.specify/templates/spec-template.md) to understand required sections.
+
+5. **Write or update the specification**:
    - **If IS_EXISTING_BRANCH is false** (new feature on main branch):
      - Write a new specification to SPEC_FILE using the template structure
      - Replace placeholders with concrete details derived from the feature description
@@ -102,14 +67,10 @@ Given that feature description, do this:
        - Maintain the template structure and section order
      - The goal is evolution, not replacement - build upon the existing spec rather than starting over
 
-7. Create or update a GitHub issue for this feature:
-   - **Determine target repository**:
-     - Check if `.fork-info.json` exists in the feature directory
-     - If it exists:
-       - Validate required fields: `is_fork` (true), `upstream_owner` (non-empty), `upstream_repo` (non-empty)
-       - If validation fails, prompt user for correct information (see step 1)
-       - Use `upstream_owner/upstream_repo` for all GitHub operations
-     - If it doesn't exist, use the current repository (origin)
+6. Create or update a GitHub issue for this feature:
+   - **Use target repository determined in step 1**:
+     - If fork mode: Use `upstream_owner/upstream_repo` for all GitHub operations
+     - If origin mode: Use `origin_owner/origin_repo` for all GitHub operations
    - **Generate the issue title** in format `<Icon> [Type]: <Feature name>` where:
      - Icon: 📖 (Docs), 🪲 (Fix), ⚠️ (Security fix), 🩹 (Patch), 🚀 (Feature/Minor), 🌟 (Breaking change/Major)
      - Type: Docs, Fix, Patch, Feature, or Breaking change
@@ -142,8 +103,8 @@ Given that feature description, do this:
    gh issue edit <issue-number> --body-file <SPEC_FILE>
    ```
 
-8. **Post final status comment**: "✅ Specification complete. Ready for clarification with `/clarify` or planning with `/plan`."
+7. **Post final status comment**: "✅ Specification complete. Ready for clarification with `/clarify` or planning with `/plan`."
 
-9. Report completion with branch name, spec file path, whether it's a new or updated feature, issue number, target repository (if fork), and readiness for the next phase.
+8. Report completion with branch name, spec file path, whether it's a new or updated feature, issue number, target repository (if fork), and readiness for the next phase.
 
 Note: The script handles branch creation/reuse and initializes the spec file before writing.