Communitygithub.com

liuzhengdongfortest/cs-decide

Dokumentiert endgültige Technologieentscheidungen, Architekturentscheidungen, langfristige Einschränkungen und Codierungskonventionen als dauerhafte Entscheidungsdokumente. Wird ausgelöst, wenn der Benutzer 'Entscheidung aufzeichnen', 'Technologieauswahl archivieren', 'ADR', 'diese Einschränkung aufzeichnen' oder 'die Konvention niederschreiben' sagt, oder nach einer Design-/Analyse-Phase eine wichtige Wahl getroffen wurde. Nur endgültige Entscheidungen werden archiviert, keine, die noch diskutiert werden.

Was ist cs-decide?

Das Skill 'liuzhengdongfortest/cs-decide' ermöglicht es, technische Entscheidungen in einem KI-gestützten Entwicklungskontext (wie Claude Code oder Cursor) dauerhaft zu dokumentieren. Es unterstützt vier Kategorien von Entscheidungen: Technologieauswahl (tech-stack), Architekturentscheidungen (architecture), langfristige Einschränkungen (constraint) und Codierungskonventionen (convention). Der Hauptnutzen liegt darin, Wissen zu bewahren und sicherzustellen, dass Entscheidungen später nachvollziehbar sind, ohne dass Entwickler sich erneut einarbeiten müssen. Das Skill wird durch bestimmte Schlüsselwörter wie 'Entscheidung aufzeichnen', 'Technologieauswahl archivieren' oder 'ADR' ausgelöst, oder wird aktiv, nachdem der Benutzer in einer Design- oder Analyse-Phase eine wichtige Wahl getroffen hat. Dabei archiviert es ausschließlich endgültig getroffene Entscheidungen, nicht solche, die noch in der Diskussion sind. Es funktioniert auf Basis einer Markdown-Datei (z. B. `decisions/YYYY-MM-DD-title.md`), die automatisch generiert wird und Kontext, Entscheidung sowie Konsequenzen strukturiert festhält. Dieses Skill ist besonders nützlich für Teams, die Architektur-Entscheidungsaufzeichnungen (ADRs) oder ähnliche Dokumentationsstandards nutzen, um technische Schulden zu vermeiden und die Kommunikation zu verbessern.

Funktioniert mit~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/liuzhengdongfortest/codestable/tree/main/skills/cs-decide

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Was macht cs-decide?

Dokumentiert endgültige Technologieentscheidungen, Architekturentscheidungen, langfristige Einschränkungen und Codierungskonventionen als dauerhafte Entscheidungsdokumente (tech-stack / architecture / constraint / convention).

Funktion

Dieses Skill erfasst wichtige technische Entscheidungen in strukturierten Markdown-Dateien, sodass sie später leicht nachvollzogen und verstanden werden können.

Auslöser

Das Skill wird aktiviert, wenn der Benutzer einen der folgenden Befehle sagt oder schreibt:

  • "Entscheidung aufzeichnen"
  • "Technologieauswahl archivieren"
  • "ADR"
  • "Diese Einschränkung aufzeichnen"
  • "Die Konvention niederschreiben"

Es wird auch automatisch ausgelöst, nachdem der Benutzer in einer Design- oder Analyse-Phase eine wichtige technische Wahl getroffen hat.

Kategorien

KategorieBeschreibung
tech-stackAuswahl von Technologien, Frameworks, Bibliotheken
architectureArchitekturentscheidungen, Systemdesign
constraintLangfristige Einschränkungen, Randbedingungen
conventionCodierungskonventionen, Stilrichtlinien

Verwendung

  1. Stelle sicher, dass die Entscheidung endgültig getroffen wurde (nicht mehr in Diskussion).
  2. Verwende einen der Auslöser, um das Skill zu aktivieren.
  3. Das Skill generiert eine Markdown-Datei im Format decisions/YYYY-MM-DD-title.md mit:
    • Kontext: Hintergrund und Problemstellung
    • Entscheidung: Die getroffene Wahl
    • Konsequenzen: Auswirkungen und Begründung

Beispiel

# Entscheidungsprotokoll: Verwendung von PostgreSQL

**Datum**: 2024-01-15
**Kategorie**: tech-stack

## Kontext
Wir benötigen eine zuverlässige, skalierbare relationale Datenbank.

## Entscheidung
Wir verwenden PostgreSQL 16 als primäre Datenbank.

## Konsequenzen
- Höhere Komplexität im Betrieb
- Bessere Datenintegrität und Transaktionsunterstützung

Hinweis

Nur endgültige Entscheidungen werden archiviert. Diskussionen und unentschiedene Optionen werden nicht dokumentiert, um die Dokumentation übersichtlich zu halten.

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

liuzhengdongfortest/cs

CodeStable 工作流根入口,介绍体系全貌并把诉求路由到对应 cs-* 子技能。触发:用户只输入 `cs`、说"介绍一下 codestable"、"该用哪个技能"、"不知道用哪个",或诉求还很开放未收敛。本技能只做路由不做事。

liuzhengdongfortest/cs-arch

维护 `.codestable/architecture/` 这份只记现状的系统地图,三种模式 update / check / backfill。触发:用户说"刷新 architecture"、"做架构检查"、"补这个模块的架构文档"、"方案和代码对得上吗",或 feature 阶段需要先做架构动作。不写未来规划(走 cs-roadmap)。

liuzhengdongfortest/cs-brainstorm

想法还模糊时的讨论入口,做分诊后路由到 feature-design / feature-brainstorm / roadmap。AI 是思考伙伴不是记录员。触发:用户说"有个想法还没想清楚"、"先 brainstorm 一下"、"聊一聊这块"、"方向还在摇摆"。不处理 bug 和重构。

