@eldrforge/kodrdriv 0.0.14 → 0.0.17
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +1 -9
- package/dist/arguments.js +306 -55
- package/dist/arguments.js.map +1 -1
- package/dist/audio/devices.js +284 -0
- package/dist/audio/devices.js.map +1 -0
- package/dist/audio/index.js +31 -0
- package/dist/audio/index.js.map +1 -0
- package/dist/audio/processor.js +766 -0
- package/dist/audio/processor.js.map +1 -0
- package/dist/audio/types.js +16 -0
- package/dist/audio/types.js.map +1 -0
- package/dist/audio/validation.js +35 -0
- package/dist/audio/validation.js.map +1 -0
- package/dist/commands/audio-commit.js +64 -248
- package/dist/commands/audio-commit.js.map +1 -1
- package/dist/commands/audio-review.js +90 -701
- package/dist/commands/audio-review.js.map +1 -1
- package/dist/commands/commit.js +18 -18
- package/dist/commands/commit.js.map +1 -1
- package/dist/commands/release.js +14 -15
- package/dist/commands/release.js.map +1 -1
- package/dist/commands/review.js +152 -0
- package/dist/commands/review.js.map +1 -0
- package/dist/commands/select-audio.js +265 -0
- package/dist/commands/select-audio.js.map +1 -0
- package/dist/constants.js +86 -68
- package/dist/constants.js.map +1 -1
- package/dist/content/diff.js +155 -1
- package/dist/content/diff.js.map +1 -1
- package/dist/content/issues.js +256 -0
- package/dist/content/issues.js.map +1 -0
- package/dist/content/releaseNotes.js +90 -0
- package/dist/content/releaseNotes.js.map +1 -0
- package/dist/main.js +9 -2
- package/dist/main.js.map +1 -1
- package/dist/prompt/instructions/commit.md +18 -15
- package/dist/prompt/instructions/release.md +6 -5
- package/dist/prompt/instructions/{audio-review.md → review.md} +24 -18
- package/dist/prompt/prompts.js +87 -19
- package/dist/prompt/prompts.js.map +1 -1
- package/dist/types.js +27 -3
- package/dist/types.js.map +1 -1
- package/dist/util/general.js +7 -1
- package/dist/util/general.js.map +1 -1
- package/dist/util/openai.js +34 -3
- package/dist/util/openai.js.map +1 -1
- package/dist/util/stdin.js +61 -0
- package/dist/util/stdin.js.map +1 -0
- package/package.json +6 -6
- package/.kodrdriv/config.yaml +0 -20
- package/.kodrdriv/context/content.md +0 -7
- package/RELEASE_NOTES.md +0 -14
- package/docs/index.html +0 -17
- package/docs/package.json +0 -36
- package/docs/pnpm-lock.yaml +0 -3441
- package/docs/public/README.md +0 -132
- package/docs/public/advanced-usage.md +0 -188
- package/docs/public/code-icon.svg +0 -4
- package/docs/public/commands.md +0 -116
- package/docs/public/configuration.md +0 -274
- package/docs/public/examples.md +0 -352
- package/docs/public/kodrdriv-logo.svg +0 -62
- package/docs/src/App.css +0 -387
- package/docs/src/App.tsx +0 -60
- package/docs/src/components/DocumentPage.tsx +0 -56
- package/docs/src/components/ErrorMessage.tsx +0 -15
- package/docs/src/components/LoadingSpinner.tsx +0 -14
- package/docs/src/components/MarkdownRenderer.tsx +0 -56
- package/docs/src/components/Navigation.css +0 -73
- package/docs/src/components/Navigation.tsx +0 -36
- package/docs/src/index.css +0 -61
- package/docs/src/main.tsx +0 -10
- package/docs/src/test/setup.ts +0 -1
- package/docs/src/vite-env.d.ts +0 -10
- package/docs/tsconfig.node.json +0 -13
- package/docs/vite.config.ts +0 -15
- package/docs/vitest.config.ts +0 -15
- package/eslint.config.mjs +0 -83
- package/nodemon.json +0 -14
- package/output/kodrdriv/250701-1442-release-notes.md +0 -3
- package/pnpm-workspace.yaml +0 -5
- package/tsconfig.tsbuildinfo +0 -1
- package/vite.config.ts +0 -90
- package/vitest.config.ts +0 -24
package/docs/public/README.md
DELETED
|
@@ -1,132 +0,0 @@
|
|
|
1
|
-
# KodrDriv
|
|
2
|
-
|
|
3
|
-
KodrDriv is a powerful utility designed to automatically generate intelligent release notes and commit messages from your Git repository. It analyzes commit history, pull requests, and related metadata to create comprehensive, well-structured documentation of your project's evolution. By leveraging advanced AI-powered analysis, it helps teams maintain clear visibility into their codebase's development history while reducing the manual effort typically required for changelog maintenance.
|
|
4
|
-
|
|
5
|
-
## What is KodrDriv?
|
|
6
|
-
|
|
7
|
-
KodrDriv is an AI-powered Git workflow automation tool designed to solve the common problem of writing meaningful commit messages and release notes. It provides a unified way to:
|
|
8
|
-
|
|
9
|
-
- **Generate intelligent commit messages** from your code changes
|
|
10
|
-
- **Create comprehensive release notes** automatically from Git history
|
|
11
|
-
- **Automate the entire release process** with pull request and GitHub integration
|
|
12
|
-
- **Manage workspace dependencies** for monorepo and multi-package development
|
|
13
|
-
- **Maintain consistent documentation** with minimal manual effort
|
|
14
|
-
|
|
15
|
-
## Why KodrDriv?
|
|
16
|
-
|
|
17
|
-
Writing good commit messages and release notes is time-consuming and often done when you're least in the mood for reflection. **KodrDriv was created specifically to solve the "context switch" problem that happens when you've been deep in code and Git asks you to summarize what you've done.**
|
|
18
|
-
|
|
19
|
-
Without KodrDriv, you need to manually:
|
|
20
|
-
- Stop your flow to write commit messages
|
|
21
|
-
- Remember all the changes you made across multiple files
|
|
22
|
-
- Craft meaningful release notes from scattered commit messages
|
|
23
|
-
- Coordinate complex release workflows with multiple steps
|
|
24
|
-
|
|
25
|
-
KodrDriv reads your code changes and Git history to automatically generate contextual, meaningful documentation that reflects your actual work.
|
|
26
|
-
|
|
27
|
-
## Installation
|
|
28
|
-
|
|
29
|
-
Install KodrDriv globally using npm:
|
|
30
|
-
|
|
31
|
-
```bash
|
|
32
|
-
npm install -g @eldrforge/kodrdriv
|
|
33
|
-
```
|
|
34
|
-
|
|
35
|
-
This will make the `kodrdriv` command available globally on your system.
|
|
36
|
-
|
|
37
|
-
## Quick Start
|
|
38
|
-
|
|
39
|
-
Here's how to get started with KodrDriv:
|
|
40
|
-
|
|
41
|
-
### Generate a Commit Message
|
|
42
|
-
|
|
43
|
-
```bash
|
|
44
|
-
# Make some changes to your code
|
|
45
|
-
git add .
|
|
46
|
-
kodrdriv commit
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
### Generate Release Notes
|
|
50
|
-
|
|
51
|
-
```bash
|
|
52
|
-
# Generate release notes from your recent changes
|
|
53
|
-
kodrdriv release
|
|
54
|
-
```
|
|
55
|
-
|
|
56
|
-
### Automate Your Release Process
|
|
57
|
-
|
|
58
|
-
```bash
|
|
59
|
-
# Fully automated release with dependency updates, PR creation, and GitHub release
|
|
60
|
-
kodrdriv publish
|
|
61
|
-
```
|
|
62
|
-
|
|
63
|
-
### Link Local Packages for Development
|
|
64
|
-
|
|
65
|
-
```bash
|
|
66
|
-
# Automatically link workspace packages for local development
|
|
67
|
-
kodrdriv link --scope-roots '{"@company": "../"}'
|
|
68
|
-
```
|
|
69
|
-
|
|
70
|
-
## Key Features
|
|
71
|
-
|
|
72
|
-
### AI-Powered Analysis
|
|
73
|
-
Uses OpenAI models to understand your code changes and generate contextual commit messages and release notes.
|
|
74
|
-
|
|
75
|
-
### Comprehensive Release Automation
|
|
76
|
-
The `publish` command handles dependency updates, version bumping, PR creation, status checks, merging, and GitHub releases.
|
|
77
|
-
|
|
78
|
-
### Intelligent Workspace Management
|
|
79
|
-
Automatically discovers and links related packages in monorepos and multi-package projects.
|
|
80
|
-
|
|
81
|
-
### Flexible Configuration
|
|
82
|
-
Supports hierarchical configuration with command-line overrides, config files, and environment variables.
|
|
83
|
-
|
|
84
|
-
### Custom Instructions
|
|
85
|
-
Extend or replace default AI instructions to match your project's specific conventions and requirements.
|
|
86
|
-
|
|
87
|
-
## Documentation
|
|
88
|
-
|
|
89
|
-
📚 **Complete Documentation**
|
|
90
|
-
|
|
91
|
-
**Quick Links:**
|
|
92
|
-
- [Commands](docs/public/commands.md) - Detailed documentation of all commands (commit, release, publish, link)
|
|
93
|
-
- [Configuration](docs/public/configuration.md) - All configuration options, hierarchical config, and environment variables
|
|
94
|
-
- [Advanced Usage](docs/public/advanced-usage.md) - Custom instructions, context, prompt structure, and advanced features
|
|
95
|
-
- [Examples](docs/public/examples.md) - Practical usage examples and common workflows
|
|
96
|
-
|
|
97
|
-
## Basic Command Options
|
|
98
|
-
|
|
99
|
-
- `--dry-run`: Perform a dry run without saving files
|
|
100
|
-
- `--verbose`: Enable verbose logging
|
|
101
|
-
- `--debug`: Enable debug logging
|
|
102
|
-
- `--check-config`: Display current configuration hierarchy
|
|
103
|
-
- `--version`: Display version information
|
|
104
|
-
|
|
105
|
-
For complete command-line options and detailed usage, see the [Configuration Documentation](docs/public/configuration.md).
|
|
106
|
-
|
|
107
|
-
## Environment Variables
|
|
108
|
-
|
|
109
|
-
KodrDriv requires OpenAI API credentials for AI-powered features:
|
|
110
|
-
|
|
111
|
-
- `OPENAI_API_KEY`: OpenAI API key (required)
|
|
112
|
-
- `GITHUB_TOKEN`: Required for publish command and GitHub operations
|
|
113
|
-
|
|
114
|
-
## Contributing
|
|
115
|
-
|
|
116
|
-
We welcome contributions! Please see our [Contributing Guide](CONTRIBUTING.md) for details.
|
|
117
|
-
|
|
118
|
-
## License
|
|
119
|
-
|
|
120
|
-
Apache-2.0 - see [LICENSE](LICENSE) file for details.
|
|
121
|
-
|
|
122
|
-
## About the Name
|
|
123
|
-
|
|
124
|
-
Ski carving and efficient software development have a lot in common. Carving uses edge control to follow a smooth, energy-efficient arc — just like automation uses clean, repeatable scripts to replace manual work. Both are about flow: linking turns or commits without hesitation. As carving unlocks speed and control, automation unlocks scalability and momentum. The result is clean tracks — razor-thin arcs on snow, or tidy diffs in code. And when you've mastered your craft, you don't stop to think about your last move. Your code leaves a clean trail — and your commit message can be automated straight from the diff.
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
@@ -1,188 +0,0 @@
|
|
|
1
|
-
# Advanced Usage
|
|
2
|
-
|
|
3
|
-
This section covers advanced features and customization options for KodrDriv.
|
|
4
|
-
|
|
5
|
-
## Custom Instructions
|
|
6
|
-
|
|
7
|
-
KodrDriv comes with default instructions that guide the AI in generating release notes or change logs. These instructions can be customized to match your project's specific needs and conventions.
|
|
8
|
-
|
|
9
|
-
### Default Instructions
|
|
10
|
-
|
|
11
|
-
The default instructions are defined in the source code:
|
|
12
|
-
|
|
13
|
-
- **Commit Instructions**: The default instructions for commit message generation are defined in [src/prompt/instructions/commit.ts](https://github.com/eldrforge/kodrdriv/blob/main/src/prompt/instructions/commit.ts).
|
|
14
|
-
|
|
15
|
-
- **Release Instructions**: The default instructions for release notes generation are defined in [src/prompt/instructions/release.ts](https://github.com/eldrforge/kodrdriv/blob/main/src/prompt/instructions/release.ts).
|
|
16
|
-
|
|
17
|
-
These instruction files contain detailed guidelines for the AI on how to format and structure the output, including examples and specific requirements for different types of changes.
|
|
18
|
-
|
|
19
|
-
### Customizing Instructions
|
|
20
|
-
|
|
21
|
-
You can override these default instructions in several ways:
|
|
22
|
-
|
|
23
|
-
1. **Command Line Option**: Use the `--instructions` flag to specify a custom instructions file:
|
|
24
|
-
```bash
|
|
25
|
-
kodrdriv --instructions ./my-custom-instructions.txt
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
2. **Default Location**: Even without specifying a command line option, KodrDriv will automatically look for an instructions file at `./.kodrdriv/instructions.md` in your current working directory.
|
|
29
|
-
|
|
30
|
-
3. **File Format**: While the default file is named `instructions.md`, you can use any text file with any extension. The content doesn't have to be in Markdown format - any plain text content will work. This gives you flexibility to use your preferred text editor or format for writing instructions.
|
|
31
|
-
|
|
32
|
-
### Extending Default Instructions
|
|
33
|
-
|
|
34
|
-
The configuration directory (configDir) allows you to further customize both commit and release instructions by adding pre and post content to the default instructions. This is done by creating additional files in your `.kodrdriv/instructions` directory:
|
|
35
|
-
|
|
36
|
-
#### Release Instructions
|
|
37
|
-
1. **Pre-Content**: Create a file named `release-pre.md` to add content that will be prepended to the default release instructions.
|
|
38
|
-
2. **Post-Content**: Create a file named `release-post.md` to add content that should be appended to the default release instructions.
|
|
39
|
-
|
|
40
|
-
#### Commit Instructions
|
|
41
|
-
1. **Pre-Content**: Create a file named `commit-pre.md` to add content that will be prepended to the default commit instructions.
|
|
42
|
-
2. **Post-Content**: Create a file named `commit-post.md` to add content that should be appended to the default commit instructions.
|
|
43
|
-
|
|
44
|
-
For example, if you want to add specific formatting requirements before the default release instructions, you could create `.kodrdriv/instructions/release-pre.md`, and if you want to add instructions to the end of the commit instructions, you would have a file in `.kodrdriv/instructions/commit-post.md`.
|
|
45
|
-
|
|
46
|
-
### Overriding Default Instructions
|
|
47
|
-
|
|
48
|
-
While the pre and post content files provide a way to extend the default instructions, you can also completely replace them by creating either `commit.md` or `release.md` in your `.kodrdriv/instructions` directory. This gives you full control over the instruction content.
|
|
49
|
-
|
|
50
|
-
However, please note that completely replacing the default instructions should be done with caution. The default instructions are carefully crafted to:
|
|
51
|
-
- Ensure consistent formatting
|
|
52
|
-
- Maintain proper context awareness
|
|
53
|
-
- Follow best practices for commit messages and release notes
|
|
54
|
-
- Handle edge cases and special scenarios
|
|
55
|
-
|
|
56
|
-
By replacing these instructions entirely, you may lose these benefits and potentially create inconsistencies in your documentation. It's recommended to use the pre and post content files to extend the default instructions rather than replacing them entirely, unless you have a specific need to do so.
|
|
57
|
-
|
|
58
|
-
To enable instruction overrides, you'll need to use the `--overrides` flag when running the command.
|
|
59
|
-
|
|
60
|
-
## Context
|
|
61
|
-
|
|
62
|
-
KodrDriv can use contextual information about your project to generate more meaningful commit messages and release notes. Context is provided through Markdown files stored in a dedicated directory.
|
|
63
|
-
|
|
64
|
-
### Context Directory Structure
|
|
65
|
-
|
|
66
|
-
The structure of your context directory is entirely up to you. There are no strict requirements for how you organize your context files - you can structure them in whatever way makes the most sense for your project and team.
|
|
67
|
-
|
|
68
|
-
Here are two example approaches to organizing context files:
|
|
69
|
-
|
|
70
|
-
#### Hierarchical Structure Example
|
|
71
|
-
|
|
72
|
-
You can organize context in a hierarchical structure with subdirectories for different categories:
|
|
73
|
-
|
|
74
|
-
```
|
|
75
|
-
.kodrdriv/context/
|
|
76
|
-
├── context.md # Main context file describing sections
|
|
77
|
-
├── people/ # Directory for information about people
|
|
78
|
-
│ ├── context.md # Description of the people section
|
|
79
|
-
│ ├── team-members.md # Information about team members
|
|
80
|
-
│ └── contributors.md # Information about contributors
|
|
81
|
-
├── projects/ # Directory for project information
|
|
82
|
-
│ ├── context.md # Description of the projects section
|
|
83
|
-
│ └── project-details.md # Details about various projects
|
|
84
|
-
└── technologies/ # Directory for technical information
|
|
85
|
-
├── context.md # Description of the technologies section
|
|
86
|
-
├── frameworks.md # Information about frameworks used
|
|
87
|
-
└── libraries.md # Information about libraries used
|
|
88
|
-
```
|
|
89
|
-
|
|
90
|
-
#### Individual Records Example
|
|
91
|
-
|
|
92
|
-
Alternatively, you can use a flatter structure with individual files for each entity:
|
|
93
|
-
|
|
94
|
-
```
|
|
95
|
-
.kodrdriv/context/
|
|
96
|
-
├── context.md # Main context file describing sections
|
|
97
|
-
├── people/ # Directory for individual people information
|
|
98
|
-
│ ├── context.md # Description of the people section
|
|
99
|
-
│ ├── john-doe.md # Information specific to John Doe
|
|
100
|
-
│ ├── jane-smith.md # Information specific to Jane Smith
|
|
101
|
-
│ └── alex-johnson.md # Information specific to Alex Johnson
|
|
102
|
-
```
|
|
103
|
-
|
|
104
|
-
Choose the organization that works best for your needs. The system will process the context files regardless of the structure, as long as they follow the basic Markdown formatting guidelines.
|
|
105
|
-
|
|
106
|
-
### Main Context File
|
|
107
|
-
|
|
108
|
-
The `context.md` file in each directory serves as an introduction to that section. The system loads this file first to understand the structure of the information. For example, a `context.md` file in the people directory might look like:
|
|
109
|
-
|
|
110
|
-
```markdown
|
|
111
|
-
## People
|
|
112
|
-
|
|
113
|
-
This section contains subsections that have information about people.
|
|
114
|
-
```
|
|
115
|
-
|
|
116
|
-
### Context Files
|
|
117
|
-
|
|
118
|
-
After loading the `context.md` file, the system reads all other Markdown files in the directory. It uses the first header in each file as the name of the section or subsection. For example:
|
|
119
|
-
|
|
120
|
-
```markdown
|
|
121
|
-
## Team Members
|
|
122
|
-
|
|
123
|
-
- John Doe: Lead Developer, focuses on backend systems
|
|
124
|
-
- Jane Smith: UX Designer, specializes in responsive interfaces
|
|
125
|
-
- Alex Johnson: DevOps Engineer, manages deployment pipelines
|
|
126
|
-
```
|
|
127
|
-
|
|
128
|
-
### Context Location
|
|
129
|
-
|
|
130
|
-
You can specify where to store your context files in two recommended ways:
|
|
131
|
-
|
|
132
|
-
1. **Project Directory**: Store context files in your project repository at `.kodrdriv/context/`. This is useful when the context is specific to the project and should be versioned with the code.
|
|
133
|
-
|
|
134
|
-
2. **gitignore Directory**: Alternatively, you can store context in your `.gitignore` directory if you want to keep it separate from your project files or if the context contains sensitive information that shouldn't be committed to the repository.
|
|
135
|
-
|
|
136
|
-
To specify a custom context directory, use the `--context-dir` option:
|
|
137
|
-
|
|
138
|
-
```bash
|
|
139
|
-
kodrdriv commit --context-dir ~/my-custom-context
|
|
140
|
-
```
|
|
141
|
-
|
|
142
|
-
By default, KodrDriv looks for context in the `.kodrdriv/context` directory within your project.
|
|
143
|
-
|
|
144
|
-
## Prompt Structure
|
|
145
|
-
|
|
146
|
-
When KodrDriv sends a request to the LLM, it structures the prompt using XML-like tags to organize different components of the input. The prompt is composed of three main sections:
|
|
147
|
-
|
|
148
|
-
```
|
|
149
|
-
<instructions>
|
|
150
|
-
[Your custom instructions or the default instructions]
|
|
151
|
-
</instructions>
|
|
152
|
-
|
|
153
|
-
<log>
|
|
154
|
-
[Git log output if --content-types includes 'log']
|
|
155
|
-
</log>
|
|
156
|
-
|
|
157
|
-
<diff>
|
|
158
|
-
[Git diff output if --content-types includes 'diff']
|
|
159
|
-
</diff>
|
|
160
|
-
```
|
|
161
|
-
|
|
162
|
-
Each section serves a specific purpose:
|
|
163
|
-
- `<instructions>`: Contains the guidance for the LLM on how to format and structure the output
|
|
164
|
-
- `<log>`: Contains the git log output, providing commit history and messages
|
|
165
|
-
- `<diff>`: Contains the git diff output, showing the actual code changes
|
|
166
|
-
|
|
167
|
-
## About the Name
|
|
168
|
-
|
|
169
|
-
Ski carving and efficient software development have a lot in common. Carving uses edge control to follow a smooth, energy-efficient arc — just like automation uses clean, repeatable scripts to replace manual work. Both are about flow: linking turns or commits without hesitation. As carving unlocks speed and control, automation unlocks scalability and momentum. The result is clean tracks — razor-thin arcs on snow, or tidy diffs in code. And when you've mastered your craft, you don't stop to think about your last move. Your code leaves a clean trail — and your commit message can be automated straight from the diff. And — snowboarders carve too. Different board, same beauty. We won't hold it against you if you're dropping clean edges on a single plank.
|
|
170
|
-
|
|
171
|
-
## Origin Story: kodrdriv
|
|
172
|
-
|
|
173
|
-
It always happened at the same moment.
|
|
174
|
-
|
|
175
|
-
You've just spent the entire day in a flow state — the kind that only comes when everything clicks. Whether it was writing code for a critical feature or hammering out chapters of a Markdown or AsciiDoc book, you were locked in. Maybe you were racing the clock to hit a deadline. Maybe you were just up late trying to carve something beautiful out of nothing. Either way, you went right up to the wire, focused, dialed in, exhausted but satisfied.
|
|
176
|
-
|
|
177
|
-
And then… Git hits you with the meta-question:
|
|
178
|
-
"What did you do?"
|
|
179
|
-
|
|
180
|
-
That one prompt — to sum it all up in a commit message — feels totally out of place. It asks you to stop, zoom out, and articulate everything you've just done, right when your brain is at its least reflective. You're not in summary mode. You're still in it. Still shaping. Still carving.
|
|
181
|
-
|
|
182
|
-
And that's the thing: it sounds silly, like it shouldn't be a real problem. But every developer, every writer who lives in Git knows that exact moment. The friction is real. The context switch is jarring. It's like being asked to narrate your entire ski run after you've blasted through powder, dodged trees, hit the cliff drop — and now you're out of breath, standing at the bottom, being asked to give a PowerPoint.
|
|
183
|
-
|
|
184
|
-
That's why I built kodrdriv.
|
|
185
|
-
|
|
186
|
-
It's not just a tool — it's a mindset shift. The idea is simple: you've already carved your line in the snow. Your code is there. Your diffs are real. Instead of making you explain it, kodrdriv uses an LLM to read the trail you left behind and generate a clean, meaningful commit message. One that actually reflects your work — without breaking your flow or making you guess what mattered most.
|
|
187
|
-
|
|
188
|
-
Whether you're merging branches or writing books, kodrdriv is built for that end-of-day moment when you want to commit and move on — not pause for existential reflection. It reads the line you've drawn, and it helps you push it forward.
|
|
@@ -1,4 +0,0 @@
|
|
|
1
|
-
<svg xmlns="http://www.w3.org/2000/svg" width="32" height="32" viewBox="0 0 24 24" fill="none" stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
|
2
|
-
<polyline points="16,18 22,12 16,6"></polyline>
|
|
3
|
-
<polyline points="8,6 2,12 8,18"></polyline>
|
|
4
|
-
</svg>
|
package/docs/public/commands.md
DELETED
|
@@ -1,116 +0,0 @@
|
|
|
1
|
-
# Commands
|
|
2
|
-
|
|
3
|
-
KodrDriv provides four main commands for automating Git workflows and generating intelligent documentation.
|
|
4
|
-
|
|
5
|
-
## Commit Command
|
|
6
|
-
|
|
7
|
-
Generate intelligent commit messages:
|
|
8
|
-
|
|
9
|
-
```bash
|
|
10
|
-
kodrdriv commit
|
|
11
|
-
```
|
|
12
|
-
|
|
13
|
-
The commit command analyzes your changes and generates contextual commit messages using AI. It can work with both staged and unstaged changes.
|
|
14
|
-
|
|
15
|
-
> [!TIP]
|
|
16
|
-
> ### Working with Staged Changes
|
|
17
|
-
>
|
|
18
|
-
> When you have staged changes using `git add`, the `kodrdriv commit` command will automatically analyze the diff of your staged changes. This allows you to selectively stage files and generate a commit message that specifically addresses those changes, rather than all uncommitted changes in your working directory.
|
|
19
|
-
|
|
20
|
-
> [!TIP]
|
|
21
|
-
> ### Quick Commit with --sendit
|
|
22
|
-
>
|
|
23
|
-
> If you trust the quality of the generated commit messages, you can use the `--sendit` flag to automatically commit your changes with the generated message without review. This is useful for quick, routine changes where you want to streamline your workflow.
|
|
24
|
-
|
|
25
|
-
### Commit Command Options
|
|
26
|
-
|
|
27
|
-
- `--cached`: Use cached diff for generating commit messages
|
|
28
|
-
- `--sendit`: Commit with the generated message without review (default: false)
|
|
29
|
-
- `--context <context>`: Provide additional context (as a string or file path) to guide the commit message generation. This context is included in the prompt sent to the AI and can be used to specify the purpose, theme, or any special considerations for the commit.
|
|
30
|
-
- `--message-limit <messageLimit>`: Limit the number of recent commit messages (from git log) to include in the prompt for context (default: 10). This can help focus the AI on the most relevant recent changes.
|
|
31
|
-
|
|
32
|
-
## Release Command
|
|
33
|
-
|
|
34
|
-
Generate comprehensive release notes based on changes since the last release:
|
|
35
|
-
|
|
36
|
-
```bash
|
|
37
|
-
kodrdriv release
|
|
38
|
-
```
|
|
39
|
-
|
|
40
|
-
The release command analyzes changes between two Git references and generates structured release notes.
|
|
41
|
-
|
|
42
|
-
> [!TIP]
|
|
43
|
-
> ### Custom Release Range
|
|
44
|
-
>
|
|
45
|
-
> The `kodrdriv release` command supports customizing the range of commits to analyze using the `--from` and `--to` options. By default, it compares changes between the `main` branch and `HEAD`, but you can specify any valid Git reference (branch, tag, or commit hash) for either endpoint. This flexibility allows you to generate release notes for specific version ranges or between different branches.
|
|
46
|
-
|
|
47
|
-
> [!TIP]
|
|
48
|
-
> ### Comparing Releases
|
|
49
|
-
>
|
|
50
|
-
> You can use the `--from` and `--to` options to generate release notes comparing two different releases. For example, to see what changed between v1.0.0 and v1.1.0, you could use `kodrdriv release --from v1.0.0 --to v1.1.0`. This is particularly useful for creating detailed changelogs when preparing release documentation.
|
|
51
|
-
|
|
52
|
-
### Release Command Options
|
|
53
|
-
|
|
54
|
-
- `--from <from>`: Branch or reference to generate release notes from (default: 'main')
|
|
55
|
-
- `--to <to>`: Branch or reference to generate release notes to (default: 'HEAD')
|
|
56
|
-
- `--context <context>`: Provide additional context (as a string or file path) to guide the release notes generation. This context is included in the prompt sent to the AI and can be used to specify the purpose, theme, or any special considerations for the release.
|
|
57
|
-
- `--message-limit <messageLimit>`: Limit the number of recent commit messages (from git log) to include in the release notes prompt (default: 10). Reducing this number can make the summary more focused, while increasing it provides broader historical context.
|
|
58
|
-
|
|
59
|
-
## Publish Command
|
|
60
|
-
|
|
61
|
-
Automate the entire release process, from dependency updates to GitHub release creation:
|
|
62
|
-
|
|
63
|
-
```bash
|
|
64
|
-
kodrdriv publish
|
|
65
|
-
```
|
|
66
|
-
|
|
67
|
-
The `publish` command orchestrates a comprehensive release workflow, designed to ensure a safe and consistent release process. Here's what it does:
|
|
68
|
-
|
|
69
|
-
1. **Dependency Management**: If a `pnpm-workspace.yaml` file is present, it's temporarily renamed to switch from workspace dependencies to registry versions. It then runs `pnpm update --latest` to ensure dependencies are up to date. You can configure specific dependency patterns to update instead of updating all dependencies using the `dependencyUpdatePatterns` configuration option.
|
|
70
|
-
|
|
71
|
-
2. **Pre-flight Checks**: Before committing any changes, it runs the `prepublishOnly` script from your `package.json`. This script should contain your project's pre-flight checks (e.g., `clean`, `lint`, `build`, `test`) to ensure the project is in a good state. **Note**: A `prepublishOnly` script is required in your `package.json` - the publish command will fail if this script is not present.
|
|
72
|
-
|
|
73
|
-
3. **Release Commit**: If there are changes to `package.json` or `pnpm-lock.yaml`, it creates an intelligent commit message for the dependency updates.
|
|
74
|
-
|
|
75
|
-
4. **Version Bump**: It automatically bumps the patch version of your project.
|
|
76
|
-
|
|
77
|
-
5. **Release Notes**: It generates release notes based on the recent changes and saves them to `RELEASE_NOTES.md`.
|
|
78
|
-
|
|
79
|
-
6. **Pull Request Automation**:
|
|
80
|
-
- It pushes the changes and tags to the origin.
|
|
81
|
-
- It creates a new pull request for the release.
|
|
82
|
-
- It waits for all status checks on the pull request to pass.
|
|
83
|
-
- Once checks are complete, it automatically merges the pull request using the configured merge method (default: squash).
|
|
84
|
-
|
|
85
|
-
7. **GitHub Release**: After the PR is merged, it checks out the `main` branch, pulls the latest changes, and creates a new GitHub release with the tag and release notes.
|
|
86
|
-
|
|
87
|
-
8. **New Release Branch**: Finally, it creates and pushes a new release branch for the next version (e.g., `release/0.0.5`).
|
|
88
|
-
|
|
89
|
-
This command is designed for repositories that follow a pull-request-based release workflow with required status checks. It streamlines the process, reducing manual steps and potential for error.
|
|
90
|
-
|
|
91
|
-
### Publish Command Options
|
|
92
|
-
|
|
93
|
-
- `--merge-method <method>`: Method to merge pull requests during the publish process (default: 'squash')
|
|
94
|
-
- Available methods: 'merge', 'squash', 'rebase'
|
|
95
|
-
|
|
96
|
-
## Link Command
|
|
97
|
-
|
|
98
|
-
Manage pnpm workspace links for local development with sibling projects:
|
|
99
|
-
|
|
100
|
-
```bash
|
|
101
|
-
kodrdriv link
|
|
102
|
-
```
|
|
103
|
-
|
|
104
|
-
The `link` command automates the creation and management of pnpm workspace configurations for local development. It scans your project's dependencies and automatically discovers matching sibling packages in configured scope directories, then updates your `pnpm-workspace.yaml` file to link them for local development.
|
|
105
|
-
|
|
106
|
-
This is particularly useful when working with monorepos or related packages where you want to use local versions of dependencies instead of published registry versions during development.
|
|
107
|
-
|
|
108
|
-
### Link Command Options
|
|
109
|
-
|
|
110
|
-
- `--scope-roots <scopeRoots>`: JSON mapping of scopes to root directories for package discovery
|
|
111
|
-
- **Format**: `'{"@scope": "path", "@another": "path"}'`
|
|
112
|
-
- **Example**: `'{"@company": "../", "@myorg": "../../packages/"}'`
|
|
113
|
-
- **Required**: At least one scope mapping must be provided
|
|
114
|
-
- `--workspace-file <workspaceFile>`: Path to the workspace file to create/update (default: 'pnpm-workspace.yaml')
|
|
115
|
-
|
|
116
|
-
For detailed information about each command, including advanced configuration options and use cases, see the complete [Commands Documentation](commands.md).
|