[Extension]: Update Reconcile Extension to v1.1.0

[stn1slv]

Note

This is an update to an existing catalog entry, not a new submission. The reconcile extension is already in extensions/catalog.community.json at version 1.0.0. This submission bumps it to 1.1.0. Three fields change: version, download_url, and updated_at. Everything else is unchanged.

Important

1.1.0 contains a breaking change. The feature directory is now a required first argument. Existing invocations that relied on the active-feature default will stop with a usage error rather than guessing which feature to rewrite.

Extension ID

reconcile

Extension Name

Reconcile Extension

Version

1.1.0

Description

Reconcile implementation drift by surgically updating the feature's own spec, plan, and tasks.

Author

Stanislav Deviatov

Repository URL

https://github.com/stn1slv/spec-kit-reconcile

Download URL

https://github.com/stn1slv/spec-kit-reconcile/archive/refs/tags/v1.1.0.zip

License

MIT

Homepage (optional)

https://github.com/stn1slv/spec-kit-reconcile

Documentation URL (optional)

https://github.com/stn1slv/spec-kit-reconcile/blob/main/README.md

Changelog URL (optional)

https://github.com/stn1slv/spec-kit-reconcile/blob/main/CHANGELOG.md

Required Spec Kit Version

=0.1.0

Required Tools (optional)

None beyond Spec Kit's own check-prerequisites.sh.

Number of Commands

1

Number of Hooks (optional)

0

Tags

reconcile, drift, tasks, remediation

Key Features

What 1.1.0 changes over 1.0.0 (full detail in CHANGELOG.md). Three of these were conflicts with Spec Kit's own conventions, each verified against the v0.16.1 templates:

• [P] is no longer emitted on generated tasks. The command previously documented [P] as a priority flag for blocking work. In templates/tasks-template.md it means "can run in parallel: different files, no dependencies", and templates/commands/implement.md reads it to decide which tasks to run together, so blocking remediation tasks were being written into tasks.md as safe to parallelize. A gap report cannot establish file-level independence, so the marker is now never emitted, and never stripped from tasks /speckit.tasks wrote.
• Tasks are placed under the phase heading that already exists. The previous example showed ## [US2] Settings Dashboard, which is the inline task tag rather than a heading; real files use ## Phase N: User Story N - [Title] (Priority: PN). Following the old example created a second, differently named section instead of matching the existing one.
• Spec edits target the real structure. The command amended an "Acceptance Criteria" section and referenced AC-04 style IDs, neither of which exists in spec-template.md. It now amends **Acceptance Scenarios** in Given/When/Then form under the relevant ### User Story N, and detects a project's own section names and ID convention rather than assuming them.
• Every spec section is now reachable. Reconciliation previously touched only user scenarios, so a gap report describing a changed capability had nowhere to land. Functional Requirements (FR-XXX), Edge Cases, Key Entities, Success Criteria (SC-XXX) and Assumptions are all in scope, bounded by a rule that only the sections the report implicates may be touched.
• Scope modifiers are enforced. --spec-only, --plan-only and --tasks-only were declared in the input parsing and then never referenced again, so they had no defined effect on any edit. They are now honored at every write site and combine as a union.
• Re-runs are safe. The input is prose users naturally refine and resubmit, but a second run previously appended a duplicate task set and a second revision note. Tasks and revision notes now carry a [Sync: slug] key matched against tags already in the files, and a task /speckit.implement has marked [X] is never edited.

Testing Checklist

• Extension installs successfully via download URL
• All commands execute without errors
• Documentation is complete and accurate
• No security vulnerabilities identified
• Tested on at least one real project

Submission Requirements

• Valid extension.yml manifest included
• README.md with installation and usage instructions
• LICENSE file included
• GitHub release created with version tag
• All command files exist and are properly formatted
• Extension ID follows naming conventions (lowercase-with-hyphens)

Testing Details

Installed from the v1.1.0 release download URL and run on a real project, invoking /speckit.reconcile.run with a feature path and a gap report. The command executed without errors and produced the expected amendments to the feature's spec.md, plan.md and tasks.md.

Two things worth stating plainly for reviewers:

• The extension ships a single Markdown command prompt and has no automated test suite, so correctness is established by real runs rather than CI. Beyond the run above, the 1.1.0 changes went through four rounds of review against the Spec Kit templates and the implement command, which is where the three convention conflicts listed under Key Features were found.
• The breaking change is deliberate. A command that rewrites three files in place should not infer which feature it is about to modify, and requiring the path also removed the precedence and fallback rules the previous inference needed.

Example Usage

# Install
specify extension add reconcile --from https://github.com/stn1slv/spec-kit-reconcile/archive/refs/tags/v1.1.0.zip

# Reconcile drift in a specific feature
/speckit.reconcile.run specs/007-invoice-settings "Backend exists, but the React screen is unreachable; need sidebar link and route"

# A requirement-shaped gap amends the feature's Functional Requirements
/speckit.reconcile.run specs/007-invoice-settings "The /api/v1/settings endpoint now requires an org_id header not in the original plan"

# Restrict scope if desired
/speckit.reconcile.run specs/007-invoice-settings "Sidebar link missing" --tasks-only

Proposed Catalog Entry

{
  "name": "Reconcile Extension",
  "id": "reconcile",
  "description": "Reconcile implementation drift by surgically updating the feature's own spec, plan, and tasks.",
  "author": "Stanislav Deviatov",
  "version": "1.1.0",
  "download_url": "https://github.com/stn1slv/spec-kit-reconcile/archive/refs/tags/v1.1.0.zip",
  "repository": "https://github.com/stn1slv/spec-kit-reconcile",
  "homepage": "https://github.com/stn1slv/spec-kit-reconcile",
  "documentation": "https://github.com/stn1slv/spec-kit-reconcile/blob/main/README.md",
  "changelog": "https://github.com/stn1slv/spec-kit-reconcile/blob/main/CHANGELOG.md",
  "license": "MIT",
  "category": "docs",
  "effect": "read-write",
  "requires": {
    "speckit_version": ">=0.1.0"
  },
  "provides": {
    "commands": 1,
    "hooks": 0
  },
  "tags": [
    "reconcile",
    "drift",
    "tasks",
    "remediation"
  ],
  "verified": false,
  "downloads": 0,
  "stars": 0,
  "created_at": "2026-03-14T00:00:00Z",
  "updated_at": "2026-08-09T00:00:00Z"
}

Additional Context

The stars field is left at 0 to match the existing entry, matching how the archive extension's 1.1.0 bump was recorded.

This extension is the inner-loop counterpart to archive, already in the catalog: reconcile keeps a feature's own artifacts aligned with the shipped code during the PR phase, and archive folds the finished feature into .specify/memory/ after merge. 1.1.0 adds a recommendation to re-run /speckit.archive.run when the reconciled feature has already been archived, since amending its spec leaves project memory stale. The two remain independent: neither requires the other to be installed.

[github-actions]

cc @github/spec-kit-maintainers — new catalog submission for review.

[github-actions]

Pull request created: #4034

Generated by Add Community Extension from Issue Submission · 195.9 AIC · ⌖ 16.5 AIC · ⊞ 35.2K

[mnriem]

Thank you!