# No Edit Code

> Use this skill for ANY question about code — bugs, features, refactors, "how do I...", "fix this", "why does this break" — even if the user doesn't explicitly say "don't touch the code." It stops Claude from editing, writing, or running code-changing commands and instead returns a short, precise written proposal describing the change, backed by at most 3 documentation sources (official docs and/or the project's own README/comments). Trigger this whenever a coding question comes up in conversation, unless the user has explicitly asked for code to be applied/committed/edited directly.

- Skill: `ecaminero/no-edit-code` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ecaminero/no-edit-code`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ecaminero/no-edit-code/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: ecaminero (https://skillmd.com/u/ecaminero)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ecaminero/no-edit-code

---


# No-Code Proposals

## Why this exists

The person using this skill wants to stay in control of their codebase. They want Claude's read on a problem — not Claude's hands on the keyboard. Every code question should come back as something they can read in a few seconds, decide on, and apply themselves (or ask for next).

## What to do instead of editing

When this skill is active and a code question comes up:

1. **Do not call Edit, Write, or any command that changes files** (no applying patches, no `git commit`, no running codemods). Reading files, searching, and running read-only commands (tests, linters, `git diff` on existing state) to understand the problem is fine and encouraged — the restriction is on *changing* things, not on investigating.
2. Investigate enough to be confident: read the relevant file(s), understand the existing pattern, check how similar things are done elsewhere in the project.
3. Write a proposal instead of a diff.

## Proposal format

Keep it short. A proposal is not a report — if you can cut a sentence and lose nothing, cut it.

- **1–3 sentences** stating what to change and why.
- **Optional**: a short illustrative snippet (a handful of lines) if code communicates the idea faster than prose — but label it clearly as an example, not something applied. Skip it entirely if the prose already makes the change obvious.
- **Sources**: at most 3 links, the ones that most directly justify the proposal. No source dump — pick the 3 (or fewer) that matter most.

Do not present multiple alternative approaches unless the user asked for options — pick the best one and propose it. If you're genuinely unsure between two approaches, say so in one line rather than listing both in full.

## Sourcing the documentation

Sources can come from two places — use whichever actually backs the claim:

- **Official docs, found via web search.** For a library/framework/language question, search for and cite the specific page (API reference, guide section) that supports the proposal — not just the docs homepage.
- **The project's own documentation.** READMEs, doc comments, ADRs, or config files in the repo that establish how *this* codebase already does things. These often matter more than official docs, since the goal is a proposal that fits the existing code.

Cap it at 3 total, mixing both kinds when relevant (e.g., 1 official doc + 2 project files, or 3 project files, or 2 official docs). If you can't find a source that actually supports the proposal, say so rather than citing something tangential just to hit the format — an honest "no direct doc for this, based on existing pattern in `file.py`" beats a padded citation list.

## Example

**User:** "Users are getting logged out randomly — I think it's the session refresh logic."

**Proposal:**
The refresh in `auth/session.py` re-issues a token but never resets the idle timer, so a background refresh can still leave the session to expire out from under an active user. Reset `last_active` inside `refresh_token()` right after the new token is issued.

```python
def refresh_token(session):
    session.token = issue_token(session.user)
    session.last_active = now()  # add this line
```

Sources:
- [Project: `auth/session.py` — existing `last_active` handling in `touch_session()`]
- [Official: JWT refresh best practices — Auth0 docs, "Refresh Token Rotation"]

## When this skill doesn't apply

If the user explicitly asks you to apply, commit, or push a change ("go ahead and fix it", "make that edit", "commit this"), that instruction overrides the skill for that request — do the edit as normal. The skill governs the default when someone raises a code question without asking for execution.