Live events for "classic quiz with no assignment" content type + live events for all quiz types content update + new event types for quizzes

.claude/skills/create_commit_msg/SKILL.md

@@ -0,0 +1,194 @@
+---
+name: create_commit_msg
+description: Help create a well-formatted git commit message following Canvas LMS conventions
+disable-model-invocation: true
+---
+
+# Create Commit
+
+Help create a well-formatted git commit message following Canvas LMS conventions.
+
+## Format Requirements
+
+**Title line** (required):
+- Maximum 60 characters
+- Concise summary of the change
+- Imperative mood (e.g., "Fix bug" not "Fixed bug")
+
+**Body** (required for non-trivial changes):
+- Each line maximum 60 characters
+- Explain WHY the change was made
+- Include technical details and context
+- Describe what was changed (if not obvious from title)
+- Keep it concise but detailed
+- Avoid redundant information
+
+**Ticket reference** (required):
+- Use `refs TICKET-ID` for general work
+- Use `Fixes TICKET-ID` for bug fixes
+- Use `closes TICKET-ID` for completing features
+- If ticket is unknown, prompt user for it
+
+**Feature flag** (required):
+- Use `flag=flag_name` if a feature flag is involved
+- Use `flag=none` if no flag is needed
+
+**Test plan** (required):
+- Include manual testing steps for QA
+- Focus on user-facing verification steps
+- Be specific about expected results
+- Include different scenarios/edge cases
+- Don't mention automated tests (always implied)
+
+## Instructions for Claude
+
+⚠️ **CRITICAL: NEVER AUTOMATICALLY COMMIT** ⚠️
+- This command ONLY generates the commit message
+- DO NOT run `git commit` or any commit commands
+- ONLY display the message to the user
+- ALWAYS ask for explicit confirmation before committing
+- Wait for user approval before taking any git actions
+- **Each invocation requires NEW explicit approval** — prior
+  approval in the same session does NOT carry over. Even if
+  the user approved a commit earlier in this conversation,
+  you MUST ask again for each new invocation of this command.
+
+When the user invokes this command:
+
+1. **Gather information**:
+   - Review ONLY staged changes: `git diff --staged`
+   - Check staged files: `git status`
+   - DO NOT look at unstaged changes (`git diff` without
+     `--staged`) — only staged content is being committed
+   - **If nothing is staged, stop immediately** and tell
+     the user there is nothing to commit
+   - Identify what was changed and why
+   - If ticket number or feature flag is unknown, ask
+     for BOTH in a single message (not separately)
+
+2. **Generate commit message**:
+   - Title: 60 chars max, imperative mood
+   - Body: 60 chars per line, explain the "why"
+   - Include technical details and context
+   - Add ticket reference (refs/Fixes/closes)
+   - Add flag reference (flag=name or flag=none)
+   - Create detailed test plan with manual steps
+
+3. **Format**:
+   ```
+   Short title (max 50 chars)
+
+   Body paragraph explaining the change. Each line max
+   65 chars. Explain why this change was needed and what
+   it fixes or improves.
+
+   Additional context about the implementation if needed.
+   Break into multiple paragraphs for readability.
+
+   Changes:
+   - Bullet point summary of key changes (optional)
+   - Keep bullets concise but informative
+   - Focus on what, not how
+
+   refs TICKET-1234
+   flag=feature_flag_name
+
+   Test plan:
+   Setup:
+   - Setup step 1
+   - Setup step 2
+
+   Testing:
+   - Test step 1 with expected result
+   - Test step 2 with expected result
+   - Verify edge case X
+   - Verify edge case Y
+
+   Expected Results:
+   - Clear description of what should happen
+   ```
+
+4. **Display message and get approval**:
+   - Show the complete generated commit message in a code block
+   - DO NOT commit anything at this stage
+   - Ask: "Would you like me to commit these changes with
+     this message?"
+   - If user says yes, THEN run the git commit command
+     using a heredoc to preserve formatting:
+     ```
+     git commit -m "$(cat <<'EOF'
+     Title here
+
+     Body here
+     EOF
+     )"
+     ```
+   - NEVER use `--no-verify` to skip hooks
+   - If user requests changes, regenerate the message
+   - NEVER commit without explicit user confirmation
+
+## Example (Generic)
+
+```
+Add validation for email input field
+
+Email addresses were not being validated before submission,
+allowing invalid formats to be saved to the database. This
+caused downstream errors in notification systems.
+
+Added client-side validation using regex pattern and
+server-side validation in the controller. Invalid emails
+now show an error message and prevent form submission.
+
+Changes:
+- Add email format validation to user form
+- Add server-side validation in UsersController
+- Display error message for invalid email format
+- Add validation tests for edge cases
+
+refs COURSE-1234
+flag=none
+
+Test plan:
+Setup:
+- Navigate to user profile edit page as any user role
+
+Testing:
+- Enter valid email (user@example.com) and verify it saves
+- Enter invalid email (notanemail) and verify error appears
+- Enter email without @ symbol and verify error appears
+- Enter email without domain and verify error appears
+- Try submitting form with invalid email via console
+- Verify server rejects invalid email with proper error
+- Test with very long email address (255+ chars)
+- Verify email validation works for new user creation
+
+Expected Results:
+- Valid emails save successfully without errors
+- Invalid emails show clear error message and block save
+- Server validation prevents bypassing client validation
+- Error messages are clear and actionable
+```
+
+## Command Workflow
+
+1. User invokes `/create_commit_msg`
+2. Claude reviews ONLY staged changes (`git diff --staged`)
+3. Claude asks for ticket number (if needed)
+4. Claude asks about feature flags (if needed)
+5. Claude generates and displays the commit message
+6. **Claude asks: "Would you like me to commit with this
+   message?"**
+7. User reviews and approves OR requests changes
+8. Only after approval: Claude runs git commit command
+
+**Important**: Steps 1-6 MUST complete before any git commit
+command is executed. The user must explicitly approve.
+
+## Notes
+
+- Keep commit messages focused on one logical change
+- If changes are unrelated, create separate commits
+- Test plan should be thorough but realistic for QA
+- Include accessibility testing when UI changes are made
+- Specify browser/environment requirements if relevant

