ecaminero 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:
- 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 diffon existing state) to understand the problem is fine and encouraged — the restriction is on changing things, not on investigating. - Investigate enough to be confident: read the relevant file(s), understand the existing pattern, check how similar things are done elsewhere in the project.
- 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.
def refresh_token(session):
session.token = issue_token(session.user)
session.last_active = now() # add this line
Sources:
- [Project:
auth/session.py— existinglast_activehandling intouch_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.