docs(skills): add the minimal-code decision ladder to /feature Phase 0 - #4008
Conversation
Challenge every mechanism a change would introduce before proposing an implementation, stopping at the first rung that holds: product decision -> reuse -> stdlib -> native platform -> installed dependency -> one-liner -> minimal code. Persisted state gets its own rule: state encoding a policy is not a code choice, since code is deleted while data has to be migrated, so it requires explicit user confirmation before it is built. The ladder outcome is carried into the "present plan" step as one line per rejected mechanism. Guardrails stay non-negotiable: understanding the problem, trust-boundary validation, data-loss handling, security, accessibility, and anything the user explicitly asked for are never traded away. Claude-Session: https://claude.ai/code/session_019Cow7oT71FcBKpD5brmwBs
|
Warning Review limit reached
Next review available in: 44 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
WalkthroughThe feature skill adds a minimal-code ladder. It requires persisted policy-state decisions and explicit confirmation. The Phase 0 checklist records the ladder outcome and pending decisions. ChangesFeature workflow guidance
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related issues
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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 |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.claude/skills/feature/SKILL.md:
- Line 141: Update the Phase 0 “Ladder outcome (§4b)” requirement in SKILL.md to
include a “Selected rung” entry identifying the chosen mechanism or explicitly
stating when rung 0 removes it, while retaining the existing rejected-mechanism
and pending-state details.
- Line 124: Update the decision ladder in SKILL.md so rung 0 is terminal only
when the product decision removes the mechanism; when the mechanism remains
required, including accepting its cost or failure, continue through rung 1 and
subsequent reuse, standard-library, and native-platform checks.
- Line 132: Update §5 in SKILL.md to add a distinct, explicit confirmation step
for every persisted policy decision identified by the ladder, and state that
implementation must not begin until the user approves each one. Keep the
existing “awaiting confirmation” tracking, but make approval a blocking
prerequisite rather than part of general validation.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 5b55bcb6-e724-4279-be95-0950aa301000
📒 Files selected for processing (1)
.claude/skills/feature/SKILL.md
…confirmation Address review feedback on the minimal-code ladder: Rung 0 now holds only when the mechanism actually disappears. "Accept the cost" or "surface it to the user" can leave the mechanism required, and the stop-at-the-first-rung rule would then skip reuse, stdlib, platform features and the one-liner rung. Persisted state needs a blocking yes on that specific state, stated both in the ladder and in the present-plan step, so it is never covered by a general "plan validated". On the frontend side the rule is scoped to state that is actually retained or restored: a transient request or response field is not persisted state. The presented plan now reports the selected rung, not only the rejected options, so the decision that was made survives into the implementation. Claude-Session: https://claude.ai/code/session_019Cow7oT71FcBKpD5brmwBs
Closes #3944
Part of #3943
Adds the minimal-code decision ladder to the
/featureskill, run before an implementation is proposed.Placement — deliberate change vs the issue text
The issue asked for the ladder in Phase 1 ("before writing new code"). It landed at the end of Phase 0 instead, as
§4b, immediately before§5 Present plan & ask questions.Reason: the first rung is a product question ("does a decision remove this mechanism?"), and §5 is the one place the skill already stops and talks to the user. Running the ladder in Phase 1 would mean discovering the answer after the plan was already validated. The ladder outcome is now carried into §5 as an explicit bullet, so a rejected mechanism is visible at the moment the user validates.
Rungs
Product decision → reuse → stdlib → native platform → installed dependency → one-liner → minimal code. Stop at the first rung that holds.
Two additions beyond the original 7-rung list:
Guardrails unchanged
Understanding the problem before picking a rung, validation at trust boundaries, error handling that prevents data loss, security, and anything the user explicitly asked for are never traded away. The ladder prunes gratuitous mechanisms, never guardrails.
Docs-only: one file, no runtime code, no dependency change.
https://claude.ai/code/session_019Cow7oT71FcBKpD5brmwBs
Summary by CodeRabbit