linear-release-control

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Linear Release Control

Layer: Practice

Linearはcurrent release-driven profileの標準release planning / health / portfolio toolであり、Constitutionではない。重要なのはLinearというsurfaceではなく、Canonical Consistencyを保ったrelease-level planning ownershipである。

同等以上のportfolio/release-planning guaranteeを持つalternativeへ移行する場合はADR-0017のrefinement contractを使う。

Layer: Practice

对于当前的 release-driven profile，Linear 是标准的 release planning / health / portfolio 工具，而不是 Constitution。关键并不在于 Linear 这一 surface，而在于保持 Canonical Consistency 的 release-level planning ownership。

如果迁移到具备同等或更高 portfolio/release-planning guarantee 的 alternative，应使用 ADR-0017 的 refinement contract。

Use this Skill when

release Projectを作成・更新する
release health / target date / blockerを整理する
複数repositoryのrelease状態を俯瞰する
Linear Project Updateを作成する
LinearとGitHubの状態差分をreconcileする
Initiative / Milestone / Cycle / Linear Issueを使うか判断する

通常のimplementationだけならこのSkillを読み込まない。

创建或更新 release Project
整理 release health / target date / blocker
概览多个 repository 的 release 状态
创建 Linear Project Update
reconcile Linear 与 GitHub 之间的状态差异
判断是否使用 Initiative / Milestone / Cycle / Linear Issue

如果只是常规 implementation，不要加载此 Skill。

Source of Truth

source / integration: Git
implementation scope / acceptance criteria: GitHub Issue
implementation dependency: GitHub Issue dependency metadata
code review / CI / merge evidence: GitHub PR / checks
release integration evidence: release PR
release goal / date / health / portfolio: Linear Project / Initiative
durable project knowledge: repository-controlled docs

Linearの値からGitHub execution stateを推測しない。矛盾時はGitHub evidenceを確認してLinear側をreconcileする。

source / integration: Git
implementation scope / acceptance criteria: GitHub Issue
implementation dependency: GitHub Issue dependency metadata
code review / CI / merge evidence: GitHub PR / checks
release integration evidence: release PR
release goal / date / health / portfolio: Linear Project / Initiative
durable project knowledge: repository-controlled docs

不要根据 Linear 中的值推测 GitHub execution state。出现矛盾时，应检查 GitHub evidence，并 reconcile Linear 侧。

Object mapping

Project

1 release train = 1 Linear Project

。週次計画とreleaseは1:1にせず、Projectはversion単位で管理する。

同じversion / release date / release decisionを共有する複数repositoryは1 Projectへまとめてよい。独立versionなら分ける。

最低限:

release goal
version
target date when known
health
release PR / repository / release docs links
release-level blockers / limitations

1 release train = 1 Linear Project

。不要让周次 planning 与 release 形成 1:1 关系；Project 按 version 管理。

共享相同 version / release date / release decision 的多个 repository 可以合并到同一个 Project。如果 version 相互独立，则应分开。

至少包括：

release goal
version
已知时的 target date
health
release PR / repository / release docs 链接
release-level blockers / limitations

Initiative

複数release Projectを束ねるproduct / roadmap goalだけに使う。単一releaseのためだけに作らない。

仅用于承载多个 release Project 的 product / roadmap goal。不要仅为单个 release 创建。

Milestone

release-level checkpointだけに使う。

Scope frozen
Implementation complete
Release candidate verified
Released

必要なcheckpointだけ作る。ticket groupingには使わない。

仅用于 release-level checkpoint。

Scope frozen
Implementation complete
Release candidate verified
Released

仅创建必需的 checkpoint。不要用于 ticket grouping。

Cycle

defaultでは週次planningをCycleへ重複登録しない。release cadenceは可変。

次の場合のみ検討する:

releaseが複数planning windowを跨ぐ
複数Project間のteam capacityを見たい
release cadenceとは別のiteration metricが必要

