JSai23
JSai23/claude-tooling
相关职业SOC
基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/JSai23/claude-tooling --skill verify-design-a命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Write high-quality session prompts (SESSION_WORKER.md and SESSION_REVIEWER.md) for an agent loop. Reads repo context and follows the loop-author guide to produce targeted, effective prompts. Use when setting up a new loop or rewriting session prompts for an existing one.
Pre-flight checks and launch for agent loops. Validates branch state, session prompts, creates loop directory structure, and launches run.sh in a tmux session. Use when the user wants to start a new agent loop in the current repo.
Cross-repo visibility for agent loops. Lists running, completed, and crashed loops. Reads the registry and per-repo tracking logs. Shows tmux attach commands. Use when checking what loops are active, what ran recently, or loop details.
正在显示 SKILL.md
基于 SOC 职业分类
| name | verify-design-a |
| type | action |
| description | Architecture review in hindsight — what to question, dependency analysis, abstraction assessment |
| user-invocable | false |
Action skill — Architecture review procedures: dependency analysis, abstraction assessment, output format.
Evaluating code architecture in hindsight — now that it's built, does the structure make sense?
Type and class design — Why does this class exist? Would functions suffice? Should these be separate types or one? Is inheritance justified?
Module structure — Why is this code in this package? Should modules be split or merged? Are boundaries in the right places? Does directory structure reflect architecture?
Dependencies — Why does A depend on B? Could it be inverted? Hidden coupling through shared state? Circular dependencies? Dependencies pointing toward stability?
Abstractions — Earning their complexity? More than one implementation? Interface premature? Would concrete code be clearer?
Diagrams first. Show module dependencies, data flow, layer structure. Reference diagrams in every finding.
Format findings as:
Not naming/formatting (that's style). Not fake code (that's larp). Sound architecture is the goal, not findings.
## Concern: {title}
DIAGRAM: {ASCII dependency or data flow diagram}
OBSERVATION: What the current design does
QUESTION: Why is it this way? What's the tradeoff?
ALTERNATIVE: Different approach to consider
IMPACT: What would change if refactored
Refactor candidates as prioritized list with FROM/TO/TRADEOFF for each.