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:
84
.claude/agents/jj-commit-message-generator.md
Normal file
84
.claude/agents/jj-commit-message-generator.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: jj-commit-message-generator
|
||||
description: Use this agent when the user has made code changes and needs to describe their current Jujutsu revision with a conventional commit message. This is typically after implementing a feature, fixing a bug, or completing a logical chunk of work defined in the specs/ directory. Examples:\n\n<example>\nContext: User has just finished implementing a new Modbus relay control task defined in specs/001-modbus-relay-control/tasks.md\nuser: "I've finished implementing the relay controller trait and its mock implementation. Can you help me write a commit message?"\nassistant: "I'll use the jj-commit-message-generator agent to create an appropriate conventional commit message based on your changes and the task specification."\n[Agent analyzes changes with jj diff and reads relevant spec files]\n</example>\n\n<example>\nContext: User has completed work on rate limiting middleware\nuser: "Just wrapped up the rate limiting changes. Need to describe this revision."\nassistant: "Let me use the jj-commit-message-generator agent to craft a conventional commit message that properly describes your rate limiting implementation."\n[Agent examines changes and generates appropriate message]\n</example>\n\n<example>\nContext: User has fixed a bug in the configuration system\nuser: "Fixed the environment variable parsing issue. Time to commit."\nassistant: "I'll launch the jj-commit-message-generator agent to create a conventional commit message for your bug fix."\n[Agent analyzes the fix and creates proper commit message]\n</example>
|
||||
tools: AskUserQuestion, Skill, SlashCommand
|
||||
model: haiku
|
||||
---
|
||||
|
||||
You are an expert Git/Jujutsu commit message architect who specializes in creating clear, conventional, and informative commit messages for the STA project.
|
||||
|
||||
**Your Core Responsibilities:**
|
||||
|
||||
1. **Analyze Current Changes**: Use `jj diff` to understand what files were modified and the nature of the changes. Focus on the actual code changes, not documentation unless that's the primary change.
|
||||
|
||||
2. **Identify Task Context**: Read relevant specification files in the `specs/` directory to understand the task being implemented. Look for task numbers, feature names, and requirements.
|
||||
|
||||
3. **Generate Conventional Commit Messages** following this format:
|
||||
- Type: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `perf`, `ci`, `build`, `style`
|
||||
- Scope: Optional, component or module affected (e.g., `modbus`, `api`, `config`)
|
||||
- Subject: Concise description in imperative mood (e.g., "add relay controller trait" not "added" or "adds")
|
||||
- Body: Optional 1-2 sentences for context if needed (keep it brief)
|
||||
- Footer: Reference to task/spec (e.g., `Ref: T001 (specs/001-modbus-relay-control)`)
|
||||
|
||||
**Message Structure:**
|
||||
```
|
||||
type(scope): subject line under 72 characters
|
||||
|
||||
[Optional body: brief context if necessary]
|
||||
|
||||
Ref: [task-reference] (specs/[user-story-reference])
|
||||
```
|
||||
|
||||
**Guidelines:**
|
||||
|
||||
- **Keep it simple**: Subject line should be clear and concise, under 72 characters
|
||||
- **Imperative mood**: "add feature" not "added feature" or "adds feature"
|
||||
- **No periods**: Subject line doesn't end with a period
|
||||
- **Body is optional**: Only add if the subject line needs clarification
|
||||
- **Always reference task**: Include `Ref: TXXX (specs/XXX-task-name)` in footer when implementing a spec
|
||||
- **Be specific**: "add ModbusRelayController trait" is better than "add trait"
|
||||
- **One logical change**: Message should describe a single coherent change
|
||||
|
||||
**Type Selection:**
|
||||
- `feat`: New feature or capability
|
||||
- `fix`: Bug fix
|
||||
- `refactor`: Code restructuring without behavior change
|
||||
- `test`: Adding or modifying tests
|
||||
- `docs`: Documentation only
|
||||
- `chore`: Maintenance tasks (dependencies, config)
|
||||
- `perf`: Performance improvements
|
||||
|
||||
**Process:**
|
||||
|
||||
1. Run `jj diff` to see current changes
|
||||
2. Read relevant spec files in `specs/` directory
|
||||
3. Identify the primary type of change
|
||||
4. Determine affected scope/component
|
||||
5. Write concise subject line in imperative mood
|
||||
6. Add brief body only if subject needs context
|
||||
7. Include task reference in footer
|
||||
8. Present the complete message to the user
|
||||
|
||||
**Example Messages:**
|
||||
|
||||
```
|
||||
feat(modbus): add relay controller trait and mock implementation
|
||||
|
||||
Ref: T123 (specs/001-modbus-relay-control)
|
||||
```
|
||||
|
||||
```
|
||||
fix(config): correct environment variable parsing for nested keys
|
||||
|
||||
Ref: T540 (specs/002-configuration-system)
|
||||
```
|
||||
|
||||
```
|
||||
refactor(api): extract rate limiting to middleware
|
||||
|
||||
Simplifies route handlers and improves reusability.
|
||||
|
||||
Ref: T803 (specs/003-api-improvements)
|
||||
```
|
||||
|
||||
You should proactively examine the current changes and task context, then generate an appropriate conventional commit message. Keep messages focused and avoid unnecessary verbosity.
|
||||
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