Karissaself
88 posts
Karissaself
@karissasel_
在这个死亡率 100% 的时代，没什么可怕的。 And miles to go before I sleep.
Katılım Aralık 2025
234 Takip Edilen14 Takipçiler
/check 是我最近用的最多的 skill
有时候写接口自己没把握的 经常一个 commit 一个 /check 效果确实比一般的 review 好很多
/check 他不会告诉我一些鸡毛蒜皮的 warning
Tw93@HiTw93
Continuing the series on how I design skills in Waza, this one is about how I built /check, the code review skill. The starting point is simple. A model saying “it’s done” does not mean it is actually done. It can still leave behind broken logic, non-existent pieces, hidden regressions, or unresolved risks. In my experience building agents, giving the model a concrete checklist to verify completion works far better than simply asking it to “double check.” So /check was never designed as one giant all-in-one reviewer. It is a review orchestration system with clear division of responsibility. The main SKILL.md acts as the lead reviewer, handling review levels and process control. Under agents/, there are independent specialists such as a security reviewer and an architecture reviewer, each focused on its own domain. Which specialist gets involved is decided by an activation rule set, not the keyword matching approach many people use. The review tiers are also intentional. For changes under 100 lines, it runs a fast review. For changes between 100 and 500 lines, it brings in specialists when needed. For changes above 500 lines, it activates the full review path and adds an adversarial testing round. That round looks for failure modes from four angles: broken assumptions, problems that appear only under combined failures, errors in cross-layer integration, and abuse or misuse scenarios. Findings are then handled in four levels. Safe and obvious fixes can be applied directly. Issues that are mostly clear but still worth confirming are packaged for you to review. Cases that require judgment are escalated to you. Lower-priority observations are still surfaced, but /check does not interrupt you for every minor issue, and it does not overstep into changing behavioral logic on its own. There is also one hard rule: if verification has not run, the task is not complete. /check includes a probing script that detects project types such as Cargo, TypeScript, and Python, then runs the appropriate validation flow. If it cannot detect the project type, it fails explicitly instead of pretending everything passed. The result is something closer to an experienced technical reviewer: different strategies for different change sizes, explicit specialist involvement, and a stronger definition of what “done” actually means. I just tried to distill those engineering habits into a simple and reusable skill inside Waza. And if you have better ideas for code review workflows, I’d love contributions to Waza. PRs are welcome. github.com/tw93/waza
中文
我感觉现在的工作就是在明确需求
用清晰的语言描述你的需求
用当前领域最好的 SOTA AI Agent 来完成需求
一般能一遍过
可以并行多个任务
我基本上都是这么做
中文
其实我感觉我对象挺好的 就是很多时候都在抱怨 一到不顺心了就开始对我抱怨
我也很烦啊 我工作这么多 还要处理她的事情
感觉她独立处理事情的能力几乎为零
我对象有烦恼时 belike：“私聊呼唤免费 智能 Agent”
中文
还有我昨天来南京陪我女朋友搬家，女朋友来南京实习，今天租房真想感叹一下“南京房子真便宜啊😭”
Karissaself@karissasel_
来上海实习一转眼就两周了，慢慢开始会上手一些工作，工作没有想象中的那么压力大（也许我是实习生） 但是不断的从学校里面淅淅沥沥的消息变成一种隐形的压力压在我身上，我不自觉的害怕未来可能有的风险（代课被抓，各种测验考试要飞回去学校考试其中的心力和金钱成本）不知道我付出的是否值得
中文
来上海实习一转眼就两周了，慢慢开始会上手一些工作，工作没有想象中的那么压力大（也许我是实习生）
但是不断的从学校里面淅淅沥沥的消息变成一种隐形的压力压在我身上，我不自觉的害怕未来可能有的风险（代课被抓，各种测验考试要飞回去学校考试其中的心力和金钱成本）不知道我付出的是否值得
中文
Karissaself retweetledi
但是我用了两天 OMX 感觉这个插件确实很有想法 但是 ralplan 的时候定下 plan 却不给我看😡 我一气之下给他删了
lifcc@mylifcc
Codex 很强大，但它很笨经常问问问问问。 oh-my-codex正好可以解决这个问题，我一个prompt已经跑了5个小时了。 $deep-interview 澄清需求 → $ralplan 拍板计划 → $team / $ralph 并行执行。 从此，Codex 也有了自己的工作流和团队大脑。
中文