Skip to content

Week 4 Reflection: Commands Capture Judgment

Goal: Explain what makes a custom slash command useful, safe, and reusable.

Time: 20–30 minutes.

This week, you moved from using OpenCode's built-in workflows to creating your own shortcuts. The important lesson is not "JSON config is neat." The important lesson is that a command captures a repeatable way of working.

What to Submit

Write a short reflection in your own words. Aim for 300–500 words total.

Use these headings:

  1. The Commands I Wrote
  2. The Command That Worked Best
  3. What Peer Testing Revealed
  4. My Rule for Writing Commands

Prompt 1: The Commands I Wrote

List the three commands you created in Lab 4.1.

For each one, include:

  • Command name.
  • Example invocation.
  • What it is supposed to do.
  • Whether it should be read-only or allowed to edit.

Example:

/explain-file lib/db.js
Purpose: Explain a file for a beginner.
Safety level: Read-only. It should not edit files.

If one command changed during peer testing, note the final version, not only the first draft.

Prompt 2: Which Command Worked Best?

Choose one command that worked well.

Answer these questions:

  • Why was the command useful?
  • What made the template clear?
  • Did $ARGUMENTS make it more flexible?
  • What output format did you ask for?

Good reflections are specific. Instead of saying "it was clear," explain what made it clear: order of steps, file path argument, approval language, output headings, or verification instructions.

Prompt 3: What Did Peer Testing Reveal?

Use your notes from Lab 4.2.

Answer these questions:

  • What did your peer expect the command to do?
  • Where did their expectation differ from yours?
  • What feedback did they give?
  • What did you change in the template?
  • Did the second run improve? How do you know?

Beginner-safe warning: do not treat peer confusion as failure. Confusion is data. It shows where your command was depending on hidden context.

Prompt 4: When Should You Not Write a Command?

Commands are useful, but not every prompt deserves one.

Explain one task that should not become a command.

Choose one reason:

  • It is a one-time task.
  • It needs deep judgment each time.
  • It is too broad.
  • It needs too many arguments.
  • It would be safer as a read-only review.
  • It belongs in a skill or custom agent later in the course.

Example:

I would not create /build-app because it is too broad. The agent would have to guess architecture, files, tests, and design choices. A better command would be narrower, like /component Button or /write-tests lib/db.js.

Prompt 5: Your Command-Writing Rule

Write your personal rule for creating future commands.

Your rule should mention:

  • Repetition: will you use it three or more times?
  • Scope: is the task narrow enough?
  • Arguments: is $ARGUMENTS clear?
  • Safety: should it use plan-like behavior or build-like behavior?
  • Verification: how will you know it worked?

Example:

I will write a command only after I have repeated the same prompt at least three times. The command must have a narrow purpose, a clear example invocation, and safety language that says whether edits are allowed. If it edits files, it must include approval and testing instructions.

Success Criteria

You are done when your reflection:

  • Names all three commands from Lab 4.1.
  • Describes one command that improved after peer testing.
  • Explains at least one hidden assumption your peer found.
  • Gives one example of a task that should not become a command.
  • States your personal rule for future commands.

Troubleshooting

Q: My commands did not work perfectly. Can I still complete the reflection? A: Yes. Write what failed and what you changed. Iteration is the point of Week 4.

Q: My peer did not find any problems. A: Ask whether the command would still be clear without your example. You can also test with a different argument or ask them what output format they would prefer.

Q: I only finished two commands. A: Finish the third before submitting if possible. If time is gone, explain what the third command would be and why it belongs in your workflow.

Q: I am not sure whether a command should use plan or build. A: Use this default: explanation, review, and reports should be plan-like; file creation, tests, and fixes may be build-like but must ask before editing.

Takeaway

Custom commands are not magic buttons. They are reusable decisions.

When you write a good command, you are teaching OpenCode how you want a repeated task handled: what context to inspect, what output to produce, when to ask permission, and how to verify the result.