feat: pre-flight discipline rule (karpathy principles)#46
Conversation
Encodes the four upstream-failure preventions Karpathy named: silent assumptions, overcomplicated diffs, drive-by edits, vague success criteria. Self-correction catches mistakes after the fact - this catches them before. Adds rules/pre-flight-discipline.mdc (alwaysApply: true) and a §1b cross-reference in SKILL.md so it sits next to self-correction in the narrative. No changes to existing rules or agents. Adapted from forrestchang/andrej-karpathy-skills (MIT) with light reframing to match pro-workflow's voice and structure.
📝 WalkthroughWalkthroughThis PR introduces pre-flight discipline guidelines by creating a new rules file ( Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
skills/pro-workflow/SKILL.md (1)
82-87: Consider adding a reminder about minimum viable code.The CLAUDE.md snippet covers rules 1, 3, and 4, but omits rule 2 ("Minimum viable code"). While the full rules are always-on via the
.mdcfile, adding a brief mention could reinforce this key principle.💡 Proposed addition
## Pre-Flight Discipline Before coding: state assumptions, present ambiguity, push back if simpler exists. +Keep changes minimal - no abstractions or features beyond the request. Every changed line traces to the request - no drive-by edits. Convert imperatives to verifiable goals: "fix bug" → "failing test → make it pass".🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@skills/pro-workflow/SKILL.md` around lines 82 - 87, Add a short reminder about "Minimum viable code" to the "Pre-Flight Discipline" section: edit the block under the "## Pre-Flight Discipline" header and append or insert a concise sentence (one line) that states developers should implement the smallest change that satisfies the failing behavior or test (e.g., "Prefer minimum viable code: implement the smallest, testable change to satisfy the requirement"). Ensure this new line sits alongside the existing lines about assumptions/ambiguity and converting imperatives to verifiable goals so the principle is visible in the same guidance paragraph.rules/pre-flight-discipline.mdc (1)
21-21: Consider clarifying the error handling guideline."No error handling for scenarios that cannot happen" could be misinterpreted as discouraging defensive error handling in production code. While the intent (preventing over-engineering of impossible scenarios) is clear in context, consider clarifying to distinguish between truly impossible cases and merely unlikely errors.
📝 Potential clarification
-- No error handling for scenarios that cannot happen. +- No error handling for scenarios that are logically impossible (e.g., null-checking hardcoded constants).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@skills/pro-workflow/SKILL.md`:
- Around line 82-87: Add a short reminder about "Minimum viable code" to the
"Pre-Flight Discipline" section: edit the block under the "## Pre-Flight
Discipline" header and append or insert a concise sentence (one line) that
states developers should implement the smallest change that satisfies the
failing behavior or test (e.g., "Prefer minimum viable code: implement the
smallest, testable change to satisfy the requirement"). Ensure this new line
sits alongside the existing lines about assumptions/ambiguity and converting
imperatives to verifiable goals so the principle is visible in the same guidance
paragraph.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: e417f4e3-5c18-42f3-8b69-4072133759e7
📒 Files selected for processing (2)
rules/pre-flight-discipline.mdcskills/pro-workflow/SKILL.md
1 participant
Summary
Adds a fifth always-on rule that encodes the four upstream-failure preventions Andrej Karpathy named for LLM coding: silent assumptions, overcomplicated diffs, drive-by edits, vague success criteria.
Pro-workflow already quotes Karpathy's 80/20 line in
SKILL.mdbut none of the four behavioral principles were encoded as rules. The closest existing rules —quality-gatesandself-correction— both fire after the mistake. This one fires before.Changes
rules/pre-flight-discipline.mdc(alwaysApply: true, ~60 lines)skills/pro-workflow/SKILL.md— adds §1b "Pre-Flight Discipline" between Self-Correction (§1) and Worktrees (§2), with a CLAUDE.md snippet and a pointer to the rule fileAttribution
Adapted from forrestchang/andrej-karpathy-skills (MIT) — single-skill repo of the same four principles. Reframed lightly to match pro-workflow's voice (
pre-flight-disciplinevs.karpathy-guidelines, principle headings rewritten) but the substance is intentionally faithful. Source link preserved in both files.Test plan
rules/pre-flight-discipline.mdcloads as an always-on rule (frontmatter parses,alwaysApply: true)SKILL.mdrenders cleanly with the new §1b sectionSummary by CodeRabbit