docs(prompts): remove fork-info.json dependency, use git remote detection instead

- Update /specify, /plan, /tasks, and /implement prompts to detect fork mode via git remote -v

- Remove all references to .fork-info.json configuration file

- Simplify fork contribution workflow with automatic detection

- Add comprehensive linter configuration documentation to README

Author: MariusStorhaug

.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/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.

.github/prompts/tasks.prompt.md

@@ -12,7 +12,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 detects whether you're creating new tasks or updating existing ones based on the presence of tasks.md in the feature directory.
 
@@ -83,13 +83,14 @@ $ARGUMENTS
 
 8. Update the Pull Request description:
    - **Determine workflow mode and target repository**:
-     - Check if `.fork-info.json` exists in the feature directory (same location as plan.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
    - Append or update the tasks.md content in the existing PR description
    - Format tasks with checkboxes for each task phase:
      * Setup: `- [ ] T001: Task description`

README.md

@@ -373,28 +373,56 @@ Build:
 
 ### Example 3 - Configuring the Repository Linter
 
-This example shows how to configure the repository linter to skip certain validations or disable the linter entirely.
+The workflow uses [super-linter](https://github.com/super-linter/super-linter) to lint your repository code.
+The linter runs on pull requests and provides status updates directly in the PR.
+
+#### Disabling the Linter
+
+You can skip repository linting entirely:
 
 ```yaml
-# Skip the linter entirely
 Linter:
   Skip: true
 ```
 
+#### Configuring Linter Validation Rules
+
+The workflow supports all environment variables that super-linter provides. You can configure these through the `Linter.env` object:
+
 ```yaml
-# Disable specific linter validations
 Linter:
   env:
+    # Disable specific validations
     VALIDATE_BIOME_FORMAT: false
     VALIDATE_BIOME_LINT: false
     VALIDATE_GITHUB_ACTIONS_ZIZMOR: false
     VALIDATE_JSCPD: false
     VALIDATE_JSON_PRETTIER: false
     VALIDATE_MARKDOWN_PRETTIER: false
     VALIDATE_YAML_PRETTIER: false
+
+    # Or enable only specific validations
+    VALIDATE_YAML: true
+    VALIDATE_JSON: true
+    VALIDATE_MARKDOWN: true
 ```
 
-For a complete list of available linter environment variables, see the [super-linter documentation](https://github.com/super-linter/super-linter#environment-variables).
+#### Additional Configuration
+
+Any super-linter environment variable can be set through the `Linter.env` object:
+
+```yaml
+Linter:
+  env:
+    LOG_LEVEL: DEBUG
+    FILTER_REGEX_EXCLUDE: '.*test.*'
+    VALIDATE_ALL_CODEBASE: false
+```
+
+**Note:** The `GITHUB_TOKEN` is automatically provided by the workflow to enable status updates in pull requests.
+
+For a complete list of available environment variables and configuration options, see the
+[super-linter environment variables documentation](https://github.com/super-linter/super-linter#environment-variables).
 
 ## Specifications and practices