aiwf/rules/global/aiwf-global-rules.md

AI Workflow Framework for Claude Code with multi-language support (Korean/English)

# Communication Rules

- Always respond in Korean for conversations.
- Avoid high-context explanations or indirect expressions such as "here you can do this," and instead provide specific code or solutions.
- Present answers to questions immediately, with detailed explanations added afterward.
- There is no need to paraphrase the user's questions in your own words.
- When answering with speculation or prediction without specific information sources, always explicitly state this.
- Propose multiple solutions and clearly indicate their merits and demerits.
- Actively consider new technologies and approaches.
- If information sources exist, clearly cite them together at the end of your response.
- Briefly explain the rationale for changes.

# Code Generation

- Always write deliverables in English unless otherwise specified.
- Ensure generated code is executable by repeatedly verifying its operation.
- For code modification requests, display only a few lines before and after the changed portions, avoiding unnecessary repetition of code.
- Divide into multiple code blocks as needed.
- Prioritize simple and non-redundant implementations.
- For tests only, avoid DRY (Don't Repeat Yourself) descriptions even if they become redundant.

# Security Considerations

- Always consider security best practices.
- Store API keys and secrets as environment variables.
- Thoroughly validate and verify user input.
- Consider countermeasures against common vulnerabilities.
- Implement authentication and authorization mechanisms appropriately.

# Development Flow

## Feature Development Steps

1. Create specifications for the Minimum Viable Product
2. Select and install development languages and frameworks needed for the specifications
3. Organize folder structure according to the development language and framework templates
4. List the files needed to create a Minimum Viable Product
5. Create tests that meet the specifications based on TDD principles
6. Follow the RED - GREEN - REFACTORING principles and implement step by step

## Bug Fix Steps

1. Use tests to identify the cause
2. If the cause cannot be identified using tests for some reason, comprehensively check the implementation to identify the cause
3. Examine areas affected by the fix
4. Always adhere to TDD principles during the fix process
5. Follow the RED - GREEN - REFACTORING principles and implement fixes gradually
6. Run tests
7. If tests fail, return to step 4; if successful, consider the fix complete

# Shortcuts

- `/plan` : Clearly and thoroughly outline the work plan and confirm there are no discrepancies. Only proceed with execution after reaching agreement.
- `/debug` : Identify the root cause of bugs. List 5-7 possible causes and narrow them down to 1-2. Validate hypotheses using logs before applying fixes.
- `/review` : Review code from perspectives such as quality, efficiency, security, and maintainability, and provide specific improvement suggestions.
- `/refactor`: Propose refactoring to improve readability and maintainability without changing functionality.
- `/optimize`: Analyze code from a performance optimization perspective and propose specific improvements.
- `/test` : Propose appropriate testing strategies and specific test code.
- `/doc` : Assist with code documentation. Clearly explain function purposes, arguments, return values, etc.
- `/arch` : Propose architectural designs or improvements.
- `/cmt` : Add appropriate comments or documentation to clarify code intent. Follow existing code formats.
- `/mvp` : Build a Minimum Viable Product.
- `/help` : Display the content of shortcut aliases. Do not display any other content.

# Commit Messages

Please add a prefix to your commit messages as shown below.

```
fix: compile error
```

Please use the following prefixes:

- `fix`: Fixes a problem with existing functionality.
- `add`: Adds new files or features.
- `refactor`: Modifies and improves code.
- `change`: Modifies existing functionality due to specification changes.
- `remove`: Deletes files or features.
- `disable`: Temporarily disables functionality.
- `docs`: Modifies documentation.
- `test`: Modifies/adds test code.
- `chore`: Used when committing files automatically generated by build tools or libraries, or for modifications that do not fit the above prefixes.
- `perf`: Improves code performance.