two-axis-review
Skill0 starsChanged 2 months agoMITView on GitHub
Review the changes since a fixed point along two axes — Standards (repo coding standards + Fowler smell baseline) and Spec (does the code match the originating issue's AC?). Runs both as parallel sub-agents. Use when reviewing a branch, PR, or work-in-progress.
4 other projects use a version of this.
Adopted by
Most recently taken up by
- Tashila-109/tstack-skillstheir own version, first seen Nov 1, 2026
- lightarktech/founder-coding-skillstheir own version, first seen Jul 26, 2026
- andrewthetechie/andrew-skillstheir own version, first seen Jul 20, 2026
- dekoza/oh-my-sloptheir own version, first seen Mar 19, 2026
Other versions4 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 4
- andrewthetechie/andrew-skills★ 6same name
- dekoza/oh-my-slop★ 4same name
- lightarktech/founder-coding-skills★ 1same name
- Tashila-109/tstack-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- codebase-designSkill
- domain-modelingSkill
- grillingSkill
- grill-with-docsSkill
- implementSkill
- initSkill
- planSkill
- retroSkill
- shipSkill
- specSkill
- sprint-reviewSkill
- tddSkill
- ticket-checkSkill
The file
Files
Two-axis review
Review the diff between HEAD and a fixed point along two axes, in parallel sub-agents
so they don't pollute each other's context:
- Standards — does the code conform to this repo's documented coding standards?
- Spec — does the code faithfully implement the originating issue / spec?
先讀 docs/agents/sdlc.md——issue 可能在別的 repo,gh 指令要帶 --repo。
Process
1. Pin the fixed point
使用者給的固定點(commit、branch、tag、main、HEAD~5⋯)。沒給就問。
Diff 用三點式:git diff <fixed-point>...HEAD;commit 清單:git log <fixed-point>..HEAD --oneline。
先確認 git rev-parse <fixed-point> 解析得到且 diff 非空——壞 ref 要死在這裡,
不是死在兩個平行 subagent 裡。
2. Identify the spec source
依序找:commit 訊息裡的 issue 引用(用 gh issue view 取;優先找 task 所屬的
story,story 的 body 才有完整 AC)→ 使用者給的路徑 → docs/、specs/ 下
對得上的檔案 → 都沒有就問;確定沒有 spec 則 Spec 軸跳過並在報告註明。
3. Identify the standards sources
repo 裡任何記載程式該怎麼寫的文件(CLAUDE.md、CODING_STANDARDS、CONTRIBUTING、 design 規範)。在其之上永遠帶著 smell baseline(Fowler,Refactoring ch.3):
Mysterious Name/Duplicated Code/Feature Envy/Data Clumps/Primitive Obsession/ Repeated Switches/Shotgun Surgery/Divergent Change/Speculative Generality/ Message Chains/Middle Man/Refused Bequest
兩條約束:repo 文件優先(文件背書的寫法就壓下 baseline 的指控); baseline 永遠是 judgement call,不是硬違規。工具已強制的事一律跳過。
4. Spawn both sub-agents in parallel
一則訊息、兩個 general-purpose Agent 呼叫。
- Standards agent:給 diff 指令+commit 清單+標準文件清單+整份 smell baseline (它沒有其他管道拿到)。要求:逐檔回報 (a) 違反文件標準之處(引用文件與條文)、 (b) baseline smell(點名並引用 hunk),並區分硬違規與 judgement call。400 字內。
- Spec agent:給 diff 指令+commit 清單+spec 內容。要求:(a) spec 要求但缺漏 或不完整的、(b) spec 沒要求卻做了的(範圍膨脹)、(c) 看似做了但實作可疑的。 每條引用 spec 原文。400 字內。
5. Aggregate
## Standards、## Spec 兩節並列呈現,不合併、不重排——
兩軸刻意分開(守標準但做錯事 vs 做對事但破慣例,互相遮不住)。
結尾一行:各軸發現數與各軸內最嚴重的一條。不選跨軸贏家。
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

