What makes Spec-kit Coding notable?

1.1K downloads. Trust evidence available

How should Spec-kit Coding be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

Spec-kit Coding

Orchestrator for GitHub Spec-Kit SDD workflow in OpenClaw. Use when starting a new project with spec-driven development, setting up spec-kit toolchain, or ru... Skill: Spec-kit Coding Owner: staok Summary: Orchestrator for GitHub Spec-Kit SDD workflow in OpenClaw. Use when starting a new project with spec-driven development, setting up spec-kit toolchain, or ru... Tags: latest:1.0.5 Version history: v1.0.5 | 2026-06-16T07:40:35.431Z | user spec-kit-coding v1.0.5 - Removed unnecessary files: TODO.txt and skill-card.md - Updated SKILL.md with a new instruction: now asks users

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.1k

Updated

Oct 11, 2026

Version

1.0.5

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1.1K downloadsadoption · observed Oct 11, 2026
Latest release: 1.0.5release · observed Jun 16, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17b6q0zz08bewcdk63scg1x6h85g46x:spec-kit-coding

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-staok-spec-kit-coding/snapshot"

Documentation

CLAWHUB

152,099 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: spec-kit-coding
description: "Orchestrator for GitHub Spec-Kit SDD workflow in OpenClaw. Use when starting a new project with spec-driven development, setting up spec-kit toolchain, or running through the full SDD pipeline."
---
# Spec-Kit Coding -- OpenClaw Orchestrator

