By Friday evening, November 28, I’d completed systematic evaluation.
All workflow files at exceptional quality. But the evaluation work had revealed something. Each assessment required the same conversation. Read file. Compare to template. Provide feedback. Iterate. Each time re-explaining context. Re-providing files. Re-stating criteria.
Manageable for one intensive day. But still overhead. And I could see having similar repetitive conversations in the future.
The Repetition Problem
Saturday morning, November 29, I decided to solve this problem for next time I needed to evaluate workers, coordinators, or documentation.
I had a base evaluation command. It evaluated files in any directory. But using it required this sequence:
- Run the command with directory path
- Tell it to read the standards file first
- Tell it which files to evaluate
- Tell it to compare with the assessment file after
- Review the results
Same sequence I’d used dozens of times during yesterday’s work. Same context explanation. Same file references. Same instruction sequence.
And I kept forgetting pieces. This was the fifth time in a week I’d forgotten to mention the standards file until after the evaluation had already started.
Context overhead remained.
The Wrong Tools
I had two tools for working on these tasks.
Chat: Interactive conversation. Flexible. But required explaining context every time.
Workflows: Full automation. Agents handling everything. But heavy. Not suitable for iterative exploration.
The base evaluation command was closer. But it still required too much manual context provision each time.
The Pattern Discovery
Saturday afternoon, I looked at how the base evaluation command worked.
It was general-purpose. You give it a directory, and it evaluates all files in that directory. Flexible. Reusable. But requiring context each time.
But I wasn’t evaluating random directories. I was evaluating specific file types repeatedly:
- Coordinator files (always in the coordinator directory, always using coordinator standards, always comparing to coordinator assessment)
- Worker files (always in the worker directory, always using worker standards, always comparing to worker assessment)
- Documentation files (always in the documentation directory, always using documentation standards, always comparing to documentation assessment)
The context was predictable. The same for each file type, every time.
What if I created specialized commands that extended the base command? Each specialized command would just call the base command but with all the context pre-configured.
A wrapper pattern. The specialized command wraps the base command, providing all the arguments and context automatically.
Building the Specialized Commands
Saturday afternoon, I created three specialized commands.
Each command extended the base evaluation command:
Coordinator evaluation command:
Call base evaluation command with:
- Directory: coordinator directory path
- Instructions: "first read coordinator standards file,
then evaluate all coordinator files across all workflows,
then compare with coordinator assessment file"
Worker evaluation command:
Call base evaluation command with:
- Directory: worker directory path
- Instructions: "first read worker standards file,
then evaluate all worker files across all workflows,
then compare with worker assessment file"
Documentation evaluation command:
Call base evaluation command with:
- Directory: documentation directory path
- Instructions: "first read documentation standards file,
then evaluate all documentation files across all workflows,
then compare with documentation assessment file"
All the context I’d been manually providing was now built into the specialized commands.
The base command remained general-purpose. The specialized commands provided domain-specific context.
Testing the Pattern
Saturday evening, I tested one of the specialized commands.
I ran the coordinator evaluation command. Just the command name. No arguments. No context.
The command automatically called the base evaluation command with all context provided. Evaluated files. Presented findings.
No manual context provision. No forgotten pieces.
The Command Extension Pattern
This created a reusable pattern:
Base command: General-purpose functionality. Takes arguments. Flexible.
Specialized commands: Domain-specific wrappers. Pre-configure all arguments and context. Call base command.
The base command doesn’t change. It remains general-purpose and reusable.
The specialized commands eliminate context overhead for repeated use cases.
One base command. Multiple specialized extensions. Each extension captures a specific repetitive pattern.
Applying the Pattern Elsewhere
Saturday evening, I recognized this pattern could apply to other repetitive tasks.
I had another base command for running workflow scripts. It needed significant context: workflow path, test repository paths, configuration settings, environment setup.
I created a specialized command that extended it. The specialized command pre-loaded all the context.
Same pattern. Base command stayed general-purpose. Specialized command eliminated context overhead.
The pattern was broadly applicable. Any time you have a general-purpose base command with repetitive use and predictable context, you can create a specialized wrapper.
When to Use the Pattern
The extension pattern works when:
Base command exists: You have a working general-purpose command.
Repetitive use: You use it multiple times with similar context.
Predictable context: The context is the same each time for a specific use case.
Don’t use the pattern when context varies significantly each time or when use is infrequent enough that overhead doesn’t matter.
What I Learned
First, command extension is a reusable pattern. Base command for general use. Specialized wrappers for repetitive contexts.
Second, one base command can support multiple specialized extensions. Each extension captures a different repetitive pattern.
Third, the pattern applies broadly. Evaluation commands. Workflow script commands. Any repetitive task with predictable context.
Fourth, keep base commands general-purpose. Don’t compromise flexibility for specific use cases. Extensions handle specificity.
The Pattern Established
Saturday evening, November 29, I’d created specialized evaluation commands that extended the base command with pre-configured context.
The overhead of manual context provision was eliminated. The risk of forgetting pieces was gone. The cognitive load was handled by the specialized commands.
The command extension pattern had become my approach for repetitive tasks. Base commands stay general. Specialized commands eliminate overhead.
And the pattern applied beyond evaluation. Any repetitive task with predictable context could use the same approach.
After the holiday break, I’d find another instance where this pattern helped me in finalizing the testing of the workflows.
Next: Testing Tracker