specify-cli 1.2.0__tar.gz → 1.2.1__tar.gz

{specify_cli-1.2.0 → specify_cli-1.2.1}/.github/workflows/lint.yml

@@ -15,6 +15,8 @@ jobs:
         docs/**/*.md
         README.md
         README.zh-CN.md
+        README.ja.md
+        README.ko.md
         CODE_OF_CONDUCT.md
         CONTRIBUTING.md
         DEVELOPMENT.md

{specify_cli-1.2.0 → specify_cli-1.2.1}/AGENTS.md

@@ -44,6 +44,16 @@ an LLM, read
 Behavioral changes need positive and negative coverage; bug fixes need
 before-and-after regression evidence.
 
+## PowerShell Compatibility
+
+All PowerShell scripts in the repository and all generated PowerShell
+functionality MUST target Windows PowerShell 5.1, the version included with
+Windows. When adding or changing PowerShell code, use only syntax, cmdlets,
+parameters, and .NET APIs available in Windows PowerShell 5.1. Account for
+encoding and other runtime differences, preserve the required behavioral
+parity with Bash and Python implementations, and provide Windows PowerShell
+5.1 validation evidence for behavioral changes.
+
 ## Branches and Agent Contributions
 
 When creating a branch, follow [Branch naming](CONTRIBUTING.md#branch-naming).

{specify_cli-1.2.0 → specify_cli-1.2.1}/CHANGELOG.md

@@ -2,6 +2,31 @@
 
 <!-- insert new changelog below this comment -->
 
+## [1.2.1] - 2026-10-16
+
+### Changed
+
+- docs: add catalog reference (#4976)
+- Update Applied Epistemic Engineering extension to v1.5.0 (#4982)
+- Update Evaluator Contract extension to v1.1.1 (#4980)
+- test(integrations): characterize delivery boundaries (#4975)
+- fix(extensions): list commands the way the active agent registers them (#4964)
+- feat(workflows): add opt-in output capture to command and prompt steps (#4957)
+- docs: add README capability map (#4974)
+- docs: target Windows PowerShell 5.1 (#4973)
+- docs(mcp): document the first-class version and artifact tools (#4969)
+- fix(workflows): load custom steps before update (#4768)
+- Add gh-address-cr extension to community catalog (#4971)
+- [bug-fix] Fix missing-plan-template: reject empty plan setup (#4962)
+- fix(powershell): preserve plans in literal feature paths (#4956)
+- fix(extensions): delete the catalog config when the last entry is removed (#4909)
+- fix(integrations): move extension artifacts on integration uninstall (#4911)
+- fix(integrations): show hyphenated command names for docker-agent and junie (#4910)
+- Update Reconcile Extension to v1.3.1 (#4950)
+- docs: add Korean (한국어) README (#4939)
+- docs: distinguish extension reconciliation from core SDD (#4948)
+- chore: release 1.2.0, begin 1.2.1.dev0 development (#4949)
+
 ## [1.2.0] - 2026-10-13
 
 ### Changed

{specify_cli-1.2.0 → specify_cli-1.2.1}/CONTRIBUTING.md

@@ -234,6 +234,13 @@ core scripts, extensions, presets, and tooling; workflow step types; and
 execution wiring such as script selection, workflow shell steps, and CI `run:`
 steps. Existing tests count when they cover the changed behavior.
 
+Behavioral changes to repository-maintained or generated PowerShell
+functionality must include evidence from Windows PowerShell 5.1 or reproducible
+evidence that demonstrates 5.1 compatibility. All PowerShell scripts in the
+repository and all generated PowerShell functionality MUST target Windows
+PowerShell 5.1. Check syntax, cmdlet and parameter availability, .NET Framework
+APIs, encoding, and process/runtime behavior against that target.
+
 Bug fixes also need a regression test that fails before the fix and passes
 afterward. If a baseline or an execution path cannot be tested automatically,
 explain the limitation and provide reproducible evidence for the affected

{specify_cli-1.2.0 → specify_cli-1.2.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: specify-cli
-Version: 1.2.0
+Version: 1.2.1
 Summary: Specify CLI, part of GitHub Spec Kit. A tool to bootstrap your projects for Spec-Driven Development (SDD).
 License-File: LICENSE
 Requires-Python: >=3.11
@@ -35,12 +35,13 @@ Description-Content-Type: text/markdown
 <p align="center">
     <strong>English</strong> ·
     <a href="./README.zh-CN.md">简体中文</a> ·
-    <a href="./README.ja.md">日本語</a>
+    <a href="./README.ja.md">日本語</a> ·
+    <a href="./README.ko.md">한국어</a>
 </p>
 
 Spec Kit is an open source toolkit that gives AI coding agents structured
-processes, reusable templates, and documented outcomes. Start with one of the
-three processes below, customize it, or bring your own.
+processes, reusable templates, and documented outcomes. Start with a ready-made
+process, customize it, or bring your own.
 
 ## Choose your process
 
@@ -49,9 +50,40 @@ three processes below, customize it, or bring your own.
 | Build a feature or application | [Spec-Driven Development](#spec-driven-development) | A specification carried through planning, implementation, and convergence |
 | Diagnose and repair broken behavior | [Bug fixing](#bug-fixing) | An assessed cause, scoped fix, and recorded verification |
 | Decide whether an idea deserves investment | [Idea assessment](#idea-assessment) | An evidence-backed go, clarify, or stop decision |
-
-These are **independent entry points**, not three mandatory phases. SDD ships in
-core; bug fixing and assessment are bundled extensions you install when needed.
+| Adopt or create a different process | [Your own process](#capabilities) | A process adapted or assembled from reusable primitives |
+
+These are **independent entry points**, not mandatory phases. SDD ships in core;
+bug fixing and assessment are bundled extensions you install when needed, and
+the primitives below let you adopt or create other processes.
+
+## Capabilities
+
+Spec Kit combines ready-to-use processes with composable mechanisms:
+
+| Capability | Spec Kit mechanism |
+| --- | --- |
+| Connect to or switch between coding agents | [Integration](https://github.github.io/spec-kit/reference/integrations.html) |
+| Add a command, quality gate, or complete process | [Extension](https://github.github.io/spec-kit/reference/extensions.html) |
+| Connect a process to an external tool or service | [Extension](https://github.github.io/spec-kit/reference/extensions.html) |
+| React to coding-agent lifecycle events | [Extension event hook](https://github.github.io/spec-kit/reference/extensions.html#project-extension-and-hook-configuration) |
+| Adapt templates, commands, terminology, or methodology | [Preset](https://github.github.io/spec-kit/reference/presets.html) |
+| Enforce organizational or regulatory standards | [Preset](https://github.github.io/spec-kit/reference/presets.html) |
+| Override a template for one project | [Project-local override](https://github.github.io/spec-kit/guides/customization.html#project-local-overrides-and-resolution) |
+| Automate prompts, commands, gates, and shell tasks | [Workflow](https://github.github.io/spec-kit/reference/workflows.html) |
+| Modify an installed workflow without forking it | [Workflow overlay](https://github.github.io/spec-kit/reference/workflows.html#workflow-overlays) |
+| Add reusable executable behavior to workflows | [Workflow step](https://github.github.io/spec-kit/reference/workflows.html#custom-step-packages) |
+| Install a curated setup for a role or team | [Bundle](https://github.github.io/spec-kit/reference/bundles.html) |
+| Discover community components | [Catalog](https://github.github.io/spec-kit/reference/catalogs.html) |
+| Host a private catalog of approved components | [Catalog](https://github.github.io/spec-kit/reference/catalogs.html) |
+| Access private catalogs and component downloads | [Authentication](https://github.github.io/spec-kit/reference/authentication.html) |
+| Work offline or behind a firewall | [Local sources and self-hosted catalogs](https://github.github.io/spec-kit/install/air-gapped.html) |
+| Inspect which layer supplies a command, template, or script | [Artifact inventory](https://github.github.io/spec-kit/reference/artifacts.html) |
+
+Search the active catalogs with commands such as `specify extension search`,
+`specify preset search`, `specify workflow search`, and `specify bundle search`.
+Spec Kit includes community catalogs, and organizations can add their own
+curated sources. Catalog listings are not audits or endorsements, so review
+community source code before installing or running it.
 
 <a id="-get-started"></a>
 <a id="-prerequisites"></a>

{specify_cli-1.2.0 → specify_cli-1.2.1}/README.ja.md

@@ -14,7 +14,8 @@
 <p align="center">
     <a href="./README.md">English</a> ·
     <a href="./README.zh-CN.md">简体中文</a> ·
-    <strong>日本語</strong>
+    <strong>日本語</strong> ·
+    <a href="./README.ko.md">한국어</a>
 </p>
 
 Spec Kitは、AIコーディングエージェントに構造化されたプロセス、再利用可能なテンプレート、記録に残る成果をもたらすオープンソースのツールキットです。以下の3つのプロセスのいずれかから始め、必要に応じてカスタマイズしたり、自分自身のプロセスを持ち込んだりすることもできます。

specify_cli-1.2.1/README.ko.md

@@ -0,0 +1,208 @@
+<div align="center">
+    <img src="https://raw.githubusercontent.com/github/spec-kit/main/media/logo_large.webp" alt="Spec Kit 로고" width="200" height="200"/>
+    <h1>🌱 Spec Kit</h1>
+    <h3><em>코딩 에이전트와 함께 스펙으로 개발하고, 버그를 고치고, 아이디어를 평가하세요.</em></h3>
+</div>
+
+<p align="center">
+    <a href="https://github.com/github/spec-kit/releases/latest"><img src="https://img.shields.io/github/v/release/github/spec-kit" alt="최신 릴리스"/></a>
+    <a href="https://github.com/github/spec-kit/stargazers"><img src="https://img.shields.io/github/stars/github/spec-kit?style=social" alt="GitHub stars"/></a>
+    <a href="https://github.com/github/spec-kit/blob/main/LICENSE"><img src="https://img.shields.io/github/license/github/spec-kit" alt="라이선스"/></a>
+    <a href="https://github.github.io/spec-kit/"><img src="https://img.shields.io/badge/docs-GitHub_Pages-blue" alt="문서"/></a>
+</p>
+
+<p align="center">
+    <a href="./README.md">English</a> ·
+    <a href="./README.zh-CN.md">简体中文</a> ·
+    <a href="./README.ja.md">日本語</a> ·
+    <strong>한국어</strong>
+</p>
+
+Spec Kit은 AI 코딩 에이전트에게 체계적인 프로세스, 재사용 가능한 템플릿, 문서로 남는 결과물을
+제공하는 오픈 소스 툴킷입니다. 아래 세 가지 프로세스 중 하나로 시작해 필요에 맞게 고쳐 쓰거나,
+직접 만든 프로세스를 가져와도 됩니다.
+
+## 프로세스 선택
+
+| 필요한 것 | 프로세스 | 결과 |
+| --- | --- | --- |
+| 기능이나 애플리케이션 만들기 | [스펙 주도 개발](#스펙-주도-개발) | 계획, 구현, 수렴까지 이어지는 스펙 |
+| 잘못된 동작을 진단하고 고치기 | [버그 수정](#버그-수정) | 평가를 거친 원인, 범위를 한정한 수정, 기록으로 남는 검증 |
+| 아이디어에 투자할 가치가 있는지 판단하기 | [아이디어 평가](#아이디어-평가) | 근거에 기반한 진행, 명확화, 중단 결정 |
+
+세 프로세스는 반드시 거쳐야 하는 세 단계가 아니라 **각각 독립된 진입점**입니다. 스펙 주도 개발(SDD)은
+코어에 포함되어 있고, 버그 수정과 아이디어 평가는 Spec Kit에 함께 제공되며 필요할 때 설치하는 확장입니다.
+
+<a id="-get-started"></a>
+<a id="-prerequisites"></a>
+
+## 시작하기
+
+Linux, macOS, Windows 환경에서 **Python 3.11+**, **[uv](https://github.github.io/spec-kit/install/uv.html)**,
+그리고 지원되는 AI 코딩 에이전트가 필요합니다.
+**CLI 설정**은 터미널에서 진행합니다. 아래 명령어를 실행해 Spec Kit을 설치하고 프로젝트를 만드세요:
+
+```bash
+uv tool install specify-cli
+specify init my-project --integration copilot
+cd my-project
+```
+
+<a id="-supported-ai-coding-agent-integrations"></a>
+
+예시는 **GitHub Copilot의 기본 스킬 모드**를 기준으로 합니다. 지원되는 다른 에이전트를 쓰려면
+`copilot`을 해당 에이전트의 [통합 키](https://github.github.io/spec-kit/reference/integrations.html)로 바꾸세요.
+
+이미 코드가 있나요? [기존 프로젝트 가이드](https://github.github.io/spec-kit/guides/existing-projects.html)를 따르세요.
+특정 버전 고정, 다른 설치 방법, CI, 문제 해결은
+[설치](https://github.github.io/spec-kit/installation.html) 문서를 참고하세요.
+기존 설치를 업데이트하려면 [업그레이드](https://github.github.io/spec-kit/upgrade.html) 문서를 참고하세요.
+
+이제 **프로젝트 디렉터리에서 코딩 에이전트를 실행**하고 아래 프로세스 중 하나를 고르세요.
+각 `/speckit-*` **스킬은 에이전트 채팅에서** 한 번에 하나씩 호출하고, 결과를 검토한 뒤 다음으로
+넘어가세요. 이들은 터미널 명령어가 아니라 에이전트 스킬입니다. 에이전트나 모드에 따라
+[호출 문법이 다를 수 있습니다](https://github.github.io/spec-kit/reference/integrations.html#command-invocation).
+
+<a id="-what-is-spec-driven-development"></a>
+<a id="sdd-quickstart"></a>
+
+## 스펙 주도 개발
+
+**어떻게** 만들지 정하기 전에 **무엇을, 왜** 만드는지부터 정의합니다. SDD는 요구 사항을 스펙,
+기술 계획, 실행 가능한 작업으로 바꾸고, 이 산출물을 기준으로 구현을 이끕니다.
+
+**원칙(constitution)은 프로젝트당 한 번 정하고, 기능마다 스펙 작성(specify) → 계획(plan) → 작업 분해(tasks) → 구현(implement) → 수렴(converge)을 진행합니다.**
+
+에이전트 채팅에서 다음 스킬을 호출하세요:
+
+```text
+/speckit-constitution Create principles focused on code quality, testing, and maintainability.
+/speckit-specify Build a photo organizer with albums grouped by date and a tile preview of each album.
+/speckit-plan Use Vite with vanilla JavaScript. Keep images local and store metadata in SQLite.
+/speckit-tasks
+/speckit-implement
+/speckit-converge
+```
+
+수렴 결과가 **Converged**로 나올 때까지 **implement → converge**를 반복하세요.
+품질 게이트를 더 두고 싶다면 명확화, 체크리스트, 일관성 분석을 추가하세요.
+
+[SDD 실습 가이드](https://github.github.io/spec-kit/quickstart.html) ·
+[명령어 레퍼런스](https://github.github.io/spec-kit/reference/agentic-sdd.html)
+
+<a id="-bug-fixing-with-spec-kit"></a>
+<a id="bug-fix-quickstart"></a>
+
+## 버그 수정
+
+진단, 수정, 검증을 분리해서 에이전트가 평가로 밝혀낸 원인을 고치고 원래 증상을 다시 확인하게
+합니다. SDD 기능 워크플로를 먼저 거칠 필요는 없습니다.
+
+**CLI 설정(터미널):** 프로젝트 디렉터리에서 선택형 확장을 설치하세요:
+
+```bash
+specify extension add bug
+```
+
+그다음 에이전트 채팅에서 **평가(assess) → 수정(fix) → 테스트(test)** 스킬을 호출하세요:
+
+```text
+/speckit-bug-assess "Submitting an empty password crashes the login form." slug=login-crash
+/speckit-bug-fix slug=login-crash
+/speckit-bug-test slug=login-crash
+```
+
+보고서는 `.specify/bugs/login-crash/`에 저장됩니다. 최종 판정이
+`verified`(검증됨), `partial`(부분 검증), `failed`(실패) 중 무엇인지 확인하세요. 검증이 빠졌다면 수정에
+성공한 것이 아닙니다.
+
+[버그 수정 실습 가이드](https://github.github.io/spec-kit/guides/bugfix.html) ·
+[명령어 레퍼런스](https://github.github.io/spec-kit/reference/agentic-bugfix.html)
+
+<a id="-assessing-ideas-with-spec-kit"></a>
+<a id="idea-assessment-quickstart"></a>
+
+## 아이디어 평가
+
+소프트웨어가 되든 안 되든, 아이디어에 뛰어들기 전에 근거부터 모읍니다.
+독립적으로 쓰는 프로세스라서 소스 코드가 없는 프로젝트에서도 동작합니다.
+
+**CLI 설정(터미널):** 프로젝트 디렉터리에서 선택형 확장을 설치하세요:
+
+```bash
+specify extension add assess
+```
+
+그다음 에이전트 채팅에서 **접수(intake) → 조사(research) → 정의(define) → 구체화(shape) → 결정(decide)** 스킬을 호출하세요:
+
+```text
+/speckit-assess-intake "Let users work offline and sync when they reconnect." slug=offline-mode
+/speckit-assess-research slug=offline-mode
+/speckit-assess-define slug=offline-mode
+/speckit-assess-shape slug=offline-mode
+/speckit-assess-decide slug=offline-mode
+```
+
+산출물은 `.specify/assessments/offline-mode/`에 저장되며, 마지막에
+**진행(go) / 명확화 필요(needs-clarification) / 중단(kill)** 중 하나로 결정이 나옵니다.
+불확실한 부분은 단계 전체를 다시 생성하지 말고, 기존 Markdown 산출물을 직접 또는 에이전트와 함께
+다듬어 해소하세요. 만들기로 했다면 `go` 결정을 `/speckit-specify`로 넘길 수 있습니다. 이유를
+기록해 두고 멈추는 것도 유용한 결과입니다.
+
+[아이디어 평가 실습 가이드](https://github.github.io/spec-kit/guides/assessment.html) ·
+[명령어 레퍼런스](https://github.github.io/spec-kit/reference/agentic-assessment.html)
+
+<a id="-making-spec-kit-your-own-extensions--presets"></a>
+<a id="-bundles-role-based-setups"></a>
+<a id="-community"></a>
+
+## 커스터마이즈하거나 직접 만든 프로세스 가져오기
+
+**확장**은 기능을 추가하고, **프리셋**은 기존 동작을 조정하며, **워크플로**는 단계를 자동화하고,
+**번들**은 역할별 구성을 하나로 묶습니다. 일회성 템플릿 변경에는 프로젝트 로컬 오버라이드를 사용하세요.
+
+[커스터마이즈 가이드](https://github.github.io/spec-kit/guides/customization.html) ·
+[커뮤니티 확장, 프리셋, 번들, 실습 가이드](https://github.github.io/spec-kit/community/overview.html)
+
+<a id="-specify-cli-reference"></a>
+<a id="available-slash-commands"></a>
+<a id="-learn-more"></a>
+<a id="-core-philosophy"></a>
+<a id="-development-phases"></a>
+<a id="-experimental-goals"></a>
+<a id="-video-overview"></a>
+<a id="-does-spec-kit-use-spec-kit"></a>
+
+## 문서
+
+- [CLI 레퍼런스](https://github.github.io/spec-kit/reference/overview.html)와 [프로세스 명령어](https://github.github.io/spec-kit/reference/agentic-sdd.html#command-overview)
+- [SDD 철학](https://github.github.io/spec-kit/concepts/sdd.html), [전체 방법론](./spec-driven.md), [기존 스펙 발전시키기](https://github.github.io/spec-kit/guides/evolving-specs.html)
+- [소개 영상](https://github.github.io/spec-kit/quickstart.html#video-overview)과 [프로젝트 연혁](https://github.github.io/spec-kit/history.html)
+- [Spec Kit이 Spec Kit을 쓰는 방법](./CONTRIBUTING.md#does-spec-kit-use-spec-kit)
+
+## 스타 추이
+
+<p align="center">
+    <a href="https://www.star-history.com/#github/spec-kit&Date">
+        <picture>
+            <source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=github%2Fspec-kit&type=Date&theme=dark"/>
+            <source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=github%2Fspec-kit&type=Date"/>
+            <img src="https://api.star-history.com/svg?repos=github%2Fspec-kit&type=Date" alt="Spec Kit 스타 추이 차트"/>
+        </picture>
+    </a>
+</p>
+
+<p align="center">
+    <em>Spec Kit을 빛내 주시는 모든 분께 감사드립니다.</em>
+</p>
+
+<a id="-support"></a>
+
+## 지원 및 기여
+
+[버그 신고 또는 기능 요청](https://github.com/github/spec-kit/issues/new) ·
+[기여 가이드](./CONTRIBUTING.md) · [행동 강령](./CODE_OF_CONDUCT.md)
+
+<a id="-license"></a>
+
+Spec Kit은 [MIT 라이선스](./LICENSE)로 배포됩니다.

{specify_cli-1.2.0 → specify_cli-1.2.1}/README.md

@@ -14,12 +14,13 @@
 <p align="center">
     <strong>English</strong> ·
     <a href="./README.zh-CN.md">简体中文</a> ·
-    <a href="./README.ja.md">日本語</a>
+    <a href="./README.ja.md">日本語</a> ·
+    <a href="./README.ko.md">한국어</a>
 </p>
 
 Spec Kit is an open source toolkit that gives AI coding agents structured
-processes, reusable templates, and documented outcomes. Start with one of the
-three processes below, customize it, or bring your own.
+processes, reusable templates, and documented outcomes. Start with a ready-made
+process, customize it, or bring your own.
 
 ## Choose your process
 
@@ -28,9 +29,40 @@ three processes below, customize it, or bring your own.
 | Build a feature or application | [Spec-Driven Development](#spec-driven-development) | A specification carried through planning, implementation, and convergence |
 | Diagnose and repair broken behavior | [Bug fixing](#bug-fixing) | An assessed cause, scoped fix, and recorded verification |
 | Decide whether an idea deserves investment | [Idea assessment](#idea-assessment) | An evidence-backed go, clarify, or stop decision |
-
-These are **independent entry points**, not three mandatory phases. SDD ships in
-core; bug fixing and assessment are bundled extensions you install when needed.
+| Adopt or create a different process | [Your own process](#capabilities) | A process adapted or assembled from reusable primitives |
+
+These are **independent entry points**, not mandatory phases. SDD ships in core;
+bug fixing and assessment are bundled extensions you install when needed, and
+the primitives below let you adopt or create other processes.
+
+## Capabilities
+
+Spec Kit combines ready-to-use processes with composable mechanisms:
+
+| Capability | Spec Kit mechanism |
+| --- | --- |
+| Connect to or switch between coding agents | [Integration](https://github.github.io/spec-kit/reference/integrations.html) |
+| Add a command, quality gate, or complete process | [Extension](https://github.github.io/spec-kit/reference/extensions.html) |
+| Connect a process to an external tool or service | [Extension](https://github.github.io/spec-kit/reference/extensions.html) |
+| React to coding-agent lifecycle events | [Extension event hook](https://github.github.io/spec-kit/reference/extensions.html#project-extension-and-hook-configuration) |
+| Adapt templates, commands, terminology, or methodology | [Preset](https://github.github.io/spec-kit/reference/presets.html) |
+| Enforce organizational or regulatory standards | [Preset](https://github.github.io/spec-kit/reference/presets.html) |
+| Override a template for one project | [Project-local override](https://github.github.io/spec-kit/guides/customization.html#project-local-overrides-and-resolution) |
+| Automate prompts, commands, gates, and shell tasks | [Workflow](https://github.github.io/spec-kit/reference/workflows.html) |
+| Modify an installed workflow without forking it | [Workflow overlay](https://github.github.io/spec-kit/reference/workflows.html#workflow-overlays) |
+| Add reusable executable behavior to workflows | [Workflow step](https://github.github.io/spec-kit/reference/workflows.html#custom-step-packages) |
+| Install a curated setup for a role or team | [Bundle](https://github.github.io/spec-kit/reference/bundles.html) |
+| Discover community components | [Catalog](https://github.github.io/spec-kit/reference/catalogs.html) |
+| Host a private catalog of approved components | [Catalog](https://github.github.io/spec-kit/reference/catalogs.html) |
+| Access private catalogs and component downloads | [Authentication](https://github.github.io/spec-kit/reference/authentication.html) |
+| Work offline or behind a firewall | [Local sources and self-hosted catalogs](https://github.github.io/spec-kit/install/air-gapped.html) |
+| Inspect which layer supplies a command, template, or script | [Artifact inventory](https://github.github.io/spec-kit/reference/artifacts.html) |
+
+Search the active catalogs with commands such as `specify extension search`,
+`specify preset search`, `specify workflow search`, and `specify bundle search`.
+Spec Kit includes community catalogs, and organizations can add their own
+curated sources. Catalog listings are not audits or endorsements, so review
+community source code before installing or running it.
 
 <a id="-get-started"></a>
 <a id="-prerequisites"></a>

{specify_cli-1.2.0 → specify_cli-1.2.1}/README.zh-CN.md

@@ -14,7 +14,8 @@
 <p align="center">
     <a href="./README.md">English</a> ·
     <strong>简体中文</strong> ·
-    <a href="./README.ja.md">日本語</a>
+    <a href="./README.ja.md">日本語</a> ·
+    <a href="./README.ko.md">한국어</a>
 </p>
 
 Spec Kit 是一个开源工具套件，为 AI 编码助手提供结构化流程、可复用模板和有据可查的成果。

{specify_cli-1.2.0 → specify_cli-1.2.1}/design/integration.md

@@ -72,6 +72,14 @@ Core templates that call scripts declare `sh`, `ps`, and `py` commands in
 `scripts:` frontmatter; template processing replaces `{SCRIPT}` with the
 selected variant. `py` is opt-in; non-interactive init defaults to `sh` on
 POSIX or `ps` on Windows. Maintain equivalent stdout behavior across all three.
+All PowerShell scripts in the repository and all PowerShell functionality
+generated from repository templates MUST target Windows PowerShell 5.1. All
+such code must use only language features, cmdlets, parameters, and runtime
+APIs available in Windows PowerShell 5.1. Implementations must also account for
+encoding, .NET Framework, and process/runtime differences in Windows
+PowerShell 5.1 while preserving the required Bash and Python behavioral parity.
+Validation evidence for behavioral PowerShell changes must exercise Windows
+PowerShell 5.1 or otherwise demonstrate 5.1 compatibility.
 Bundled extension commands do not yet use this core-template script routing.
 `__AGENT__` and command references are resolved during rendering, not by
 adding per-agent wrapper scripts. For `generic`, extension registration

{specify_cli-1.2.0 → specify_cli-1.2.1}/docs/README.md

@@ -32,6 +32,7 @@ To build the documentation locally:
 - `guides/bugfix.md` - Bug-fixing walkthrough
 - `guides/assessment.md` - Idea assessment walkthrough
 - `guides/customization.md` - Choosing and combining customization building blocks
+- `reference/catalogs.md` - Catalog discovery, trust, private sources, and precedence
 - `reference/agentic-*.md` - Detailed process command references
 - `_site/` - Generated documentation output (ignored by git)
 

{specify_cli-1.2.0 → specify_cli-1.2.1}/docs/community/extensions.md

@@ -79,6 +79,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Fix Findings | Automated analyze-fix-reanalyze loop that resolves spec findings until clean | `code` | Read+Write | [spec-kit-fix-findings](https://github.com/Quratulain-bilal/spec-kit-fix-findings) |
 | FixIt Extension | Spec-aware bug fixing — maps bugs to spec artifacts, proposes a plan, applies minimal changes | `code` | Read+Write | [spec-kit-fixit](https://github.com/speckit-community/spec-kit-fixit) |
 | Fleet Orchestrator | Orchestrate a full feature lifecycle with human-in-the-loop gates across all SpecKit phases | `process` | Read+Write | [spec-kit-fleet](https://github.com/sharathsatish/spec-kit-fleet) |
+| gh-address-cr | Auditable PR review-resolution & trust-gated address engine for Spec Kit workflows. | `process` | Read+Write | [spec-kit-extensions](https://github.com/RbBtSn0w/spec-kit-extensions) |
 | GitHub Issue Triage | Fetch open GitHub issues, classify each as bug, feature, or chore, then delegate to the correct workflow without saving bugs or chores as specs. | `integration` | Read+Write | [speckit-extensions](https://github.com/arrrrny/speckit-extensions) |
 | GitHub Issues Integration 1 | Generate spec artifacts from GitHub Issues - import issues, sync updates, and maintain bidirectional traceability | `integration` | Read+Write | [spec-kit-github-issues](https://github.com/Fatima367/spec-kit-github-issues) |
 | GitHub Issues Integration 2 | Creates and syncs local specs from an existing GitHub issue | `integration` | Read+Write | [spec-kit-issue](https://github.com/aaronrsun/spec-kit-issue) |
@@ -138,7 +139,7 @@ The following community-contributed extensions are available in [`catalog.commun
 | Quality Gates (Enforcement Layer) | Deterministic quality enforcement for Spec Kit projects at three boundaries: the agent boundary (Claude Code PreToolUse/PostToolUse/Stop hooks), the git boundary (pre-commit / pre-merge-commit / commit-msg), and the CI boundary (projected GitHub Actions / GitLab CI / Jenkins pipelines). One policy file, one verify entrypoint, identical results at every boundary. | `process` | Read+Write | [spec-gates](https://github.com/schwichtgit/spec-gates) |
 | RAG Azure Builder | Spec Kit extension for onboarding and operating an Azure RAG stack with guided workflows. | `process` | Read+Write | [spec-kit-extension-rag-azure-builder](https://github.com/Sertxito/spec-kit-extension-rag-azure-builder) |
 | Ralph Loop | Autonomous implementation loop using AI agent CLI | `code` | Read+Write | [spec-kit-ralph](https://github.com/Rubiss-Projects/spec-kit-ralph) |
-| Reconcile Extension | Reconcile implementation drift by surgically updating feature artifacts. | `docs` | Read+Write | [spec-kit-reconcile](https://github.com/stn1slv/spec-kit-reconcile) |
+| Reconcile Extension | Reconcile implementation drift by surgically updating the feature's own spec, plan, and tasks. | `docs` | Read+Write | [spec-kit-reconcile](https://github.com/stn1slv/spec-kit-reconcile) |
 | Red Team | Adversarial review of specs before /speckit.plan — parallel lens agents surface risks that clarify/analyze structurally can't (prompt injection, integrity gaps, cross-spec drift, silent failures). Produces a structured findings report; no auto-edits to specs. | `docs` | Read+Write | [spec-kit-red-team](https://github.com/ashbrener/spec-kit-red-team) |
 | Research Harness | State-externalizing research harness: budgeted exploration, evidence curation, and claim verification for spec-driven development | `process` | Read+Write | [spec-kit-harness](https://github.com/formin/spec-kit-harness) |
 | Repository Governance | Generate project-governance projections from Spec Kit metadata | `process` | Read+Write | [spec-kit-agent-governance](https://github.com/bigsmartben/spec-kit-agent-governance) |

{specify_cli-1.2.0 → specify_cli-1.2.1}/docs/community/overview.md

@@ -6,6 +6,9 @@ The Spec Kit community builds extensions, presets, bundles, workflow steps, walk
 > Review community source code before installation and use it at your own
 > discretion. A catalog listing is not an audit or endorsement.
 
+Learn how discovery-only community sources and approved private sources fit
+together in the [catalog reference](../reference/catalogs.md).
+
 ## Extensions
 
 Extensions add new capabilities to Spec Kit — domain-specific commands, external tool integrations, quality gates, and more. Over 130 community extensions are available from 70+ authors, covering everything from accessibility governance to multi-agent orchestration.

{specify_cli-1.2.0 → specify_cli-1.2.1}/docs/concepts/spec-persistence.md

@@ -19,11 +19,21 @@ is adding remaining work to `tasks.md`. It does not select a persistence model,
 rewrite intent to match code, or treat approval of code as agreement with
 documented intent.
 
+The core workflow has no dedicated command that automatically reconciles
+differences among `spec.md`, `plan.md`, and `tasks.md`. Analyze reports
+inconsistencies without editing artifacts, and converge only appends remaining
+work to `tasks.md`. Teams can reconcile artifacts directly, and extensions can
+provide their own commands or hooks to coordinate reconciliation during or
+after delivery. Extension behavior does not change the responsibilities of the
+core commands.
+
 Persistence is the team's choice of how to maintain artifacts **after
 delivery**, not an alternative way to deliver or determine completeness.
 Discoveries can occur during implementation, but their timing does not define
-the persistence model. If the team agrees to change the intended contract,
-make that intent explicit in the artifacts and deliver against it.
+the persistence model. Reconciliation can also occur during delivery without
+becoming part of the core workflow or the persistence strategy. If the team
+agrees to change the intended contract, make that intent explicit in the
+artifacts and deliver against it.
 
 A later change requiring implementation still goes through the shared delivery
 process and convergence against its explicit intended artifacts, whether those
@@ -55,14 +65,17 @@ all allowed to inform each other.
 
 After delivery, accepted discoveries can inform maintenance edits to any
 artifact. The team decides what those discoveries mean for intended behavior,
-technical approach, or task breakdown, then manually reconciles `spec.md`,
-`plan.md`, and `tasks.md` with that agreed direction. The implementation is
-evidence for that discussion, not a replacement source of intent.
+technical approach, or task breakdown. The team can reconcile `spec.md`,
+`plan.md`, and `tasks.md` itself or use an extension whose documented behavior
+does so. The implementation is evidence for that discussion, not a replacement
+source of intent.
 
 This is a team-owned maintenance convention, not a requirement for a new core
-amendment command or an artifact-rewriting role for converge. If reconciliation
-identifies implementation work, deliver that change through the shared process
-against the explicit intended artifacts.
+amendment command or an artifact-rewriting role for analyze or converge.
+Extension-provided reconciliation remains extension behavior, whether it runs
+during or after delivery. If reconciliation identifies implementation work,
+deliver that change through the shared process against the explicit intended
+artifacts.
 
 Flow-back works well when:
 

{specify_cli-1.2.0 → specify_cli-1.2.1}/docs/guides/evolving-specs.md

@@ -44,10 +44,18 @@ Converge is append-only: its only possible write is adding tasks to `tasks.md`.
 It does not choose a persistence strategy or rewrite the artifacts to accept
 code as a replacement for documented intent.
 
+Core has no dedicated command that automatically reconciles differences among
+`spec.md`, `plan.md`, and `tasks.md`. `/speckit.analyze` reports inconsistencies
+without changing the artifacts. A team can reconcile them directly, or an
+extension can provide commands or hooks that do so during or after delivery
+according to that extension's documented behavior. Those actions do not change
+the responsibilities of the core commands.
+
 Discoveries may arise during delivery under any model. If they lead to an
 agreed change of intent, make the revised contract explicit in the artifacts
-and deliver against it. The maintenance choices below apply after delivery;
-they do not replace this loop.
+and deliver against it. Reconciliation may occur during delivery, but the
+maintenance choices below describe what the team persists after delivery; they
+do not replace this loop.
 
 ## Flow-Forward Spec
 
@@ -68,17 +76,16 @@ Use living spec when `spec.md` is the contract and `plan.md` and `tasks.md` are
 derived from it.
 
 After delivery, maintain `spec.md` as the contract. When intended behavior
-changes, revise the existing `spec.md` first. Then regenerate or manually revise
-downstream artifacts so they match the updated spec:
+changes, revise the existing `spec.md` first. Then reconcile downstream
+artifacts so they match the updated spec:
 
-1. Start from a clean working tree or a dedicated branch so every generated
+1. Start from a clean working tree or a dedicated branch so every artifact
    change is reviewable.
-2. Update `spec.md` with `/speckit.clarify` or an explicit edit.
-3. Rerun `/speckit.plan` or revise `plan.md` so the technical approach matches
-   the revised spec.
-4. Rerun `/speckit.tasks` or revise `tasks.md` so implementation work matches
-   the revised plan.
-5. Run `/speckit.analyze` to catch gaps between the spec, plan, and tasks.
+2. Update `spec.md` with the intended contract.
+3. Reconcile `plan.md` and `tasks.md` directly or through an extension according
+   to the team's documented convention.
+4. Run `/speckit.analyze` to report any remaining gaps between the spec, plan,
+   and tasks.
 
 These steps maintain the artifact set; they do not deliver changed behavior.
 If the revised contract requires implementation, use the shared delivery loop
@@ -107,7 +114,8 @@ alignment with that agreed direction:
 
 The implementation provides evidence for the team's decision; accepting code
 does not automatically make it the intended contract. Reconcile the artifacts
-manually, not through converge or a required core amendment command. If the
+directly or through an extension. Analyze and converge do not provide automatic
+all-artifact reconciliation, and no core amendment command is required. If the
 agreed direction requires implementation, use the shared delivery loop above
 against explicit intended artifacts.
 

{specify_cli-1.2.0 → specify_cli-1.2.1}/docs/index.md

@@ -172,7 +172,7 @@ Community extensions like CI Guard and Architecture Guard add compliance gates a
   </a>
   <a href="reference/overview.md" class="nav-card">
     <strong>Reference</strong>
-    <span>Core commands, integrations, extensions, presets, and workflows</span>
+    <span>Core commands, catalogs, integrations, extensions, presets, and workflows</span>
   </a>
   <a href="community/overview.md" class="nav-card">
     <strong>Community</strong>