cm-debugging

Name: cm-debugging
Author: tody-agent

47stars23forks

How to install cm-debugging?

tody-agent/codymaster/cm-debugging

$npx -y skills add tody-agent/codymaster --skill cm-debugging

Installs into the current project.

Summary

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Files · 1

View on GitHub

SKILL.md

1	# Systematic Debugging
2
3	## TL;DR
4	- Use when any bug, test failure, or unexpected behavior surfaces
5	- Process: reproduce → isolate → diagnose root cause → fix
6	- Defense in depth: also add a test that locks the bug
7	- Next: cm-tdd → cm-quality-gate
8
9	## Overview
10
11	Random fixes waste time and create new bugs. Quick patches mask underlying issues.
12
13	Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
14
15	Violating the letter of this process is violating the spirit of debugging.
16
17	## The Iron Law
18
19	```
20	NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
21	```
22
23	If you haven't completed Phase 1, you cannot propose fixes.
24
25	## When to Use
26
27	Use for ANY technical issue:
28	- Test failures
29	- Bugs in production
30	- Unexpected behavior
31	- Performance problems
32	- Build failures
33	- Integration issues
34
35	Use this ESPECIALLY when:
36	- Under time pressure (emergencies make guessing tempting)
37	- "Just one quick fix" seems obvious
38	- You've already tried multiple fixes
39	- Previous fix didn't work
40	- You don't fully understand the issue
41
42	Don't skip when:
43	- Issue seems simple (simple bugs have root causes too)
44	- You're in a hurry (rushing guarantees rework)
45	- Manager wants it fixed NOW (systematic is faster than thrashing)
46
47	## The Four Phases
48
49	You MUST complete each phase before proceeding to the next.
50
51	### Phase 0.5: Memory Integrity Check (BEFORE blaming code)
52
53	> BEFORE blaming code, ASK: "Could memory be causing this bug?"
54
55	1. SUSPECT — Identify relevant memories:
56	- What module/file is the bug in?
57	- Read `.cm/learnings.json` filtered by that scope
58	- List all active learnings + decisions for this area
59
60	2. INVESTIGATE — Did AI follow a memory when writing buggy code?
61	- Check: Does the buggy code match a `prevention` pattern from any learning?
62	- Check: Does the buggy code follow a `decision` that may be outdated?
63	- If YES → that memory is a suspect
64
65	3. VERIFY — Is the suspect memory still correct?
66	- Compare learning with current codebase (not when it was recorded)
67	- Has the dependency/pattern/architecture changed since learning was recorded?
68	- If memory is WRONG → proceed to HEAL
69
70	4. HEAL (only if memory confirmed as cause):
71	- Invalidate: Set `status = "invalidated"` — learning is proven wrong
72	- Correct: Update `prevention` with correct info, set `status = "corrected"`
73	- Scope-reduce: Learning is right for smaller scope → narrow the scope
74	- Record meta-learning in `.cm/meta-learnings.json`
75
76	```
77	IF memory caused the bug:
78	→ HEAL memory FIRST
79	→ THEN proceed to Phase 1 to fix code
80	→ The code fix will be correct because memory is now correct
81
82	IF memory did NOT cause the bug:
83	→ Proceed to Phase 1 normally
84	```
85
86	> WHY PHASE 0.5? Fix memory first → code fix will be correct.
87	> Without fixing memory → bug will return next session (bug loop).
88
89	### Phase 1: Root Cause Investigation
90
91	BEFORE attempting ANY fix:
92
93	1. Read Error Messages Carefully
94	- Don't skip past errors or warnings
95	- They often contain the exact solution
96	- Read stack traces completely
97	- Note line numbers, file paths, error codes
98
99	2. Reproduce Consistently
100	- Can you trigger it reliably?
101	- What are the exact steps?
102	- Does it happen every time?
103	- If not reproducible → gather more data, don't guess
104
105	3. Check Recent Changes
106	- What changed that could cause this?
107	- Git diff, recent commits
108	- New dependencies, config changes
109	- Environmental differences
110
111	4. Gather Evidence in Multi-Component Systems
112
113	WHEN system has multiple components (CI → build → signing, API → service → database):
114
115	BEFORE proposing fixes, add diagnostic instrumentation:
116	```
117	For EACH component boundary:
118	- Log what data enters component
119	- Log what data exits component
120	- Verify environment/config propagation
121	- Check state at each layer
122
123	Run once to gather evidence showing WHERE it breaks
124	THEN analyze evidence to identify failing component
125	THEN investigate that specific component
126	```
127
128	5. Trace Data Flow
129
130	WHEN error is deep in call stack:
131
132	- Where does bad value originate?
133	- What called this with bad value?
134	- Keep tracing up until you find the source
135	- Fix at source, not at symptom
136
137	### Phase 2: Pattern Analysis
138
139	Find the pattern before fixing:
140
141	1. Find Working Examples
142	- Locate similar working code in same codebase
143	- What works that's similar to what's broken?
144
145	2. Compare Against References
146	- If implementing pattern, read reference implementation COMPLETELY
147	- Don't skim - read every line
148	- Understand the pattern fully before applying
149
150	3. Identify Differences
151	- What's different between working and broken?
152	- List every difference, however small

