Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 95 additions & 0 deletions .claude/commands/code-review2.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,95 @@
# Code Reviewer Assistant for Claude Code

You are an expert code reviewer tasked with analyzing a codebase and providing actionable feedback. Your primary responsibilities are:

## Core Review Process

1. **Analyze the codebase structure** - Understand the project architecture, technologies used, and coding patterns
2. **Identify issues and improvements** across these categories:
- **Security vulnerabilities** and potential attack vectors
- **Performance bottlenecks** and optimization opportunities
- **Code quality issues** (readability, maintainability, complexity)
- **Best practices violations** for the specific language/framework
- **Bug risks** and potential runtime errors
- **Architecture concerns** and design pattern improvements
- **Testing gaps** and test quality issues
- **Documentation deficiencies**

3. **Prioritize findings** using this severity scale:
- 🔴 **Critical**: Security vulnerabilities, breaking bugs, major performance issues
- 🟠 **High**: Significant code quality issues, architectural problems
- 🟡 **Medium**: Minor bugs, style inconsistencies, missing tests
- 🟢 **Low**: Documentation improvements, minor optimizations

## TASK.md Management

Always read the existing TASK.md file first. Then update it by:

### Adding New Tasks
- Append new review findings to the appropriate priority sections
- Use clear, actionable task descriptions
- Include file paths and line numbers where relevant
- Reference specific code snippets when helpful

### Task Format
```markdown
## 🔴 Critical Priority
- [ ] **[SECURITY]** Fix SQL injection vulnerability in `src/auth/login.js:45-52`
- [ ] **[BUG]** Handle null pointer exception in `utils/parser.js:120`

## 🟠 High Priority
- [ ] **[REFACTOR]** Extract complex validation logic from `UserController.js` into separate service
- [ ] **[PERFORMANCE]** Optimize database queries in `reports/generator.js`

## 🟡 Medium Priority
- [ ] **[TESTING]** Add unit tests for `PaymentProcessor` class
- [ ] **[STYLE]** Consistent error handling patterns across API endpoints

## 🟢 Low Priority
- [ ] **[DOCS]** Add JSDoc comments to public API methods
- [ ] **[CLEANUP]** Remove unused imports in `components/` directory
```

### Maintaining Existing Tasks
- Don't duplicate existing tasks
- Mark completed items you can verify as `[x]`
- Update or clarify existing task descriptions if needed

## Review Guidelines

### Be Specific and Actionable
- ✅ "Extract the 50-line validation function in `UserService.js:120-170` into a separate `ValidationService` class"
- ❌ "Code is too complex"

### Include Context
- Explain *why* something needs to be changed
- Suggest specific solutions or alternatives
- Reference relevant documentation or best practices

### Focus on Impact
- Prioritize issues that affect security, performance, or maintainability
- Consider the effort-to-benefit ratio of suggestions

### Language/Framework Specific Checks
- Apply appropriate linting rules and conventions
- Check for framework-specific anti-patterns
- Validate dependency usage and versions

## Output Format

Provide a summary of your review findings, then show the updated TASK.md content. Structure your response as:

1. **Review Summary** - High-level overview of findings
2. **Key Issues Found** - Brief list of most important problems
3. **Updated TASK.md** - The complete updated file content

## Commands to Execute

When invoked, you should:
1. Scan the entire codebase for issues
2. Read the current TASK.md file
3. Analyze and categorize all findings
4. Update TASK.md with new actionable tasks
5. Provide a comprehensive review summary

Focus on being thorough but practical - aim for improvements that will genuinely make the codebase more secure, performant, and maintainable.
4 changes: 4 additions & 0 deletions .claude/commands/commit-and-push.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,4 @@
ADD all modified and new files to git. If you think there are files that should not be in version control, ask the user. If you see files that you think should be bundled into separate commits, ask the user.
THEN commit with a clear and concise one-line commit message, using semantic commit notation.
THEN push the commit to origin.
The user is EXPLICITLY asking you to perform these git tasks.
42 changes: 0 additions & 42 deletions .claude/commands/commit-message.md

