All authors

Claude Skills by AsiaOstrich
github.com/AsiaOstrich272 skills0 installs398 views
- Adr Assistant[UDS] 创建、管理并追踪架构决策记录(ADR)。 Use when: 架构决策、技术选型、设计取舍、模式选择。 Not for: 不改变架构的决策——记在规格或 commit 里即可;想法还没成形到足以下决定——请用 /brainstorm。 Keywords: ADR, architecture decision, decision record, trade-off, 架构决策, 决策记录, 设计取舍.Votes: 0GitHub stars: 75
- Ai Collaboration Standards防止 AI 幻觉,确保分析代码或提出建议时给出以证据为基础的回应。 Use when: 分析代码、提出建议、提供选项,或用户询问把握度/确定性时。 Not for: 编写 AI 指令文件本身——请用 /ai-instruction-standards;审查具体的 diff——请用 /code-review。 Keywords: certainty, assumption, inference, evidence, source, 证据, 假设, 推论, 确定性, 反幻觉.Votes: 0GitHub stars: 75
- Api Design Assistant引导 API 设计,遵循 REST、GraphQL 与 gRPC 最佳实践。 Use when: 设计 API、审查端点、API 版本策略决策。 Not for: 验证运行中的 API 是否符合消费端期待——请用 /contract-test;API 背后的 schema 设计——请用 /database。 Keywords: API, REST, GraphQL, gRPC, endpoint, versioning, 接口设计, 端点, 版本策略.Votes: 0GitHub stars: 75
- Audit Assistant[UDS] 诊断 UDS 安装的健康状态,并向上游提交结构化反馈。 Use when: .standards/ 看起来损坏或不同步、验证 manifest 完整性、反馈既有 UDS 标准用起来的摩擦点。 Not for: 审计你自己应用程序的代码质量——请用 /metrics 或 /code-review;依赖包与密钥扫描——请用 /scan。 Keywords: UDS audit, health check, manifest integrity, standards feedback, friction, 安装健康, 标准审计, 反馈, 完整性检查.Votes: 0GitHub stars: 75
- Brainstorm Assistant[UDS] 在规格出现之前执行的结构化多角色头脑风暴,并附带评分质量关卡。 Use when: 想法还很模糊、在敲定方向前探索替代方案、需要多样性而不是第一个看似合理的答案。 Not for: 方向已经定了的工作规划——请用 /plan 或 /sdd;记录已经做成的决策——请用 /adr。 Keywords: brainstorm, ideation, divergence, convergence, persona ensemble, devil advocate, 头脑风暴, 发想, 发散收敛, 多角色.Votes: 0GitHub stars: 75
- Ci Cd Assistant引导 CI/CD 流水线的设计、配置与优化。 Use when: 搭建流水线、缩短构建时间、配置部署阶段。 Not for: 没有 CI/CD 平台的部署——请用 /deploy;版本号递增与晋级——请用 /release。 Keywords: CI/CD, pipeline, GitHub Actions, deployment, build, 持续集成, 持续部署, 流水线.Votes: 0GitHub stars: 75
- Code Review Assistant[UDS] 系统性代码审查的参考资料:八大审查类别,以及 BLOCKING/IMPORTANT/SUGGESTION 评论前缀。 Use when: 审查 pull request 或 diff、决定审查意见的措辞与优先级、与团队议定审查范围。 Not for: 执行有关卡的审查流程——该部分已移至采用层(XSPEC-095);提交前的关卡验证——请用 /checkin。 Keywords: code review, pull request review, review checklist, BLOCKING, comment prefix, 代码审查, 审查类别, 评论前缀, 审查清单.Votes: 0GitHub stars: 75
- Commit Standards[UDS] 生成符合 Conventional Commits 规范的 commit message,包含双语格式。 Use when: 为已暂存的变更撰写 commit message、选择 type 与 scope、产出英文与中文并列的主旨与正文。 Not for: 判断这份变更是否已可提交——请用 /checkin;把多个 commit 汇整成发布说明——请用 /changelog。 Keywords: commit message, Conventional Commits, feat, fix, refactor, scope, bilingual, 提交信息, 双语 commit, 提交规范.Votes: 0GitHub stars: 75
- Contract Test Assistant[UDS] 引导 API 与微服务的契约测试策略。 Use when: API 契约、微服务、消费者驱动测试、提供者验证。 Not for: 一开始的 API 接口设计——请用 /api-design;经由 UI 的用户可见流程——请用 /e2e。 Keywords: contract test, Pact, OpenAPI, consumer-driven, provider, 契约测试, 消费者驱动, 提供者验证.Votes: 0GitHub stars: 75
- Database Assistant引导数据库设计、迁移与查询优化。 Use when: schema 设计、迁移规划、查询优化、索引策略。 Not for: 应用程序代码迁移或框架升级——请用 /migrate;数据之上的 API 契约——请用 /api-design。 Keywords: database, schema, migration, SQL, index, query, 数据库, 迁移, 查询, 索引策略.Votes: 0GitHub stars: 75
- Deploy Assistant引导在没有 CI/CD 平台(GitHub Actions/GitLab CI)的情况下完成可靠部署。 Use when: 部署到 VPS、离线隔离的服务器,或任何没有 CI/CD 基础设施的环境。 Not for: 建立在 GitHub Actions 或 GitLab CI 上的流水线——请用 /ci-cd;版本号递增与发布晋级——请用 /release。 Keywords: deployment, no-cicd, shell script, blue-green, smoke test, rollback, 无 CI/CD, 部署, 蓝绿部署, 回滚.Votes: 0GitHub stars: 75
- Dev Methodology[UDS] 为项目选择并追踪当前采用的开发方法论(SDD、BDD、TDD)。 Use when: 决定项目该遵循哪一套方法论、切换方法论、查询目前方法论处于哪个阶段。 Not for: 查询某个开发阶段该执行哪个命令——请用 /dev-workflow;执行方法论本身——请用 /sdd、/bdd 或 /tdd。 Keywords: methodology, SDD, BDD, TDD, phase tracking, methodology selection, 方法论, 开发方法选择, 阶段追踪.Votes: 0GitHub stars: 75
- Dev Workflow Guide[UDS] 把目前的软件开发阶段对应到正确的 UDS 命令与 Skill。 Use when: 不确定手上的任务该用哪个 UDS 命令、初次上手 UDS、带着一个功能从规划走到发布。 Not for: 选择或切换方法论——请用 /methodology;实际执行某阶段的工作——请用该阶段自己的 Skill。 Keywords: workflow, development phase, command routing, which command, UDS guide, 开发阶段, 命令对照, 流程指南.Votes: 0GitHub stars: 75
- Documentation Guide引导文档结构、内容需求与项目文档的最佳实践。 Use when: 创建 README、撰写文档、规划 docs 目录、项目初始设置、技术文档。 Not for: 从源代码机械式生成文档——请用 /docgen;变更日志条目——请用 /changelog。 Keywords: README, docs, documentation, CONTRIBUTING, CHANGELOG, ARCHITECTURE, API docs, 文档, 说明文档, 技术文档.Votes: 0GitHub stars: 75
- Durable Execution Assistant[UDS] 引导容错工作流设计,包含检查点、重试策略与回滚计划。 Use when: 长时间运行的工作流总是中途失败、设计检查点的粒度、选择重试或退避策略。 Not for: 处理正在发生中的线上事故——请用 /incident;部署回滚的实现机制——请用 /deploy。 Keywords: durable execution, checkpoint, retry, backoff, idempotency, rollback, 持久执行, 检查点, 重试策略, 幂等.Votes: 0GitHub stars: 75
- E2e Assistant[UDS] 从 BDD 的 .feature 场景生成 E2E 测试骨架,并支持框架检测与覆盖缺口分析。 Use when: 把已完成的 .feature 场景转成可运行的 E2E 骨架、检测项目使用的 E2E 框架、找出没有 E2E 覆盖的 AC。 Not for: 跨多个故事且带有共享状态的旅程——请用 journey-test Skill;编写 .feature 场景本身——请用 /bdd。 Keywords: E2E, end-to-end test, feature file, test skeleton, framework detection, 端对端测试, 测试骨架, 场景转测试, 覆盖缺口.Votes: 0GitHub stars: 75
- Git Workflow Guide引导 Git 分支策略、分支命名与合并操作。 Use when: 创建分支、合并、pull request、Git 工作流程相关问题。 Not for: 撰写 commit message——请用 /commit;推送前的安全检查——请用 /push。 Keywords: branch, merge, PR, pull request, GitFlow, GitHub Flow, 分支, 合并, 工作流程, 分支命名.Votes: 0GitHub stars: 75
- Incident Response Assistant引导事故响应、根因分析与事后复盘文档撰写。 Use when: 生产环境事故、服务中断响应、撰写事后复盘、根因分析(RCA)。 Not for: 在故障发生前设计重试与检查点——请用 /durable;设置告警阈值与 Error Budget 策略——请用 /slo。 Keywords: incident, outage, post-mortem, RCA, root cause, 事故, 服务中断, 事后复盘, 根因分析.Votes: 0GitHub stars: 75
- Journey Test Assistant[UDS] 从项目描述生成连贯的用户旅程测试计划(TESTPLAN)与旅程 E2E 骨架。 Use when: 新项目从第一天就需要一条测试旅程、测试跨多个故事延续的状态、建立以用户画像驱动的旅程计划。 Not for: 单一 AC 的独立 E2E 骨架——请用 /e2e;测量实际达成的代码覆盖率——请用 /coverage。 Keywords: user journey, TESTPLAN, journey test, persona, cross-story state, 用户旅程, 旅程测试, 测试计划, 用户画像.Votes: 0GitHub stars: 75
- Knowledge Graph[UDS] 通过知识图谱追踪规格、决策与代码之间的影响链;没有引擎时以 Markdown 后备方案运作。 Use when: 想知道某份规格或决策会影响到什么、找出哪些代码实现了某个产物、追踪规格、ADR 与模块之间的依赖关系。 Not for: 没有规格或决策锚点的纯文本搜索——请用 Grep;撰写规格本身——请用 /sdd。 Keywords: knowledge graph, impact chain, traceability, spec impact, decision graph, 知识图谱, 影响链, 规格追踪, 依赖关系.Votes: 0GitHub stars: 75
- Metrics Dashboard Assistant[UDS] 长期追踪开发指标、代码质量指标与技术债。 Use when: 评估项目的持续健康状态、分类技术债并观察其趋势、向团队汇报代码质量。 Not for: 初次评估一个不熟悉的代码库——请用 /discover;单看测试覆盖率——请用 /coverage 或 /ac-coverage。 Keywords: metrics, code quality, technical debt, project health, debt trend, 开发指标, 技术债, 项目健康度, 质量趋势.Votes: 0GitHub stars: 75
- Migration Assistant[UDS] 引导系统性的代码迁移、框架升级与技术现代化。 Use when: 规划框架或主版本升级、评估迁移风险、在 API 迁移前先抓取契约测试的固定样本。 Not for: 维持同一套框架的原地改善——请用 /refactor;数据库 schema 设计——请用 /database。 Keywords: migration, framework upgrade, modernization, breaking change, dependency upgrade, 迁移, 升级, 技术现代化, 破坏性变更.Votes: 0GitHub stars: 75
- Observability Assistant引导可观测性建设、指标设计与告警配置。 Use when: 新服务的埋点、SLO 定义、告警设计、成熟度评估。 Not for: 设置数值目标与 Error Budget 策略——请用 /slo;日志格式与级别——请用 /logging-guide。 Keywords: observability, metrics, traces, golden signals, alerting, SLO, 可观测性, 指标, 追踪, 告警.Votes: 0GitHub stars: 75
- Orchestrate以 Claude 原生 Agent tool 编排多任务执行计划(以 DAG 为基础,不需外部引擎)。 Use when: 执行带有并行/顺序任务依赖关系的 plan.json 文件。 Not for: 一开始生成计划——请用 /plan;彼此之间没有依赖关系的单一任务。 Keywords: orchestrate, plan, execute, DAG, task plan, 编排, 执行计划, 并行, 任务依赖.Votes: 0GitHub stars: 75
- Plan从 Spec 文档、OpenSpec 变更或自由文本需求生成 plan.json。 Use when: 把规格转换成可供 /orchestrate 执行的任务计划。 Not for: 执行产出的计划——请用 /orchestrate;判断这个想法值不值得做——请用 /brainstorm。 Keywords: plan, spec, task plan, plan.json, DAG, 计划, 规格, 任务, 任务计划.Votes: 0GitHub stars: 75
- Pr Automation Assistant引导 pull request 创建、审查自动化与合并策略。 Use when: 创建 PR、自动化审查流程、配置合并策略。 Not for: 审查本身的内容实质——请用 /code-review;分支命名与合并策略——请用 /git-workflow-guide。 Keywords: pull request, PR, merge, review, GitHub, GitLab, 合并请求, 审查自动化, 合并策略.Votes: 0GitHub stars: 75
- Project Discovery[UDS] 在既有代码库新增功能之前,评估项目健康度、架构与风险。 Use when: 接手不熟悉或老旧的项目、动工前先估算风险、建立风险登记簿。 Not for: 对已经熟悉的代码库做持续指标追踪——请用 /metrics;从代码回推规格——请用 /reverse。 Keywords: discovery, project assessment, legacy onboarding, risk register, technical debt, 现状评估, 项目盘点, 风险登记簿, 老旧系统.Votes: 0GitHub stars: 75
- PushAI 辅助的 git push 安全层,提供质量关卡与协作护栏。 Use when: 推送 commit、强制推送、推送到受保护分支、推送 feature 分支。 Not for: 撰写 commit 内容——请用 /commit;分支与合并策略的决策——请用 /git-workflow-guide。 Keywords: git push, force push, protected branch, quality gate, push receipt, PR automation, 推送, 保护分支, 质量门禁, 强制推送.Votes: 0GitHub stars: 75
- Release Standards[UDS] 引导发布流程——语义化版本、发布模式,以及 start/finish/promote/deploy 的顺序。 Use when: 切一个发布版本、决定语义化版本要升哪一位、把 release candidate 晋级为稳定版、记录一次部署。 Not for: 撰写变更日志条目本身——请用 /changelog;部署的实现机制——请用 /deploy。 Keywords: release, semantic versioning, version bump, release candidate, promote, 发布, 语义化版本, 发版流程, 版本晋级.Votes: 0GitHub stars: 75
- Requirement Assistant[UDS] 撰写符合 INVEST 准则的用户故事与需求。 Use when: 把一个功能构想转成用户故事、定义可测试的验收条件、检视待办项目的质量。 Not for: 带有设计与差异操作的完整规格文档——请用 /sdd;判断这个构想本身对不对——请用 /brainstorm。 Keywords: requirement, user story, INVEST, acceptance criteria, backlog refinement, 需求, 用户故事, 验收条件, 待办梳理.Votes: 0GitHub stars: 75
- Retrospective Assistant[UDS] 引导 Sprint 与 Release 周期的结构化团队回顾。 Use when: Sprint 结束、发布后复盘、迭代审视、流程改善。 Not for: 生产环境事故的事后复盘——请用 /incident;追踪两次回顾之间的指标趋势——请用 /metrics。 Keywords: retrospective, retro, sprint review, lessons learned, action items, 回顾, 复盘, 迭代审视, 流程改善.Votes: 0GitHub stars: 75
- Runbook Assistant引导 Runbook 的撰写、维护与演练。 Use when: 撰写 Runbook、规划演练、审计 Runbook 覆盖范围、事故后更新 Runbook。 Not for: 处理正在进行中的事故——请用 /incident;部署流程本身——请用 /deploy。 Keywords: runbook, operations, drill, on-call, procedure, 运维手册, 演练, 值班, 标准流程.Votes: 0GitHub stars: 75
- Security Assistant引导安全审查与漏洞评估,遵循 OWASP 标准。 Use when: 安全审计、漏洞检查、安全编码审查、威胁建模。 Not for: 自动化的依赖包、CVE 与密钥扫描——请用 /scan;处理正在发生的安全事件——请用 /incident。 Keywords: security, OWASP, vulnerability, authentication, authorization, 信息安全, 漏洞, 认证, 授权, 威胁建模.Votes: 0GitHub stars: 75
- Testing Guide测试金字塔,以及 UT/IT/ST/E2E 的测试编写标准。 支持 ISTQB 与业界通行金字塔两种框架。 Use when: 编写测试、讨论测试覆盖率、测试策略或测试命名时。 Not for: 驱动红-绿-重构循环——请用 /tdd;测量实际达成的覆盖率——请用 /coverage。 Keywords: test, unit, integration, e2e, coverage, mock, ISTQB, SIT, 测试, 单元测试, 集成测试, 端对端.Votes: 0GitHub stars: 75
- Ai Collaboration Standards防止 AI 幻覺,確保分析程式碼或提出建議時給出以證據為基礎的回應。 Use when: 分析程式碼、提出建議、提供選項,或使用者詢問把握度/確定性時。 Not for: 撰寫 AI 指令檔本身——請用 /ai-instruction-standards;審查具體的 diff——請用 /code-review。 Keywords: certainty, assumption, inference, evidence, source, 證據, 假設, 推論, 確定性, 反幻覺.Votes: 0GitHub stars: 75
- Atdd Assistant[UDS] 驗收測試驅動開發(ATDD)的參考資料:INVEST 準則、Gherkin 驗收條件格式與 Three Amigos 結構。 Use when: 與 Product Owner 一起定義驗收條件、進行規格工作坊、用 INVEST 檢視使用者故事。 Not for: 執行 ATDD 生命週期或強制 PO 簽核關卡——該部分已移至採用層(XSPEC-095);撰寫單元測試——請用 /tdd。 Keywords: ATDD, acceptance test, acceptance criteria, INVEST, specification workshop, Three Amigos, 驗收測試驅動開發, 驗收條件, 規格工作坊.Votes: 0GitHub stars: 75
- Bdd Assistant[UDS] 行為驅動開發(BDD)的參考資料:Gherkin 的 Given-When-Then 格式與 Three Amigos 結構。 Use when: 撰寫或審查 .feature 場景、選定通用語言、針對行為進行探索式對話。 Not for: 執行 BDD 生命週期或 RED/GREEN 自動化——該部分已移至採用層(XSPEC-095);把 .feature 檔轉成 E2E 骨架——請用 /e2e。 Keywords: BDD, Gherkin, Given When Then, feature file, scenario, Three Amigos, 行為驅動開發, 場景, 特性檔, 通用語言.Votes: 0GitHub stars: 75
- Changelog Guide[UDS] 以 Keep a Changelog 格式產生並維護 CHANGELOG.md 條目。 Use when: 從 commit 歷史撰寫變更日誌條目、填寫 Unreleased 區段、將變更分類為 Added/Changed/Fixed。 Not for: 決定下一個版本號或執行發版——請用 /release;撰寫 commit message 本身——請用 /commit。 Keywords: changelog, CHANGELOG.md, Keep a Changelog, release notes, unreleased, 變更日誌, 發布說明, 版本紀錄.Votes: 0GitHub stars: 75
- Checkin Assistant[UDS] 提交前品質關卡的參考資料:關卡定義、檢查清單項目,以及絕不可提交的規則。 Use when: 決定 commit 前必須通過哪些檢查、稽核專案實際強制了哪些品質關卡、確認是否已可簽入。 Not for: 執行關卡流程或中止 commit——該部分已移至採用層(XSPEC-095);找出並清除除錯殘留——請用 /sweep。 Keywords: check-in, pre-commit, quality gate, commit readiness, never commit, 簽入, 提交前檢查, 品質關卡, 檢查清單.Votes: 0GitHub stars: 75
- Code Review Assistant[UDS] 系統性程式碼審查的參考資料:八大審查類別,以及 BLOCKING/IMPORTANT/SUGGESTION 評論前綴。 Use when: 審查 pull request 或 diff、決定審查意見的措辭與優先序、與團隊議定審查範圍。 Not for: 執行有關卡的審查流程——該部分已移至採用層(XSPEC-095);提交前的關卡驗證——請用 /checkin。 Keywords: code review, pull request review, review checklist, BLOCKING, comment prefix, 程式碼審查, 審查類別, 評論前綴, 審查清單.Votes: 0GitHub stars: 75
- Commit Standards[UDS] 產生符合 Conventional Commits 規範的 commit message,包含雙語格式。 Use when: 為已暫存的變更撰寫 commit message、選擇 type 與 scope、產出英文與中文並列的主旨與內文。 Not for: 判斷這份變更是否已可提交——請用 /checkin;把多個 commit 彙整成發布說明——請用 /changelog。 Keywords: commit message, Conventional Commits, feat, fix, refactor, scope, bilingual, 提交訊息, 雙語 commit, 提交規範.Votes: 0GitHub stars: 75
- Docs Generator[UDS] 從專案原始檔產生使用文件(速查表、參考手冊、使用指南)。 Use when: 從 CLI 與 Skill 定義產出速查表或功能參考手冊、指令變更後重新產生文件、確認產生的文件是否為最新。 Not for: 決定專案需要哪些文件或手寫敘述性內容——請用 /documentation-guide;變更日誌條目——請用 /changelog。 Keywords: docgen, usage docs, cheatsheet, feature reference, generated documentation, 使用文件, 速查表, 文件產生, 參考手冊.Votes: 0GitHub stars: 75
- Documentation Guide引導文件結構、內容需求與專案文件的最佳實踐。 Use when: 建立 README、撰寫文件、規劃 docs 目錄、專案初始設定、技術文件。 Not for: 從原始碼機械式產生文件——請用 /docgen;變更日誌條目——請用 /changelog。 Keywords: README, docs, documentation, CONTRIBUTING, CHANGELOG, ARCHITECTURE, API docs, 文件, 說明文件, 技術文件.Votes: 0GitHub stars: 75
- Error Code Guide設計一致的錯誤碼,遵循 PREFIX_CATEGORY_NUMBER 格式。 Use when: 定義錯誤碼、建立錯誤處理機制、設計 API。 Not for: 日誌格式與層級——請用 /logging-guide;處理已經到達正式環境的錯誤——請用 /incident。 Keywords: error code, error handling, error format, API errors, 錯誤碼, 錯誤處理, 錯誤格式.Votes: 0GitHub stars: 75
- Git Workflow Guide引導 Git 分支策略、分支命名與合併操作。 Use when: 建立分支、合併、pull request、Git 工作流程相關問題。 Not for: 撰寫 commit message——請用 /commit;推送前的安全檢查——請用 /push。 Keywords: branch, merge, PR, pull request, GitFlow, GitHub Flow, 分支, 合併, 工作流程, 分支命名.Votes: 0GitHub stars: 75
- Logging Guide實作結構化日誌,包含適當的日誌層級與敏感資料處理。 Use when: 加入日誌、除錯、建立可觀測性。 Not for: 指標、追蹤與告警設計——請用 /observability;錯誤碼分類體系——請用 /error-code-guide。 Keywords: logging, log level, structured logging, observability, 日誌, 結構化日誌, 日誌層級, 敏感資料.Votes: 0GitHub stars: 75
- Project Structure Guide依各語言的最佳實踐組織專案目錄結構的指南。 Use when: 建立專案、重整結構、新增模組、設定建置流程、決定檔案該放哪裡。 Not for: 專門為 AI 導覽而設計的結構——請用 /ai-friendly-architecture;原地重整既有程式碼——請用 /refactor。 Keywords: project, structure, directory, layout, gitignore, scaffold, file placement, utils, helpers, shared, 專案結構, 目錄配置, 檔案擺放.Votes: 0GitHub stars: 75
- Refactoring Assistant[UDS] 引導重構決策與策略選擇,包含「重構還是重寫」這個判斷。 Use when: 程式碼已經難以修改、在戰術性與架構性重構之間做選擇、要在老舊程式碼裡安全地動手。 Not for: 換到不同框架或主版本——請用 /migrate;清除除錯殘留與死碼——請用 /sweep。 Keywords: refactor, rewrite, strangler, legacy code, technical debt, code smell, 重構, 重寫, 技術債, 壞味道.Votes: 0GitHub stars: 75
- Release Standards[UDS] 引導發布流程——語意化版本、發布模式,以及 start/finish/promote/deploy 的順序。 Use when: 切一個發布版本、決定語意化版本要升哪一位、把 release candidate 晉級為穩定版、記錄一次部署。 Not for: 撰寫變更日誌條目本身——請用 /changelog;部署的實作機制——請用 /deploy。 Keywords: release, semantic versioning, version bump, release candidate, promote, 發布, 語意化版本, 發版流程, 版本晉級.Votes: 0GitHub stars: 75
- Requirement Assistant[UDS] 撰寫符合 INVEST 準則的使用者故事與需求。 Use when: 把一個功能構想轉成使用者故事、定義可測試的驗收條件、檢視待辦項目的品質。 Not for: 帶有設計與差異操作的完整規格文件——請用 /sdd;判斷這個構想本身對不對——請用 /brainstorm。 Keywords: requirement, user story, INVEST, acceptance criteria, backlog refinement, 需求, 使用者故事, 驗收條件, 待辦整理.Votes: 0GitHub stars: 75