참고소스 수정본

참고/instructor-main/.cursor/rules/documentation-sync.mdc

@@ -0,0 +1,36 @@
+---
+description: when making code changes or adding documentation
+globs: ["*.py", "*.md"]
+alwaysApply: true
+---
+
+- When making code changes:
+    - Update related documentation files to reflect the changes
+    - Check docstrings and type hints are up to date
+    - Update any example code in markdown files
+    - Review README.md if the changes affect installation or usage
+
+- When creating new markdown files:
+    - Add the file to mkdocs.yml under the appropriate section
+    - Follow the existing hierarchy and indentation
+    - Use descriptive nav titles
+    - Example:
+        ```yaml
+        nav:
+          - Home: index.md
+          - Guides:
+              - Getting Started: guides/getting-started.md
+              - Your New File: guides/your-new-file.md
+        ```
+
+- For API documentation:
+    - Ensure new functions/classes are documented
+    - Include type hints and docstrings
+    - Add usage examples
+    - Update API reference docs if auto-generated
+
+- Documentation Quality:
+    - Write at grade 10 reading level (see simple-language.mdc)
+    - Include working code examples
+    - Add links to related documentation
+    - Use consistent formatting and style 

참고/instructor-main/.cursor/rules/followups.mdc

@@ -0,0 +1,8 @@
+---
+description: when AI agents are collaborating on code
+globs: "*"
+alwaysApply: true
+---
+Make sure to come up with follow-up hot keys. They should be thoughtful and actionable and result in small additional code changes based on the context that you have available.
+
+using [J], [K], [L]

참고/instructor-main/.cursor/rules/new-features-planning.mdc

@@ -0,0 +1,45 @@
+---
+description: when asked to implement new features or clients
+globs: *.py
+alwaysApply: true
+---
+
+- When being asked to make new features, make sure that you check out from main a new branch and make incremental commits
+  - Use conventional commit format: `<type>(<scope>): <description>`
+    - Types: feat, fix, docs, style, refactor, perf, test, chore
+    - Example: `feat(validation): add email validation function` 
+    - Keep commits focused on a single change
+    - Write descriptive commit messages in imperative mood
+  - Use `git commit -m "type(scope): subject" -m "body" -m "footer"` for multiline commits
+- If the feature is very large, create a temporary `todo.md`
+- And start a pull request using `gh`
+  - Create PRs with multiline bodies using:
+    ```bash
+    gh pr create --title "feat(component): add new feature" --body "$(cat <<EOF
+    ## Description
+    Detailed explanation of the changes
+
+    ## Changes
+    - List important changes
+    - Another change
+
+    ## Testing
+    How this was tested
+
+    This PR was written by [Cursor](cursor.com)
+    EOF
+    )" -r jxnl,ivanleomk
+    ```
+  - Or use the `-F` flag with a file: `gh pr create -F pr_body.md`
+- Make sure to include `This PR was written by [Cursor](mdc:cursor.com)`
+- Add default reviewers:
+    - Use `gh pr edit <id> --add-reviewer jxnl,ivanleomk`
+    - Or include `-r jxnl,ivanleomk` when creating the PR
+- use `gh pr view <id> --comments | cat` to view all the comments
+- For PR updates:
+    - Do not directly commit to an existing PR branch
+    - Instead, create a new PR that builds on top of the original PR's branch
+    - This creates a "stacked PR" pattern where:
+        1. The original PR (base) contains the initial changes
+        2. The new PR (stack) contains only the review-related updates
+        3. Once the base PR is merged, the stack can be rebased onto main 

참고/instructor-main/.cursor/rules/readme.md

@@ -0,0 +1,100 @@
+# Cursor Rules
+
+Cursor rules are configuration files that help guide AI-assisted development in the Cursor IDE. They provide structured instructions for how the AI should behave in specific contexts or when working with certain types of files.
+
+## What is Cursor?
+
+[Cursor](https://cursor.sh) is an AI-powered IDE that helps developers write, understand, and maintain code more efficiently. It integrates AI capabilities directly into the development workflow, providing features like:
+
+- AI-assisted code completion
+- Natural language code generation
+- Intelligent code explanations
+- Automated refactoring suggestions
+
+## Understanding Cursor Rules
+
+Cursor rules are defined in `.mdc` files within the `.cursor/rules` directory. Each rule file follows a specific naming convention: lowercase names with the `.mdc` extension (e.g., `simple-language.mdc`).
+
+Each rule file contains:
+
+1. **Metadata Header**: YAML frontmatter that defines:
+   ```yaml
+   ---
+   description: when to apply this rule
+   globs: file patterns to match (e.g., "*.py", "*.md", or "*" for all files)
+   alwaysApply: true/false  # whether to apply automatically
+   ---
+   ```
+
+2. **Rule Content**: Markdown-formatted instructions that guide the AI's behavior
+
+## Available Rules
+
+Currently, the following rules are defined:
+
+### `simple-language.mdc`
+- **Purpose**: Ensures documentation is written at a grade 10 reading level
+- **Applies to**: Markdown files (*.md)
+- **Auto Apply**: No
+- **Key Requirements**: 
+  - Write at grade 10 reading level
+  - Ensure code blocks are self-contained with complete imports
+
+### `new-features-planning.mdc`
+- **Purpose**: Guides feature implementation workflow
+- **Applies to**: Python files (*.py)
+- **Auto Apply**: Yes
+- **Key Requirements**:
+  - Create new branch from main
+  - Make incremental commits
+  - Create todo.md for large features
+  - Start pull requests using GitHub CLI (`gh`)
+  - Include "This PR was written by [Cursor](https://cursor.sh)" in PRs
+
+### `followups.mdc`
+- **Purpose**: Ensures thoughtful follow-up suggestions
+- **Applies to**: All files
+- **Auto Apply**: Yes
+- **Key Requirements**:
+  - Generate actionable hotkey suggestions using:
+    - [J]: First follow-up action
+    - [K]: Second follow-up action
+    - [L]: Third follow-up action
+  - Focus on small, contextual code changes
+  - Suggestions should be thoughtful and actionable
+
+### `documentation-sync.mdc`
+- **Purpose**: Maintains documentation consistency with code changes
+- **Applies to**: Python and Markdown files (*.py, *.md)
+- **Auto Apply**: Yes
+- **Key Requirements**:
+  - Update docs when code changes
+  - Add new markdown files to mkdocs.yml
+  - Keep API documentation current
+  - Maintain documentation quality standards
+
+## Creating New Rules
+
+To create a new rule:
+
+1. Create a `.mdc` file in `.cursor/rules/` using lowercase naming
+2. Add YAML frontmatter with required metadata:
+   ```yaml
+   ---
+   description: when to apply this rule
+   globs: file patterns to match
+   alwaysApply: true/false
+   ---
+   ```
+3. Write clear, specific instructions in Markdown
+4. Test the rule with relevant file types
+
+## Best Practices
+
+- Keep rules focused and specific
+- Use clear, actionable language
+- Test rules thoroughly before committing
+- Document any special requirements or dependencies
+- Update rules as project needs evolve
+- Use consistent file naming (lowercase with .mdc extension)
+- Ensure globs patterns are explicit and documented

참고/instructor-main/.cursor/rules/simple-language.mdc

@@ -0,0 +1,8 @@
+---
+description: when writing documentation
+globs: *.md
+alwaysApply: false
+---
+
+- When writing documents and concepts make sure that you write at a grade 10 reading level 
+- make sure every code block has complete imports and makes no references to previous code blocks, each one needs to be self contained