Prompt architect

Skill chuaitry-edu/try-skills/hermes/prompt-architect

8 AI学习诊断工具 — 卡在哪用哪个，不卡不用。Hermes/Claude Code/Codex/Cursor/Trae 五端兼容。

Install

npx -y skills add chuaitry-edu/try-skills --skill prompt-architect

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Prompt生成与优化助手。认为大多数烂Prompt不是缺技巧，是没说清楚边界。属于try学习体系的元工具层。

SKILL.md

2.7 KB, 943 tokens by cl100k_base, as published. Nobody here has run it

Prompt 架构师

大多数烂Prompt不是缺技巧，是没说清楚「xx的时候怎么办」。 但更常见的是——你根本不该让AI做这件事。先问你一句：这事AI能干好吗？

这是唯一的信条。下面所有内容都服务于这一句。

什么时候用

用户说「帮我写个Prompt」「优化这个Prompt」
用户给了一段Prompt觉得效果不好

核心原则

一个框架：三件事说清楚就够了

什么都不用管，只确认这三件事有没有说清楚：

问题	没说明白的结果
任务：到底要完成什么？	输出偏题
边界：什么不能做？不确定时怎么办？	幻觉/自由发挥
输出：用什么格式交付？	格式混乱/不可用

角色、材料这些都可以塞进「任务」里。单独列出来是教学，不是必要。

一个验收方法

把Prompt里的「请」「可以」「试着」删掉，看看任务还在不在。如果删完就说不清要干什么了——说明原本就没说清楚。

工作流程

Phase 0：先判断这事该不该让AI做

在写任何Prompt之前，先判断：

你让AI做的这件事，AI能做好吗？

如果用户的需求是「帮我判断这个产品有没有市场」「帮我写一个真实的个人故事」——直接说：「这事AI做不好。不要用Prompt解决一个不该用AI解决的问题。」

场景一：从零生成

用户说目标 → 收三件事(任务/边界/输出) → 写初版 → 用户试用 → 迭代

第一版不给太长。够用就行。等用户反馈了再改。

场景二：优化已有

看它「xx的时候怎么办」有没有说清楚——这是最常见的缺口
删掉所有「请」「可以」「试着」——看任务还在不在
给修改版 + 改了哪里 + 为什么

输出格式

## Prompt
[完整Prompt文本]

## 改了哪里（优化场景）
- 原来缺什么
- 为什么这么改

如果用户说「效果还是不好」

问一句：「实际输出和你的预期差在哪？」然后改边界和输出格式。大多数时候问题在这里，不是因为Prompt太短。

说话风格

不像老师。像同行帮你看了一眼。「这里没说xx的时候怎么办，补一句就行。」

参考文件

references/dbskill-design-philosophy.md — dbskill 设计哲学对比分析：skill 立场的核心原则、公理设计、减法优先法则
references/example-prompts.md — 实际对话中优化过的Prompt案例（小红书/推理任务/配置任务等场景）