Skip to content

Commit 7cd9299

Browse files
Miyamura80Miyamura80
authored
Initial commit
0 parents  commit 7cd9299

File tree

125 files changed

+11445
-0
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

125 files changed

+11445
-0
lines changed

‎.claude/skills/cleanup/SKILL.md‎

Lines changed: 143 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,143 @@
1+
---
2+
name: cleanup
3+
description: Git branch hygiene - delete merged/closed branch, prune stale refs, sync dependencies
4+
user_invocable: true
5+
triggers:
6+
- /cleanup
7+
---
8+
9+
# Git Cleanup Skill
10+
11+
Automates git branch hygiene after merging or closing PRs. Safely deletes merged branches (and force-deletes closed/abandoned branches), prunes stale remote tracking refs, syncs dependencies, and runs garbage collection.
12+
13+
## Workflow
14+
15+
Execute these steps in order:
16+
17+
### 1. Check current branch
18+
19+
```bash
20+
git branch --show-current
21+
```
22+
23+
Store the result as `CURRENT_BRANCH`.
24+
25+
### 2. Guard against main/master
26+
27+
If `CURRENT_BRANCH` is `main` or `master`:
28+
- Report: "Already on main branch. No branch to clean up."
29+
- Skip to step 7 (pull latest) and continue from there.
30+
31+
### 3. Check for uncommitted changes
32+
33+
```bash
34+
git status --porcelain
35+
```
36+
37+
If output is non-empty:
38+
- Warn the user: "You have uncommitted changes. Please commit or stash them first."
39+
- Stop and do not proceed.
40+
41+
### 4. Check if branch is merged or closed
42+
43+
First check for merged PRs:
44+
```bash
45+
gh pr list --state merged --head CURRENT_BRANCH --json number
46+
```
47+
48+
If merged, proceed to step 5.
49+
50+
If not merged, check for closed PRs:
51+
```bash
52+
gh pr list --state closed --head CURRENT_BRANCH --json number
53+
```
54+
55+
If closed (result is non-empty):
56+
- Report: "Branch 'CURRENT_BRANCH' has a closed (unmerged) PR. Proceeding with deletion."
57+
- Proceed to step 5 (will use force delete in step 6).
58+
59+
If neither merged nor closed:
60+
- Check if the branch is merged locally: `git branch --merged main | grep -w CURRENT_BRANCH`
61+
- If not merged anywhere, warn: "Branch 'CURRENT_BRANCH' does not appear to be merged or closed. Use `git branch -D` manually if you want to force delete."
62+
- Stop and do not proceed.
63+
64+
Store whether the branch was `MERGED` or `CLOSED` for use in step 6.
65+
66+
### 5. Switch to main
67+
68+
```bash
69+
git checkout main
70+
```
71+
72+
### 6. Delete the branch
73+
74+
If branch was `MERGED`:
75+
```bash
76+
git branch -d CURRENT_BRANCH
77+
```
78+
79+
If branch was `CLOSED` (PR closed without merging):
80+
```bash
81+
git branch -D CURRENT_BRANCH
82+
```
83+
84+
Report: "Deleted branch CURRENT_BRANCH." (mention if force-deleted due to closed PR)
85+
86+
### 7. Pull latest
87+
88+
```bash
89+
git pull origin main
90+
```
91+
92+
### 8. Prune remote tracking refs
93+
94+
```bash
95+
git fetch --prune
96+
```
97+
98+
### 9. Delete stale local branches
99+
100+
Find and delete local branches whose upstream is gone:
101+
102+
```bash
103+
git for-each-ref --format '%(refname:short) %(upstream:track)' refs/heads | while read branch track; do
104+
if [ "$track" = "[gone]" ]; then
105+
git branch -d "$branch" 2>/dev/null && echo "Deleted stale branch: $branch"
106+
fi
107+
done
108+
```
109+
110+
Report any branches deleted.
111+
112+
### 10. Sync dependencies
113+
114+
Detect package manager and sync:
115+
116+
- If `uv.lock` exists: `uv sync`
117+
- Else if `bun.lockb` exists: `bun install`
118+
- Else if `package-lock.json` exists: `npm install`
119+
- Else if `requirements.txt` exists: `pip install -r requirements.txt`
120+
- Else: Skip dependency sync
121+
122+
### 11. Git garbage collection
123+
124+
```bash
125+
git gc --prune=now
126+
```
127+
128+
### 12. Summary
129+
130+
Report completion:
131+
- Branch deleted (if applicable)
132+
- Number of stale branches pruned
133+
- Dependencies synced (which package manager)
134+
- Garbage collection complete
135+
136+
## Error Handling
137+
138+
- **Dirty working tree**: Stop immediately and ask user to commit/stash
139+
- **Branch not merged or closed**: Warn and stop - never force delete without explicit user request
140+
- **Branch closed (not merged)**: Force delete with `-D` since branch is abandoned
141+
- **Already on main**: Skip branch deletion, continue with pull/prune/gc
142+
- **No remote**: If `git pull` fails due to no remote, continue with local operations
143+
- **gh CLI not available**: Fall back to `git branch --merged` check