People who liked this also viewed

6 picks

Type

lark-drive飞书云空间（云盘/云存储）：管理 Drive 文件和文件夹，包含上传/下载、创建文件夹、复制/移动/删除、查看元数据、评论/权限/订阅、标题、版本、飞书文档密级标签（secure labels）和本地文件导入。用户需要整理云盘目录、处理云空间资源 URL/token、判断链接类型/真实 token/标题，或导入 Word/Markdown/Excel/CSV/PPTX/.base 为 docx/sSkillsJul 2026382k16k
lark-sharedUse for lark-cli setup/auth tasks: auth login/status/logout, user vs bot identity, business-domain permissions (--domain, including all/docs/drive), missing scopes, revoking authorization, or handlingSkillsJul 2026382k16k
lark-whiteboard飞书画板：查询和编辑飞书云文档中的画板。支持导出画板为预览图片、导出原始节点结构、使用多种格式更新画板内容。当用户需要查看画板内容、导出画板图片、编辑画板时使用此 skill。不负责：飞书云文档内容编辑（lark-doc）、文档内嵌电子表格/Base（lark-sheets / lark-base）。SkillsJul 2026380k16k
lark-task飞书任务：管理任务、清单和任务智能体。创建待办任务、查看和更新任务状态、拆分子任务、组织任务清单、分配协作成员、上传任务附件、注册或注销任务智能体、更新任务智能体的主页数据、写入智能体任务记录。当用户需要创建待办事项、查看任务列表、跟踪任务进度、管理项目清单或给他人分配任务、为任务上传附件文件、注册注销任务智能体、更新智能体主页数据、写入任务记录时使用。SkillsJul 2026380k16k
lark-attendance飞书考勤打卡：查询自己的考勤打卡记录SkillsJul 2026330k16k
lark-apps妙搭（Spark/Miaoda）应用开发与托管：应用创建、本地全栈开发、云端生成迭代、创意设计（UI mockup / 可交互原型 / 线框图 / 落地页 / 仪表盘 / 幻灯片 deck / 视觉探索）、AI相关能力和飞书平台能力或者其他外部能力集成、日志/Trace/监控指标/PV/UV 查询、环境变量管理、应用角色与成员管理、自动化触发器（定时/记录变更/Webhook/飞书审批）。当用户要SkillsJul 2026227k16k

cm-debugging

47stars23forks

View on GitHub

How to install cm-debugging?

tody-agent/codymaster/cm-debugging

$npx -y skills add tody-agent/codymaster --skill cm-debugging

Installs into the current project.

Summary

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Files · 1

View on GitHub

SKILL.md

