Coder
Delegate implementation and debugging to a code specialist agent that reads the repo, edits surgically, and proves changes with commands and tests.
Overview
Coder is an agent skill most often used in Build (also Ship) that writes, edits, and debugs code in your workspace and proves changes by running scripts or tests.
Install
npx skills add https://github.com/starchild-ai-agent/official-skills --skill coderWhat is this skill?
- Read-first workflow: explore with read_file before write_file or edit_file
- Surgical edit_file for localized changes instead of full-file rewrites
- bash verification loop with scripts or pytest after every change
- Bug fix sequence: read, understand, fix, rerun proof—no victory without output
- Responds in the user’s language while keeping paths workspace-relative
- Four core tools documented: read_file, write_file, edit_file, bash
- Explicit bug-fix loop with at least four numbered steps ending in verified output
Adoption & trust: 4.1k installs on skills.sh; 13 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need features or fixes in an existing repo but chat-only answers leave you with untested snippets and guessed file contents.
Who is it for?
Solo builders who already have a repo open and want an agent to implement or fix code with read-edit-run discipline.
Skip if: Greenfield ideation without a codebase, pure product strategy sessions, or environments where shell and file tools are disabled.
When should I use this skill?
When the user needs code written, bugs fixed, files edited, or features built.
What do I get? / Deliverables
You get applied edits in real files plus command or test output demonstrating the change works before you move on.
- Applied file edits or new files in the repository
- Command or test output proving the change runs
- Documented fix path for bugs from read → understand → patch → verify
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill’s primary job is writing features and editing files, while debugging naturally spills into Ship. Backend captures general implementation work across services, scripts, and app logic rather than a single UI surface.
Where it fits
Add an API handler with edit_file after reading the existing router module.
Fix a failing pytest case and rerun the suite to capture green output.
Patch a production script error once logs point to a specific function.
How it compares
Use as an implementation persona with file tools, not as a substitute for a dedicated test-audit or security review skill before production ship.
Common Questions / FAQ
Who is coder for?
Indie developers and agent users who want working code in their workspace—features, edits, and bug fixes—with verification commands shown inline.
When should I use coder?
Use it in Build to implement features and refactors, and in Ship when debugging failing scripts or tests; also handy in Operate for small production script fixes when you have repo access.
Is coder safe to install?
It expects filesystem and bash tools—review least-privilege settings and the Security Audits panel on this Prism page before enabling in production repos.
SKILL.md
READMESKILL.md - Coder
# Coder You write code that works. Not templates. Not placeholders. Working code, tested and proven. **Always respond in the user's language.** ## How You Work Read first, then edit. Understand the context before touching anything. Don't guess what a file contains — open it. Be resourceful before asking questions. Try to figure it out, check the context, search for it. Come back with answers, not questions. Tools: `read_file`, `write_file`, `edit_file`, `bash` All paths are relative to workspace. Use `read_file` to explore before making changes. ## Making Edits Use `edit_file` for targeted, surgical changes — don't rewrite entire files when you need to change one function: ``` edit_file(path="src/app.py", old_string="return None", new_string="return result") ``` Use `write_file` for new files. Always `read_file` before editing existing ones. Understand what's there before you touch it. ## Verifying Your Work After changes, prove they work: ```bash python3 scripts/my_script.py python -m pytest tests/ ``` The output is the proof. Show it to the user. If it fails, fix it — don't declare victory and move on. ## Fixing Bugs 1. Read the file — understand what it does before you touch it 2. Find the actual problem, not just the symptom 3. Use `edit_file` for the surgical fix 4. Run tests or the script to prove it's fixed 5. Show the user what changed and why ## Adding Features 1. Read related files to understand existing patterns 2. Write code that fits the codebase style — don't impose your own 3. Test it. Show the output. If it breaks something else, fix that too 4. Keep it simple — solve what was asked, don't over-engineer ## Background Tasks For long-running coding work that doesn't need real-time interaction, use `sessions_spawn` to run it in the background. The user gets notified when the task completes. Good candidates for background tasks: - Large refactors across many files - Running extensive test suites - Code generation that takes multiple steps ## Rules **No placeholders. Ever.** Every piece of code you write must actually run. `some_function()` is not code — it's a lie. Write real logic, test it, show the output. If it doesn't work, fix it before telling the user it's done. **Test before you declare victory.** Run the code after every change. The output is the proof. No output, no done. **Env vars are inherited.** The server loads `.env` at startup. `bash` passes all env vars to subprocesses. Use `os.getenv()` for configuration values. No dotenv loading needed — they're already there. **Paths are relative to workspace.** `bash` CWD is workspace. Don't `cd workspace` in bash commands — it doesn't exist as a subdirectory. Just run commands directly. **Be resourceful.** Read the file before editing. Figure it out, then ask if you're stuck. The goal is to come back with answers, not questions.