默认情况下，不要在 Cycle 中重复登记周次 planning。release cadence 是可变的。

仅在以下情况下考虑使用：

release 跨越多个 planning window
需要查看多个 Project 之间的 team capacity
需要与 release cadence 不同的 iteration metric

Linear Issue

GitHub Issueを全面mirrorしない。

Linear Issueは次のようなrelease-level / coordination workに限定する:

cross-repository blocker
external dependency
release decision
signing / distribution / store review
non-code deliverable
operational coordination

code changeのscope / acceptance criteriaはGitHub Issueへ置き、Linear Issueからlinkする。

不要全面 mirror GitHub Issue。

Linear Issue 仅限于以下 release-level / coordination work：

cross-repository blocker
external dependency
release decision
signing / distribution / store review
non-code deliverable
operational coordination

code change 的 scope / acceptance criteria 应放在 GitHub Issue 中，并从 Linear Issue 链接过去。

Release lifecycle

Start

version / goal / 分かる場合のrelease dateを確認する。週次境界は自動公開日ではない。
Linear Projectを作成または既存Projectをreconcileする。
relevant repositories / release docsをresourceとしてlinkする。
GitHubでrelease branchを作成する。
release branchにmeaningful diffが入ったらDraft release PRを作成し、Linear Projectからlinkする。

确认 version / goal，以及可确定的 release date。周次边界并不是自动发布日期。
创建 Linear Project，或与现有 Project 进行 reconcile。
将相关 repositories / release docs 作为 resource 链接进来。
在 GitHub 中创建 release branch。
release branch 中出现有意义的 diff 后，创建 Draft release PR，并从 Linear Project 链接过去。

During implementation

implementationはGitHub Issue / ticket PRで追跡する。
LinearへPR本文・CI log・review discussionを複製しない。
release判断へ影響するblockerだけProject / Linear Issueへ反映する。
週次/変更量/滞留/緊急性でreview（hold/candidate/blocked）。GitHub scopeと公開価値・リスク・滞留・release-only CI/deploy実測を使い、PR数だけで判断しない。
candidateならGitHub PRにfreeze SHA/scope、carry-over、validation、明示承認を記録。Linearはhealthのみ投影する。
Project UpdateはGitHub actual stateを確認してから作成する。

Project Updateの標準内容:

health:
```
onTrack / atRisk / offTrack
```
completed / integrated highlights
current blockers
release gate state
next checkpoint / decision
canonical evidence links

implementation 通过 GitHub Issue / ticket PR 进行追踪。
不要把 PR 正文、CI log 或 review discussion 复制到 Linear。
仅将影响 release 判断的 blocker 反映到 Project / Linear Issue。
根据周次、变更量、滞留情况和紧迫性进行 review（hold/candidate/blocked）。使用 GitHub scope 以及发布价值、风险、滞留情况和 release-only CI/deploy 实测数据，不要仅凭 PR 数量判断。
如果判定为 candidate，则在 GitHub PR 中记录 freeze SHA/scope、carry-over、validation 和明确批准。Linear 仅投影 health。
确认 GitHub actual state 后，再创建 Project Update。

Project Update 的标准内容：

health:
```
onTrack / atRisk / offTrack
```
completed / integrated highlights
current blockers
release gate state
next checkpoint / decision
canonical evidence links

Completion

release PRのmergeとrelease-level gateをGitHubで確認する。
tag / package / deploy / store等、projectで定義したactual availabilityを確認する。
final Project Updateを作成する。
```
Released
```
milestoneを完了する。
actual releaseが確認できた時点でProjectをCompletedへ移す。

在 GitHub 中确认 release PR 的 merge 和 release-level gate。
确认 project 中定义的 actual availability，例如 tag / package / deploy / store。
创建 final Project Update。
完成
```
Released
```
milestone。
actual release 得到确认后，将 Project 移至 Completed。

Agent / MCP policy

Interactive PM操作ではChatGPT等のLinear connector/pluginを使用してよい。