1	# Systematic Debugging
2
3	## TL;DR
4	- Use when any bug, test failure, or unexpected behavior surfaces
5	- Process: reproduce → isolate → diagnose root cause → fix
6	- Defense in depth: also add a test that locks the bug
7	- Next: cm-tdd → cm-quality-gate
8
9	## Overview
10
11	Random fixes waste time and create new bugs. Quick patches mask underlying issues.
12
13	Core principle: ALWAYS find root cause before attempting fixes. Symptom fixes are failure.
14
15	Violating the letter of this process is violating the spirit of debugging.
16
17	## The Iron Law
18
19	```
20	NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
21	```
22
23	If you haven't completed Phase 1, you cannot propose fixes.
24
25	## When to Use
26
27	Use for ANY technical issue:
28	- Test failures
29	- Bugs in production
30	- Unexpected behavior
31	- Performance problems
32	- Build failures
33	- Integration issues
34
35	Use this ESPECIALLY when:
36	- Under time pressure (emergencies make guessing tempting)
37	- "Just one quick fix" seems obvious
38	- You've already tried multiple fixes
39	- Previous fix didn't work
40	- You don't fully understand the issue
41
42	Don't skip when:
43	- Issue seems simple (simple bugs have root causes too)
44	- You're in a hurry (rushing guarantees rework)
45	- Manager wants it fixed NOW (systematic is faster than thrashing)
46
47	## The Four Phases
48
49	You MUST complete each phase before proceeding to the next.
50
51	### Phase 0.5: Memory Integrity Check (BEFORE blaming code)
52
53	> BEFORE blaming code, ASK: "Could memory be causing this bug?"
54
55	1. SUSPECT — Identify relevant memories:
56	- What module/file is the bug in?
57	- Read `.cm/learnings.json` filtered by that scope
58	- List all active learnings + decisions for this area
59
60	2. INVESTIGATE — Did AI follow a memory when writing buggy code?
61	- Check: Does the buggy code match a `prevention` pattern from any learning?
62	- Check: Does the buggy code follow a `decision` that may be outdated?
63	- If YES → that memory is a suspect
64
65	3. VERIFY — Is the suspect memory still correct?
66	- Compare learning with current codebase (not when it was recorded)
67	- Has the dependency/pattern/architecture changed since learning was recorded?
68	- If memory is WRONG → proceed to HEAL
69
70	4. HEAL (only if memory confirmed as cause):
71	- Invalidate: Set `status = "invalidated"` — learning is proven wrong
72	- Correct: Update `prevention` with correct info, set `status = "corrected"`
73	- Scope-reduce: Learning is right for smaller scope → narrow the scope
74	- Record meta-learning in `.cm/meta-learnings.json`
75
76	```
77	IF memory caused the bug:
78	→ HEAL memory FIRST
79	→ THEN proceed to Phase 1 to fix code
80	→ The code fix will be correct because memory is now correct
81
82	IF memory did NOT cause the bug:
83	→ Proceed to Phase 1 normally
84	```
85
86	> WHY PHASE 0.5? Fix memory first → code fix will be correct.
87	> Without fixing memory → bug will return next session (bug loop).
88
89	### Phase 1: Root Cause Investigation
90
91	BEFORE attempting ANY fix:
92
93	1. Read Error Messages Carefully
94	- Don't skip past errors or warnings
95	- They often contain the exact solution
96	- Read stack traces completely
97	- Note line numbers, file paths, error codes
98
99	2. Reproduce Consistently
100	- Can you trigger it reliably?
101	- What are the exact steps?
102	- Does it happen every time?
103	- If not reproducible → gather more data, don't guess
104
105	3. Check Recent Changes
106	- What changed that could cause this?
107	- Git diff, recent commits
108	- New dependencies, config changes
109	- Environmental differences
110
111	4. Gather Evidence in Multi-Component Systems
112
113	WHEN system has multiple components (CI → build → signing, API → service → database):
114
115	BEFORE proposing fixes, add diagnostic instrumentation:
116	```
117	For EACH component boundary:
118	- Log what data enters component
119	- Log what data exits component
120	- Verify environment/config propagation
121	- Check state at each layer
122
123	Run once to gather evidence showing WHERE it breaks
124	THEN analyze evidence to identify failing component
125	THEN investigate that specific component
126	```
127
128	5. Trace Data Flow
129
130	WHEN error is deep in call stack:
131
132	- Where does bad value originate?
133	- What called this with bad value?
134	- Keep tracing up until you find the source
135	- Fix at source, not at symptom
136
137	### Phase 2: Pattern Analysis
138
139	Find the pattern before fixing:
140
141	1. Find Working Examples
142	- Locate similar working code in same codebase
143	- What works that's similar to what's broken?
144
145	2. Compare Against References
146	- If implementing pattern, read reference implementation COMPLETELY
147	- Don't skim - read every line
148	- Understand the pattern fully before applying
149
150	3. Identify Differences
151	- What's different between working and broken?
152	- List every difference, however small

People who liked this also viewed

6 picks

Type