junieに限った話ではなく、cursorやgithub cpilotを使う上で避けて通れないのがそれぞれの設定ファイルだ。毎回プロンプトで頑張って書くでもいいけど、設定ファイルを作成すればプロジェクト内での共有もできるしこの設定ファイル自体は別のプロジェクトでも流用ができる。なので設定しておいて損はないです!

JetBrainsのJunieの設定ファイルは?
結論から書くと、プロジェクトのルートディレクトリに.junie/guidelines.md
ファイルを設置する。
主な機能
- コーディング規約とベストプラクティスを定義し、Junieがコード生成時に自動的にこれらのガイドラインに従うようにする
- プロジェクトのコーディング標準を統合することで、毎回のプロンプトに同じ指示を含める必要がなくなる
作成方法
- 自動生成: 「プロジェクト構造とテクノロジースタックを分析し、新しい開発者向けの簡潔で構造化された情報を含む.junie/guidelines.mdファイルを作成する」といったコマンドを実行することで自動作成可能
- 手動作成: 既存のガイドをコピーして手動で作成することも可能
内容例
テストを特定のフォルダに配置する指示、特定のフレームワークの使用、既存のガイドラインファイルへの参照、プロジェクト構造の推奨事項、テスト実行方法、ビルド手順などが含まれます。
このファイルにより、Junieはプロジェクトのコンテキストとコーディングスタイルを理解し、一貫した高品質なコードを生成できるようになります。
guidelines.mdに記載すべき構成を考えてみる
プロンプトは基本markdown形式で記載する。
# JetBrains Junie Guidelines
## Overview
This document outlines the guidelines and best practices for using JetBrains Junie, providing developers with comprehensive information to maximize productivity and maintain code quality.
## Table of Contents
- [Getting Started](#getting-started)
- [Core Principles](#core-principles)
- [Development Standards](#development-standards)
- [Code Style Guide](#code-style-guide)
- [Testing Guidelines](#testing-guidelines)
- [Documentation Standards](#documentation-standards)
- [Performance Best Practices](#performance-best-practices)
- [Security Guidelines](#security-guidelines)
- [Troubleshooting](#troubleshooting)
- [Contributing](#contributing)
- [FAQ](#faq)
## Getting Started
### Prerequisites
- Required software versions
- System requirements
- Installation dependencies
### Installation
```bash
# Installation commands
npm install @jetbrains/junie
```
### Quick Start
Step-by-step guide to get your first project running with Junie.
## Core Principles
### Design Philosophy
- Simplicity and clarity
- Performance optimization
- Developer experience focus
- Maintainability
### Architecture Guidelines
- Modular design patterns
- Dependency management
- Component structure
- Data flow principles
## Development Standards
### Project Structure
```
project/
├── src/
│ ├── components/
│ ├── services/
│ ├── utils/
│ └── tests/
├── docs/
└── config/
```
### Naming Conventions
- File naming standards
- Variable and function naming
- Class and interface naming
- Constants and enums
### Import and Export Guidelines
- Module import/export best practices
- Dependency organization
- Circular dependency prevention
## Code Style Guide
### Formatting Rules
- Indentation (spaces vs tabs)
- Line length limits
- Bracket placement
- Semicolon usage
### Language-Specific Guidelines
- TypeScript/JavaScript conventions
- CSS/SCSS standards
- HTML structure guidelines
### Linting Configuration
```json
{
"extends": ["@jetbrains/junie-eslint-config"],
"rules": {
// Custom rules
}
}
```
## Testing Guidelines
### Testing Strategy
- Unit testing approach
- Integration testing
- End-to-end testing
- Test coverage requirements
### Testing Tools and Setup
- Recommended testing frameworks
- Mock and stub guidelines
- Test data management
### Test Writing Best Practices
```javascript
// Example test structure
describe('Component', () => {
it('should behave correctly', () => {
// Test implementation
});
});
```
## Documentation Standards
### Code Documentation
- Inline comment guidelines
- JSDoc/TSDoc standards
- API documentation requirements
### README Requirements
- Project description
- Installation instructions
- Usage examples
- Contributing guidelines
### Changelog Maintenance
- Version numbering (SemVer)
- Release notes format
- Breaking changes documentation
## Performance Best Practices
### Optimization Techniques
- Bundle size optimization
- Runtime performance
- Memory management
- Lazy loading strategies
### Monitoring and Profiling
- Performance metrics
- Debugging tools
- Profiling guidelines
## Security Guidelines
### Code Security
- Input validation
- XSS prevention
- CSRF protection
- Dependency security
### Data Protection
- Sensitive data handling
- Encryption standards
- Authentication practices
## Troubleshooting
### Common Issues
- Frequent error scenarios
- Solution patterns
- Debug techniques
### Error Handling
- Error boundary implementation
- Logging standards
- Error reporting
### Debugging Tools
- Browser DevTools usage
- IDE debugging setup
- Console debugging techniques
## Contributing
### Development Workflow
- Git workflow (GitFlow/GitHub Flow)
- Branch naming conventions
- Commit message format
### Pull Request Guidelines
- PR template
- Review process
- Merge requirements
### Code Review Checklist
- [ ] Code follows style guidelines
- [ ] Tests are included and passing
- [ ] Documentation is updated
- [ ] Performance impact assessed
## Version History
## License
This project is licensed under the [License Name] - see the LICENSE file for details.
主要な特徴
- Getting Started
- インストールと初期設定
- Core Principles
- 設計哲学とアーキテクチャ指針
- Development Standards
- プロジェクト構造と命名規則
- Code Style Guide
- コードフォーマットと言語固有のガイドライン
- Testing Guidelines
- テスト戦略とベストプラクティス
- Documentation Standards
- ドキュメント作成の標準
- Performance & Security
- パフォーマンス最適化とセキュリティ指針
- Contributing
- 開発ワークフローとコントリビューション方法
基本はこんなとこだろうか?全部が全部必要なわけでもないと思うし、プロジェクトによって変わってくることもあるはずなので、基本的にはチーム内で話し合ってどんな構成にすべきか決めていくのがベストだと思います。
AIの便利さは言わずもがなですが、使う側の使い方で得られる結果はだいぶ変わってくるのでしっかり考えて使っていきたいですね。