📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -0,0 +1,209 @@
|
||||
---
|
||||
name: super-code
|
||||
description: "Standing house style to enforce dense, correct, and idiomatic code on all coding tasks. Minimizes code bloat and agent operation overhead."
|
||||
risk: safe
|
||||
source: community
|
||||
date_added: "2026-06-16"
|
||||
---
|
||||
|
||||
# Super Code Skill
|
||||
|
||||
## Overview
|
||||
|
||||
Produce code that is short, correct, idiomatic, and maintainable — in that priority order.
|
||||
This skill addresses two distinct inefficiency types that must be fixed independently:
|
||||
|
||||
1. **Code-token inefficiency** — the artifact itself is bloated (unnecessary lines, boilerplate, over-abstraction)
|
||||
2. **Generation-token inefficiency** — how the agent operates during a session (full-file rewrites, unrequested files, prose padding before/after changes)
|
||||
|
||||
Both matter. Fixing only one is not enough.
|
||||
|
||||
## When to Use This Skill
|
||||
|
||||
- Apply this skill automatically on EVERY coding task in the IDE.
|
||||
- Use whenever the user asks to write, edit, refactor, generate, or review code in any language.
|
||||
- This is a standing house style, not an on-demand pass — always apply it.
|
||||
|
||||
---
|
||||
|
||||
## Priority Order (never violate this ranking)
|
||||
|
||||
```
|
||||
Correctness → Clarity → Necessary robustness → Conciseness → Micro-performance
|
||||
```
|
||||
|
||||
Conciseness **never** wins over correctness or readability. If a compression would drop error handling for a case that can actually occur, or produce code a human couldn't read in six months, undo that specific compression. Short bad code is worse than long correct code.
|
||||
|
||||
---
|
||||
|
||||
## Workflow — apply to every coding task
|
||||
|
||||
### Step 1: Commit to minimal correct shape BEFORE writing
|
||||
|
||||
Before touching a file, decide:
|
||||
- What is the smallest surface area that correctly solves this problem?
|
||||
- What does the caller actually need from this function/class/module?
|
||||
- Is there a stdlib/framework primitive that already does this?
|
||||
|
||||
Write that down mentally (not in a prose block to the user). This is the target shape.
|
||||
|
||||
### Step 2: Write using language-idiomatic patterns
|
||||
|
||||
Read the relevant reference file for the language in use:
|
||||
- Bash/Shell → `bash/SKILL.md`
|
||||
- C → `c/SKILL.md`
|
||||
- C++ → `cpp/SKILL.md`
|
||||
- C# → `csharp/SKILL.md`
|
||||
- Dart/Flutter → `dart/SKILL.md`
|
||||
- Elixir/Erlang → `elixir/SKILL.md`
|
||||
- Go → `go/SKILL.md`
|
||||
- Java → `java/SKILL.md`
|
||||
- Kotlin/Compose → `kotlin/SKILL.md`
|
||||
- PHP → `php/SKILL.md`
|
||||
- Python → `python/SKILL.md`
|
||||
- Ruby → `ruby/SKILL.md`
|
||||
- Rust → `rust/SKILL.md`
|
||||
- Scala → `scala/SKILL.md`
|
||||
- Swift → `swift/SKILL.md`
|
||||
- TypeScript/JavaScript → `typescript/SKILL.md`
|
||||
|
||||
Apply idiomatic patterns from that file. They replace verbose imperative code with correct, concise equivalents that are still readable.
|
||||
|
||||
### Step 3: Compression pass on your own draft
|
||||
|
||||
Before presenting any code, scan it for:
|
||||
|
||||
| Anti-pattern | Fix |
|
||||
|---|---|
|
||||
| Comment restates what code does | Delete comment, or rewrite to say *why* |
|
||||
| Single-use helper function/class | Inline it |
|
||||
| Stdlib/framework already does this | Replace with the primitive |
|
||||
| Defensive handling for impossible case | Remove |
|
||||
| Verbose loop replaceable by idiomatic expression | Replace |
|
||||
| Logging/print nobody asked for | Remove |
|
||||
| Extra config/files/parameters not requested | Remove |
|
||||
| Unused import or variable | Remove |
|
||||
|
||||
### Step 4: Guardrail check — run this before presenting
|
||||
|
||||
Ask yourself (silently):
|
||||
- [ ] Did I remove handling for a case that **can** actually happen?
|
||||
- [ ] Did I make this harder to read for a human six months from now?
|
||||
- [ ] Did I drop correctness or security to save lines?
|
||||
|
||||
If yes to any: undo that specific compression and keep the rest.
|
||||
|
||||
### Step 5: Present output — generation-token rules
|
||||
|
||||
**Always:**
|
||||
- Edit files via targeted patches/diffs, not full rewrites, unless the file is new or the change touches >70% of lines
|
||||
- Present only what was asked for
|
||||
|
||||
**Never:**
|
||||
- Generate unrequested files (tests, READMEs, configs, types) unless the user asked
|
||||
- Add prose blocks before/after code explaining what you're about to do or just did — just do it
|
||||
- Re-explain the user's own requirement back to them before writing
|
||||
- Restate what changed in a paragraph after showing the diff — the diff is self-evident
|
||||
|
||||
---
|
||||
|
||||
## Universal Anti-Pattern Checklist
|
||||
|
||||
These apply in every language. The language-specific files extend this list.
|
||||
|
||||
### Comments
|
||||
- ❌ `// Loop through the list and add each item` → ❌ delete
|
||||
- ✅ `// Order matters: process refunds before charges` → ✅ keep (explains *why*)
|
||||
- Rule: if the comment could be generated mechanically from reading the code, it adds no value
|
||||
|
||||
### Defensive coding
|
||||
- Only handle error cases that can actually occur given the call site
|
||||
- If the caller guarantees non-null, don't null-check inside the function
|
||||
- If a catch block can only log and rethrow, consider removing the try/catch
|
||||
|
||||
### Abstractions
|
||||
- Don't extract a function for logic used exactly once in one place
|
||||
- Don't create a wrapper class around a primitive used only once
|
||||
- Threshold: abstraction earns its place when it's used 2+ times OR when it has a meaningful name that genuinely clarifies domain logic
|
||||
|
||||
### Scaffolding
|
||||
- No placeholder TODOs unless the user asked for a scaffold
|
||||
- No `// TODO: add error handling` — either add it or don't
|
||||
- No empty catch blocks "just in case"
|
||||
- No parameters the current callers don't use
|
||||
|
||||
---
|
||||
|
||||
## Generation-Token Rules (agentic IDE specific)
|
||||
|
||||
These govern how you operate inside the session, not just what you produce:
|
||||
|
||||
### File edits
|
||||
- Prefer surgical patches: show only the changed lines + minimal context
|
||||
- Full file rewrite is acceptable only for: new files, files shorter than ~30 lines, or changes touching >70% of the file
|
||||
- Never repeat unchanged portions of a file to "show the full context"
|
||||
|
||||
### Unrequested artifacts
|
||||
- Do not create test files, README updates, type definition files, config files, or CI scripts unless explicitly requested
|
||||
- If you believe a test file would be valuable, offer it in one sentence after the main output — don't generate it unasked
|
||||
|
||||
### Prose overhead
|
||||
- No "Here's what I'm going to do:" preambles
|
||||
- No "I've made the following changes:" postambles (the diff shows this)
|
||||
- No "Let me know if you'd like me to..." closers
|
||||
- One-line clarification is acceptable if a requirement is genuinely ambiguous; otherwise, make a reasonable choice and note the assumption in a comment inside the code if it matters
|
||||
|
||||
---
|
||||
|
||||
## Language Reference Files
|
||||
|
||||
| Language / Stack | File |
|
||||
|---|---|
|
||||
| Bash / Shell | `bash/SKILL.md` |
|
||||
| C | `c/SKILL.md` |
|
||||
| C++ | `cpp/SKILL.md` |
|
||||
| C# / .NET | `csharp/SKILL.md` |
|
||||
| Dart / Flutter | `dart/SKILL.md` |
|
||||
| Elixir / Erlang | `elixir/SKILL.md` |
|
||||
| Go | `go/SKILL.md` |
|
||||
| Java | `java/SKILL.md` |
|
||||
| Kotlin + Compose (Android) | `kotlin/SKILL.md` |
|
||||
| PHP | `php/SKILL.md` |
|
||||
| Python | `python/SKILL.md` |
|
||||
| Ruby | `ruby/SKILL.md` |
|
||||
| Rust | `rust/SKILL.md` |
|
||||
| Scala | `scala/SKILL.md` |
|
||||
| Swift (iOS/macOS) | `swift/SKILL.md` |
|
||||
| TypeScript / JavaScript | `typescript/SKILL.md` |
|
||||
|
||||
Read the relevant file at Step 2. If the language isn't listed, apply the universal checklist above and use the language's own idioms for loops, error handling, and data transformation.
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Refactoring a verbose loop
|
||||
```java
|
||||
// Anti-pattern
|
||||
List<String> names = new ArrayList<>();
|
||||
for (User u : users) {
|
||||
if (u.isActive()) {
|
||||
names.add(u.getName());
|
||||
}
|
||||
}
|
||||
// Super-code idiomatic (Java)
|
||||
List<String> names = users.stream().filter(User::isActive).map(User::getName).toList();
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Problem: Code is too dense to read
|
||||
**Symptoms:** Reviewer complains or logic is unreadable.
|
||||
**Solution:** Revert the overly compressed section. Clarity and correctness always win over conciseness.
|
||||
|
||||
## Related Skills
|
||||
|
||||
- `@karpathy-guidelines` - For behavioral guidelines on surgical changes and simplicity.
|
||||
|
||||
## Limitations
|
||||
|
||||
- **Language Support:** Language-specific idioms require reference files.
|
||||
- **Readability Tradeoffs:** Extreme compression can sometimes harm readability if not careful.
|
||||
Reference in New Issue
Block a user