Refine development guidelines for improved code quality

Update the development guide to emphasize best practices including updating specifications during work, mandatory code formatting and linting, README updates for user-visible changes, and cleanup of unused code. This fosters consistent, high-quality contributions that enhance the project's reliability and maintainability.

AGENTS.md

@@ -136,6 +136,7 @@ mod tests {
 - Write code in appropriate modules following the hexagonal architecture
 - Keep core business logic separate from external integrations
 - Use workspace dependencies consistently
+- When working from a spec, update the spec with the current status as soon as you finish something
 
 ### 2. Testing
 - Write tests alongside code in `#[cfg(test)]` modules
@@ -148,15 +149,17 @@ mod tests {
 - Use `cargo fmt` for formatting
 - Use `cargo clippy` for linting
 - Ensure documentation for public APIs
-- _ALWAYS_ format and lint after making a change, and fix the linting errors
+- _ALWAYS_ format and lint after making a change, and fix linting errors and warnings
+- When a change is end-user visible, update the README.md. Use the README.md documentation guidelines
+- Always clean up unused code. No todo's or unused code is allowed after a change
 
 ### 4. Commit Standards
+- *Always* ensure the workspace compiles: `cargo build --workspace`
 - Commit both code and tests together
-- Write clear, descriptive commit messages
-- Ensure the workspace compiles: `cargo build --workspace`
+- Write clear, descriptive commit messages, focusing on user benefits over technical details. Use prose over bullet points
 
 ### Version Control
-- **Use JJ (Jujutsu)** as the primary tool for all source control operations due to its concurrency and conflict-free design
+- **Use JJ (Jujutsu)** as the primary tool for all source control operations due to its concurrency and conflict-free design. Use a specialized agent if available
 - **Git fallback**: Only for complex operations unsupported by JJ (e.g., interactive rebasing)
 
 ## Project Structure Guidelines
@@ -208,4 +211,4 @@ mod tests {
 ### Technical Documentation
 - **docs/architecture.md**: Detailed technical specifications, implementation details, and developer-focused content
 - **specs/**: Implementation planning, API specifications, and historical context
-- **Code Comments**: Use for implementation details and complex logic explanations
+- **Code Comments**: Use sparingly for implementation details. *Do* explain complex logic