chore(dev): add automated commit message generation workflow
Add jj-commit-message-generator agent and /sta:commit slash command to automate conventional commit message creation for STA project tasks. Features: - Agent analyzes jj diff and task specs to generate messages - Slash command provides simple interface: /sta:commit T020 - Follows project conventions and TDD workflow patterns - Uses lightweight Haiku model for fast generation
This commit is contained in:
58
.claude/commands/sta-commit.md
Normal file
58
.claude/commands/sta-commit.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# Generate and Set Commit Message for Task
|
||||
|
||||
Generate a conventional commit message for the specified task from specs/001-modbus-relay-control/tasks.md and set it on the current Jujutsu revision.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. Extract the task ID from the command argument (e.g., "T020" from `/sta:commit T020`)
|
||||
2. Read the task details from `specs/001-modbus-relay-control/tasks.md` to understand what was implemented
|
||||
3. Check the current working copy changes with `jj diff` to see what files were modified
|
||||
4. Use the `jj-commit-message-generator` agent via the Task tool with this prompt:
|
||||
|
||||
```
|
||||
Generate a conventional commit message for the current Jujutsu revision. I've just completed task {TASK_ID} from specs/001-modbus-relay-control/tasks.md, which involved {brief description from task}. Analyze the changes and generate an appropriate commit message following the project's TDD workflow conventions.
|
||||
```
|
||||
|
||||
5. After the agent generates the message, set it on the current revision using `jj describe -m "..."`
|
||||
6. Confirm to the user that the commit message has been set successfully
|
||||
|
||||
## Task Context
|
||||
|
||||
- Tasks are numbered like T001, T017, T020, etc.
|
||||
- Tasks follow TDD (Test-Driven Development):
|
||||
- Odd-numbered tasks (T017, T019, T021) are typically RED phase (failing tests)
|
||||
- Even-numbered tasks (T018, T020, T022) are typically GREEN phase (implementation)
|
||||
- Some tasks are marked with `[P]` indicating they can be done in parallel
|
||||
- Task descriptions include complexity, files to modify, and test requirements
|
||||
|
||||
## Commit Message Format
|
||||
|
||||
The agent should generate messages following this format:
|
||||
|
||||
```
|
||||
<type>(<scope>): <subject>
|
||||
|
||||
<body>
|
||||
|
||||
TDD phase: <red/green/refactor phase info if applicable>
|
||||
|
||||
Ref: {TASK_ID} (specs/001-modbus-relay-control/tasks.md)
|
||||
```
|
||||
|
||||
Where:
|
||||
- `type`: test, feat, refactor, docs, chore, fix
|
||||
- `scope`: domain, application, infrastructure, presentation, settings, middleware
|
||||
- `subject`: imperative mood, lowercase, no period, <72 chars
|
||||
- `body`: explain what and why, not how
|
||||
|
||||
## Usage Examples
|
||||
|
||||
```
|
||||
/sta:commit T020
|
||||
```
|
||||
|
||||
This would:
|
||||
1. Read T020 from tasks.md (implement RelayState enum)
|
||||
2. Analyze current changes
|
||||
3. Generate message like: `feat(domain): implement RelayState enum with serialization support`
|
||||
4. Set it on current revision
|
||||
41
.claude/commands/sta-rustdoc.md
Normal file
41
.claude/commands/sta-rustdoc.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# Add Missing Rust Documentation
|
||||
|
||||
Run cargo clippy to identify items missing documentation, then add appropriate doc comments to all flagged items.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. Run `cargo clippy --all-targets` to find missing documentation warnings
|
||||
2. Parse the output to identify all items (functions, structs, enums, modules, etc.) that need documentation
|
||||
3. For each missing doc comment:
|
||||
- Read the relevant file to understand the context
|
||||
- Add appropriate /// doc comments for public items
|
||||
- Add appropriate //! module-level doc comments where needed
|
||||
- Follow Rust documentation conventions:
|
||||
- First line is a brief summary (imperative mood: "Creates", "Returns", not "Create", "Return")
|
||||
- Add "# Errors" section for functions returning Result
|
||||
- Add "# Panics" section if function can panic
|
||||
- Add "# Examples" for complex public APIs
|
||||
- Use #[must_use] attribute where appropriate
|
||||
4. After adding all documentation, run cargo clippy again to verify no missing docs warnings remain
|
||||
5. Report summary of what was documented
|
||||
|
||||
## Documentation Style Guidelines
|
||||
|
||||
- Modules (//!): Describe the module's purpose and main types/functions
|
||||
- Structs/Enums: Describe what the type represents
|
||||
- Functions/Methods: Describe what it does, parameters, return value
|
||||
- Fields: Document public fields with ///
|
||||
- Keep it concise but informative
|
||||
- Use markdown formatting for code examples
|
||||
|
||||
## Example Output Format
|
||||
|
||||
After completion, report:
|
||||
|
||||
Added documentation to:
|
||||
- Module: src/domain/relay/entity.rs (module-level docs)
|
||||
- Struct: Relay (3 public methods documented)
|
||||
- Function: toggle() at src/domain/relay/entity.rs:XX
|
||||
|
||||
Total: X items documented
|
||||
Clippy warnings resolved: X
|
||||
Reference in New Issue
Block a user