liuzhengdongfortest/cs-explore

对仓库做定向代码探索并把"提问→读代码→得结论"沉淀为可检索证据,三种类型 question / module-overview / spike。触发:用户说"先 explore 一下"、"这个仓库里 X 怎么实现"、"快速熟悉这个模块"、"把探索结果存档"。

liuzhengdongfortest/cs-feat

新功能开发的子流程入口,把"加个 X 能力"从想法走到验收闭环。触发:用户说"做新功能"、"加个 X"、"实现 XX"。只做路由,根据已有产物决定走 brainstorm / design / fastforward / implement / acceptance。不处理 bug。

liuzhengdongfortest/cs-feat-accept

feature 流程阶段 3——验收闭环:对照 design 核实现 + 回写 architecture / requirement / roadmap,最后产出 {slug}-acceptance.md。触发:用户说"功能写完了验收一下"、"做最后检查"、"准备 merge"、"出验收报告"。前置依赖 cs-feat-impl 完成。

liuzhengdongfortest/cs-feat-design

feature 流程阶段 1——为新功能起草 {slug}-design.md 作为后续实现和验收的唯一输入,拍板后抽出 checklist。触发:用户说"开始设计方案"、"写 design doc"、"准备实现 XX",前提是已知道做什么、为谁、怎么算成功。

liuzhengdongfortest/cs-feat-ff

feature 流程的超轻量通道——不写 design / checklist 直接动手,但先指引 AI 查 CodeStable 知识库再开工。触发:用户说"快速模式"、"fastforward"、"别那么多步骤"、"直接开干",且需求小到不值得走 design 流程。

liuzhengdongfortest/cs-feat-impl

feature 流程阶段 2——按 {slug}-checklist.yaml 里 design 切好的 paradigm 维度 steps 推进,每步具体改哪个文件由 implement 自决,写完用统一格式汇报。触发:用户说"方案确认了开始实现"、"按方案写代码"、"开工"。前提是 design 已 approved 且有 checklist。遇到方案外情况要回方案谈不要硬冲。

liuzhengdongfortest/cs-guide

写或更新对外指南文档——开发者指南(dev-guide)和用户指南(user-guide),产物在项目 docs/ 目录。任务导向(怎么用 X 做 Y),与 libdoc 的零件参考不同。触发:用户说"写文档"、"开发者指南"、"用户指南",或 feature-acceptance 收尾时推送。

liuzhengdongfortest/cs-issue

修 bug 的子流程入口,把"发现问题"走到验证修复闭环,留下 report / analysis / fix-note 三份文件。触发:用户说"修 bug"、"有个问题"、"修复 XX"。只做路由,根据已有产物走 report / analyze / fix。简单问题走快速通道。

liuzhengdongfortest/cs-issue-analyze

issue 流程阶段 2——读 report + 读代码定位根因、评估风险,给用户 2-3 个修复方案让 TA 拍板。这一步不改代码。触发:用户说"分析这个 bug"、"找根因"、"定位问题",且已有 {slug}-report.md。

liuzhengdongfortest/cs-issue-fix

issue 流程阶段 3——按已确认根因和方案定点修复、验证、写 {slug}-fix-note.md 落档。两个入口:标准路径从 analyze 来,快速通道从 report 直接来。触发:用户说"开始修 bug"、"按分析修"、"动手改代码"。只动方案声明的文件,不顺手优化。

liuzhengdongfortest/cs-issue-report

issue 流程阶段 1——通过对话把问题落成可复现、可追溯的 {slug}-report.md,并判定走标准路径还是快速通道。只问现象不猜根因。触发:用户说"提个 issue"、"记录这个 bug"、"我发现一个问题"。issue 工作流的起点。

liuzhengdongfortest/cs-learn

把踩过的坑或好做法沉淀成可检索的 learning 文档,两条轨道 pitfall(坑)/ knowledge(默认做法)。触发:用户说"沉淀知识"、"learning"、"把这次经验记下来",或 acceptance / fix 收尾时推送。

liuzhengdongfortest/cs-libdoc

给库的公开表面(组件 / 函数 / 命令)逐条目生成参考文档,带清单追踪,支持单条目和批量。信息源是源码本身(与 guidedoc 任务导向不同)。触发:用户说"写 API 文档"、"组件文档"、"libdoc",或 acceptance 后发现新增公开接口。

liuzhengdongfortest/cs-onboard

把新仓库或有零散文档的仓库接入 CodeStable 体系,两条路径自动判断:空仓库从零搭骨架,已有文档走审计 + 迁移映射。触发:用户说"在这个项目里用 CodeStable"、"搭 CodeStable 结构"、"初始化 CodeStable"、"迁移到 CodeStable"。

liuzhengdongfortest/cs-refactor

代码优化的子流程入口,处理"行为不变、结构变"的工作(结构 / 性能 / 可读性),按 scan → design → apply 分步执行每步人工放行。触发:用户说"优化一下 / 重构 / 重写 / 拆一下 / 性能不行 / 代码太长"且不夹带行为改动。不处理新需求 / bug / 跨模块架构重划。

liuzhengdongfortest/cs-refactor-ff

refactor 流程的超轻量通道——直接识别 1-3 条低风险优化、一次确认、原地改、跑测试自证。触发:用户说"快速重构"、"小重构"、"简单优化下 XX 函数"、"别那么多步骤",且改动在单函数 / 单组件局部、有测试可自证。

liuzhengdongfortest/cs-req

维护 `.codestable/requirements/` 下的能力愿景文档。三种模式 draft / backfill / update。触发:design 阶段起草愿景、acceptance 阶段落档,或用户说"刷新 requirements"、"补一份 req"、"先把愿景写下来"。

Verwandte Skills