Enhance workflow and iteration support across commands

- Updated implement.prompt.md to include workflow modes (Local and Fork) and iteration support for task completion tracking.
- Enhanced plan.prompt.md with workflow modes, iteration detection, and refined task generation based on existing plans.
- Improved specify.prompt.md to support fork contributions, detailed branch naming, and specification writing/updating processes.
- Modified tasks.prompt.md to incorporate workflow modes, iteration detection, and task updating mechanisms.
- Refined create-new-feature.ps1 script to manage branch creation based on current branch context and existing feature detection.
- Added a new constitution-template.md for project governance and principles documentation.
- Removed obsolete spec.md for the Merge CI and Main Workflows feature.

Author: MariusStorhaug

.github/prompts/constitution.prompt.md

@@ -1,5 +1,5 @@
 ---
-description: Create or update the project constitution from interactive or provided principle inputs, ensuring all dependent templates stay in sync.
+description: Create (if absent) or iteratively update the project constitution from interactive or provided inputs, ensuring all dependent templates stay in sync.
 ---
 
 # Constitution
@@ -10,15 +10,49 @@ User input:
 
 $ARGUMENTS
 
-You are updating the project constitution at `.specify/memory/constitution.md`. This file is a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`). Your job is to (a) collect/derive concrete values, (b) fill the template precisely, and (c) propagate any amendments across dependent artifacts.
+**Note**: This command operates on the local repository's constitution and does not typically require fork-specific logic, as constitutional changes are usually made within the repository itself rather than targeting upstream repositories.
+
+You are (a) creating or (b) iterating on the project constitution at `.specify/memory/constitution.md`.
+
+Two operating modes:
+
+1. Initial Creation Mode (constitution file does NOT exist):
+   - Copy `.specify/templates/constitution-template.md` to `.specify/memory/constitution.md` verbatim before processing.
+   - Treat the copied file as a TEMPLATE containing placeholder tokens in square brackets (e.g. `[PROJECT_NAME]`, `[PRINCIPLE_1_NAME]`).
+   - Produce an initial version (default `1.0.0` unless the user specifies otherwise). Ratification date = today (unless user supplies one). Last amended date = same as ratification.
+2. Iteration Mode (constitution file already exists):
+   - Load the existing `.specify/memory/constitution.md` (NOT the template) as the authoritative current constitution.
+   - Do NOT re-copy the template. Only reference the template to discover any NEW placeholders/sections that could be adopted.
+   - Identify new functionality / sections / principles requested (from user input or arguments) and integrate them.
+   - If a new principle or governance rule appears to REPLACE or substantially OVERLAP an existing one, generate a Replacement Analysis Table and request user confirmation before destructive changes. If interactive confirmation is not possible in this run, mark the affected original item with `TODO(REVIEW_REPLACEMENT): Proposed replacement: <new title>` and include in the Sync Impact Report under deferred actions.
+   - Preserve original ratification date. Increment version per rules below. Update last amended date to today if any material change occurs.
+
+Replacement Analysis Table (when overlap detected):
+
+| Existing Item | Proposed New / Change | Overlap Basis | Suggested Action |
+|---------------|-----------------------|---------------|------------------|
+| <title / section> | <incoming title / change> | e.g. semantic similarity, scope duplication | Replace / Merge / Keep Both |
+
+Heuristics for overlap:
+- Title similarity score (case-insensitive) >= 0.6 (rough string similarity) OR
+- >50% of bullet rules conceptually duplicate (same verbs/nouns) OR
+- Governance rule introduces stricter variant of an existing rule.
+
+If ambiguity remains, prefer non-destructive addition plus TODO marker.
 
 Follow this execution flow:
 
-1. Load the existing constitution template at `.specify/memory/constitution.md`.
-   - Identify every placeholder token of the form `[ALL_CAPS_IDENTIFIER]`.
-   **IMPORTANT**: The user might require less or more principles than the ones used in the template. If a number is specified, respect that - follow the general template. You will update the doc accordingly.
+0. Existence Check & Mode Selection:
+   - If `.specify/memory/constitution.md` is missing → enter Initial Creation Mode (copy template, then proceed).
+   - If it exists → Iteration Mode (operate directly on existing file; treat remaining bracket tokens, if any, as still-to-be-resolved placeholders).
+
+1. Load Source Document:
+   - Creation Mode: load freshly copied `.specify/memory/constitution.md` (formerly the template).
+   - Iteration Mode: load existing `.specify/memory/constitution.md` and independently load `.specify/templates/constitution-template.md` only to detect any NEW placeholders/sections not yet present.
+   - Identify every placeholder token `[ALL_CAPS_IDENTIFIER]` still unresolved in the working constitution (not just in template).
+   - IMPORTANT: User may request changing the number of principles. Respect explicit user instruction; re-number or re-label as needed (maintain Roman numeral style if already in use; otherwise adopt consistent scheme).
 
-2. Collect/derive values for placeholders:
+2. Collect/derive values for placeholders (and new/changed content):
    - If user input (conversation) supplies a value, use it.
    - Otherwise infer from existing repo context (README, docs, prior constitution versions if embedded).
    - For governance dates: `RATIFICATION_DATE` is the original adoption date (if unknown ask or mark TODO), `LAST_AMENDED_DATE` is today if changes are made, otherwise keep previous.
@@ -28,34 +62,39 @@ Follow this execution flow:
      * PATCH: Clarifications, wording, typo fixes, non-semantic refinements.
    - If version bump type ambiguous, propose reasoning before finalizing.
 
-3. Draft the updated constitution content:
+3. Draft / Merge updated constitution content:
+    - In Iteration Mode, integrate new principles/sections with minimal disruption:
+       * Retain stable identifiers (e.g., keep existing principle numbering unless renumbering is explicitly required or gaps introduced by removals).
+       * When replacing, either (a) fully substitute content if user confirmed or (b) append revised content and mark old with `DEPRECATED:` prefix plus TODO for removal in a future major version.
    - Replace every placeholder with concrete text (no bracketed tokens left except intentionally retained template slots that the project has chosen not to define yet—explicitly justify any left).
    - Preserve heading hierarchy and comments can be removed once replaced unless they still add clarifying guidance.
    - Ensure each Principle section: succinct name line, paragraph (or bullet list) capturing non‑negotiable rules, explicit rationale if not obvious.
    - Ensure Governance section lists amendment procedure, versioning policy, and compliance review expectations.
 
 4. Consistency propagation checklist (convert prior checklist into active validations):
-   - Read `.specify/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
-   - Read `.specify/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
-   - Read `.specify/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
-   - Read each command file in `.specify/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
+   - Read [`.specify/templates/plan-template.md`](../../.specify/templates/plan-template.md) and ensure any "Constitution Check" or rules align with updated principles.
+   - Read [`.specify/templates/spec-template.md`](../../.specify/templates/spec-template.md) for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
+   - Read [`.specify/templates/tasks-template.md`](../../.specify/templates/tasks-template.md) and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
+   - Read each related prompt file in `.github/prompts/` (including this one) to verify no outdated agent-specific references remain (e.g., names tied to a specific LLM vendor) when generic guidance is required.
    - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
 
 5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
    - Version change: old → new
    - List of modified principles (old title → new title if renamed)
    - Added sections
    - Removed sections
+   - Deprecated (marked) sections pending removal
    - Templates requiring updates (✅ updated / ⚠ pending) with file paths
    - Follow-up TODOs if any placeholders intentionally deferred.
+   - Replacement items needing confirmation (if any)
 
 6. Validation before final output:
    - No remaining unexplained bracket tokens.
    - Version line matches report.
    - Dates ISO format YYYY-MM-DD.
    - Principles are declarative, testable, and free of vague language ("should" → replace with MUST/SHOULD rationale where appropriate).
 
-7. Write the completed constitution back to `.specify/memory/constitution.md` (overwrite).
+7. Write the completed constitution back to [`.specify/memory/constitution.md`](../../.specify/memory/constitution.md) (overwrite). Never write to the template path during iteration.
 
 8. Output a final summary to the user with:
    - New version and bump rationale.

.github/prompts/implement.prompt.md

@@ -10,7 +10,13 @@ User input:
 
 $ARGUMENTS
 
-1. Run `.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks` from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
+**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`.
+
+**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.
+
+1. Run [`.specify/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks`](../../.specify/scripts/powershell/check-prerequisites.ps1) from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute.
 
 2. Load and analyze the implementation context:
    - **REQUIRED**: Read tasks.md for the complete task list and execution plan
