القائمة
Drive a Genie change test-first through the genie MCP tools, working entirely from the live image (no files). Use when adding behavior or fixing a bug in the image — anything where a test should lead.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Refactor messy Pharo code safely through the genie MCP tools, working from the live image (no files). Use for renames, method extraction, moving behavior, or general cleanup of existing code.
Use when reviewing or refactoring code that pulls apart another object's private representation, such as raw limb/byte/slot access, slice constructors, or helper methods that expose internal storage. Guides agents to find representation envy and suggest moving behavior onto the object that owns the representation, using live-image Genie tools when working in Pharo.
Rename Pharo methods safely through Genie's `rename_method` MCP refactoring tool. Use when a selector should be renamed while preserving behavior, updating senders and symbol references across the live image, including as one step in larger refactorings such as clarify API names, split responsibilities, or move behavior behind better messages.
Use when modifying a Genie-backed Pharo project through the live MCP server on localhost:8087; includes project ownership, image read/change/test/save workflow, and first steps for new user projects.
Drive a Genie change test-first through the genie MCP tools, working entirely from the live image (no files). Use when adding behavior or fixing a bug in the image — anything where a test should lead.
| name | pharo-tdd |
| description | Drive a Genie change test-first through the genie MCP tools, working entirely from the live image (no files). Use when adding behavior or fixing a bug in the image — anything where a test should lead. |
All work goes through the genie MCP tools — there are no files. Prefer the
most specific MCP tool available: read with the read tools, change methods with
define_method, change classes with define_class, and use dedicated
refactoring/removal tools when they exist. Use eval only as a last resort
when no specific MCP tool can express the operation, and keep it minimal.
Confirm every change by reading it back. Never assume a class/selector exists —
look it up first.
Locate. Find the class and its test class:
list_classes (package) → list_methods → get_method_source.
Find the matching ...Test (TestCase subclass). If none exists, create it
via define_class (superclass TestCase).
Red. Write or adjust ONE failing test with define_method (protocol
tests). Run it: run_test with class_name. Expect failure. If it
passes immediately, the test isn't exercising the new behavior — fix the
test before writing code.
Green. Implement the smallest method that could pass, via
define_method. Run run_test again → expect green. Read the method back
with get_method_source to confirm what's installed.
Regression check. Run run_test for the whole package_name. A green
class test with a red package is not done.
Refactor. Clean up while green, re-running run_test after each step.
(For larger cleanups, switch to the pharo-refactor skill.)
Done. Persist with save_image gated on tests — pass test_package so
it runs them and saves the image only if green. Summarize what changed
(class >> selector list).
Genie returns full stack traces: failing block source, receiver, and its
variables. Read them. Reproduce with run_test, read/search tools, and the
smallest existing MCP call that exercises the behavior. Use eval only if the
needed probe cannot be expressed through a dedicated MCP tool; if you must use
it, make it minimal and non-mutating unless the task explicitly requires a
mutation. Fix the smallest thing the trace implicates, then re-run the test.
Don't guess.
ShiftClassInstaller / define_class), never the
deprecated subclass:instanceVariableNames:classVariableNames:package:.define_method, protocol tests.eval is always a last resort, never the default path.