external agentがLinearへ直接アクセスする場合はLinear公式remote MCPをcapabilityとして使える。

Coordinator / release manager:
```
https://mcp.linear.app/mcp
```
read-only worker:
```
https://mcp.linear.app/mcp/readonly
```

implementation workerは原則Linear write不要。planning contextが必要ならread-onlyを優先する。

MCP auth / API key / user-global client configをrepository truthにしない。credentialをcommitしない。

在交互式 PM 操作中，可以使用 ChatGPT 等产品的 Linear connector/plugin。

当 external agent 需要直接访问 Linear 时，可以将 Linear 官方 remote MCP 作为 capability 使用。

Coordinator / release manager:
```
https://mcp.linear.app/mcp
```
read-only worker:
```
https://mcp.linear.app/mcp/readonly
```

implementation worker 原则上无需写入 Linear；如需 planning context，优先使用 read-only。

MCP auth / API key / user-global client config 不得作为 repository truth。不要 commit credential。

Mutation rules

Linearへwriteする前にcanonical GitHub evidenceを確認する。

禁止:

unmerged PRをDone / implementation completeと推測
failing / unknown CIを無視してhealthを楽観更新
Linearだけにtechnical dependencyを追加してGitHub dependency graphと分岐
acceptance criteriaをGitHubとLinearで別々に保守
full GitHub Issue mirrorを自動作成

写入 Linear 之前，先检查 canonical GitHub evidence。

禁止：

将 unmerged PR 推测为 Done / implementation complete
忽略 failing / unknown CI，乐观地更新 health
仅在 Linear 中添加 technical dependency，导致其与 GitHub dependency graph 分叉
分别在 GitHub 与 Linear 中维护 acceptance criteria
自动创建完整的 GitHub Issue mirror

Built-in Linear agents

Linear coding sessionsはbaseline execution pathにしない。Supervisor isolation、number-only ticket branch、PR state lifecycle、release/stack topology、current-SHA validation contractを満たせるadapterとして明示導入した場合のみ使用する。

Loopsもbaselineにしない。利用する場合はstatus summarization / notification等のderived automationに限定し、canonical execution stateを変更するautomationは個別reviewする。

不要将 Linear coding sessions 作为 baseline execution path。只有在明确作为 adapter 引入，且满足 supervisor isolation、number-only ticket branch、PR state lifecycle、release/stack topology、current-SHA validation contract 后，才可使用。

也不要把 Loops 作为 baseline。如需使用，仅限于 status summarization / notification 等 derived automation；任何会改变 canonical execution state 的 automation 都必须单独 review。

Failure / unavailable fallback

Linearが利用不能でもimplementation / release integrationを止めない。

GitHub Issue / PR / release branch / repository docsからcanonical execution stateを復旧し、Linear復旧後にProject stateをreconcileする。

即使 Linear 不可用，也不得阻塞 implementation / release integration。

从 GitHub Issue / PR / release branch / repository docs 恢复 canonical execution state；Linear 恢复后，reconcile Project state。

Constitutional mapping

Canonical Consistency: GitHub execution factsとLinear release-level factsのfield ownershipを分離する
Evidence Integrity: release health/progressをGitHubのdurable evidenceからreconcileする
Organizational Continuity: release goal/date/healthを一つのagent sessionだけに保持しない

Canonical Consistency：将 GitHub execution facts 与 Linear release-level facts 的 field ownership 分离
Evidence Integrity：根据 GitHub 的 durable evidence reconcile release health/progress
Organizational Continuity：不要只在单个 agent session 中保存 release goal/date/health

Re-evaluate / remove

release planningを別systemが同等以上に担う
project規模/形態がLinear control planeを不要にする
GitHub等がrelease-level viewを十分に提供し二重surfaceのcostが上回る

由其他同等或更优的系统承担 release planning
项目规模或形态使 Linear control plane 不再必要
GitHub 等已能充分提供 release-level view，且双重 surface 的成本高于收益