@@ -21,12 +27,18 @@ $ARGUMENTS
    - **IF EXISTS**: Read quickstart.md for integration scenarios
 
 3. Parse tasks.md structure and extract:
+   - **Detect iteration state**: Check task completion markers
+     - Tasks marked [X] are complete - skip unless user requests changes
+     - Tasks marked [ ] are pending - these need implementation
+     - If all tasks are complete, check if user input requests additional work
    - **Task phases**: Setup, Tests, Core, Integration, Polish
    - **Task dependencies**: Sequential vs parallel execution rules
    - **Task details**: ID, description, file paths, parallel markers [P]
    - **Execution flow**: Order and dependency requirements
 
 4. Execute implementation following the task plan:
+   - **Skip completed tasks**: Don't re-implement tasks marked [X] unless explicitly requested
+   - **Resume from last incomplete task**: Start with first [ ] task found
    - **Phase-by-phase execution**: Complete each phase before moving to the next
    - **Respect dependencies**: Run sequential tasks in order, parallel tasks [P] can run together
    - **Follow TDD approach**: Execute test tasks before their corresponding implementation tasks
@@ -56,9 +68,22 @@ $ARGUMENTS
    - Report final status with summary of completed work
 
 8. Create or update 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."
+       - 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
-   - **Determine PR type and icon** based on the changes:
+   - **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 |
      |-|-|-|
