Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use when you have a spec or requirements for a multi-step task. Creates comprehensive implementation plans with bite-sized tasks, exact file paths, and complete code examples.
.claude/skills/graniet-writing-plans/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-07 | ✗→✓ | ▲ Improved | 30% | 0% |
| case-10 | ✗→✓ | ▲ Improved | 47% | 0% |
| case-18 | ✗→✓ | ▲ Improved | 41% | 0% |
| case-21 | ✗→✓ | ▲ Improved | 60% | 0% |
| case-12 | ✓→✗ | ▼ Worse | 74% | 0% |
This skill is repo-local and stays inactive until explicitly activated.
When the original instructions refer to legacy tool names, use these Kheish mappings:
terminal => bashweb_extract => web_fetch, plus web_search when discovery is neededsearch_files => grep_search and glob_searchbrowser_* tools require a browser-capable surfaced tool or MCP; if none is available, use the closest available surface and say so explicitlyWhen the instructions mention local helper files, resolve them from ${KHEISH_SKILL_DIR}.
Write comprehensive implementation plans assuming the implementer has zero context for the codebase and questionable taste. Document everything they need: which files to touch, complete code, testing commands, docs to check, how to verify. Give them bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
Assume the implementer is a skilled developer but knows almost nothing about the toolset or problem domain. Assume they don't know good test design very well.
Core principle: A good plan makes implementation obvious. If someone has to guess, the plan is incomplete.
Always use before:
Don't skip when:
Each task = 2-5 minutes of focused work.
Every step is one action:
Too big:
markdown### Task 1: Build authentication system [50 lines of code across 5 files]
Right size:
markdown### Task 1: Create User model with email field [10 lines, 1 file] ### Task 2: Add password hash field to User [8 lines, 1 file] ### Task 3: Create password hashing utility [15 lines, 1 file]
Every plan MUST start with:
markdown# [Feature Name] Implementation Plan > **For Kheish:** Use subagent-driven-development skill to implement this plan task-by-task. **Goal:** [One sentence describing what this builds] **Architecture:** [2-3 sentences about approach] **Tech Stack:** [Key technologies/libraries] ---
Each task follows this format:
`markdown### Task N: [Descriptive Name] **Objective:** What this task accomplishes (one sentence) **Files:** - Create: `exact/path/to/new_file.py` - Modify: `exact/path/to/existing.py:45-67` (line numbers if known) - Test: `tests/path/to/test_file.py` **Step 1: Write failing test**
def test_specific_behavior(): result = function(input) assert result == expected
**Step 2: Run test to verify failure**
Run: `pytest tests/path/test.py::test_specific_behavior -v`
Expected: FAIL — "function not defined"
**Step 3: Write minimal implementation**
def function(input): return expected
**Step 4: Run test to verify pass**
Run: `pytest tests/path/test.py::test_specific_behavior -v`
Expected: PASS
**Step 5: Commit**
git add tests/path/test.py src/path/file.py git commit -m "feat: add specific feature"
Read and understand:
Use Kheish tools to understand the project:
python# Understand project structure search_files("*.py", target="files", path="src/") # Look at similar features search_files("similar_pattern", path="src/", file_glob="*.py") # Check existing tests search_files("*.py", target="files", path="tests/") # Read key files read_file("src/app.py")
Decide:
Create tasks in order:
For each task, include:
src/config/settings.py)Check:
bashmkdir -p docs/plans # Save plan to docs/plans/YYYY-MM-DD-feature-name.md git add docs/plans/ git commit -m "docs: add implementation plan for [feature]"
Bad: Copy-paste validation in 3 places Good: Extract validation function, use everywhere
Bad: Add "flexibility" for future requirements Good: Implement only what's needed now
python# Bad — YAGNI violation class User: def __init__(self, name, email): self.name = name self.email = email self.preferences = {} # Not needed yet! self.metadata = {} # Not needed yet! # Good — YAGNI class User: def __init__(self, name, email): self.name = name self.email = email
Every task that produces code should include the full TDD cycle:
See test-driven-development skill for details.
Commit after every task:
bashgit add [files] git commit -m "type: description"
Bad: "Add authentication" Good: "Create User model with email and password_hash fields"
Bad: "Step 1: Add validation function" Good: "Step 1: Add validation function" followed by the complete function code
Bad: "Step 3: Test it works" Good: "Step 3: Run pytest tests/test_auth.py -v, expected: 3 passed"
Bad: "Create the model file" Good: "Create: src/models/user.py"
After saving the plan, offer the execution approach:
"Plan complete and saved. Ready to execute using subagent-driven-development — I'll dispatch a fresh subagent per task with two-stage review (spec compliance then code quality). Shall I proceed?"
When executing, use the subagent-driven-development skill:
delegate_task per task with full contextBite-sized tasks (2-5 min each)
Exact file paths
Complete code (copy-pasteable)
Exact commands with expected output
Verification steps
DRY, YAGNI, TDD
Frequent commitsA good plan makes implementation obvious.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→fail | 3,777 | 18,198 | +382% | 1 | 1 | 0% | 240 | 2,236 | +832% | 0 | 0 | — |
case-02 | fail→fail | 3,794 | 4,431 | +17% | 1 | 1 | 0% | 253 | 2,368 | +836% | 0 | 0 | — |
case-03 | fail→fail | 3,865 | 4,489 | +16% | 1 | 1 | 0% | 166 | 2,341 | +1310% | 0 | 0 | — |
case-04 | pass→pass | 10,932 | 6,304 | -42% | 1 | 1 | 0% | 1,912 | 3,141 | +64% | 0 | 0 | — |
case-05 | pass→pass | 10,651 | 5,987 | -44% | 1 | 1 | 0% | 1,793 | 3,089 | +72% | 0 | 0 | — |
case-06 | pass→pass | 11,041 | 7,634 | -31% | 1 | 1 | 0% | 1,909 | 3,512 | +84% | 0 | 0 | — |
case-07 | fail→pass | 11,585 | 2,898 | -75% | 1 | 1 | 0% | 1,958 | 2,552 | +30% | 0 | 0 | — |
case-08 | pass→pass | 7,552 | 5,109 | -32% | 1 | 1 | 0% | 1,386 | 2,791 | +101% | 0 | 0 | — |
case-09 | pass→pass | 8,011 | 4,933 | -38% | 1 | 1 | 0% | 1,451 | 2,855 | +97% | 0 | 0 | — |
case-10 | fail→pass | 9,523 | 2,695 | -72% | 1 | 1 | 0% | 1,648 | 2,424 | +47% | 0 | 0 | — |
case-11 | pass→pass | 11,746 | 3,430 | -71% | 1 | 1 | 0% | 2,045 | 2,563 | +25% | 0 | 0 | — |
case-12 | pass→fail | 6,830 | 5,398 | -21% | 1 | 1 | 0% | 1,330 | 2,318 | +74% | 0 | 0 | — |
case-13 | fail→fail | 2,225 | 5,858 | +163% | 1 | 1 | 0% | 295 | 2,361 | +700% | 0 | 0 | — |
case-14 | pass→fail | 22,617 | 4,173 | -82% | 1 | 1 | 0% | 3,761 | 2,391 | -36% | 0 | 0 | — |
case-15 | pass→fail | 15,211 | 5,532 | -64% | 1 | 1 | 0% | 2,914 | 2,321 | -20% | 0 | 0 | — |
case-16 | pass→pass | 11,447 | 6,951 | -39% | 1 | 1 | 0% | 1,805 | 3,153 | +75% | 0 | 0 | — |
case-17 | pass→pass | 12,026 | 10,227 | -15% | 1 | 1 | 0% | 2,044 | 3,938 | +93% | 0 | 0 | — |
case-18 | fail→pass | 11,991 | 4,276 | -64% | 1 | 1 | 0% | 1,908 | 2,695 | +41% | 0 | 0 | — |
case-19 | pass→pass | 11,220 | 4,515 | -60% | 1 | 1 | 0% | 1,806 | 2,689 | +49% | 0 | 0 | — |
case-20 | pass→pass | 11,035 | 5,210 | -53% | 1 | 1 | 0% | 1,658 | 2,827 | +71% | 0 | 0 | — |
case-21 | fail→pass | 11,622 | 3,921 | -66% | 1 | 1 | 0% | 1,705 | 2,734 | +60% | 0 | 0 | — |
case-22 | pass→pass | 7,500 | 4,208 | -44% | 1 | 1 | 0% | 1,293 | 2,692 | +108% | 0 | 0 | — |
case-23 | pass→pass | 8,554 | 5,056 | -41% | 1 | 1 | 0% | 1,604 | 2,976 | +86% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 23 cases were attempted, and 16 counted toward the lift figure. The other 7 produced results that are not comparable between the two arms, so they are excluded from the headline rather than averaged into it. The headline lift of +4 percentage points is the difference between those two pass rates over the 16 comparable cases. 3 cases got worse with the skill loaded, and they are included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.