This file was deleted.

155 changes: 155 additions & 0 deletions .claude/commands/evaluate-repository.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,155 @@
# Repository Evaluation Prompt (Awesome-Claude-Code · Full Version)

## Evaluation Context (Claude Code Ecosystem)

You are evaluating a repository intended for use in or alongside **Claude Code**, where certain features (such as hooks, commands, scripts, or automation) may execute implicitly or with elevated trust once enabled by a user.

In this ecosystem, risk commonly arises not from overtly malicious code, but from implicit execution surfaces, including:
- Hooks that execute automatically based on tool lifecycle events
- Custom commands that may invoke shell scripts
- Scripts that run in the user’s local environment
- Persistent state files that influence control flow
- Network access triggered indirectly by tooling

Your task is to perform a conservative, evidence-based, static review that:
- Identifies trust boundaries and implicit execution
- Distinguishes declared behavior from effective capability
- Surfaces red flags or areas requiring further manual inspection
- Avoids inferring author intent beyond what is observable

When uncertain, prefer explicit uncertainty over confident speculation.

---

## Instructions

Perform a static, read-only review of the repository named at the end of this prompt.

Do not run any code, install dependencies, or execute scripts.
Base your assessment solely on repository contents and documentation.

This evaluation supports curation and triage, not automated approval.

---

## Evaluation Criteria

For each category below:
- Assign a score from 1–10
- Provide concise justification
- Explicitly note uncertainty
- Separate red flags from speculation

### 1. Code Quality
Assess structure, readability, correctness, and internal consistency.

### 2. Security & Safety
Assess risks related to:
- Implicit execution (hooks, background behavior)
- File system access
- Network access
- Credential handling
- Tool escalation or privilege assumptions

### 3. Documentation & Transparency
Assess whether documentation accurately describes behavior, discloses side effects, and matches implementation.

### 4. Functionality & Scope
Assess whether the repository appears to do what it claims within its stated scope.

### 5. Repository Hygiene & Maintenance
Assess signals of care, maintainability, licensing, and publication quality.

---

## Claude-Code-Specific Checklist

Explicitly answer each item:
- Defines hooks (stop, lifecycle, or similar)
- Hooks execute shell scripts
- Commands invoke shell or external tools
- Writes persistent local state files
- Reads state to control execution flow
- Performs implicit execution without explicit confirmation
- Documents hook or command side effects
- Includes safe defaults
- Includes a clear disable or cancel mechanism

Briefly explain any checked item.

---

## Permissions & Side Effects Analysis

### A. Reported / Declared Permissions
From documentation or config:
- File system:
- Network:
- Execution / hooks:
- APIs / tools:

### B. Likely Actual Permissions (Inferred)
From static inspection:
- File system:
- Network:
- Execution / hooks:
- APIs / tools:

Mark items as confirmed, likely, or unclear.

### C. Discrepancies
List mismatches between declared and inferred behavior.

---

## Red Flag Scan

Check all that apply and justify:
- Malware or spyware indicators
- Undisclosed implicit execution
- Undocumented file or network activity
- Unsupported claims
- Supply-chain or trust risks

---

## Overall Assessment

### Overall Score
Score: X / 10

### Recommendation
Choose one:
- Recommend
- Recommend with caveats
- Needs further manual review
- Definitely reject

### Fast-Reject Heuristic
If "Definitely reject", specify which applies:
- Clear malicious behavior
- Undisclosed high-risk implicit execution
- Severe claim/behavior mismatch
- Unsafe defaults with no mitigation
- Other (explain)

---

## Possible Remedies / Improvement Suggestions

If applicable, list specific, minimal changes that could materially improve the submission or change the recommendation (e.g., documentation clarifications, safer defaults, permission scoping).

---

## Output Format

Use clear section headings corresponding to the sections above.
Keep the evaluation concise, precise, and evidence-based.

---

REPOSITORY:

IF PRESENT: <REPO>$ARGUMENTS</REPO>

ELSE: The repository you are currently working in.
7 changes: 7 additions & 0 deletions _plans/footer.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
Add a footer to the TermInput page.
Include an icon representing American Sign Language.
Include a disclaimer section with notes saying:
- that this site is not for professional use and is only for helping study ASL.
- uses public domain videos that are not owned by this creator.
- does not promise that the signs provided are the most recent versions of ASL
- attempts to restrict signs to ASL vs other sign languages (BSL, etc).
61 changes: 61 additions & 0 deletions _specs/flashcard-session.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,61 @@
# Spec for flashcard-session

branch: claude/feature/flashcard-session

## Summary

A full-screen flashcard practice session that displays ASL terms one at a time with color-coded cards, embedded video demonstrations, keyboard and button navigation, shuffle, and an alphabetical term list for direct access.

## Functional Requirements

- Display the current term in a color-coded card that fills the available width
- Show an embedded video (via iframe) for the current term below the card
- Derive the video URL from the term's `code` field; fall back to a constructed StartASL URL when `code` is empty; handle the special `type: "spell"` case by showing a fingerspelling GIF
- Show a position counter (e.g. "3 / 42") below the video
- Provide Prev and Next buttons to step through terms sequentially, wrapping around at the ends
- Support left/right arrow-key navigation equivalent to Prev/Next
- Provide a Shuffle button that randomizes the term order and resets to position 1; card colors follow the shuffle
- Provide a List button that toggles an alphabetical listbox to the right of the main content area
- The listbox must be sorted alphabetically and computed only once per term list (recalculated only after a shuffle)
- Selecting an item in the listbox navigates directly to that term; the selected item stays highlighted and tracks the current card as the user navigates with Prev/Next/arrows
- Provide a Back button that returns to the category selection screen

## Possible Edge Cases

- Term with an empty `code` field and no matching StartASL video URL (video will 404 silently)
- Term with `type: "spell"` and no fingerspelling GIF present in the public folder
- Single-term list (Prev/Next wrapping lands on the same card)
- Very long term labels that overflow the card area
- Shuffling while the listbox is open — listbox should remain open and reflect the new order

## Acceptance Criteria

- Navigating with Prev, Next, and arrow keys updates the card term, video, position counter, and listbox selection
- Shuffle randomizes the card order, resets to position 1, and updates the listbox
- The listbox appears to the right of the card/video column when toggled and does not reflow the main content
- The listbox selection always matches the current card, including after keyboard and button navigation
- The sorted order of the listbox does not change unless a shuffle occurs
- The Back button exits the session without side effects

## Open Questions

- Should the List panel be persistent (always visible) or remain a toggle?
- Always visible.
- Should terms with no resolvable video URL show a placeholder rather than a broken iframe?
- Please show a placeholder when no resolvable URL available.
- Should arrow-key navigation be disabled when focus is inside the listbox to avoid conflicts?
- yes

## Testing Guidelines

Create a test file(s) in the ./tests folder for the new feature, and create meaningful tests for the following cases, without going too heavy:

- Renders the first term on mount
- Next button advances the index; wraps from last to first
- Prev button decrements the index; wraps from first to last
- ArrowRight and ArrowLeft key events trigger the same navigation as buttons
- Shuffle produces a different order and resets currentIndex to 0
- List button toggles the listbox visibility
- Selecting an option in the listbox sets currentIndex to the correct value
- Listbox value stays in sync with currentIndex after button navigation
- sortedTerms is sorted alphabetically and stable between renders
1 change: 1 addition & 0 deletions package.json
Original file line number Diff line number Diff line change
Expand Up @@ -18,6 +18,7 @@
},
"devDependencies": {
"@eslint/js": "^9.39.4",
"@testing-library/dom": "^10.4.1",
"@testing-library/jest-dom": "^6.9.1",
"@testing-library/react": "^16.3.2",
"@types/react": "^19.2.14",
Expand Down
Loading
Loading