@@ -69,20 +94,53 @@ $ARGUMENTS
      | Feature | 🚀 | Minor |
      | Breaking change | 🌟 | Major |
 
-   - **PR title format**: `<Icon> [Type of change]: <Short description>`
-   - **PR description structure**:
-     * Start with a summary paragraph describing the key outcome and changes for user
-     * DO NOT add a title before the leading paragraph
-     * At the end of the PR paragraph, add a "- Fixes #<issue-number>" line to link the PR to the issue
-     * Follow with additional details answering Why, How, and What
-     * Avoid superfluous headers or sections
-     * We do not need details, we need to add what changes for the user of the code
+   - Fallback PR title format (if issue title unavailable): `<Icon> [Type of change]: <Short description>`
+   - **PR description structure** (formatted as a release note):
+     * Start with a user-focused summary paragraph describing what's new, improved, or fixed
+     * Write in past tense, focusing on capabilities and user benefits (e.g., "Added support for...", "Improved performance of...", "Fixed issue where...")
+     * DO NOT add a title or heading before the leading paragraph
+     * Keep the tone professional and concise - this will be read as a release note
+     * At the end of the summary paragraph, add "- Fixes #<issue-number>" to link the PR to the issue
+     * Follow with additional release-note style details:
+       - **What's Changed**: Brief bullet points of key changes from the user's perspective
+       - **Technical Details** (optional): Implementation notes if relevant for maintainers
+       - **Breaking Changes** (if applicable): Clear warning and migration guidance
+       - **Usage** (if applicable): Brief example or updated command syntax
+     * Avoid superfluous headers, verbose explanations, or internal implementation details
+     * Focus on what changes for the end user or developer using this code
    - **Apply appropriate label(s)** based on the type of change
    - **Link the PR** to the associated issue
+   - **After PR updates**: 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 status and labels automatically in the target repository. If not available, provide these fallback commands with the correct repository:
+   ```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>
+
+   # Update PR title to match issue (if needed)
+   gh pr edit <PR-number> --title "<Issue title>"
+
+   # Update labels
+   gh pr edit <PR-number> --add-label "<Type>"
+   ```
 
 9. Update issue labels:
-   - Remove 'plan' label from the linked issue
+   - **Determine target repository** (same logic as step 8):
+     - 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 'plan' label from the linked issue in the target repository
    - Add 'implement' label to the linked issue
+   - **After updating labels**: Ensure `.fork-info.json` (if it exists) has the issue number stored
+
+   **GitHub Integration**: If GitHub tools are available, update labels automatically in the target repository. If not available, use:
+   ```bash
+   # If fork: gh issue edit <issue-number> --repo <upstream_owner>/<upstream_repo> ...
+   # If local: gh issue edit <issue-number> ...
+   gh issue edit <issue-number> --remove-label "Plan" --add-label "Implementation"
+   ```
 
 10. Update the constitution:
     - Read the [Constitution](../../.specify/memory/constitution.md) file.