Helps developers write code comments explaining intent, rationale, and key tradeoffs.
The material indicates this is a prompt-only/documentation-style skill with no keys required, no remote endpoints, and no evident code execution or data access capabilities. Overall risk is low, with only minor trust uncertainty due to low community adoption and unknown maintenance status.
The material explicitly states that no keys or environment variables are required, and shows no path for credential collection, storage, transmission, or misuse.
No remote endpoints are declared, and the content appears to be a commenting guideline/prompt with no indication of sending user data to external services.
The system marks it as prompt-only; the README only describes commenting principles and example code, with no claim of spawning local processes, executing scripts, or invoking system capabilities.
There is no declared ability to read or write local files, project data, clipboard contents, databases, or other resources, and no signs of excessive access are present.
The source is an open-source GitHub repository, which is a positive sign because the code is in principle auditable; however, the license is undeclared, it has 0 stars, and maintenance status is unknown, so supply-chain trust is only moderate and manual review is advisable before use.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "Commenting Intent" skill from askskill: 1. Download https://raw.githubusercontent.com/obra/clank/main/skills/coding/commenting-intent/SKILL.md 2. Save it as ~/.claude/skills/commenting-intent/SKILL.md 3. Reload skills and tell me it's ready
Please review the following function and add comments only for why it is implemented this way and any non-obvious design tradeoffs. Do not explain what each line does. Output the commented code and a short list of rationale behind each added comment.
Code updated with intent-focused comments plus a brief rationale list.
Most comments in the code below just repeat what the code already says. Identify those low-value comments, remove or rewrite them to explain business context, edge cases, performance concerns, or compatibility reasons, and explain your editing principles.
A revised version with mechanical comments removed and intent-based comments preserved, plus editing principles.
Review this code change and identify where comments should be added to explain design intent, historical constraints, fallback behavior, or security considerations. Output in the format: location - suggested comment - reason.
Location-based comment suggestions that improve maintainability during code review.
Good comments explain WHY, not WHAT. Code already shows what it does. Comments should explain intent, decisions, and non-obvious reasoning.
Core principle: If the comment just restates the code, delete the comment or improve the code.
Agents comment mechanics (what code does):
❌ Over-commenting (baseline):
# Calculate subtotal by multiplying price and quantity for each item, then summing
subtotal = sum(item.price * item.quantity for item in items)
# Calculate tax amount based on the subtotal and tax rate
tax = subtotal * tax_rate
# Calculate final total by adding subtotal and tax
total = subtotal + tax
Problem: Comments just restate obvious code. No value added.
✅ Comment intent only:
def calculate_total_price(items, tax_rate):
"""Calculate order total including tax."""
subtotal = sum(item.price * item.quantity for item in items)
tax = subtotal * tax_rate
return subtotal + tax # No comments needed - code is clear
✅ WHY you chose this approach:
def is_rate_limited(user_id, redis_client):
# Using Redis instead of in-memory to support distributed rate limiting
# across multiple app servers. Limit: 100 req/min per business requirements.
key = f"rate_limit:{user_id}"
current = redis_client.get(key)
if current is None:
redis_client.setex(key, 60, 1) # 60 sec TTL
return False
return int(current) >= 100 # Limit per product requirements doc
Explains: WHY Redis, WHY these limits, WHERE requirements came from.
✅ WHY this algorithm:
def find_user(users, email):
# Binary search requires sorted array. We sort by email on load
# to enable O(log n) lookups. Worth the upfront sort cost because
# lookups happen 100x more frequently than updates.
return binary_search(users, email)
Explains: WHY binary search, WHY pre-sorted, trade-off reasoning.
✅ WHY these values:
MAX_RETRIES = 3 # Testing showed 3 retries handles 99.9% of transient failures
TIMEOUT_MS = 5000 # API SLA guarantees < 5sec response time
BATCH_SIZE = 100 # Larger batches caused memory issues in prod (incident #1234)
Explains: WHERE values came from (testing, SLA, incident).
✅ WHY unusual code:
# WORKAROUND: Library bug #456 - must call reset() twice
# Fixed in v2.0 but we're on v1.8
client.reset()
client.reset()
Warns future maintainer: Unusual code has reason, link to issue.
❌ Restates the code:
# Set user name to "John"
user.name = "John"
# Loop through items
for item in items:
# Process the item
process(item)
✅ Let code speak:
user.name = "John"
for item in items:
process(item)
❌ Obvious pattern:
# Initialize search boundaries to cover entire array
left, right = 0, len(arr) - 1
# Continue searching while there's a valid range
while left <= right:
✅ Comment intent only:
def binary_search(arr, target):
# Binary search for O(log n) performance on sorted array
left, right = 0, len(arr) - 1
while left <= right:
# ... implementation (standard pattern, no comments needed)
For each comment, ask:
Does it explain WHY, not WHAT?
Would I understand without it?
Does it add information beyond the code?
| Comment This | Don't Comment This |
|---|
…
Write evergreen comments focused on what and why, not historical context.
Compare 2-3 approaches before execution to choose a stronger solution.
Plan with pseudocode first, refine approaches, then translate into working code.
Search past Claude Code chats to recover facts, decisions, and context.
Design systems by hiding implementation details behind domain-level interfaces.
Name code by domain meaning to improve clarity and team alignment.
Capture the why behind git changes with standardized contextual commit history.
Evaluate code review feedback rigorously before deciding whether to implement it.
Distill a single OpenClaw PR into a short intent memo safely.
Clarify intent, requirements, and solution direction before any creative implementation work.
Clarify ambiguous changes into testable acceptance criteria and implementation requirements.
Improve code clarity and maintainability by assigning each variable one purpose.