How do I install the Remember Interactive Programming skill?

Run npx skillmds@latest add paulasilvatech/remember-interactive-programming-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Remember Interactive Programming safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Remember Interactive Programming?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Remember Interactive Programming free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Remember Interactive Programming?

paulasilvatech (@paulasilvatech) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Remember Interactive Programming by paulasilvatech

Name: Remember Interactive Programming
Author: paulasilvatech

Remember Interactive Programming

Remind the agent to work as an interactive programmer against a live system or REPL, using evaluated behavior as the source of truth, explaining hidden evaluations to the human, preferring structural editing, and maintaining a todo list. Use when a user wants REPL-driven programming guidance, especially for Clojure or Backseat Driver workflows.

File contents

Remember interactive programming

Work as an interactive programmer with a micro-prompt mindset: use the live system or REPL as the source of truth, make small evaluated changes, explain hidden tool evaluations succinctly, prefer structural editing, and keep the todo list current. Adapt the reminder with workflow and/or workspace specifics when the user provides them.

When to invoke

"Remember to use the REPL while programming."
"Work interactively against the running system."
"Use Backseat Driver or a live Clojure REPL for this change."
"Keep me informed about what you evaluate and maintain todos."

Interactive programming stance

Principle	Behavior
System as source of truth	Validate assumptions by evaluating code in the running system or REPL instead of relying only on static reading.
Small feedback loops	Explore, modify, evaluate, and adjust in short cycles.
Human-visible narration	The human does not see tool evaluations; summarize large evaluations before or after running them.
Structural editing	Prefer structural editing tools when editing languages such as Clojure where syntax trees matter.
Todo tending	Keep the todo list current so interactive exploration does not lose the goal.

REPL workflow

State the immediate question the REPL evaluation will answer.
Evaluate the smallest expression or code path that provides evidence.
If evaluating a large amount of code, describe succinctly what is being evaluated.
Use results from the live system to decide the next edit.
Prefer structural editing tools for code changes when available.
Re-evaluate the changed behavior and update the todo list.

Gotchas

Do not hide large evaluations: the human cannot see what the REPL tool evaluates, so summarize intent and outcome.
Do not treat files as the only truth: running state may contain loaded vars, data, routes, or configuration not obvious from source.
Do not let exploration sprawl: every evaluation should connect to a todo or current hypothesis.
Do not use text-only edits when structural editing is available and safer: preserve balanced forms and language structure.

Output template

## Interactive programming checkpoint

**Status:** exploring | changed | blocked
**Current hypothesis:** <what the live evaluation is testing>

| Evaluation or edit | Evidence from the system | Next todo |
| --- | --- | --- |
| `<REPL expression or structural edit summary>` | `<observed result>` | `<next action>` |

**Human-visible summary:** <succinct explanation of any large evaluation>

Quality gate

The live system or REPL was treated as the source of truth when available.
Large evaluations were described succinctly for the human.
Structural editing tools were preferred for structural code changes when available.
The todo list was maintained during exploration and implementation.
The final response reports what was learned from evaluated behavior, not only what was edited.

---name: remember-interactive-programming-2description: Remind the agent to work as an interactive programmer against a live system or REPL, using evaluated behavior as the source of truth, explaining hidden evaluations to the human, preferring structural editing, and maintaining a todo list. Use when a user wants REPL-driven programming guidance, especially for Clojure or Backseat Driver workflows.---# Remember interactive programmingWork as an interactive programmer with a micro-prompt mindset: use the live system or REPL as the source of truth, make small evaluated changes, explain hidden tool evaluations succinctly, prefer structural editing, and keep the todo list current. Adapt the reminder with workflow and/or workspace specifics when the user provides them.## When to invoke- "Remember to use the REPL while programming."- "Work interactively against the running system."- "Use Backseat Driver or a live Clojure REPL for this change."- "Keep me informed about what you evaluate and maintain todos."## Interactive programming stance| Principle | Behavior || --- | --- || System as source of truth | Validate assumptions by evaluating code in the running system or REPL instead of relying only on static reading. || Small feedback loops | Explore, modify, evaluate, and adjust in short cycles. || Human-visible narration | The human does not see tool evaluations; summarize large evaluations before or after running them. || Structural editing | Prefer structural editing tools when editing languages such as Clojure where syntax trees matter. || Todo tending | Keep the todo list current so interactive exploration does not lose the goal. |## REPL workflow1. State the immediate question the REPL evaluation will answer.2. Evaluate the smallest expression or code path that provides evidence.3. If evaluating a large amount of code, describe succinctly what is being evaluated.4. Use results from the live system to decide the next edit.5. Prefer structural editing tools for code changes when available.6. Re-evaluate the changed behavior and update the todo list.## Gotchas- **Do not hide large evaluations**: the human cannot see what the REPL tool evaluates, so summarize intent and outcome.- **Do not treat files as the only truth**: running state may contain loaded vars, data, routes, or configuration not obvious from source.- **Do not let exploration sprawl**: every evaluation should connect to a todo or current hypothesis.- **Do not use text-only edits when structural editing is available and safer**: preserve balanced forms and language structure.## Output template```markdown## Interactive programming checkpoint**Status:** exploring | changed | blocked**Current hypothesis:** <what the live evaluation is testing>| Evaluation or edit | Evidence from the system | Next todo || --- | --- | --- || `<REPL expression or structural edit summary>` | `<observed result>` | `<next action>` |**Human-visible summary:** <succinct explanation of any large evaluation>```## Quality gate- [ ] The live system or REPL was treated as the source of truth when available.- [ ] Large evaluations were described succinctly for the human.- [ ] Structural editing tools were preferred for structural code changes when available.- [ ] The todo list was maintained during exploration and implementation.- [ ] The final response reports what was learned from evaluated behavior, not only what was edited.

Frequently asked questions