Initial commit

commands/implement-tests.md

@@ -0,0 +1,5 @@
+Implement tests for features described in the documentation (`*.md`) and
+`plans/` directory changes - see changes with `git diff`.
+
+Note for this command, the documentation is driving the test code changes, not
+the other way around.

commands/implement.md

@@ -0,0 +1,8 @@
+Implement code changes for features described in the documentation (`*.md`) and
+`plans/` directory changes - see changes with `git diff`.
+
+Note for this command, the documentation is driving the code changes, not the
+other way around.
+
+After the plan is updated, update the plan with any changes and change the
+status in the plan file to `Implemented`.

commands/plan.md

@@ -0,0 +1,15 @@
+Create a plan file named `plans/<current date>-"$ARGUMENTS".md`. Replace spaces
+with '-' in the filename.
+
+If a plan already exists that has not be committed, then update that plan.
+
+Then switch to plan mode and create a plan for coding the current changes and
+untracked files (start with `git diff` and `git status`) described in the
+README.md and other documentation files. Note, in this phase, we are using
+documentation to drive the code, not the other way around. When the plan is
+complete, write it to the plan file.
+
+The documentation may be written in past tense as if the feature already exists.
+Assume any changes that have not been committed have not been implemented yet,
+even though they are described as already implemented. This is a side effect of
+documentation driven development.

commands/skip.md

@@ -0,0 +1 @@
+Skip this edit/command and continue what you were doing.

commands/update-docs.md

@@ -0,0 +1,11 @@
+Update any relevant documentation to accurately reflect the current code changes (`git diff`)
+and fill in any missing information. Some guidelines:
+
+- Be concise. AI tends to generate very verbose/wordy documentation. Don't do that.
+- Don't add trivial examples that users can easily figure out.
+- Avoid duplicated information when possible.
+
+Update `CLAUDE.md` with any architectural or technical details.
+
+Also, update the `CHANGELOG.md` to describe changes as benefits to the user. It should not
+include technical details of the change - that is what `git log` is for.