‎.claude/skills/code-quality/SKILL.md‎

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
---
2+
name: code-quality
3+
description: Instructions for running code quality checks and maintaining standards in the Python-Template project.
4+
---
5+
# Code Quality Skill
6+
7+
This skill provides instructions for running code quality checks and maintaining standards in the Python-Template project.
8+
9+
## Commands
10+
11+
Use the following `make` targets to ensure code quality:
12+
13+
- `make fmt`: Runs the `ruff` formatter and formats JSON files.
14+
- `make ruff`: Runs the `ruff` linter to catch common errors and style issues.
15+
- `make vulture`: Searches for dead code across the project.
16+
- `make ty`: Runs the `ty` type checker to ensure type safety.
17+
- `make ci`: Runs all of the above checks (`ruff`, `vulture`, `import_lint`, `ty`, `docs_lint`, `check_deps`) in sequence.
18+
19+
## Workflow
20+
21+
1. **Before Committing**: Always run `make fmt` and `make ruff`.
22+
2. **Major Changes**: Run `make ci` to ensure no regressions in types or dead code.
23+
3. **Continuous Integration**: These checks are enforced in the CI pipeline. Ensure all pass before opening a PR.

‎.claude/skills/prd/SKILL.md‎

Lines changed: 225 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,225 @@
1+
---
2+
name: prd
3+
description: Generate a Product Requirements Document (PRD) for a new feature. Use when planning a feature, starting a new project, or when asked to create a PRD.
4+
---
5+
# PRD Generator
6+
7+
Create detailed Product Requirements Documents that are clear, actionable, and suitable for implementation.
8+
9+
## The Job
10+
11+
1. Receive a feature description from the user
12+
2. Ask 3-5 essential clarifying questions (with lettered options)
13+
3. Generate a structured PRD based on answers
14+
4. Save to `tasks/prd-[feature-name].md`
15+
16+
**Important:** Do NOT start implementing. Just create the PRD.
17+
18+
## Step 1: Clarifying Questions
19+
20+
Ask only critical questions where the initial prompt is ambiguous. Focus on:
21+
22+
- **Problem/Goal:** What problem does this solve?
23+
- **Core Functionality:** What are the key actions?
24+
- **Scope/Boundaries:** What should it NOT do?
25+
- **Success Criteria:** How do we know it's done?
26+
27+
### Format Questions Like This:
28+
29+
```
30+
1. What is the primary goal of this feature?
31+
A. Improve user onboarding experience
32+
B. Increase user retention
33+
C. Reduce support burden
34+
D. Other: [please specify]
35+
36+
2. Who is the target user?
37+
A. New users only
38+
B. Existing users only
39+
C. All users
40+
D. Admin users only
41+
42+
3. What is the scope?
43+
A. Minimal viable version
44+
B. Full-featured implementation
45+
C. Just the backend/API
46+
D. Just the UI
47+
```
48+
49+
This lets users respond with "1A, 2C, 3B" for quick iteration.
50+
51+
## Step 2: PRD Structure
52+
53+
Generate the PRD with these sections:
54+
55+
### 1. Introduction/Overview
56+
Brief description of the feature and the problem it solves.
57+
58+
### 2. Goals
59+
Specific, measurable objectives (bullet list).
60+
61+
### 3. User Stories
62+
Each story needs:
63+
- **Title:** Short descriptive name
64+
- **Description:** "As a [user], I want [feature] so that [benefit]"
65+
- **Acceptance Criteria:** Verifiable checklist of what "done" means
66+
67+
Each story should be small enough to implement in one focused session.
68+
69+
**Format:**
70+
```markdown
71+
### US-001: [Title]
72+
**Description:** As a [user], I want [feature] so that [benefit].
73+
74+
**Acceptance Criteria:**
75+
- [ ] Specific verifiable criterion
76+
- [ ] Another criterion
77+
- [ ] Typecheck/lint passes
78+
- [ ] **[UI stories only]** Verify in browser using dev-browser skill
79+
```
80+
81+
**Important:**
82+
- Acceptance criteria must be verifiable, not vague. "Works correctly" is bad. "Button shows confirmation dialog before deleting" is good.
83+
- **For any story with UI changes:** Always include "Verify in browser using dev-browser skill" as acceptance criteria. This ensures visual verification of frontend work.
84+
85+
### 4. Functional Requirements
86+
Numbered list of specific functionalities:
87+
- "FR-1: The system must allow users to..."
88+
- "FR-2: When a user clicks X, the system must..."
89+
90+
Be explicit and unambiguous.
91+
92+
### 5. Non-Goals (Out of Scope)
93+
What this feature will NOT include. Critical for managing scope.
94+
95+
### 6. Design Considerations (Optional)
96+
- UI/UX requirements
97+
- Link to mockups if available
98+
- Relevant existing components to reuse
99+
100+
### 7. Technical Considerations (Optional)
101+
- Known constraints or dependencies
102+
- Integration points with existing systems
103+
- Performance requirements
104+
105+
### 8. Success Metrics
106+
How will success be measured?
107+
- "Reduce time to complete X by 50%"
108+
- "Increase conversion rate by 10%"
109+
110+
### 9. Open Questions
111+
Remaining questions or areas needing clarification.
112+
113+
## Writing for Junior Developers
114+
115+
The PRD reader may be a junior developer or AI agent. Therefore:
116+
117+
- Be explicit and unambiguous
118+
- Avoid jargon or explain it
119+
- Provide enough detail to understand purpose and core logic
120+
- Number requirements for easy reference
121+
- Use concrete examples where helpful
122+
123+
## Output
124+
125+
- **Format:** Markdown (`.md`)
126+
- **Location:** `tasks/`
127+
- **Filename:** `prd-[feature-name].md` (kebab-case)
128+
129+
## Example PRD
130+
131+
```markdown
132+
# PRD: Task Priority System
133+
134+
## Introduction
135+
136+
Add priority levels to tasks so users can focus on what matters most. Tasks can be marked as high, medium, or low priority, with visual indicators and filtering to help users manage their workload effectively.
137+
138+
## Goals
139+
140+
- Allow assigning priority (high/medium/low) to any task
141+
- Provide clear visual differentiation between priority levels
142+
- Enable filtering and sorting by priority
143+
- Default new tasks to medium priority
144+
145+
## User Stories
146+
147+
### US-001: Add priority field to database
148+
**Description:** As a developer, I need to store task priority so it persists across sessions.
149+
150+
**Acceptance Criteria:**
151+
- [ ] Add priority column to tasks table: 'high' | 'medium' | 'low' (default 'medium')
152+
- [ ] Generate and run migration successfully
153+
- [ ] Typecheck passes
154+
155+
### US-002: Display priority indicator on task cards
156+
**Description:** As a user, I want to see task priority at a glance so I know what needs attention first.
157+
158+
**Acceptance Criteria:**
159+
- [ ] Each task card shows colored priority badge (red=high, yellow=medium, gray=low)
160+
- [ ] Priority visible without hovering or clicking
161+
- [ ] Typecheck passes
162+
- [ ] Verify in browser using dev-browser skill
163+
164+
### US-003: Add priority selector to task edit
165+
**Description:** As a user, I want to change a task's priority when editing it.
166+
167+
**Acceptance Criteria:**
168+
- [ ] Priority dropdown in task edit modal
169+
- [ ] Shows current priority as selected
170+
- [ ] Saves immediately on selection change
171+
- [ ] Typecheck passes
172+
- [ ] Verify in browser using dev-browser skill
173+
174+
### US-004: Filter tasks by priority
175+
**Description:** As a user, I want to filter the task list to see only high-priority items when I'm focused.
176+
177+
**Acceptance Criteria:**
178+
- [ ] Filter dropdown with options: All | High | Medium | Low
179+
- [ ] Filter persists in URL params
180+
- [ ] Empty state message when no tasks match filter
181+
- [ ] Typecheck passes
182+
- [ ] Verify in browser using dev-browser skill
183+
184+
## Functional Requirements
185+
186+
- FR-1: Add `priority` field to tasks table ('high' | 'medium' | 'low', default 'medium')
187+
- FR-2: Display colored priority badge on each task card
188+
- FR-3: Include priority selector in task edit modal
189+
- FR-4: Add priority filter dropdown to task list header
190+
- FR-5: Sort by priority within each status column (high to medium to low)
191+
192+
## Non-Goals
193+
194+
- No priority-based notifications or reminders
195+
- No automatic priority assignment based on due date
196+
- No priority inheritance for subtasks
197+
198+
## Technical Considerations
199+
200+
- Reuse existing badge component with color variants
201+
- Filter state managed via URL search params
202+
- Priority stored in database, not computed
203+
204+
## Success Metrics
205+
206+
- Users can change priority in under 2 clicks
207+
- High-priority tasks immediately visible at top of lists
208+
- No regression in task list performance
209+
210+
## Open Questions
211+
212+
- Should priority affect task ordering within a column?
213+
- Should we add keyboard shortcuts for priority changes?
214+
```
215+
216+
## Checklist
217+
218+
Before saving the PRD:
219+
220+
- [ ] Asked clarifying questions with lettered options
221+
- [ ] Incorporated user's answers
222+
- [ ] User stories are small and specific
223+
- [ ] Functional requirements are numbered and unambiguous
224+
- [ ] Non-goals section defines clear boundaries
225+
- [ ] Saved to `tasks/prd-[feature-name].md`

0 commit comments

Comments
 (0)