How do I install the Kernel Change Intent skill?

Run npx skillmds@latest add gvago/kernel-change-intent in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Kernel Change Intent safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Kernel Change Intent?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Kernel Change Intent free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under Apache-2.

Who published Kernel Change Intent?

gvago (@gvago) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Kernel Change Intent by gvago — Agent Skill

Name: Kernel Change Intent
Author: gvago

Kernel Change Intent

Use when reviewing a Linux kernel PR diff, verifies commit goal and implementation claims (Sashiko stages 1-2): design soundness, UAPI/ABI breakage, and commit-message-vs-code mismatches in the CHANGED code only. Part of the linux-kernel-review suite.

gvago a809bf9 2.6 KB Updated Sep 17, 2026

File contents

kernel-change-intent

Lens for commit goal and implementation-claim verification (Sashiko stages 1-2). Runs no tools. Judges whether the change's concept is sound and whether the code actually does what the commit message claims.

How to apply

Read the commit message first, then verify every claim against the diff. Do not trust the message; assume it may be wrong or even intentionally misleading.
Question assumptions. Consider simpler alternative designs.
Judge changed lines and their direct blast radius only.

Rule index

I1. Architectural soundness. Flag fundamentally flawed concepts, long-term maintainability hazards, and violations of established kernel design principles. Consider system-wide implications.
I2. UAPI and backwards compatibility. Any UAPI breakage or ABI change without proper deprecation is action_required (Critical-class).
I3. Claim-vs-code match. Every claim in the commit message must be fully realized in the diff. Flag missing pieces: a core change without updating corresponding callers, a struct change without updating all initializers, incomplete implementations, undocumented side-effects.
I4. API contract completeness. When defining or modifying structures containing function pointers, verify all logically required callbacks are implemented. Check for interface omissions.
I5. Semantic soundness of arguments. Verify arguments passed to external subsystems (kobjects, netdevs, etc.) are valid and semantically correct: non-empty strings, correct sizes, correct format specifiers, correct bitwise operations, sound bounds math.

Mapping a finding to the contract

action_level: action_required for UAPI breakage or a proven claim/code mismatch that changes behavior; remediation_recommended for maintainability or design concerns.
category: Correctness for mismatches, Maintainability for design.
evidence: quote the commit-message claim and cite the code that contradicts or fails to implement it.

What NOT to flag

Low-level memory or locking errors, other lenses own those.
Stylistic disagreement with a design that violates no kernel principle.
Commit message wording nits with no code impact.

Sourcing

Stage text adapted from Sashiko (Apache-2.0). No reference files needed; this lens is pure reasoning.

---name: kernel-change-intentdescription: Use when reviewing a Linux kernel PR diff, verifies commit goal and implementation claims (Sashiko stages 1-2): design soundness, UAPI/ABI breakage, and commit-message-vs-code mismatches in the CHANGED code only. Part of the linux-kernel-review suite.license: Apache-2.0---# kernel-change-intentLens for commit goal and implementation-claim verification (Sashiko stages1-2). Runs no tools. Judges whether the change's concept is sound andwhether the code actually does what the commit message claims.## How to apply- Read the commit message first, then verify every claim against the diff. Do not trust the message; assume it may be wrong or even intentionally misleading.- Question assumptions. Consider simpler alternative designs.- Judge changed lines and their direct blast radius only.## Rule index- I1. Architectural soundness. Flag fundamentally flawed concepts, long-term maintainability hazards, and violations of established kernel design principles. Consider system-wide implications.- I2. UAPI and backwards compatibility. Any UAPI breakage or ABI change without proper deprecation is action_required (Critical-class).- I3. Claim-vs-code match. Every claim in the commit message must be fully realized in the diff. Flag missing pieces: a core change without updating corresponding callers, a struct change without updating all initializers, incomplete implementations, undocumented side-effects.- I4. API contract completeness. When defining or modifying structures containing function pointers, verify all logically required callbacks are implemented. Check for interface omissions.- I5. Semantic soundness of arguments. Verify arguments passed to external subsystems (kobjects, netdevs, etc.) are valid and semantically correct: non-empty strings, correct sizes, correct format specifiers, correct bitwise operations, sound bounds math.## Mapping a finding to the contract- action_level: action_required for UAPI breakage or a proven claim/code mismatch that changes behavior; remediation_recommended for maintainability or design concerns.- category: Correctness for mismatches, Maintainability for design.- evidence: quote the commit-message claim and cite the code that contradicts or fails to implement it.## What NOT to flag- Low-level memory or locking errors, other lenses own those.- Stylistic disagreement with a design that violates no kernel principle.- Commit message wording nits with no code impact.## SourcingStage text adapted from Sashiko (Apache-2.0). No reference files needed;this lens is pure reasoning.

Frequently asked questions