5.4 KiB
5.4 KiB
title, type, tags, date
| title | type | tags | date | |||||
|---|---|---|---|---|---|---|---|---|
| Jira Workflow Steward Agent Personality | source |
|
2026-04-25 |
Source File
Summary（用中文描述）
- 核心主题：Jira Workflow Steward——软件交付可追溯性管理 Agent，通过 Jira-Git 全链路绑定，确保每一次代码变更都能从 Jira 任务追踪到分支、提交、PR 直至关线发布
- 问题域：团队代码交付过程中分支命名混乱、提交信息不规范、PR 缺乏 ticket 上下文、发布链路不可审计等交付治理难题
- 方法/机制：Jira Gate（Jira ID 强制前置检查）→ 分支策略（feature/bugfix/hotfix/release 分流）→ Gitmoji 规范提交 → PR 模板 → Commit Hook 自动化验证
- 结论/价值：使代码交付可审查、可回滚、可审计，将 Jira-linked commits 定位为质量工具而非合规打勾
Key Claims（用中文描述）
- Jira Task ID 是所有 Git 工作流输出的前提：分支名、提交信息、PR 标题均必须包含有效 Jira ID，无 ID 则停止工作流
- 分支策略需遵循仓库意图：feature/bugfix 从 develop 分支；hotfix 从 main 分支；release 用于发布准备，各路径互不混淆
- 提交信息遵循
<Gitmoji> JIRA-ID: 简短描述格式，选择 Gitmoji 需参照官方 catalog（gitmoji.dev / carloscuesta/gitmoji） - PR 是 main、release/*、大型重构和关键基础设施变更的强制门控，任何合并均需经过 review
- 秘密/凭证/客户数据严禁出现在分支名、提交信息、PR 标题或描述中
- Jira-linked commits 的价值在于提升 review 上下文、代码结构、发布说明质量和事故溯源能力，而非仅为合规
Key Quotes
"If a change cannot be traced from Jira to branch to commit to pull request to release, you treat the workflow as incomplete." — 核心原则：可追溯性即质量 "Jira-linked commits as a quality tool, not just a compliance checkbox" — 提交绑定 Jira 的定位重塑：质量工具而非合规工具 "Protect repository clarity: the commit message should say what changed, not that you 'fixed stuff'." — 提交信息质量标准
Key Concepts
- Jira-Git-Traceability：通过 Jira ID 将 Jira 任务、分支、提交、PR、发布五个环节串联为完整可追溯链路的实践
- Atomic-Commit：每次提交仅包含一个逻辑变更，易于审查、回滚和溯源的提交粒度原则
- Branch-Strategy：基于功能/缺陷/热修复/发布类型的分支分层管理模型（feature/bugfix/hotfix/release）
- Gitmoji-Commit：使用标准化 Emoji 前缀标注提交类型的提交规范（✨ 新功能、🐛 缺陷修复、♻️ 重构等）
- Jira-Gate：强制要求所有 Git 工作流输出必须携带有效 Jira Task ID 的门控机制，无 ID 则停止工作流
- Pull-Request-Governance：通过 PR 模板、安全审查、风险记录保护分支合并质量的工作流规范
- Delivery-Traceability：从需求到代码发布全链路的可重建、可审计交付记录体系
Key Entities
- Gitmoji：标准化 Emoji 提交规范工具（来源：gitmoji.dev / carloscuesta/gitmoji）；Jira Workflow Steward 使用其作为提交类型的视觉标签
- GitHub：PR 托管和分支策略执行平台；PR 模板和安全门控在此实现
- Project-Management-Project-Shepherd：同为项目管理领域的 Agent；Project Shepherd 负责整体项目协调，Jira Workflow Steward 专注交付可追溯性，两者互补
- Project-Management-Studio-Operations：同为 The Agency 项目管理层级中的 Agent；Studio Operations 负责运营流程，Jira Workflow Steward 负责技术交付链路
Connections
- Jira-Gate ← 是 Delivery-Traceability 的第一步门控
- Branch-Strategy ← 支撑 Jira-Git-Traceability 的分支层
- Atomic-Commit ← 支撑 Jira-Git-Traceability 的提交层
- Pull-Request-Governance ← 支撑 Jira-Git-Traceability 的审查层
- Gitmoji-Commit ← 提供 Atomic-Commit 的标准化视觉表达
- Project-Management-Project-Shepherd ← 上游协调者，提供 Jira 任务；Jira-Workflow-Steward 负责将任务转化为可追溯代码交付
Contradictions
- 与 Project-Management-Project-Shepherd 在职责边界上存在互补但需协调的张力：
- 冲突点：Project Shepherd 生成 Jira 任务，Jira Workflow Steward 要求任务必须存在才能工作——两者均强调任务先行，但无主动对接机制
- 当前观点：Steward 严格 gate，要求任务 ID 前置；若缺失则停止工作流并请求补充
- 对方观点：Project Shepherd 可能期望 Agent 能自动创建或推断 Jira 任务 ID
- 建议协调：在 Project Shepherd 的工作流中增加 Jira 任务预创建步骤，确保交接给 Steward 时 ID 已就绪
- 与 Project-Management-Studio-Producer 在交付粒度上存在层级差异：
- Studio Producer 关注组合级（Portfolio）ROI 和战略优先级，Jira Workflow Steward 关注原子级代码提交
- 当前观点：Steward 坚持每个 commit 对应一个 Jira ID，保持最小粒度可追溯
- 对方观点：Producer 可能在聚合分析时需要更高粒度的任务层级（Epic/Story vs Task）
- 无直接冲突，属不同抽象层级的关注点差异