.claude/skills/ketchup/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: ketchup
+description: Rebuild context after /clear by analyzing uncommitted changes across Canvas LMS and all plugin repositories
+disable-model-invocation: true
+argument-hint: [optional: "commits" to include committed changes]
+---
+
+I just cleared context. Help me ketchup by analyzing all uncommitted changes.
+
+## Repository Changes
+
+The script has gathered git status and diffs from the Canvas LMS main repository and all plugin subrepositories. Here's all the data:
+
+!`.claude/skills/ketchup/get-diffs.sh $ARGUMENTS`
+
+## Your Task
+
+Analyze the repository changes above and provide a comprehensive summary:
+
+### 1. Identify What's Being Worked On
+Based on the nature of changes across all repositories, infer:
+- What feature or task is being implemented
+- The scope and purpose of the changes
+- Any patterns (e.g., refactoring, bug fix, new feature, test updates)
+
+### 2. Assess Progress
+Determine if the changes are:
+- Complete and ready for commit
+- In progress with more work needed
+- Just started/exploratory
+
+### 3. Key Files and Locations
+List the most important files being modified with their paths and relevant line numbers.
+For example: `app/models/user.rb:45-67`
+
+### 4. Likely Next Steps
+Based on incomplete work or patterns in the changes, suggest what the developer might work on next.
+
+### 5. Committed vs Uncommitted (if applicable)
+If commit information was requested and included, note which changes are already committed in addition 
+to still uncommitted.
+
+## Analysis Guidelines
+
+- **Focus on actual code changes**, not just filenames
+- **Consider relationships** between changes (e.g., model + controller + view + test)
+- **Look for TODOs or incomplete implementations** in the diffs
+- **Identify missing pieces** (e.g., tests for new features, migrations for schema changes)
+- **Be specific** with file paths and line numbers when referencing code
+- **Keep the summary concise** but comprehensive
+
+## Important Notes
+
+- The get-diffs.sh script handles all git operations without consuming tokens
+- It works from any directory within Canvas LMS (main repo or plugin subdirectory)
+- Plugin repositories under `gems/plugins/*` are separate git repositories
+- By default, only uncommitted changes are analyzed
+- Pass "commits" or "committed" in $ARGUMENTS to also analyze recent commits
+
+## Example Usage
+
+- `/ketchup` - Analyzes only uncommitted changes
+- `/ketchup commits` - Analyzes both uncommitted changes and recent commits
+- `/ketchup some changes have been committed` - Also includes commit analysis