A pottery workshop site lets members book sessions and receive confirmation. Adding rescheduling must preserve confirmation rules. Its maintainer wants to review exactly what changes and retain that decision; a direct label edit would need less documentation.
How: work toward a solution
Keep the current confirmation requirement. Propose a rescheduling rule, record its added scenario and tasks, review, implement, and check both behaviors. Reconcile the specification and archive the change.
A proposed rescheduling rule changes the spec while preserving confirmation
Archiving does not prove correct behavior. Keep specifications and code aligned; setup and artifact maintenance must be worthwhile.
What: the concept
OpenSpec organizes specifications and change artifacts for coding agents. Artifacts can be revised as understanding improves. It supports new projects too; maintained deltas and setup cost must justify its use.
This example prioritizes the difference between current behavior and a proposed change. OpenSpec keeps specifications and change artifacts that can evolve together. Spec Kit may fit a team prioritizing its specification-to-implementation process; Superpowers emphasizes repeatable execution skills. Existing instructions may suffice for a bounded correction. OpenSpec also supports new projects; “existing project” is an example, not a hard eligibility rule. Compare compatibility and maintenance cost rather than vendor claims about competing tools.
02Applications
The workshop already confirms each booking. The proposed rule allows a member to move a booking at least 24 hours before the session; this threshold is a fictional accepted product choice. Record the added rescheduling scenario while preserving confirmation behavior. The change contains a proposal, specification delta, design, and tasks. Check the accepted time boundary and unchanged confirmation behavior. Review synchronization of the delta into current specifications and keep the archived rationale.
03Implementation & cautions
In the external agent, inspect the current official installation and supported-tool documentation, runtime, project, and existing setup. Install only the selected scope under existing authority, initialize the appropriate integration, and review generated files. The CLI performs setup and artifact operations; the agent writes and applies the change through its installed workflow. Invocation spelling depends on the tool; use the form printed for the selected integration. Confirm an actual planning artifact was produced. Verification commands depend on the installed profile, so do not assume every optional command exists. Archiving or checked task boxes do not prove working behavior: run the project’s relevant checks and report gaps. Reuse these artifacts for kickoff’s planning and work records.
Already talking with external AI? Share this article link and explain why the choice fits your project and which tradeoff matters. Ask how it applies to your agreed requirements.
Discuss this idea
Comments are shared across languages. GitHub login required to post.