Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add KtKID/x-dev-pipeline --skill x-tech-designgit clone --depth 1 https://github.com/KtKID/x-dev-pipelineWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ktkid/x-dev-pipeline/x-tech-design)<a href="https://agentmods.dev/skills/ktkid/x-dev-pipeline/x-tech-design"><img src="https://agentmods.dev/badge/skills/ktkid/x-dev-pipeline/x-tech-design/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/ktkid/x-dev-pipeline/x-tech-design"><img src="https://agentmods.dev/badge/skills/ktkid/x-dev-pipeline/x-tech-design.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00127 | $0.03352 |
| Opus 5.5 | $0.00051 | $0.01341 |
| Sonnet 5.5 | $0.00025 | $0.00670 |
| Haiku 4.5 | $0.00013 | $0.00335 |
Grade A, and why
x-tech-design scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 13d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 110 lines — stays where its author put it; the contents beside it link to each section on GitHub.
x-tech-design
把已确认的功能需求转成可供用户审查、后续任务拆解引用的技术设计。功能行为以 spec.md 为唯一事实源，技术决策与编号测试用例的主定义以独立的 tech-design.md 维护；关键约束正文留在 spec，后续任务和报告只回指约束/用例 ID。
输入与产物
| 输入 | 要求 |
|---|---|
| 项目根目录 | 可访问的明确路径；代码、规范和设计中的仓库路径相对此目录 |
| spec 路径 | 已落盘的功能 spec；通常为 docs/spec/<spec-name>/spec.md |
| spec 确认状态 | 用户确认的结论、来源及对应版本/内容基线；文件存在或父 agent 说“写完了”不等于用户已确认 |
| 约束 | 用户明确的范围、技术限制、开发规范及尚未解决的问题；没有额外约束也要注明 |
| 现有设计 | 相关架构/协议/数据归属文档路径及确认状态；若无，注明并从代码调查现状 |
产物固定为输入 spec 的同目录 tech-design.md，通常是 docs/spec/<spec-name>/tech-design.md。记录 spec 路径、版本/内容基线、确认依据、设计状态与本轮范围。默认状态为 待用户确认，不能把完成编写、通过自检或父 agent 接收当作批准。
若 tech-design.md 已存在，先读取其内容、状态和用户已有修改，基于原文做本轮设计差异；保留无关内容，不盲目覆盖已确认决策或其他人的编辑。项目采用不同 spec 路径时仍取该输入文件的父目录，不另建平行功能文档。
工作流
1. 核对输入与功能边界
完整读取 spec，核对确认依据是否覆盖当前落盘内容与范围。缺少项目根目录、spec 文件、确认依据或必要约束，以及 spec 仍待确认时，停止设计编写，报告缺项和阻塞原因；不要假定继承父会话，不编造用户批准。
读取项目适用的 AGENTS.md、相关 .agents/skills 和开发规范。设计前读取 开发规范，结合项目已有规范逐条判定适用性；引用已有权威规范，不复制维护多份。冲突会影响设计时列出来源与影响，返回澄清。
场景用 featNN 场景M 回指（如 feat02 场景3），已有 Scenario ID 时沿用；关键约束用 spec 的 C 编号回指，不复制概述或 GIVEN/WHEN/THEN。发现功能行为、边界或数据含义存在歧义，向用户/委派方报告具体回指、分歧和影响，交回需求澄清；不得用技术假设补完产品行为。可继续调查不受影响的现状，受影响设计标为阻塞，不能宣称整体可交接。
C、D、用例 T 是新条目的编号示例，各自在约束、设计、用例范围内唯一；已有约束/用例 ID 或章节定位沿用，不为了本流程重命名。旧 spec 没有 C 章节时从已确认场景和现有约束提取依据，不新造用户决定；新增约束先交 x-spec 确认。
2. 调查现有架构
围绕 spec 范围读取现有目录、模块公开入口、依赖、协议/schema、数据读写、配置与测试。区分“代码当前如此”“用户已确认”“本轮建议”，为现状和复用结论给出可定位的文件/符号证据，不把建议写成既成事实。
优先复用现有模块、技术栈与权威协议。新增模块、引入技术或替换现有方案时，说明现有方案为何不足，以及依赖、调用方、数据迁移、兼容性与维护成本的影响；只写本需求涉及的影响，不借机重构全仓。
3. 编写技术设计
读取 精简模板 并按影响范围填写。为可引用的设计条目分配稳定编号 D01、D02 等；保留已有编号，场景、设计和后续任务可据此追踪。覆盖下表，内容可以合并但不能漏掉适用项。
| 设计内容 | 必须说明 |
|---|---|
| feat 与场景映射 | 本轮范围内每个 feat 回指准确场景标识，映射设计编号、参与模块、协议/结构、流程和验证方式；不需新设计的说明沿用来源。普通场景共用主设计，失败、并发、重试等特殊场景按实际需要补设计 |
| 关键约束与测试 | 引用本轮适用的已确认 C 编号，说明对应 D 机制，并展开稳定编号测试用例；一个约束可对应多个用例，不能用正常流程测试代替禁止结果验证 |
| 模块与依赖 | 职责、具体目录、公开接口、调用方和单向依赖；跨模块只通过公开边界访问，检查循环与越界访问 |
| 数据与协议 | 核心结构、关键字段的含义/约束（按需含可空性、单位、标识、关系和不变量）；数据所有者、运行时值的权威存储、协议/schema 的权威来源与使用方；派生值及缓存/索引/快照的策略 |
| 主要功能数据流 | 回指相关场景，写清入口 → 边界校验 → 处理模块 → 状态变化/持久化 → 返回；按实际需要补充异步、幂等、并发、失败恢复，或说明不适用理由 |
| 关键决策 | 推荐方案、理由、备选与代价、影响范围、待用户确认项；区分关键架构/协议/数据归属与普通实现细节 |
| 规范与验证 | 所有规范的适用性、对应设计条目、落实位置和验证方式/证据；代码可检查的采用静态检查或测试，其余提供可定位的审查证据 |
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 13d ago First seen · 110 lines · 127 tokens per session scan A f9e90a686ba6
x-tech-design is a skill published in the GitHub repository KtKID/x-dev-pipeline (12 stars, last pushed 13d ago), licensed MIT. It adds 127 tokens to every session and 3,352 once invoked, about $0.0005 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-10-13.
Other skills, from other repositories
backlog
Seed a backlog from the project's documents: the Product Owner reads docs/ (plus the constitution and ROADMAP.md), proposes an ordered list of feature-sized items each traced to a source section, the user edits the list, and on explicit confirmation each item is filed as a GitHub issue that /story-time can import. Use…
plan-to-tasks
Transform a plancreation planv{N}.md into a structured tasks.yaml + per-WP workpackages/.yaml using parallel Sonnet sub-agents. Use after plan-creation finishes when you need execution-friendly task structure.
auto-build-loop
Autonomous build driver after SDD spec approval: phase-scoped headless build sessions, driver-owned commits, cross-provider review gates, milestone pauses, and fail-closed escalation — under explicit opt-in autonomy profiles.
pocket-closing
Close a reviewed Pocket phase or plan when the user explicitly requests closeout, including as part of an end-to-end request. Reconcile verdicts with log.json, advance only a passing phase, append a readable per-phase closeout, and finalize the plan when all phases are done. A passing verdict alone does not authorize…
engagement-scoping
Resolve the documentation engagement scope from the settings cascade — project identity, source roots, output root, delivery mode, action ceiling, confidentiality default, and the exact file set this run may touch — and freeze it to /00-control/.scope.json. Use when any /dossier: command starts, when the delivery mode…
finding-reconciliation
Merge the independent A/B/C findings tables into one adjudicated ledger in 07-verification/documentation-verification-report.md — normalizing to the finding schema, deduplicating by location and claim, recording per-finding corroboration without downgrading single-pass findings, promoting cross-pass disagreement to…