code-confidence-map

Name: code-confidence-map
Author: kanyun-inc

57stars3forks

How to install code-confidence-map?

kanyun-inc/reskill/code-confidence-map

$npx -y skills add kanyun-inc/reskill --skill code-confidence-map

Installs into the current project.

Summary

Assesses code comprehensibility and maintainability risk. Use when the user asks about code confidence, risk, maintainability, tech debt, code health, or whether code is safe to change. Also use when the user asks to analyze code quality, scan for risks, check if code is messy or

Files · 1

View on GitHub

SKILL.md

1	# Code Confidence Map
2
3	Helps AI agents answer a core question: "If this code breaks tomorrow, how well-equipped are we to understand and fix it?"
4
5	This is NOT a linter or code quality tool. It measures comprehensibility risk — the gap between code complexity and human understanding. The AI's unique advantage over static analysis tools is semantic judgment: it can tell that `processData` does 5 unrelated things, that tests only cover happy paths, or that `// don't touch this` is a red flag.
6
7	## When to Use This Skill
8
9	Use this skill when the user:
10
11	- Asks about code confidence, risk, or maintainability
12	- Says "is this code safe to change?" or "how risky is this module?"
13	- Is onboarding to a new codebase and wants to understand the landscape
14	- Wants to know where the tech debt or weak spots are
15	- Asks "which parts of the codebase are well-tested?"
16	- Says "scan this directory" or "check this file's health"
17	- Is planning a refactor and wants to assess risk first
18	- Asks about code quality, code health, or how solid a module is
19
20	## Core Concept: What "Confidence" Means
21
22	Confidence is the answer to: "If something goes wrong here, can we understand and fix it?"
23
24	It is NOT:
25	- A judgment on code quality (LOW confidence is a risk signal, not a verdict)
26	- A measure of cleverness or elegance
27	- An indicator of who wrote the code or when
28
29	Confidence levels:
30
31	\| Level \| Meaning \|
32	\| ---------- \| ----------------------------------------------------------------- \|
33	\| HIGH \| Well-tested, readable, good error handling — safe to work with \|
34	\| MEDIUM \| Partially covered — some gaps in tests, docs, or error handling \|
35	\| LOW \| Significant gaps — risky to modify without additional preparation \|
36
37	Do NOT use percentages (e.g., "73.2%"). They imply false precision for what is fundamentally a judgment call.
38
39	Overall level rule: The overall confidence level equals the lowest dimension level. If any single dimension is LOW, the overall is LOW — one critical gap is enough to make code risky to work with.
40
41	## What We Explicitly Do NOT Measure
42
43	- Time since last edit — Stable code is fine. Code that hasn't been touched in years may be the most reliable in the project.
44	- Lines of code as a standalone metric — More code does not mean worse code.
45	- Number of contributors — Team dynamics vary too much to draw conclusions.
46	- Whether code was AI-generated — Irrelevant. What matters is whether the code is understood, regardless of who or what wrote it.
47
48	## Confidence Dimensions
49
50	### Core Dimensions (4)
51
52	These are evaluated for every file in Phase 2 / Single File Mode:
53
54	#### 1. Test Safety Net
55
56	Are there tests? Do they test the right things?
57
58	- Read the test file(s) for the target module
59	- Check: do tests cover error paths and edge cases, or only happy paths?
60	- Check: are tests meaningful (not just `expect(true).toBe(true)`)?
61	- A file with no test file at all is an immediate risk signal
62
63	Why it matters: Tests are executable documentation of intent. If there are no tests, nobody has formally defined what this code is supposed to do.
64
65	#### 2. Self-Expressed Uncertainty
66
67	Does the code itself say "I'm not confident"?
68
69	Look for these markers (via grep or reading the file):
70
71	\| Marker \| What It Means \|
72	\| --------------------------- \| ------------------------------------ \|
73	\| `TODO` \| Acknowledged incomplete work \|
74	\| `FIXME` \| Known bug or issue \|
75	\| `HACK`, `WORKAROUND`, `XXX` \| Intentional shortcut or band-aid \|
76	\| `@ts-ignore` \| TypeScript safety bypassed \|
77	\| `eslint-disable` \| Linting rules intentionally bypassed \|
78	\| Empty `catch {}` blocks \| Errors silently swallowed \|
79
80	Why it matters: The code is literally telling you where the risk is.
81
82	#### 3. Comprehensibility
83
84	Can a newcomer understand this code?
85
86	This requires reading the code and making a semantic judgment:
87
88	- Naming quality: Are variables, functions, and classes named descriptively? Or are there names like `data`, `temp`, `x`, `processStuff`?
89	- Comment-to-complexity ratio: Complex logic (regex, algorithms, state machines) should have proportionally more comments. Simple code needs fewer.
90	- **Fun

People who liked this also viewed

6 picks

Type

code-confidence-map

57stars3forks

View on GitHub

How to install code-confidence-map?

kanyun-inc/reskill/code-confidence-map

$npx -y skills add kanyun-inc/reskill --skill code-confidence-map

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Code Confidence Map
2
3	Helps AI agents answer a core question: "If this code breaks tomorrow, how well-equipped are we to understand and fix it?"
4
5	This is NOT a linter or code quality tool. It measures comprehensibility risk — the gap between code complexity and human understanding. The AI's unique advantage over static analysis tools is semantic judgment: it can tell that `processData` does 5 unrelated things, that tests only cover happy paths, or that `// don't touch this` is a red flag.
6
7	## When to Use This Skill
8
9	Use this skill when the user:
10
11	- Asks about code confidence, risk, or maintainability
12	- Says "is this code safe to change?" or "how risky is this module?"
13	- Is onboarding to a new codebase and wants to understand the landscape
14	- Wants to know where the tech debt or weak spots are
15	- Asks "which parts of the codebase are well-tested?"
16	- Says "scan this directory" or "check this file's health"
17	- Is planning a refactor and wants to assess risk first
18	- Asks about code quality, code health, or how solid a module is
19
20	## Core Concept: What "Confidence" Means
21
22	Confidence is the answer to: "If something goes wrong here, can we understand and fix it?"
23
24	It is NOT:
25	- A judgment on code quality (LOW confidence is a risk signal, not a verdict)
26	- A measure of cleverness or elegance
27	- An indicator of who wrote the code or when
28
29	Confidence levels:
30
31	\| Level \| Meaning \|
32	\| ---------- \| ----------------------------------------------------------------- \|
33	\| HIGH \| Well-tested, readable, good error handling — safe to work with \|
34	\| MEDIUM \| Partially covered — some gaps in tests, docs, or error handling \|
35	\| LOW \| Significant gaps — risky to modify without additional preparation \|
36
37	Do NOT use percentages (e.g., "73.2%"). They imply false precision for what is fundamentally a judgment call.
38
39	Overall level rule: The overall confidence level equals the lowest dimension level. If any single dimension is LOW, the overall is LOW — one critical gap is enough to make code risky to work with.
40
41	## What We Explicitly Do NOT Measure
42
43	- Time since last edit — Stable code is fine. Code that hasn't been touched in years may be the most reliable in the project.
44	- Lines of code as a standalone metric — More code does not mean worse code.
45	- Number of contributors — Team dynamics vary too much to draw conclusions.
46	- Whether code was AI-generated — Irrelevant. What matters is whether the code is understood, regardless of who or what wrote it.
47
48	## Confidence Dimensions
49
50	### Core Dimensions (4)
51
52	These are evaluated for every file in Phase 2 / Single File Mode:
53
54	#### 1. Test Safety Net
55
56	Are there tests? Do they test the right things?
57
58	- Read the test file(s) for the target module
59	- Check: do tests cover error paths and edge cases, or only happy paths?
60	- Check: are tests meaningful (not just `expect(true).toBe(true)`)?
61	- A file with no test file at all is an immediate risk signal
62
63	Why it matters: Tests are executable documentation of intent. If there are no tests, nobody has formally defined what this code is supposed to do.
64
65	#### 2. Self-Expressed Uncertainty
66
67	Does the code itself say "I'm not confident"?
68
69	Look for these markers (via grep or reading the file):
70
71	\| Marker \| What It Means \|
72	\| --------------------------- \| ------------------------------------ \|
73	\| `TODO` \| Acknowledged incomplete work \|
74	\| `FIXME` \| Known bug or issue \|
75	\| `HACK`, `WORKAROUND`, `XXX` \| Intentional shortcut or band-aid \|
76	\| `@ts-ignore` \| TypeScript safety bypassed \|
77	\| `eslint-disable` \| Linting rules intentionally bypassed \|
78	\| Empty `catch {}` blocks \| Errors silently swallowed \|
79
80	Why it matters: The code is literally telling you where the risk is.
81
82	#### 3. Comprehensibility
83
84	Can a newcomer understand this code?
85
86	This requires reading the code and making a semantic judgment:
87
88	- Naming quality: Are variables, functions, and classes named descriptively? Or are there names like `data`, `temp`, `x`, `processStuff`?
89	- Comment-to-complexity ratio: Complex logic (regex, algorithms, state machines) should have proportionally more comments. Simple code needs fewer.
90	- **Fun

People who liked this also viewed

6 picks

Type