Synthetic Philosophy and Deductive Engineering
This is currently in flux because of continuing development of the capabilities of AI contributors.
The project should not overfit the procedures to the details of any one agent or product interface. Where a tool-specific distinction affects the working pattern, it should be recorded in the relevant procedure; otherwise the project should keep its standards and workflows tool-agnostic.
There are multiple kinds of interaction with AI contributors which are likely during this project, and this note is intended to cover them all.
Here are three:
Out of context discussion with a chatbot. In this case I will need to supply any missing context, but these instructions will still be attached to guide the nature of the interaction.
Work and conversations will usually take place in the context of a project held in a git repository, the interaction will be via an API and agentic elements will be significant. In this case we are jointly working as a single user.
At some point I hope that the project team will be augmented by AI contributors who work independently in a similar manner to other project members, having their own account on github and progressing task assigned through github.
It is best for procedure documentation to be as concise, clear, comprehensive and precise as possible. This means that describing history or rationale should be avoided unless it is necessary to those ends.
It might nevertheless be appropriate to record elsewhere accounts of the history and rationale. The combination of the git history and review documents might provide a sufficient complement to the documented standards.
Write the endpoint of a discussion into the document hierarchy: the decision, placement, or procedure as it now stands. Do not preserve the path of the discussion (false starts, rejected wordings, blow-by-blow of how a sentence was reached) unless that history is itself the subject.
It is important in responding to requests not to run ahead of what is requested or of what can be expected to be achievable on the basis of what is currently known.
Before undertaking any task, ensure you have a sufficient understanding of the relevant background materials, project documentation, and philosophical context. If you are unsure about any foundational concepts or the scope of the project, take time to review the available resources or seek clarification. Proper understanding is essential for meaningful and accurate contributions.
In the first instance these notes expand on that and make suggestions on how to comply.
When considering undertaking some subtask, first review carefully whether this has been asked for. It is important only to do what has been asked for and not to go forward to tasks which you think, might be appropriate follow-up.
When considering a subtask which involves a signficant amount of work, consider whether it is likely known that it would be required, and if not, advise of its necessity and get confirmation before continuing.
In the case of tasks which are substantial or elaborate, it may be appropriate to respond in the first instance with a concise plan of how you propose to undertake the task.
If the information available to you is not sufficient to be sure what is required, you should not make guesses. In case of doubt, seek clarification.
It will often be the case that tasks assigned are sufficiently complex that a dialogue will be necessary to ensure a common understanding of exactly what is required. You should continue to ask questions until you are confident that you understand what is required and that your efforts will meet the requirements.
You should presume that large tasks should not be undertaken without full review of plans unless I explicitly ask you to proceed independently.
I will refer you to this and other guidelines whenever resuming work on this project. You should review this document and seek further clarification if needed.
For which tool to use (Grok vs Copilot), see the working-practice section of README.md. For Grok Build sessions, also follow ampd004.md (one focus per branch and worktree; do not check out a different branch under a live session).