> **Repo:** [Staok/spec-kit-coding-skill](https://github.com/Staok/spec-kit-coding-skill)

Orchestrates the complete Spec-Driven Development workflow via [github/spec-kit](https://github.com/github/spec-kit).

Covers: Engineering Implementation. Does not cover
requirements discovery, operations/deployment, or cross-domain (SRE, security, etc.).

---

## HARD CONSTRAINTS

READ FIRST, APPLY ALWAYS.

These constraints are non-negotiable. Do NOT require the user to repeat them.

### Security

- Never transmit sensitive information to the network.
- Before any external action (API calls, sending data outside local machine),
explain and ask for approval.
- Do not install third-party libraries or modify system config without
asking first. If a new dependency is needed, explain why and get approval.
- Prefer reusing existing, proven, popular third-party solutions. Avoid
reinventing the wheel. Keep tool usage simple and lean. Minimize dependency footprint.
- **WARNING:** As a principle, agents should be disabled in critical-path code,
legacy system maintenance, and security-sensitive modules. Permitted only in
low-risk scenarios such as prototyping, search, and documentation.

### Feature Management / Quick Reference

- Starting a project, follow section: WORKFLOW, from STEP 1 to STEP 7.
- On first project creation, ask the user: auto-run the WORKFLOW (pause only for required confirmations), or confirm at each step.
- Add a new feature or modify an existing feature:
- "add" / "new" / behavior no spec covers -> new feature -> section: STEP 5: Spec-Kit Phases / New Feature.
- "change" / "modify" / changing existing behavior -> modify existing -> section: Feature Modification Entry Point.
- Each `/speckit-specify` invocation creates exactly ONE feature. If the user
describes a messy, multi-concern requirement, split it first:
- List each proposed feature with a short name and one-line summary.
- Note dependencies between features.
- Ask user to confirm the split before proceeding.
- When uncertain whether the user wants a new feature or a modification to an
existing one, ASK. Do not guess. Present your organized analysis. Show several or both options concisely.
- For projects that have already been delivered or already exist, if a bug is reported, refer to section: Bug Fix Entry Point.

### Communication

- Collect all unclear points first, then ask once. Avoid back-and-forth.
- Be efficient and concise. Output only necessary information.
- Remind the user how to think about the problem better; help improve prompt
quality over time.

### Documentation-First

- For spec/plan/tasks .etc phase docs (spec.md, plan.md, tasks.md): these are created via the spec

_meta.json

{
  "ownerId": "kn7200kmgerbhf59xrmr2sbm9585gczq",
  "slug": "spec-kit-coding",
  "version": "1.0.5",
  "publishedAt": 1781595635431
}

CodingGuidance/CppCodingStyle.md

## 良好实践经验 / 易错注意 / 开发套路 / 惯例写法

（引自 [Cpp-Learning/编程经验-规范, 调试、性能和内存检查工具集合.md at main · Staok/Cpp-Learning](https://github.com/Staok/Cpp-Learning/blob/main/编程经验-规范%2C 调试、性能和内存检查工具集合.md)）



### 模块 和 类

一个类的所有 对外 API，尽量都做到 线程安全的，除非需要特殊考虑或者特殊说明。锁的范围尽量小，注意内部带锁的多个函数的嵌套调用的情况。



对于启动 app process 的 各个模块 初始化、反初始化、信号 与 未catch异常管理 等等，参考这个的做法：`CppEngineeringFrameworkReference/AppContext.h`。



对于每个具体干活的、拆分好的执行业务功能的模块用一个类。每个类的具体的统一做法如下：

- 视需求，有的可以是可以创建多个，有的是单例模式。

- 对于完成业务/任务的类，不需要多例，就可以写为单例，对于单例类，写上不可拷贝或移动的构造，以及不可赋值操作的拷贝和移动构造。

- 如果是模块作用的类：

  对于类在启动其作用的时候，如果没有一直循环运行的任务（比如在一个线程里面或者 启动函数里面的 `while(true){...}`）则使用 init 的情况；相反，则使用 run 的情况。下面给出参考。

  对于 init 的情况，具体参考这个例子来写类的框架：`CppEngineeringFrameworkReference/CppModuleInitCaseExample.cpp`。

  对于 run 的情况，具体参考这个例子来写类的框架：`CppEngineeringFrameworkReference/CppModuleRunCaseExample.cpp`。

  关于框架参考代码的 log 和 线程池 相关依赖为示例参考，不是要求。

- 如果是工具作用的类，尽量做到 RAII。
- 在除了启停的 API 以外的其它对外 API 中都应该先判断 是否已经运行或者初始化完毕。
- 按照需要，对外 API 都做到 线程安全（结合具体业务考虑选择使用什么类型的锁，比如读写锁、循环锁等）；锁范围尽量小。如果内部使用线程或线程池的，则需由外部传入；如果线程内异步执行类内资源，在此之前，使用 `std::weak_ptr<XXX> selfWeakPtr = shared_from_this();` 并线程函数 lambda 按值捕获 `selfWeakPtr`（注意不要捕获 this，异步执行的线程可能捕获已经资源释放掉了的 类实例 this，因此使用这里说的 捕获 selfWeakPtr 的方法！），在里面 `.lock()` 然后判断是否为空和判断是否已经在运行或初始化完毕，再使用。
- 关于类变量初始化：
  - 类变量在声明的地方进行赋值默认值。
  - 使用 nullptr 对 指针变量（尽量使用智能指针）声明的时候 进行 初始化；指针资源释放掉后，需要再赋值为 nullptr 。
  - 对于 const 变量，则在 类构造函数 的 初始化列表 处 进行赋值。尽量使用 const。



对于程序中用到多个实例的类，比如 屏幕上的多个 object 或者 多个实体的数据 等的 建模：

- 关于类抽象、继承和多态的对数据进行建模的设计，应符合直觉、有意义、方便使用。
- 基类/抽象类、派生类 的结构设计尽量按照实际情况，尽量分层次处理，基类/抽象类中列好公共 变量 和 接口/虚函数/纯虚函数 等。

- 每个类都做到 RAII。

- 对于一类的事物，每个事物用类封装，它们最好有个共同的抽象基类（继承其），并且每个具体事物的类里面 override 所有抽象基类的虚函数（形成多态）；若这些事物要随时创建，搞一个它们的工厂类（抽象工厂模式）来用 比较通用的接口 通过 不同的入参 来创建不同的一类事物 并返回他们的基类类型指针（用 如 std::make_shared 来创建）；参考自己的 `C-C++-设计模式综合\DesignPattern\Builder`。

- 在具体的地方用 vector、map 等方式存储它们的智能指针（如 std::shared_ptr）来存着他们，或专门写个创建并管理它们的类（增删改查，判（判空）排（排序）复（复位））且用 LRU 的方式存储他们以实现 有序排列的同时 实现 增加、查询 均为O(1) 复杂度。参考自己写的 `GeneralContainer` 作为 对象池 进行管理，也避免频繁申请和释放 示例，改善程序性能，即缓存，空间换时间。



- 如果是写库，则使用 impl 模式。在对外接口的 头文件中 尽量减少和避免 include 三方库的头文件。




### 函数

- 函数的 命名 和 使用方式 （以及注释说明）要 符合直觉、易于理解，不要搞谜语考试别人。

- 可复用的部分拆分出单独的函数。函数保持短小精悍。

  > **"Give someone state and they'll have a bug one day, but teach them how to represent state in two separate locations that have to be kept in sync and they'll have bugs for a lifetime."** [ocornut/imgui: Dear ImGui: Bloat-free Graphical User interface for C++ with minimal dependencies (github.com)](https://github.com/ocornut/imgui)。
  >
  > DeepSeek 翻译为：单一状态顶多偶尔出错，双份状态终身调试不休。

- 如需用锁，优化为无锁，或 减少锁的范围，只针对必要部分。

- 函数实现尽量降低 圈复杂度。

- 不允许使用递归（即不允许函数自己调用自己），如有必要，使用栈结构和循环替代实现。循环必须有退出条件。

- 处理可能抛异常的三方函数，自己写的，尽量不主动抛异常。

- 同一个函数内，局部变量所占用的空间应小于16KB。

- 不对内容进行修改的指针型参数，使用 const 修饰。

- 函数的返回值，一般为有符号整数表示执行结果，0 表示执行成功，负值表示出错（使用 -errno，比如 -EIO），正值表示带条件的执行成功（个人习惯，使用返回的正数区分是什么警告级别的问题）。

  对外接口性质的函数：

  - 根据 GSL（C++ Core Guidelines） 的契约检查，入参检查分为：前置检查，后置检查。

CodingGuidance/DesignPattern/DesignPattern.md

# 程序设计的一些通用结构

参考并总结 [设计模式目录：22种设计模式](https://refactoringguru.cn/design-patterns/catalog)。

更多参考 [设计模式 | 菜鸟教程](https://www.runoob.com/python-design-pattern/python-design-pattern-tutorial.html)。



------

## RAII

使用 RAII（Resource Acquisition Is Initialization）模式可以确保资源在对象的生命周期内正确初始化和释放。

应尽量把程序结构定为多个类的多模块拆分和接力协作，并且，每个类写为 RAII 模式，确保类实例的所有内部资源的初始化和释放与其对象的生命周期一致，达到多次 启停的目的，方便外部使用和管理。

参考 同文件夹 的 `RAII` 目录。内有详细注释说明。



---

## 创建型模式

参考 同文件夹 的 `Pimpl` 和 `Pimpl2`、`Builder` 和 `Singleton` 目录。内有详细注释说明。



---

## 结构型模式



### 适配器(adapter) & 桥接(bridge) & 组合(composite)

适配器(adapter) 可以写为 多种信息类型之间的转换 的组件：选定一个内部的统一的格式，做例如 setIn() 和 setOut() 的方法。

如选定 jsonObj (比如 `nlohmann::json`) 作为内部的中间统一格式，就可以有 `jsonObj.setIn( jsonStr | jsonObj | xmlStr | xmlObj | yamlStr | yamlObj ... )`，以及 `jsonObj.setOut( ... )`。还可以参考 pcl 库的 各种滤波器 的使用，其中就有 `setInput()` 方法 并 重载了多种输入。



上下二者类似 ↑ ↓



桥接(bridge) 可以作为 多对多的控制或调用 的模块（模块为比组件高一个级别的层级，包括多个组件构成） 的结构：上层有多种对外接口功能，下层也有多种平台或者其它情况的各种适配，那种就可以设计一个中间层，只保留少量的、通用的接口。



类似于 ↓



组合(composite) 可以用于 信息结构呈现为树状或网状的 信息存储：将每个信息节点，用 多叉树 或者 网 的数据结构，组合到一起，再添加各种处理操作。




### 装饰器(decorator) & 外观(facade) & 代理(proxy)

这几个类似 wrap 封装一层 的结构 或 方法：比如现在有 三种 三方组件库 A、B 和 C，他们具体接口不一样但是功能行为类似，比如多种社交媒体平台接口，均有发帖和获取贴等，现在要写个上层使用统一的结构对其操作，就可以加一个 wrap 包装/封装一层，先来个比如 WrapBasic 的抽象类定义通用的必要的接口，再写 AWrap 类继承 WrapBasic 并实现 特定接口 来操作 A 库的接口，其它 B 和 C 同理。现在就有了 AWrap、BWrap 和 CWrap 三种 接口统一的 类 可供操作 三种库。



---

## 行为模式



### 行为链条(chain) & 迭代器(iterator)

行为链条(chain)：用于链式的处理逻辑，比如要进行一系列有先后的检查步骤，并要方便的可以在中间增减检查步骤：使用链表结构存储检查函数或者检查抽象类智能指针等，核心就是使用链表的数据结构，如 `std::list`。

对于链条数据结构的遍历，就需要迭代器如下。



迭代器(iterator)：搞一个对某个数据结构的指定迭代/遍历方法的迭代器类：如对于 二叉树 或 网 的数据结构有 深度优先 和 广度优先 等遍历方法。

自己实现的数据结构，需要实现基本的方法：增删改查；我再加四个：判排复遍——判空、排序（对于哈希表结构则没有）、复位（清空）和遍历。

对于遍历，可以两种：

1. 提供遍历的方法比如 `traverse(const TraverseFunction& traverse_func)`，传入一个遍历的回调函数，如下。还可以增加遍历方法指定的形参。

   ```c++
   template <typename Key, typename Value>
   void GeneralContainer<Key, Value>::traverse(const TraverseFunction& traverse_func) const
   {
       if(!traverse_func) {
           return;
       }
       std::shared_lock<std::shared_mutex> lock(mMutex);
       for (const auto& it : mList) { // 正序遍历
           traverse_func(it);
       }
   }
   ```

2. 提供这里所说的迭代器类，不同的迭代器类代表对这个数据结构的不同的遍历方法。比如 std 标准库 容器的:

   ```c++
   std::vector<int> myVector = {1, 2, 3, 4, 5};
   auto forwardIter = myVector.begin();    // forwardIter 指向 第一个 元素，forwardIter++ 则移动到第二个元素。
   auto backwardIter = myVector.rbegin();  // backwardIter 指向 最后一个 元素，backwardIter++ 则移动到倒数第二个元素。
   ```



### 中介/中央调度(mediator) & 命令(command)

中介/中央调度(mediator)：多个地方的组件请求执行动作，如果其之间有冲突，比如多个 app 要往 状态栏 弹带优先级的信息，不要各自都直接弹出，因为需要优先级高的始终在最上，因此需要一个中介或者中央调度的组件或模块，多个地方的 app 统一往这个 中介 请求弹信息，由 中介 选择 往信息栏 插入 的位置并插入、或者检查黑名单并忽略等等。

还有 GUI 程序中的弹窗场景，有的界面可以弹窗，有的界面不允许弹窗，等等还有其它设计情况，因此需要一个中介去统一接受弹窗请求并处理。



命令(command)：思想是，打包一个执行动作以及其传入参数：一个执行动作，如 GUI 程序中 用户点击一个按键，索要执行的一系列程序，封装为一个函数（多种按键有枚举等关系，或

CodingGuidance/TopLevelCodingGuidance.md

## 编码顶层指导

（引自 [Cpp-Learning/编程经验-规范, 调试、性能和内存检查工具集合.md at main · Staok/Cpp-Learning](https://github.com/Staok/Cpp-Learning/blob/main/编程经验-规范%2C 调试、性能和内存检查工具集合.md)）

- **层次化，即分清晰的多层**。程序结构分为多个层次，文件夹也按照如此划分，不同模块处于不同功能层。具体问题具体分析。
- **高内聚、低耦合。不宜常修改，应易扩展**。

  写东西时候先多思考架构。不必一上来就写 等 情况的出现，减少后面 debug 和 重构的时间。

  - 各部分选择合适的最佳实践和设计模式。
  - 多看一些 **最佳实践的文章和软件工程** 来对自己进行提高。
  - **设计模式**相关综合 [Staok/C-Cpp-design-patterns](https://github.com/Staok/C-Cpp-design-patterns)，具体参考其里面的 `DesignPattern` 文件夹下的文档和代码例子。检查 `CppCodingGuidance/DesignPattern` 若存在则直接用。

  模块化。模块独立，各端分离，接口分明。每个模块可独立的、动态的、运行时的创建、启、停和释放，程序由多个模块搭建、协作来构成。

  多写可复用代码。代码具有良好的实用性、通用性，以及安全性（风险规避）。

  易于扩展和维护。
- **参数化**。

  几个维度：

  - 对于模块的编写维度：考虑可通过修改参数来增强模块的适用范围和灵活性。模块编写考虑高复用性和多用性。敏锐的发现和合并公共的处理逻辑为一个通用的中间层，靠传入不同参数进行处理。
  - 对于设备管理维度：数据驱动法，就像 Linux 中的 设备树 作为可方便修改的数据表格，可以冷更新或者热更新到系统、程序中去并生效，不必有改动的时候每次都改代码并重新编译打包和部署。可用 json 等格式 写入 外部配置文件，程序读取并应用。
  - 对于软件整体运行层面：会有很多 settings，用户的或者系统内部的。可用 json 等格式 作为 设置存储文件，程序读写用。
  - 对于不同机型或者运行工况，需要不同套参数，将其 表格化，数据驱动，初始化时候按照机型选取对应的一套参数装填并使用。
- **可读性**。

  注释：基本要求：英文 Doxygen 注释格式，头文件写几个用例（帮助快速熟悉使用），可直接生成 API 文档的水准。
- 代码格式，以具有良好的可读性为好。整个工程整齐划一，**风格和编程模式具有连贯性**。

  参考 具体的另外提供的 细节写法格式和规范。

  （可选，默认不必用）每个项目有统一的 .clang_format 文件，时常 format 下。
- （按需）**跨平台化**。

  考虑软件的通用性和可移植性，考虑应用层的硬件无关性、跨平台性 / 跨操作系统性（主要是 Win 和 Linux），屏蔽日后换平台的工作量和痛苦。

  除非特殊要求，否则不假定编写的代码用于特定场景（比如只用于 ROS2 环境 等），要按照实用、通用的准则去写。

  三方库：尽量选用 Win 和 Linux 都兼容的，流行的、社区活跃的。
- **依赖合理**。

  按照当前需求和未来规划，合理分配哪些选择使用三方库，哪些选择自己实现。对于当前和未来需求而且功能复杂的，选择三方库（合理选择依赖的三方库，能覆盖需求，功能较丰富，尽量选择支持 Win 和 Linux 跨平台的，拒绝多用、滥用），对于代码量小的可以合理的自己实现。

  对于 C/C++ 工程，为了不复杂化部署：均使用 cmake，依赖的三方库下载并放到工程目录的 third_party 文件夹里面 来直接通过 cmake 引入来使用。对于 C 除非指定版本 否则至少 C99。对于 C++ 除非约束版本 否则至少 C++17。

  对于 Python，在工程目录建立 venv 虚拟环境来做，如果依赖特别多而且库有比较大的，则先询问用户是否还要使用 venv 虚拟环境 还是直接全局安装三方库。
- **高性能**。

  选择运行高效的、高性能的实现方式。若项目是刚开始搭建，而且高性能方案有一定难度，则可以先记录文档，先按照容易实现的（同时也有一定高性能保证的）方案来做，后面有需要则再优化性能。

  具体内部的算法实现应降低圈复杂度、降低时间复杂度，但如果代价是显著增加空间复杂度则也不必，做好权衡。代码保持简洁易读。

  也要注意避免头文件的过多嵌套导致编译时长显著增加。
- **健壮性，稳定运行**。

  风险点提前规避和检查，参考后面 `良好实践经验 / 易错注意 / 开发套路 / 惯例写法` 一节。
- **可测试性**、**易于测试**。

  保持程序的能控能观性。程序受外部控制接口统一且清晰，程序状态和对外影响、产物等明确。方便测试。

  代码必须通过测试。具体测试要求参考另外提供的。

  编码中尽量去掉 编译 warning。

  Evidence over claims — 验证之后（代码审查、修复、测试 都通过）再声称完成。

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.