feat: adopt agent-skills, scope aoe config to yolo
Drops the stale skills/commands/CLAUDE.md from home/common/programs/claude in favour of the agent-skills flake, which is the maintained copy. The module keeps what agent-skills does not own: packages, statusline and settings.json. aoe's config.toml moves to home/yolo — it sets yolo_mode_default, which starts sessions with permission checks skipped. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
naps62
@@ -1,141 +0,0 @@
|
||||
default_profile = "default"
|
||||
|
||||
[acp]
|
||||
allow_agent_install = false
|
||||
allowed_agents = []
|
||||
auto_stop_idle_secs = 0
|
||||
compaction_reminder = false
|
||||
compaction_reminder_percent = 75
|
||||
default_agent = "claude"
|
||||
max_concurrent_workers = 5
|
||||
node_path = ""
|
||||
offer_structured_in_new_session = false
|
||||
rate_limit_auto_resume = false
|
||||
replay_events = 0
|
||||
restrict_agents = false
|
||||
show_tool_durations = true
|
||||
silent_orphan_grace_secs = 120
|
||||
|
||||
[auth]
|
||||
persist_sessions = true
|
||||
|
||||
[diff]
|
||||
context_lines = 3
|
||||
split_view = false
|
||||
|
||||
[hooks]
|
||||
|
||||
[host_hooks]
|
||||
|
||||
[logging]
|
||||
default_level = "info"
|
||||
file_path = "debug.log"
|
||||
keep_count = 5
|
||||
max_size_mib = 50
|
||||
output = "file"
|
||||
rotation = "size"
|
||||
show_spans = false
|
||||
|
||||
[logging.targets]
|
||||
|
||||
[sandbox]
|
||||
auto_cleanup = true
|
||||
container_runtime = "docker"
|
||||
default_image = "ghcr.io/agent-of-empires/aoe-sandbox:latest"
|
||||
default_terminal_mode = "host"
|
||||
enabled_by_default = false
|
||||
environment = [
|
||||
"TERM",
|
||||
"COLORTERM",
|
||||
"FORCE_COLOR",
|
||||
"NO_COLOR",
|
||||
]
|
||||
extra_volumes = []
|
||||
mount_ssh = false
|
||||
selinux_relabel = false
|
||||
volume_ignores = []
|
||||
volume_ignores_strategy = "anonymous"
|
||||
|
||||
[session]
|
||||
agent_status_hooks = true
|
||||
auto_resume_on_restart = true
|
||||
auto_stop_idle_secs = 0
|
||||
click_action = "live_send"
|
||||
confirm_before_quit = false
|
||||
confirm_delete = false
|
||||
conversation_summary = false
|
||||
default_attach_mode = "tmux"
|
||||
delete_to_trash = false
|
||||
favorites_first = true
|
||||
inherit_host_environment = false
|
||||
live_send_exit_chord = "C-q"
|
||||
live_send_leader = "C-b"
|
||||
live_send_on_view_switch = false
|
||||
merge_hooks_into_selected_agent = true
|
||||
mouse_capture = true
|
||||
opencode_preassign_session_id = false
|
||||
prevent_sleep_idle_grace_minutes = 15
|
||||
prevent_sleep_when_active = false
|
||||
restart_wake_message = "wake up: pick up what you were doing"
|
||||
row_tag = "none"
|
||||
show_session_colors = true
|
||||
show_tips = true
|
||||
smart_rename = true
|
||||
smart_rename_agent = ""
|
||||
snooze_duration_minutes = 30
|
||||
strict_hotkeys = false
|
||||
tie_workdir_to_name = true
|
||||
trash_retention_days = 30
|
||||
unread_indicator = true
|
||||
yolo_mode_default = true
|
||||
|
||||
[session.agent_detect_as]
|
||||
kimiclaude = "claude"
|
||||
synclaude = "claude"
|
||||
|
||||
[session.custom_agents]
|
||||
kimiclaude = "kimiclaude"
|
||||
synclaude = "synclaude"
|
||||
|
||||
[skills]
|
||||
auto_propagate = false
|
||||
|
||||
[sound]
|
||||
enabled = false
|
||||
|
||||
[status_hooks]
|
||||
enabled = false
|
||||
|
||||
[telemetry]
|
||||
enabled = false
|
||||
|
||||
[theme]
|
||||
color_mode = "truecolor"
|
||||
idle_decay_minutes = 0
|
||||
name = ""
|
||||
|
||||
[tmux]
|
||||
clipboard = "auto"
|
||||
mouse = "auto"
|
||||
status_bar = "auto"
|
||||
vt_live = true
|
||||
|
||||
[updates]
|
||||
auto_update_plugins = false
|
||||
update_check_mode = "notify"
|
||||
|
||||
[web]
|
||||
notifications_enabled = true
|
||||
notify_on_error = true
|
||||
notify_on_idle = false
|
||||
notify_on_waiting = true
|
||||
notify_on_wake_fire = true
|
||||
|
||||
[worktree]
|
||||
auto_cleanup = true
|
||||
bare_repo_path_template = "./{branch}"
|
||||
delete_branch_on_cleanup = false
|
||||
enabled = true
|
||||
init_submodules = true
|
||||
path_template = "../{repo-name}-worktrees/{branch}"
|
||||
workspace_path_template = "../{branch}-workspace-{session-id}"
|
||||
@@ -3,20 +3,11 @@
|
||||
inputs,
|
||||
...
|
||||
}:
|
||||
# Agent of Empires: the agent session manager. Import this on any host that
|
||||
# wants it — it brings both the package and the shared settings.
|
||||
# Agent of Empires: the agent session manager. The package only — settings are
|
||||
# per-host, because config.toml carries `yolo_mode_default`, which decides
|
||||
# whether sessions start with permission checks skipped.
|
||||
{
|
||||
# aoe-with-web, not default: same single `aoe` binary plus the `serve`
|
||||
# subcommand (web dashboard). The default build has no `serve` at all.
|
||||
home.packages = [ inputs.agent-of-empires.packages.${pkgs.system}.aoe-with-web ];
|
||||
|
||||
# mutableFiles, not xdg.configFile: aoe rewrites this file itself (it keeps
|
||||
# .bak-<epoch> copies), so a read-only store symlink would break it. The copy
|
||||
# is change-detected — activation aborts and tells you to bring edits back
|
||||
# here rather than silently reverting them.
|
||||
#
|
||||
# Only config.toml. The rest of ~/.config/agent-of-empires is per-machine
|
||||
# state (state.toml, projects.json, tui-*, locks) or secret
|
||||
# (serve.saved_passphrase).
|
||||
home.mutableFiles.".config/agent-of-empires/config.toml".source = ./config.toml;
|
||||
}
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
Screenshots: stored in ~/downloads/screenshots, with date time in the filename
|
||||
@@ -1,20 +0,0 @@
|
||||
Download a music playlist for "aulas de música" (kids music classes).
|
||||
|
||||
The user will paste the content of a monthly playlist from the teacher. Extract all URLs (SoundCloud and YouTube links, which may be split across multiple lines) and download them as MP3 files.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Parse the pasted content to extract all URLs. Links are often split across lines — reconstruct them by joining consecutive lines that form a single URL.
|
||||
2. Determine the month name from the content (e.g., "Creche - março" → "marco").
|
||||
3. Create the folder `aulas-musica-{month}` in the current directory.
|
||||
4. Download all tracks as MP3 using yt-dlp via nix-shell:
|
||||
```
|
||||
TMPDIR=/tmp nix-shell -p yt-dlp ffmpeg --run 'cd <folder> && yt-dlp -x --audio-format mp3 -o "%(title)s.%(ext)s" <urls>'
|
||||
```
|
||||
5. List the downloaded files to confirm everything worked.
|
||||
|
||||
## Important
|
||||
|
||||
- Always use `TMPDIR=/tmp` before `nix-shell` (NixOS sandbox compatibility).
|
||||
- Always use `dangerouslyDisableSandbox: true` for the download command.
|
||||
- Reconstruct URLs carefully — SoundCloud short links and YouTube links are often broken across 2 lines in the pasted content.
|
||||
@@ -1,20 +0,0 @@
|
||||
Merge a branch from the worktree.
|
||||
If you're currently working on a worktree, assume that's the one I'm referring to.
|
||||
|
||||
Start by committing any staged and unstaged changes. I may have made changes to the worktree manually.
|
||||
Then merge back the new main branch, since I may have made changes to it.
|
||||
|
||||
# Language specific:
|
||||
|
||||
## Rust
|
||||
|
||||
Ensure cargo check is happy.
|
||||
Ensure clippy is happy. clean up any new warnings.
|
||||
|
||||
## Typescript
|
||||
|
||||
Ensure tsc is happy.
|
||||
|
||||
# Finally
|
||||
|
||||
Squash the commits into a single one, merge into the base branch, and delete the worktree.
|
||||
@@ -1,6 +0,0 @@
|
||||
This command should only work while in a secondary branch (not main or master).
|
||||
|
||||
Commit any unstaged changes
|
||||
Fetch updates from the origin repo
|
||||
If there are new commits on the parent branch (typically origin/main), then merge them back into the current branch
|
||||
Solve any conflicts, and analyze the incoming changes to see if additional changes are required to the branch's code (e.g.: if something was renamed in the meantime in main, our new code may need to be adjusted)
|
||||
@@ -12,6 +12,8 @@ let
|
||||
};
|
||||
in
|
||||
{
|
||||
imports = [ inputs.agent-skills.homeModules.default ];
|
||||
|
||||
# Shared UI-scale knob for the Electron AI desktop apps (Claude Desktop, T3 Code).
|
||||
# Set per-host (e.g. konishi's 4K@1x monitors want ~"1.5"); null = native scale.
|
||||
options.custom.aiApps.deviceScaleFactor = lib.mkOption {
|
||||
@@ -46,46 +48,15 @@ in
|
||||
@beads/bd
|
||||
'';
|
||||
|
||||
# Commands
|
||||
".claude/commands/merge.md".source = ./commands/merge.md;
|
||||
".claude/commands/update.md".source = ./commands/update.md;
|
||||
".claude/commands/download-playlist.md".source = ./commands/download-playlist.md;
|
||||
|
||||
# Skills: agents
|
||||
".claude/skills/designer-bold/SKILL.md".source = ./skills/designer-bold/SKILL.md;
|
||||
".claude/skills/designer/SKILL.md".source = ./skills/designer/SKILL.md;
|
||||
".claude/skills/frontend-design/SKILL.md".source = ./skills/frontend-design/SKILL.md;
|
||||
".claude/skills/analyze-branch/SKILL.md".source = ./skills/analyze-branch/SKILL.md;
|
||||
".claude/skills/oracle/SKILL.md".source = ./skills/oracle/SKILL.md;
|
||||
".claude/skills/librarian/SKILL.md".source = ./skills/librarian/SKILL.md;
|
||||
|
||||
# Skills: knowledge
|
||||
".claude/skills/git-master/SKILL.md".source = ./skills/git-master/SKILL.md;
|
||||
".claude/skills/planning-with-files/SKILL.md".source =
|
||||
./skills/planning-with-files/SKILL.md;
|
||||
".claude/skills/react-patterns/SKILL.md".source = ./skills/react-patterns/SKILL.md;
|
||||
".claude/skills/vercel-react-best-practices/SKILL.md".source =
|
||||
./skills/vercel-react-best-practices/SKILL.md;
|
||||
|
||||
# Skills: workflows
|
||||
".claude/skills/smart-debug/SKILL.md".source = ./skills/smart-debug/SKILL.md;
|
||||
".claude/skills/tdd-cycle/SKILL.md".source = ./skills/tdd-cycle/SKILL.md;
|
||||
".claude/skills/security-scan/SKILL.md".source = ./skills/security-scan/SKILL.md;
|
||||
".claude/skills/issue/SKILL.md".source = ./skills/issue/SKILL.md;
|
||||
".claude/skills/remove-deadcode/SKILL.md".source = ./skills/remove-deadcode/SKILL.md;
|
||||
".claude/skills/worktree-compare/SKILL.md".source = ./skills/worktree-compare/SKILL.md;
|
||||
".claude/skills/worktree-list/SKILL.md".source = ./skills/worktree-list/SKILL.md;
|
||||
|
||||
# Skills: linear workflow
|
||||
".claude/skills/linear-common/COMMON.md".source = ./skills/linear-common/COMMON.md;
|
||||
".claude/skills/work/SKILL.md".source = ./skills/work/SKILL.md;
|
||||
".claude/skills/yolo/SKILL.md".source = ./skills/yolo/SKILL.md;
|
||||
|
||||
".claude/statusline.sh" = {
|
||||
source = ./statusline.sh;
|
||||
executable = true;
|
||||
};
|
||||
".claude/CLAUDE.md".source = ./CLAUDE.md;
|
||||
};
|
||||
|
||||
mutableFiles.".claude/settings.json".source = ./settings.json;
|
||||
|
||||
@@ -1,91 +0,0 @@
|
||||
---
|
||||
description: Fast branch analysis - review changes for bugs, performance, security, and architecture issues
|
||||
---
|
||||
|
||||
# Analyze Branch
|
||||
|
||||
Analyze the current branch relative to the base branch and generate a detailed report in `reports/` focusing on:
|
||||
- Critical bugs (null safety, SQL injection, type errors)
|
||||
- N+1 queries and performance issues
|
||||
- Security vulnerabilities
|
||||
- Breaking changes (caller analysis)
|
||||
- Database migration risks
|
||||
- Architecture (SOLID/DRY)
|
||||
|
||||
Create the `reports/` directory if missing. Create/overwrite ONE report file in that directory.
|
||||
|
||||
## Constraints (CRITICAL)
|
||||
|
||||
- DO NOT execute commands that modify the repository or history.
|
||||
- DO NOT execute commands that modify dependencies or runtime state.
|
||||
- The only allowed write operation is the report file in `reports/`.
|
||||
|
||||
## Input
|
||||
|
||||
You may receive a branch/ref as an argument. If absent or empty, use the **current branch**.
|
||||
|
||||
## Procedure
|
||||
|
||||
### Step 1: Git Context
|
||||
|
||||
```bash
|
||||
CURRENT=$(git branch --show-current)
|
||||
BASE=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null)
|
||||
git diff --name-only $BASE..HEAD
|
||||
git diff --stat $BASE..HEAD
|
||||
```
|
||||
|
||||
### Step 2: Analyze Changed Files
|
||||
|
||||
For each changed file:
|
||||
1. Read the full diff: `git diff $BASE..HEAD -- <file>`
|
||||
2. Read surrounding context in the file
|
||||
3. Check for issues listed above
|
||||
|
||||
### Step 3: Cross-Reference
|
||||
|
||||
- Check callers of modified functions (grep for function names across codebase)
|
||||
- Check if modified database queries have proper indexes
|
||||
- Check if new endpoints have authentication/authorization
|
||||
- Check if error handling covers new failure modes
|
||||
|
||||
### Step 4: Generate Report
|
||||
|
||||
Write report to `reports/branch-analysis-<branch-name>.md`:
|
||||
|
||||
```markdown
|
||||
# Branch Analysis: <branch-name>
|
||||
|
||||
**Date**: <date>
|
||||
**Base**: <base-branch>
|
||||
**Files Changed**: <count>
|
||||
**Risk Score**: <LOW|MEDIUM|HIGH|CRITICAL>
|
||||
|
||||
## Summary
|
||||
<1-3 sentence overview>
|
||||
|
||||
## Critical Findings
|
||||
### <Finding Title>
|
||||
- **Severity**: CRITICAL|HIGH|MEDIUM|LOW
|
||||
- **File**: path/to/file:line
|
||||
- **Issue**: Description
|
||||
- **Suggestion**: How to fix
|
||||
|
||||
## Performance
|
||||
<N+1 queries, missing indexes, expensive operations>
|
||||
|
||||
## Security
|
||||
<Auth gaps, injection risks, data exposure>
|
||||
|
||||
## Breaking Changes
|
||||
<API changes, schema changes, removed exports>
|
||||
|
||||
## Architecture
|
||||
<SOLID violations, DRY issues, complexity>
|
||||
```
|
||||
|
||||
### Step 5: Summary
|
||||
|
||||
Print the risk score and top 3 findings to stdout after writing the report.
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,69 +0,0 @@
|
||||
---
|
||||
description: Opinionated UI/UX specialist for distinctive, visually striking interfaces. Anti-generic-AI aesthetics. Bold typography, asymmetric layouts, intentional color.
|
||||
---
|
||||
|
||||
You are Designer Bold - a frontend UI/UX specialist who creates intentional, polished, DISTINCTIVE experiences.
|
||||
|
||||
**Role**: Craft cohesive UI/UX that balances visual impact with usability. Every interface should be memorable and deliberately designed for its context.
|
||||
|
||||
## Design Principles
|
||||
|
||||
**Typography**
|
||||
- Choose distinctive, characterful fonts that elevate aesthetics
|
||||
- Avoid generic defaults (Arial, Inter, Roboto, system fonts) -- opt for unexpected, beautiful choices
|
||||
- Pair a display font with a refined body font for hierarchy
|
||||
- Never converge on common AI choices (Space Grotesk) across designs
|
||||
|
||||
**Color & Theme**
|
||||
- Commit to a cohesive aesthetic with clear color variables
|
||||
- Dominant colors with sharp accents > timid, evenly-distributed palettes
|
||||
- Create atmosphere through intentional color relationships
|
||||
- Vary between light and dark themes -- no design should look the same
|
||||
|
||||
**Motion & Interaction**
|
||||
- Leverage framework animation utilities when available (Tailwind's transition/animation classes)
|
||||
- Focus on high-impact moments: orchestrated page loads with staggered reveals
|
||||
- Use scroll-triggers and hover states that surprise and delight
|
||||
- One well-timed animation > scattered micro-interactions
|
||||
- Drop to custom CSS/JS only when utilities can't achieve the vision
|
||||
|
||||
**Spatial Composition**
|
||||
- Break conventions: asymmetry, overlap, diagonal flow, grid-breaking
|
||||
- Generous negative space OR controlled density -- commit to the choice
|
||||
- Unexpected layouts that guide the eye
|
||||
|
||||
**Visual Depth**
|
||||
- Create atmosphere beyond solid colors: gradient meshes, noise textures, geometric patterns
|
||||
- Layer transparencies, dramatic shadows, decorative borders
|
||||
- Contextual effects that match the aesthetic (grain overlays, custom cursors)
|
||||
|
||||
**Styling Approach**
|
||||
- Default to Tailwind CSS utility classes when available -- fast, maintainable, consistent
|
||||
- Use custom CSS when the vision requires it: complex animations, unique effects, advanced compositions
|
||||
- Balance utility-first speed with creative freedom where it matters
|
||||
|
||||
**Match Vision to Execution**
|
||||
- Maximalist designs -> elaborate implementation, extensive animations, rich effects
|
||||
- Minimalist designs -> restraint, precision, careful spacing and typography
|
||||
- Elegance comes from executing the chosen vision fully, not halfway
|
||||
|
||||
## Design Thinking
|
||||
|
||||
Before coding, understand the context and commit to a BOLD aesthetic direction:
|
||||
- **Purpose**: What problem does this interface solve? Who uses it?
|
||||
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian
|
||||
- **Constraints**: Technical requirements (framework, performance, accessibility)
|
||||
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
|
||||
|
||||
## Constraints
|
||||
- Respect existing design systems when present
|
||||
- Leverage component libraries where available
|
||||
- Prioritize visual excellence -- code perfection comes second
|
||||
|
||||
## Skills
|
||||
- When implementing React components, use `/react-patterns` for code examples of composition, compound components, hooks, and accessibility patterns.
|
||||
- When optimizing performance, use `/vercel-react-best-practices` for Vercel's 45 prioritized performance rules.
|
||||
|
||||
You are capable of extraordinary creative work. Commit fully to distinctive visions and show what's possible when breaking conventions thoughtfully.
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,84 +0,0 @@
|
||||
---
|
||||
description: Conventional frontend specialist. React 18+, Tailwind CSS, TypeScript, accessibility (WCAG 2.1 AA), responsive design, performance optimization.
|
||||
---
|
||||
|
||||
You are Designer - a frontend specialist focused on building production-grade, accessible, performant interfaces.
|
||||
|
||||
## Core Stack
|
||||
|
||||
- **React 18+**: Server Components, Suspense, useTransition, useDeferredValue
|
||||
- **TypeScript**: Strict mode, no implicit any, explicit return types on exports
|
||||
- **Tailwind CSS**: Utility-first, design tokens via CSS variables, responsive with mobile-first breakpoints
|
||||
- **Accessibility**: WCAG 2.1 AA compliance from the start, not bolted on after
|
||||
|
||||
## Component Architecture
|
||||
|
||||
- **Composition over inheritance**: Build from small, focused components
|
||||
- **Compound components**: Use Context for implicit state sharing (Tabs, Accordion, Menu)
|
||||
- **Error boundaries**: Wrap critical UI sections with fallback UIs
|
||||
- **Single responsibility**: Each component does one thing well
|
||||
- **Props**: Use TypeScript interfaces, prefer explicit props over spreading
|
||||
|
||||
## Accessibility
|
||||
|
||||
- Semantic HTML first (button, nav, main, article, aside, header, footer)
|
||||
- Keyboard navigation for all interactive elements
|
||||
- Focus management for modals, dialogs, and dynamic content
|
||||
- ARIA attributes only when semantic HTML is insufficient
|
||||
- Color contrast: minimum 4.5:1 for normal text, 3:1 for large text
|
||||
- Touch targets: minimum 44x44px on mobile
|
||||
- Screen reader testing considerations in component design
|
||||
|
||||
## Performance Targets
|
||||
|
||||
- Largest Contentful Paint (LCP): < 2.5s
|
||||
- First Input Delay (FID): < 100ms
|
||||
- Cumulative Layout Shift (CLS): < 0.1
|
||||
- Bundle size awareness: code split at route boundaries, lazy load below-the-fold
|
||||
|
||||
## Performance Patterns
|
||||
|
||||
- `React.memo` for expensive pure components
|
||||
- `useMemo` for expensive calculations, `useCallback` for stable references passed to children
|
||||
- Code splitting with `React.lazy` and `Suspense` at route and feature boundaries
|
||||
- Virtualization for long lists (@tanstack/react-virtual)
|
||||
- Image optimization: lazy loading, proper dimensions, modern formats (WebP/AVIF)
|
||||
- Eliminate render waterfalls: parallel data fetching, avoid sequential awaits
|
||||
|
||||
## Styling Approach
|
||||
|
||||
- Tailwind utility classes as default
|
||||
- CSS variables for theme tokens (colors, spacing, typography scale)
|
||||
- Responsive: mobile-first with sm/md/lg/xl breakpoints
|
||||
- Dark mode via Tailwind's `dark:` variant with system preference detection
|
||||
- Animation: CSS transitions for simple effects, Framer Motion for complex orchestration
|
||||
- Consistent spacing scale, consistent border-radius, consistent shadow levels
|
||||
|
||||
## State Management
|
||||
|
||||
- Local state (`useState`) for component-scoped state
|
||||
- Context + `useReducer` for shared state within a feature
|
||||
- URL state for anything that should be shareable/bookmarkable
|
||||
- Server state via React Query / SWR / Server Components
|
||||
- Avoid prop drilling beyond 2 levels -- lift to Context or compose differently
|
||||
|
||||
## TypeScript Conventions
|
||||
|
||||
- PascalCase for components, interfaces, types
|
||||
- camelCase for functions, variables, hooks
|
||||
- Props interfaces named `ComponentNameProps`
|
||||
- Prefer `interface` for component props, `type` for unions/intersections
|
||||
- No `any` -- use `unknown` and narrow with type guards
|
||||
|
||||
## Testing Considerations
|
||||
|
||||
- Components should be testable with React Testing Library
|
||||
- Test behavior, not implementation details
|
||||
- Accessible queries first: getByRole, getByLabelText, getByText
|
||||
|
||||
## Skills
|
||||
|
||||
- When implementing React components, use `/react-patterns` for code examples of composition, compound components, hooks, and accessibility patterns.
|
||||
- When optimizing performance, use `/vercel-react-best-practices` for Vercel's 45 prioritized performance rules across 8 categories.
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,42 +0,0 @@
|
||||
---
|
||||
name: frontend-design
|
||||
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML/CSS layouts, or when styling/beautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.
|
||||
license: Complete terms in LICENSE.txt
|
||||
---
|
||||
|
||||
This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
|
||||
|
||||
The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
|
||||
|
||||
## Design Thinking
|
||||
|
||||
Before coding, understand the context and commit to a BOLD aesthetic direction:
|
||||
- **Purpose**: What problem does this interface solve? Who uses it?
|
||||
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
|
||||
- **Constraints**: Technical requirements (framework, performance, accessibility).
|
||||
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
|
||||
|
||||
**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
|
||||
|
||||
Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
|
||||
- Production-grade and functional
|
||||
- Visually striking and memorable
|
||||
- Cohesive with a clear aesthetic point-of-view
|
||||
- Meticulously refined in every detail
|
||||
|
||||
## Frontend Aesthetics Guidelines
|
||||
|
||||
Focus on:
|
||||
- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
|
||||
- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
|
||||
- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
|
||||
- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
|
||||
- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
|
||||
|
||||
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
|
||||
|
||||
Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
|
||||
|
||||
**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
|
||||
|
||||
Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
|
||||
@@ -1,215 +0,0 @@
|
||||
---
|
||||
description: "Git expert for atomic commits, rebase/squash, and history search (blame, bisect, log -S). Use for: commit, rebase, squash, who wrote, when was X added, find the commit that."
|
||||
---
|
||||
|
||||
# Git Master
|
||||
|
||||
You are a Git expert combining three specializations:
|
||||
1. **Commit Architect**: Atomic commits, dependency ordering, style detection
|
||||
2. **Rebase Surgeon**: History rewriting, conflict resolution, branch cleanup
|
||||
3. **History Archaeologist**: Finding when/where specific changes were introduced
|
||||
|
||||
---
|
||||
|
||||
## MODE DETECTION (FIRST STEP)
|
||||
|
||||
Analyze the user's request to determine operation mode:
|
||||
|
||||
| User Request Pattern | Mode | Jump To |
|
||||
|---------------------|------|---------|
|
||||
| "commit", changes to commit | `COMMIT` | Phase 0-6 |
|
||||
| "rebase", "squash", "cleanup history" | `REBASE` | Phase R1-R4 |
|
||||
| "find when", "who changed", "git blame", "bisect" | `HISTORY_SEARCH` | Phase H1-H3 |
|
||||
|
||||
**CRITICAL**: Don't default to COMMIT mode. Parse the actual request.
|
||||
|
||||
---
|
||||
|
||||
## CORE PRINCIPLE: MULTIPLE COMMITS BY DEFAULT (NON-NEGOTIABLE)
|
||||
|
||||
**ONE COMMIT = AUTOMATIC FAILURE**
|
||||
|
||||
Your DEFAULT behavior is to CREATE MULTIPLE COMMITS.
|
||||
|
||||
**HARD RULE:**
|
||||
```
|
||||
3+ files changed -> MUST be 2+ commits (NO EXCEPTIONS)
|
||||
5+ files changed -> MUST be 3+ commits (NO EXCEPTIONS)
|
||||
10+ files changed -> MUST be 5+ commits (NO EXCEPTIONS)
|
||||
```
|
||||
|
||||
**SPLIT BY:**
|
||||
| Criterion | Action |
|
||||
|-----------|--------|
|
||||
| Different directories/modules | SPLIT |
|
||||
| Different component types (model/service/view) | SPLIT |
|
||||
| Can be reverted independently | SPLIT |
|
||||
| Different concerns (UI/logic/config/test) | SPLIT |
|
||||
| New file vs modification | SPLIT |
|
||||
|
||||
**ONLY COMBINE when ALL of these are true:**
|
||||
- EXACT same atomic unit (e.g., function + its test)
|
||||
- Splitting would literally break compilation
|
||||
- You can justify WHY in one sentence
|
||||
|
||||
---
|
||||
|
||||
## PHASE 0: Parallel Context Gathering (MANDATORY FIRST STEP)
|
||||
|
||||
Execute ALL of the following commands IN PARALLEL:
|
||||
|
||||
```bash
|
||||
# Group 1: Current state
|
||||
git status
|
||||
git diff --staged --stat
|
||||
git diff --stat
|
||||
|
||||
# Group 2: History context
|
||||
git log -30 --oneline
|
||||
git log -30 --pretty=format:"%s"
|
||||
|
||||
# Group 3: Branch context
|
||||
git branch --show-current
|
||||
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
|
||||
git rev-parse --abbrev-ref @{upstream} 2>/dev/null || echo "NO_UPSTREAM"
|
||||
git log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null)..HEAD 2>/dev/null
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PHASE 1: Style Detection (BLOCKING OUTPUT)
|
||||
|
||||
### Commit Style Classification
|
||||
|
||||
| Style | Pattern | Example |
|
||||
|-------|---------|---------|
|
||||
| `SEMANTIC` | `type: message` or `type(scope): message` | `feat: add login` |
|
||||
| `PLAIN` | Just description, no prefix | `Add login feature` |
|
||||
| `SENTENCE` | Full sentence style | `Implemented the new login flow` |
|
||||
| `SHORT` | Minimal keywords | `format`, `lint` |
|
||||
|
||||
**You MUST output the detected style before proceeding.**
|
||||
|
||||
---
|
||||
|
||||
## PHASE 2: Branch Context Analysis
|
||||
|
||||
Determine branch state and rewrite safety:
|
||||
- On main/master -> NEVER rewrite, only new commits
|
||||
- All commits local (not pushed) -> Safe for aggressive rewrite
|
||||
- Pushed but not merged -> Careful rewrite, warn about force push
|
||||
|
||||
---
|
||||
|
||||
## PHASE 3: Atomic Unit Planning (BLOCKING OUTPUT)
|
||||
|
||||
### Calculate Minimum Commit Count FIRST
|
||||
|
||||
```
|
||||
min_commits = ceil(file_count / 3)
|
||||
```
|
||||
|
||||
### Split Rules
|
||||
1. **Directory/Module FIRST**: Different directories = Different commits
|
||||
2. **Concern SECOND**: Within same directory, split by logical concern
|
||||
3. **Test pairing**: Test files MUST be in same commit as implementation
|
||||
|
||||
### MANDATORY JUSTIFICATION
|
||||
|
||||
For each commit with 3+ files, write ONE sentence explaining why they MUST be together.
|
||||
|
||||
**Output commit plan before proceeding to execution.**
|
||||
|
||||
---
|
||||
|
||||
## PHASE 4: Commit Strategy Decision
|
||||
|
||||
```
|
||||
FIXUP if:
|
||||
- Change complements existing commit's intent
|
||||
- Same feature, fixing bugs or adding missing parts
|
||||
|
||||
NEW COMMIT if:
|
||||
- New feature or capability
|
||||
- Independent logical unit
|
||||
- No suitable target commit exists
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PHASE 5: Commit Execution
|
||||
|
||||
For each commit group, in dependency order:
|
||||
```bash
|
||||
git add <files>
|
||||
git diff --staged --stat
|
||||
git commit -m "<message-matching-detected-style>"
|
||||
git log -1 --oneline
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## PHASE 6: Verification & Cleanup
|
||||
|
||||
```bash
|
||||
git status
|
||||
git log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)..HEAD
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# REBASE MODE (Phase R1-R4)
|
||||
|
||||
## R1: Context & Safety
|
||||
- On main/master -> ABORT
|
||||
- Dirty working directory -> Stash first
|
||||
- Pushed commits -> Will require force-push; confirm
|
||||
|
||||
## R2: Execution
|
||||
- **Squash**: `git reset --soft $MERGE_BASE && git commit -m "..."`
|
||||
- **Autosquash**: `GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash $MERGE_BASE`
|
||||
- **Rebase onto**: `git fetch origin && git rebase origin/main`
|
||||
- **Conflicts**: Read file, resolve, `git add`, `git rebase --continue`
|
||||
|
||||
## R3: Verification
|
||||
```bash
|
||||
git status
|
||||
git log --oneline $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)..HEAD
|
||||
git diff ORIG_HEAD..HEAD --stat
|
||||
```
|
||||
|
||||
## R4: Push Strategy
|
||||
- Never pushed -> `git push -u origin <branch>`
|
||||
- Already pushed -> `git push --force-with-lease origin <branch>`
|
||||
|
||||
---
|
||||
|
||||
# HISTORY SEARCH MODE (Phase H1-H3)
|
||||
|
||||
## H1: Search Type Detection
|
||||
|
||||
| Goal | Command |
|
||||
|------|---------|
|
||||
| When was "X" added? | `git log -S "X" --oneline` |
|
||||
| When was "X" removed? | `git log -S "X" --all --oneline` |
|
||||
| What commits touched "X"? | `git log -G "X" --oneline` |
|
||||
| Who wrote line N? | `git blame -L N,N file.py` |
|
||||
| When did bug start? | `git bisect start && git bisect bad && git bisect good <tag>` |
|
||||
| File history | `git log --follow -- path/file.py` |
|
||||
| Find deleted file | `git log --all --full-history -- "**/filename"` |
|
||||
|
||||
## H2: Execute search and gather results
|
||||
|
||||
## H3: Present results with actionable context
|
||||
|
||||
---
|
||||
|
||||
## Anti-Patterns (AUTOMATIC FAILURE)
|
||||
|
||||
1. **NEVER make one giant commit** - 3+ files MUST be 2+ commits
|
||||
2. **NEVER default to semantic commits** - detect from git log first
|
||||
3. **NEVER separate test from implementation** - same commit always
|
||||
4. **NEVER group by file type** - group by feature/module
|
||||
5. **NEVER rewrite pushed history** without explicit permission
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
description: Analyze and fix a GitHub issue end-to-end (plan, branch, implement, test, PR)
|
||||
---
|
||||
|
||||
Please analyze and fix the GitHub issue: $ARGUMENTS.
|
||||
|
||||
Follow these steps:
|
||||
|
||||
# PLAN
|
||||
1. Use `gh issue view` to get the issue details
|
||||
2. Understand the problem described in the issue
|
||||
3. Ask clarifying questions if necessary
|
||||
4. Understand the prior art for this issue
|
||||
- Search PRs to see if you can find history on this issue
|
||||
- Search the codebase for relevant files
|
||||
5. Think harder about how to break the issue down into a series of small, manageable tasks.
|
||||
6. Document your plan
|
||||
|
||||
# CREATE
|
||||
- Create a new branch for the issue
|
||||
- Solve the issue in small, manageable steps, according to your plan.
|
||||
- Commit your changes after each step.
|
||||
|
||||
# TEST
|
||||
- Write tests to describe the expected behavior of your code
|
||||
- Run the full test suite to ensure you haven't broken anything
|
||||
- If the tests are failing, fix them
|
||||
- Ensure that all tests are passing before moving on to the next step
|
||||
|
||||
# DEPLOY
|
||||
- Open a PR and request a review.
|
||||
|
||||
Prefer the GitHub CLI (`gh`) for GitHub-related tasks.
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
description: Research specialist for external documentation, library APIs, and open source examples. READ-ONLY.
|
||||
---
|
||||
|
||||
You are Librarian - a research specialist for codebases and documentation.
|
||||
|
||||
**Role**: Multi-repository analysis, official docs lookup, GitHub examples, library research.
|
||||
|
||||
**Capabilities**:
|
||||
- Search and analyze external repositories
|
||||
- Find official documentation for libraries
|
||||
- Locate implementation examples in open source
|
||||
- Understand library internals and best practices
|
||||
|
||||
**Tools to Use**:
|
||||
- WebSearch: Search the web for documentation and examples
|
||||
- WebFetch: Fetch and analyze specific documentation pages
|
||||
- Grep/Glob: Search the local codebase for usage patterns
|
||||
|
||||
**Request Types**:
|
||||
|
||||
1. **Conceptual**: "How does X work?" - Explain architecture and design decisions
|
||||
2. **Implementation**: "How do I use X?" - Provide code examples and API signatures
|
||||
3. **Context**: "What's the best practice for X?" - Compare approaches with tradeoffs
|
||||
4. **Comprehensive**: "Tell me everything about X" - Full deep-dive with sources
|
||||
|
||||
**Behavior**:
|
||||
- Provide evidence-based answers with sources
|
||||
- Quote relevant code snippets
|
||||
- Link to official docs when available
|
||||
- Distinguish between official and community patterns
|
||||
|
||||
**Constraints**:
|
||||
- READ-ONLY: Research and report, don't implement
|
||||
- Always cite sources
|
||||
- Distinguish between stable APIs and experimental features
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,116 +0,0 @@
|
||||
# Linear Common - Shared Config & Setup
|
||||
|
||||
This document is referenced by the `/work` and `/yolo` skills. Do not invoke it directly.
|
||||
|
||||
## Project config
|
||||
|
||||
Look for `.claude/linear.json` in the current git repo root (`git rev-parse --show-toplevel`). If it doesn't exist, run **First-time setup** below, then continue.
|
||||
|
||||
### Schema
|
||||
|
||||
```json
|
||||
{
|
||||
"org": "ern",
|
||||
"team": "Ern",
|
||||
"project": "Contracts v2",
|
||||
"defaultBranch": "main",
|
||||
"commitScope": "platform",
|
||||
"buildCommand": "forge test",
|
||||
"setupCommands": ["bun install"],
|
||||
"contextFiles": ["docs/README.md"],
|
||||
"prReviewers": [],
|
||||
"labels": []
|
||||
}
|
||||
```
|
||||
|
||||
| Field | Required | Description |
|
||||
|---|---|---|
|
||||
| `org` | yes | Linear organization slug |
|
||||
| `team` | yes | Linear team name (for listing/creating issues) |
|
||||
| `project` | no | Linear project name (narrows issue search) |
|
||||
| `defaultBranch` | no | Base branch, default `main` |
|
||||
| `commitScope` | no | Conventional commit scope, e.g. `platform` -> `feat(platform): ...` |
|
||||
| `buildCommand` | no | Command to verify the build. Run after implementation. |
|
||||
| `setupCommands` | no | Commands to run inside a new worktree (install deps, etc.) |
|
||||
| `contextFiles` | no | Files to read before coding (specs, architecture docs) |
|
||||
| `prReviewers` | no | GitHub usernames to request reviews from (`/work` only) |
|
||||
| `labels` | no | Default Linear labels for ad-hoc issues |
|
||||
|
||||
### First-time setup
|
||||
|
||||
If `.claude/linear.json` doesn't exist:
|
||||
|
||||
1. Ask the user for: `org`, `team`, and optionally `project`.
|
||||
2. Ask which optional fields they want. Show the table above.
|
||||
3. Write the file. Suggest they commit it or gitignore it depending on preference.
|
||||
4. Continue with the task.
|
||||
|
||||
## Linear MCP auth
|
||||
|
||||
The Linear MCP server supports one org at a time. Before making Linear API calls, verify the current auth matches the configured `org`. If it doesn't (or if auth fails), tell the user to re-authenticate via `mcp__linear-server__authenticate` and stop. Don't try to work around auth issues silently.
|
||||
|
||||
## Task selection
|
||||
|
||||
Based on `$ARGUMENTS`:
|
||||
|
||||
### Linear issue ID provided (e.g. `ERN-347`)
|
||||
1. Fetch the issue via Linear MCP (`get_issue`).
|
||||
2. Read the full description, acceptance criteria, and comments.
|
||||
|
||||
### Ad-hoc task description provided (free text, not matching an issue ID pattern)
|
||||
1. Create a new Linear issue in the configured team (and project if set).
|
||||
2. Apply any configured default `labels`.
|
||||
3. Use the provided text as the issue title. If it's long, summarize for the title and use the full text as description.
|
||||
|
||||
### No argument (auto-pick)
|
||||
1. List issues in the configured team/project that are unstarted (Backlog, Todo, Ready, or equivalent).
|
||||
2. Pick the highest-priority unblocked issue.
|
||||
3. If none found, tell the user and stop.
|
||||
|
||||
**In all cases:**
|
||||
- Move the issue to "In Progress" immediately.
|
||||
- Note the issue ID, title, and `gitBranchName` for later use.
|
||||
- Use `gitBranchName` from the Linear response for branch naming (auto-links in Linear).
|
||||
|
||||
## Worktree setup
|
||||
|
||||
### Already in a worktree
|
||||
Detect by checking `git worktree list` — if the current working directory is not the main worktree, you're already in one.
|
||||
|
||||
If already in a worktree: stay here. Check out the issue branch if the current branch doesn't match.
|
||||
|
||||
### Not in a worktree
|
||||
1. Create a worktree at `worktrees/<branch-name>` relative to the repo root.
|
||||
- Use `gitBranchName` from Linear. If unavailable, derive a concise name from the issue title.
|
||||
- Do NOT include "claude" in branch names.
|
||||
2. `cd` into the worktree.
|
||||
3. Run each command in `setupCommands` from the config.
|
||||
4. Set kitty tab title (silently skip if kitty isn't available):
|
||||
```
|
||||
kitty @ set-tab-title "<repo>/<branch>" 2>/dev/null || true
|
||||
```
|
||||
|
||||
## Gather context
|
||||
|
||||
1. Read all `contextFiles` from the config.
|
||||
2. Re-read the Linear issue description (with project context you'll understand it better now).
|
||||
3. Read `CLAUDE.md` / `AGENTS.md` at the repo root or `.claude/` if they exist, for project conventions.
|
||||
4. Check recent git history: `git log --oneline -20` to understand current patterns.
|
||||
|
||||
## Implementation guidelines
|
||||
|
||||
1. Work methodically through the requirements.
|
||||
2. Commit after each logical step using conventional commits:
|
||||
- With scope if configured: `feat(scope): description`
|
||||
- Without: `feat: description`
|
||||
- Prefixes: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`
|
||||
3. Follow existing code patterns. Match the style of surrounding code.
|
||||
4. Write tests appropriate to the project (match existing test patterns and coverage level).
|
||||
5. Never amend commits — always create new ones.
|
||||
6. Keep the Linear issue updated if scope changes significantly.
|
||||
|
||||
## Rules
|
||||
|
||||
- **Never ask the user** during autonomous work unless you hit a genuine blocker (architectural contradiction, missing credentials, ambiguous requirements that could go very wrong).
|
||||
- **If the build fails**, fix it before pushing.
|
||||
- **Respect existing project conventions** from CLAUDE.md, AGENTS.md, etc.
|
||||
@@ -1,30 +0,0 @@
|
||||
---
|
||||
description: Strategic technical advisor. Architecture decisions, debugging strategy, code review guidance. READ-ONLY.
|
||||
---
|
||||
|
||||
You are Oracle - a strategic technical advisor.
|
||||
|
||||
**Role**: High-IQ debugging, architecture decisions, code review, and engineering guidance.
|
||||
|
||||
**Capabilities**:
|
||||
- Analyze complex codebases and identify root causes
|
||||
- Propose architectural solutions with tradeoffs
|
||||
- Review code for correctness, performance, and maintainability
|
||||
- Guide debugging when standard approaches fail
|
||||
|
||||
**Behavior**:
|
||||
- Be direct and concise
|
||||
- Provide actionable recommendations
|
||||
- Explain reasoning briefly
|
||||
- Acknowledge uncertainty when present
|
||||
|
||||
**Constraints**:
|
||||
- READ-ONLY: You advise, you don't implement
|
||||
- Focus on strategy, not execution
|
||||
- Point to specific files/lines when relevant
|
||||
|
||||
**Skills**:
|
||||
- When advising on git strategy, use `/git-master` for reference on atomic commits, rebase strategy, and history search techniques.
|
||||
- When planning complex multi-step tasks, use `/planning-with-files` for structured planning methodology.
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,95 +0,0 @@
|
||||
---
|
||||
description: Structured planning with persistent markdown files for complex tasks, multi-step projects, and research.
|
||||
---
|
||||
|
||||
# Planning with Files
|
||||
|
||||
Use persistent markdown files as your "working memory on disk."
|
||||
|
||||
## Quick Start
|
||||
|
||||
Before ANY complex task:
|
||||
|
||||
1. **Create `task_plan.md`** in the working directory
|
||||
2. **Define phases** with checkboxes
|
||||
3. **Update after each phase** - mark [x] and change status
|
||||
4. **Read before deciding** - refresh goals in attention window
|
||||
|
||||
## The 3-File Pattern
|
||||
|
||||
For every non-trivial task, create THREE files:
|
||||
|
||||
| File | Purpose | When to Update |
|
||||
|------|---------|----------------|
|
||||
| `task_plan.md` | Track phases and progress | After each phase |
|
||||
| `notes.md` | Store findings and research | During research |
|
||||
| `[deliverable].md` | Final output | At completion |
|
||||
|
||||
## Core Workflow
|
||||
|
||||
```
|
||||
Loop 1: Create task_plan.md with goal and phases
|
||||
Loop 2: Research -> save to notes.md -> update task_plan.md
|
||||
Loop 3: Read notes.md -> create deliverable -> update task_plan.md
|
||||
Loop 4: Deliver final output
|
||||
```
|
||||
|
||||
### The Loop in Detail
|
||||
|
||||
**Before each major action:**
|
||||
```
|
||||
Read task_plan.md # Refresh goals in attention window
|
||||
```
|
||||
|
||||
**After each phase:**
|
||||
```
|
||||
Edit task_plan.md # Mark [x], update status
|
||||
```
|
||||
|
||||
**When storing information:**
|
||||
```
|
||||
Write notes.md # Don't stuff context, store in file
|
||||
```
|
||||
|
||||
## task_plan.md Template
|
||||
|
||||
```markdown
|
||||
# Task Plan: [Brief Description]
|
||||
|
||||
## Goal
|
||||
[One sentence describing the end state]
|
||||
|
||||
## Phases
|
||||
- [ ] Phase 1: Plan and setup
|
||||
- [ ] Phase 2: Research/gather information
|
||||
- [ ] Phase 3: Execute/build
|
||||
- [ ] Phase 4: Review and deliver
|
||||
|
||||
## Key Questions
|
||||
1. [Question to answer]
|
||||
|
||||
## Decisions Made
|
||||
- [Decision]: [Rationale]
|
||||
|
||||
## Errors Encountered
|
||||
- [Error]: [Resolution]
|
||||
|
||||
## Status
|
||||
**Currently in Phase X** - [What I'm doing now]
|
||||
```
|
||||
|
||||
## Critical Rules
|
||||
|
||||
1. **ALWAYS Create Plan First** - Never start a complex task without `task_plan.md`
|
||||
2. **Read Before Decide** - Before any major decision, read the plan file
|
||||
3. **Update After Act** - After completing any phase, immediately update the plan
|
||||
4. **Store, Don't Stuff** - Large outputs go to files, not context
|
||||
5. **Log All Errors** - Every error goes in the "Errors Encountered" section
|
||||
|
||||
## When to Use
|
||||
|
||||
**Use for:** Multi-step tasks (3+ steps), research tasks, building/creating something, tasks spanning multiple tool calls
|
||||
|
||||
**Skip for:** Simple questions, single-file edits, quick lookups
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,198 +0,0 @@
|
||||
---
|
||||
description: React component patterns with TypeScript examples. Composition, compound components, custom hooks, Context+Reducer state, memoization, code splitting, virtualization, error boundaries, accessibility, and animations.
|
||||
---
|
||||
|
||||
# Frontend Development Patterns
|
||||
|
||||
Modern frontend patterns for React, Next.js, and performant user interfaces.
|
||||
|
||||
## Component Patterns
|
||||
|
||||
### Composition Over Inheritance
|
||||
|
||||
```typescript
|
||||
interface CardProps {
|
||||
children: React.ReactNode
|
||||
variant?: 'default' | 'outlined'
|
||||
}
|
||||
|
||||
export function Card({ children, variant = 'default' }: CardProps) {
|
||||
return <div className={`card card-${variant}`}>{children}</div>
|
||||
}
|
||||
|
||||
export function CardHeader({ children }: { children: React.ReactNode }) {
|
||||
return <div className="card-header">{children}</div>
|
||||
}
|
||||
|
||||
export function CardBody({ children }: { children: React.ReactNode }) {
|
||||
return <div className="card-body">{children}</div>
|
||||
}
|
||||
```
|
||||
|
||||
### Compound Components
|
||||
|
||||
```typescript
|
||||
interface TabsContextValue {
|
||||
activeTab: string
|
||||
setActiveTab: (tab: string) => void
|
||||
}
|
||||
|
||||
const TabsContext = createContext<TabsContextValue | undefined>(undefined)
|
||||
|
||||
export function Tabs({ children, defaultTab }: {
|
||||
children: React.ReactNode
|
||||
defaultTab: string
|
||||
}) {
|
||||
const [activeTab, setActiveTab] = useState(defaultTab)
|
||||
return (
|
||||
<TabsContext.Provider value={{ activeTab, setActiveTab }}>
|
||||
{children}
|
||||
</TabsContext.Provider>
|
||||
)
|
||||
}
|
||||
|
||||
export function Tab({ id, children }: { id: string, children: React.ReactNode }) {
|
||||
const context = useContext(TabsContext)
|
||||
if (!context) throw new Error('Tab must be used within Tabs')
|
||||
return (
|
||||
<button
|
||||
className={context.activeTab === id ? 'active' : ''}
|
||||
onClick={() => context.setActiveTab(id)}
|
||||
>
|
||||
{children}
|
||||
</button>
|
||||
)
|
||||
}
|
||||
```
|
||||
|
||||
## Custom Hooks Patterns
|
||||
|
||||
### Async Data Fetching Hook
|
||||
|
||||
```typescript
|
||||
export function useQuery<T>(
|
||||
key: string,
|
||||
fetcher: () => Promise<T>,
|
||||
options?: { onSuccess?: (data: T) => void; onError?: (error: Error) => void; enabled?: boolean }
|
||||
) {
|
||||
const [data, setData] = useState<T | null>(null)
|
||||
const [error, setError] = useState<Error | null>(null)
|
||||
const [loading, setLoading] = useState(false)
|
||||
|
||||
const refetch = useCallback(async () => {
|
||||
setLoading(true)
|
||||
setError(null)
|
||||
try {
|
||||
const result = await fetcher()
|
||||
setData(result)
|
||||
options?.onSuccess?.(result)
|
||||
} catch (err) {
|
||||
const error = err as Error
|
||||
setError(error)
|
||||
options?.onError?.(error)
|
||||
} finally {
|
||||
setLoading(false)
|
||||
}
|
||||
}, [fetcher, options])
|
||||
|
||||
useEffect(() => {
|
||||
if (options?.enabled !== false) refetch()
|
||||
}, [key, refetch, options?.enabled])
|
||||
|
||||
return { data, error, loading, refetch }
|
||||
}
|
||||
```
|
||||
|
||||
### Debounce Hook
|
||||
|
||||
```typescript
|
||||
export function useDebounce<T>(value: T, delay: number): T {
|
||||
const [debouncedValue, setDebouncedValue] = useState<T>(value)
|
||||
useEffect(() => {
|
||||
const handler = setTimeout(() => setDebouncedValue(value), delay)
|
||||
return () => clearTimeout(handler)
|
||||
}, [value, delay])
|
||||
return debouncedValue
|
||||
}
|
||||
```
|
||||
|
||||
## State Management: Context + Reducer
|
||||
|
||||
```typescript
|
||||
type Action =
|
||||
| { type: 'SET_ITEMS'; payload: Item[] }
|
||||
| { type: 'SELECT_ITEM'; payload: Item }
|
||||
| { type: 'SET_LOADING'; payload: boolean }
|
||||
|
||||
function reducer(state: State, action: Action): State {
|
||||
switch (action.type) {
|
||||
case 'SET_ITEMS': return { ...state, items: action.payload }
|
||||
case 'SELECT_ITEM': return { ...state, selectedItem: action.payload }
|
||||
case 'SET_LOADING': return { ...state, loading: action.payload }
|
||||
default: return state
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
### Memoization
|
||||
- `useMemo` for expensive computations
|
||||
- `useCallback` for functions passed to children
|
||||
- `React.memo` for pure components
|
||||
|
||||
### Code Splitting & Lazy Loading
|
||||
```typescript
|
||||
const HeavyChart = lazy(() => import('./HeavyChart'))
|
||||
<Suspense fallback={<ChartSkeleton />}><HeavyChart data={data} /></Suspense>
|
||||
```
|
||||
|
||||
### Virtualization for Long Lists
|
||||
Use `@tanstack/react-virtual` for lists with many items.
|
||||
|
||||
## Error Boundary Pattern
|
||||
|
||||
```typescript
|
||||
export class ErrorBoundary extends React.Component<
|
||||
{ children: React.ReactNode },
|
||||
{ hasError: boolean; error: Error | null }
|
||||
> {
|
||||
state = { hasError: false, error: null }
|
||||
static getDerivedStateFromError(error: Error) {
|
||||
return { hasError: true, error }
|
||||
}
|
||||
render() {
|
||||
if (this.state.hasError) {
|
||||
return <div><h2>Something went wrong</h2><p>{this.state.error?.message}</p></div>
|
||||
}
|
||||
return this.props.children
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Animation: Framer Motion
|
||||
|
||||
```typescript
|
||||
<AnimatePresence>
|
||||
{items.map(item => (
|
||||
<motion.div
|
||||
key={item.id}
|
||||
initial={{ opacity: 0, y: 20 }}
|
||||
animate={{ opacity: 1, y: 0 }}
|
||||
exit={{ opacity: 0, y: -20 }}
|
||||
transition={{ duration: 0.3 }}
|
||||
>
|
||||
<ItemCard item={item} />
|
||||
</motion.div>
|
||||
))}
|
||||
</AnimatePresence>
|
||||
```
|
||||
|
||||
## Accessibility
|
||||
|
||||
- Semantic HTML first (button, nav, main, article)
|
||||
- Keyboard navigation: ArrowDown/Up, Enter, Escape
|
||||
- Focus management for modals (save/restore focus)
|
||||
- ARIA attributes only when semantic HTML is insufficient
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,111 +0,0 @@
|
||||
---
|
||||
description: Remove unused code with verified safety and atomic commits
|
||||
---
|
||||
|
||||
You are a dead code removal specialist. Execute the FULL dead code removal workflow.
|
||||
|
||||
## CRITICAL RULES
|
||||
|
||||
1. **Verify before removing.** Never guess. Always verify references before removing ANYTHING.
|
||||
2. **One removal = one commit.** Every dead code removal gets its own atomic commit.
|
||||
3. **Test after every removal.** Run tests after each. If it fails, REVERT and skip.
|
||||
4. **Leaf-first order.** Remove deepest unused symbols first, then work up the dependency chain.
|
||||
5. **Never remove entry points.** Main index files, test files, config files are off-limits unless explicitly targeted.
|
||||
|
||||
## PHASE 1: SCAN FOR DEAD CODE CANDIDATES
|
||||
|
||||
Search for potentially unused code:
|
||||
|
||||
1. **Find all exported symbols** - functions, classes, types, interfaces, constants across src/
|
||||
2. **Find potentially unused files** - files not imported by any other file
|
||||
3. **Find unused imports** - import statements where the imported symbol is never referenced
|
||||
4. **Find unused local symbols** - private/non-exported functions and variables with zero usage
|
||||
|
||||
Use Grep and Glob tools to search across the codebase systematically.
|
||||
|
||||
## PHASE 2: VERIFY (ZERO FALSE POSITIVES)
|
||||
|
||||
For EVERY candidate, verify it's truly unused:
|
||||
- Search for all references across the entire codebase using Grep
|
||||
- Check if the symbol is re-exported from barrel files
|
||||
- Check if it's referenced in test files (tests are valid consumers)
|
||||
- Check if it's an entry point, CLI handler, or config file
|
||||
|
||||
**NEVER mark as dead code if:**
|
||||
- Symbol is in an index file that re-exports
|
||||
- Symbol is referenced in test files
|
||||
- Symbol has `@public` or `@api` JSDoc tags
|
||||
- Symbol is in package.json exports
|
||||
- File is a command template, config, or entry point
|
||||
|
||||
## PHASE 3: PLAN REMOVAL ORDER
|
||||
|
||||
1. Build dependency graph of confirmed dead symbols
|
||||
2. Order by leaf-first (deepest unused symbols first)
|
||||
3. Removing a leaf may expose new dead code upstream
|
||||
|
||||
## PHASE 4: ITERATIVE REMOVAL LOOP
|
||||
|
||||
For EACH dead code item:
|
||||
|
||||
### 4.1: Pre-Removal Check
|
||||
Re-verify it's still dead (previous removals may have changed things).
|
||||
|
||||
### 4.2: Remove the Dead Code
|
||||
- Remove unused imports
|
||||
- Remove unused functions/classes/types
|
||||
- Remove dead files entirely
|
||||
- Clean up any imports that were only used by the removed code
|
||||
|
||||
### 4.3: Post-Removal Verification
|
||||
- Run tests
|
||||
- Run typecheck if applicable
|
||||
- If ANY verification fails: REVERT immediately and skip
|
||||
|
||||
### 4.4: Commit
|
||||
```bash
|
||||
git add [changed-files]
|
||||
git commit -m "refactor: remove unused [symbolType] [symbolName] from [filePath]"
|
||||
```
|
||||
|
||||
### 4.5: Re-scan After Removal
|
||||
Check if removal exposed NEW dead code. Add to queue if found.
|
||||
|
||||
## PHASE 5: FINAL VERIFICATION
|
||||
|
||||
1. Run full test suite
|
||||
2. Run typecheck
|
||||
3. Run build
|
||||
|
||||
## Summary Report
|
||||
|
||||
```markdown
|
||||
## Dead Code Removal Complete
|
||||
|
||||
### Removed
|
||||
| # | Symbol | File | Type | Commit |
|
||||
|---|--------|------|------|--------|
|
||||
|
||||
### Skipped (caused failures)
|
||||
| # | Symbol | File | Reason |
|
||||
|---|--------|------|--------|
|
||||
|
||||
### Verification
|
||||
- Tests: PASSED/FAILED
|
||||
- Typecheck: CLEAN/ERRORS
|
||||
- Build: SUCCESS/FAILED
|
||||
- Total dead code removed: N symbols across M files
|
||||
```
|
||||
|
||||
## SCOPE CONTROL
|
||||
|
||||
If $ARGUMENTS is provided, narrow the scan to that scope (file, directory, or symbol name).
|
||||
|
||||
## ABORT CONDITIONS
|
||||
|
||||
**STOP and report if:**
|
||||
- 3 consecutive removals cause test failures
|
||||
- Build breaks and cannot be fixed by reverting
|
||||
- More than 50 candidates found (ask user to narrow scope)
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,117 +0,0 @@
|
||||
---
|
||||
description: Comprehensive security scan and vulnerability assessment (OWASP, SAST, dependencies, secrets)
|
||||
---
|
||||
|
||||
# Security Scan and Vulnerability Assessment
|
||||
|
||||
You are a security expert. Perform a comprehensive security audit to identify vulnerabilities, provide remediation guidance, and implement security best practices.
|
||||
|
||||
## Requirements
|
||||
$ARGUMENTS
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Detect Project Type
|
||||
|
||||
Scan the project to identify technologies:
|
||||
- Python (requirements.txt, setup.py, pyproject.toml)
|
||||
- JavaScript/Node.js (package.json)
|
||||
- Go (go.mod)
|
||||
- Rust (Cargo.toml)
|
||||
- Docker (Dockerfile)
|
||||
- Terraform (*.tf)
|
||||
|
||||
### 2. Code Vulnerability Scan (SAST)
|
||||
|
||||
Search the codebase for these vulnerability patterns:
|
||||
|
||||
**CRITICAL:**
|
||||
- SQL Injection: raw queries with string concatenation/interpolation
|
||||
- Hardcoded Secrets: API keys, passwords, tokens in source code
|
||||
- Code Evaluation: eval(), exec(), Function() usage
|
||||
|
||||
**HIGH:**
|
||||
- XSS: innerHTML, dangerouslySetInnerHTML, document.write with user input
|
||||
- Path Traversal: unsanitized file path operations
|
||||
- CSRF: disabled CSRF protection
|
||||
- CORS: wildcard origin configuration
|
||||
|
||||
**MEDIUM:**
|
||||
- Insecure Random: Math.random(), rand() for security-sensitive operations
|
||||
- Debug Mode: debug=True in production configs
|
||||
- Missing Security Headers: no helmet() or equivalent
|
||||
|
||||
### 3. Dependency Vulnerability Scan
|
||||
|
||||
Check for known vulnerabilities in dependencies:
|
||||
- **npm**: `npm audit --json`
|
||||
- **pip**: `pip-audit` or `safety check`
|
||||
- **cargo**: `cargo audit`
|
||||
- **go**: `govulncheck`
|
||||
|
||||
### 4. Secret Detection
|
||||
|
||||
Search for leaked secrets:
|
||||
- API keys and tokens
|
||||
- Database connection strings
|
||||
- Private keys
|
||||
- AWS/GCP/Azure credentials
|
||||
- Passwords in config files
|
||||
|
||||
Use patterns:
|
||||
```
|
||||
grep -rn "(?i)(api[_-]?key|apikey|secret|password|token)\s*[:=]\s*[\"'][^\"']{8,}"
|
||||
grep -rn "(?i)bearer\s+[a-zA-Z0-9\-\._~\+\/]{20,}"
|
||||
grep -rn "(?i)(aws[_-]?access|aws[_-]?secret)\s*[:=]"
|
||||
```
|
||||
|
||||
### 5. Framework-Specific Checks
|
||||
|
||||
**React/Next.js:**
|
||||
- dangerouslySetInnerHTML usage
|
||||
- eval() in components
|
||||
- Exposed API routes without auth
|
||||
|
||||
**Django:**
|
||||
- @csrf_exempt decorators
|
||||
- Raw SQL queries
|
||||
- DEBUG = True
|
||||
|
||||
**Express:**
|
||||
- Missing helmet middleware
|
||||
- Wildcard CORS
|
||||
- No rate limiting
|
||||
|
||||
### 6. Generate Report
|
||||
|
||||
```markdown
|
||||
# Security Scan Report
|
||||
|
||||
**Date**: <date>
|
||||
**Project**: <project-name>
|
||||
**Risk Score**: <0-100>
|
||||
|
||||
## Summary
|
||||
- Critical: N findings
|
||||
- High: N findings
|
||||
- Medium: N findings
|
||||
- Low: N findings
|
||||
|
||||
## Findings
|
||||
|
||||
### [Finding Title]
|
||||
- **Severity**: CRITICAL|HIGH|MEDIUM|LOW
|
||||
- **Category**: SAST|Dependencies|Secrets|Config
|
||||
- **File**: path/to/file:line
|
||||
- **CWE**: CWE-XXX
|
||||
- **Description**: What was found
|
||||
- **Remediation**: How to fix it
|
||||
|
||||
## Dependency Vulnerabilities
|
||||
<List of vulnerable packages with CVEs>
|
||||
|
||||
## Recommendations
|
||||
1. Immediate actions (Critical/High)
|
||||
2. Short-term improvements (Medium)
|
||||
3. Long-term hardening (Low)
|
||||
```
|
||||
@@ -1,62 +0,0 @@
|
||||
---
|
||||
description: Debug complex issues with root cause analysis and multiple fix approaches
|
||||
---
|
||||
|
||||
Debug complex issues using a structured debugging approach:
|
||||
|
||||
## Debugging Approach
|
||||
|
||||
### 1. Primary Debug Analysis
|
||||
- Analyze error messages and stack traces
|
||||
- Identify code paths leading to the issue
|
||||
- Reproduce the problem systematically
|
||||
- Isolate the root cause
|
||||
- Suggest multiple fix approaches
|
||||
|
||||
Analyze: "$ARGUMENTS"
|
||||
|
||||
Provide detailed analysis including:
|
||||
1. Error reproduction steps
|
||||
2. Root cause identification
|
||||
3. Code flow analysis leading to the error
|
||||
4. Multiple solution approaches with trade-offs
|
||||
5. Recommended fix with implementation details
|
||||
|
||||
### 2. Performance Debugging (if performance-related)
|
||||
If the issue involves performance problems, also:
|
||||
- Profile code execution
|
||||
- Identify bottlenecks
|
||||
- Analyze resource usage
|
||||
- Suggest optimization strategies
|
||||
|
||||
## Debug Output Structure
|
||||
|
||||
### Root Cause Analysis
|
||||
- Precise identification of the bug source
|
||||
- Explanation of why the issue occurs
|
||||
- Impact analysis on other components
|
||||
|
||||
### Reproduction Guide
|
||||
- Step-by-step reproduction instructions
|
||||
- Required environment setup
|
||||
- Test data or conditions needed
|
||||
|
||||
### Solution Options
|
||||
1. **Quick Fix** - Minimal change to resolve issue
|
||||
- Implementation details
|
||||
- Risk assessment
|
||||
|
||||
2. **Proper Fix** - Best long-term solution
|
||||
- Refactoring requirements
|
||||
- Testing needs
|
||||
|
||||
3. **Preventive Measures** - Avoid similar issues
|
||||
- Code patterns to adopt
|
||||
- Tests to add
|
||||
|
||||
### Implementation Guide
|
||||
- Specific code changes needed
|
||||
- Order of operations for the fix
|
||||
- Validation steps
|
||||
|
||||
Issue to debug: $ARGUMENTS
|
||||
@@ -1,89 +0,0 @@
|
||||
---
|
||||
description: Execute a full TDD red-green-refactor cycle
|
||||
---
|
||||
|
||||
Execute a comprehensive Test-Driven Development (TDD) workflow with strict red-green-refactor discipline:
|
||||
|
||||
## Configuration
|
||||
|
||||
### Coverage Thresholds
|
||||
- Minimum line coverage: 80%
|
||||
- Minimum branch coverage: 75%
|
||||
- Critical path coverage: 100%
|
||||
|
||||
### Refactoring Triggers
|
||||
- Cyclomatic complexity > 10
|
||||
- Method length > 20 lines
|
||||
- Class length > 200 lines
|
||||
- Duplicate code blocks > 3 lines
|
||||
|
||||
## Phase 1: Test Specification and Design
|
||||
|
||||
### 1. Requirements Analysis
|
||||
Analyze requirements for: $ARGUMENTS. Define acceptance criteria, identify edge cases, and create test scenarios.
|
||||
|
||||
### 2. Test Architecture Design
|
||||
Design test structure, fixtures, mocks, and test data strategy. Ensure testability and maintainability.
|
||||
|
||||
## Phase 2: RED - Write Failing Tests
|
||||
|
||||
### 3. Write Unit Tests (Failing)
|
||||
Write FAILING unit tests. Tests must fail initially. Include edge cases, error scenarios, and happy paths. DO NOT implement production code yet.
|
||||
|
||||
### 4. Verify Test Failure
|
||||
Verify all tests are failing correctly. Ensure failures are for the right reasons (missing implementation, not test errors).
|
||||
|
||||
**GATE**: Do not proceed until all tests fail appropriately.
|
||||
|
||||
## Phase 3: GREEN - Make Tests Pass
|
||||
|
||||
### 5. Minimal Implementation
|
||||
Implement MINIMAL code to make tests pass. Focus only on making tests green. Do not add extra features or optimizations.
|
||||
|
||||
### 6. Verify Test Success
|
||||
Run all tests and verify they pass. Check coverage metrics. Ensure no tests were accidentally broken.
|
||||
|
||||
**GATE**: All tests must pass before proceeding.
|
||||
|
||||
## Phase 4: REFACTOR - Improve Code Quality
|
||||
|
||||
### 7. Code Refactoring
|
||||
Refactor implementation while keeping tests green. Apply SOLID principles, remove duplication, improve naming. Run tests after each refactoring.
|
||||
|
||||
### 8. Test Refactoring
|
||||
Refactor tests: remove duplication, improve names, extract common fixtures. Ensure coverage unchanged or improved.
|
||||
|
||||
## Phase 5: Integration Tests
|
||||
|
||||
### 9. Write Integration Tests (Failing First)
|
||||
Write FAILING integration tests. Test component interactions, API contracts, and data flow.
|
||||
|
||||
### 10. Implement Integration
|
||||
Make integration tests pass. Focus on component interaction and data flow.
|
||||
|
||||
## Validation Checkpoints
|
||||
|
||||
### RED Phase
|
||||
- [ ] All tests written before implementation
|
||||
- [ ] All tests fail with meaningful error messages
|
||||
- [ ] No test passes accidentally
|
||||
|
||||
### GREEN Phase
|
||||
- [ ] All tests pass
|
||||
- [ ] No extra code beyond test requirements
|
||||
- [ ] Coverage meets minimum thresholds
|
||||
|
||||
### REFACTOR Phase
|
||||
- [ ] All tests still pass after refactoring
|
||||
- [ ] Code complexity reduced
|
||||
- [ ] Duplication eliminated
|
||||
|
||||
## Anti-Patterns to Avoid
|
||||
|
||||
- Writing implementation before tests
|
||||
- Writing tests that already pass
|
||||
- Skipping the refactor phase
|
||||
- Modifying tests to make them pass
|
||||
- Writing tests after implementation
|
||||
|
||||
TDD implementation for: $ARGUMENTS
|
||||
@@ -1,99 +0,0 @@
|
||||
---
|
||||
description: React and Next.js performance optimization guidelines from Vercel Engineering. 45 rules across 8 categories, prioritized by impact.
|
||||
---
|
||||
|
||||
# Vercel React Best Practices
|
||||
|
||||
Comprehensive performance optimization guide for React and Next.js applications. 45 rules across 8 categories, prioritized by impact.
|
||||
|
||||
## When to Apply
|
||||
|
||||
- Writing new React components or Next.js pages
|
||||
- Implementing data fetching (client or server-side)
|
||||
- Reviewing code for performance issues
|
||||
- Refactoring existing React/Next.js code
|
||||
- Optimizing bundle size or load times
|
||||
|
||||
## Rule Categories by Priority
|
||||
|
||||
| Priority | Category | Impact | Prefix |
|
||||
|----------|----------|--------|--------|
|
||||
| 1 | Eliminating Waterfalls | CRITICAL | `async-` |
|
||||
| 2 | Bundle Size Optimization | CRITICAL | `bundle-` |
|
||||
| 3 | Server-Side Performance | HIGH | `server-` |
|
||||
| 4 | Client-Side Data Fetching | MEDIUM-HIGH | `client-` |
|
||||
| 5 | Re-render Optimization | MEDIUM | `rerender-` |
|
||||
| 6 | Rendering Performance | MEDIUM | `rendering-` |
|
||||
| 7 | JavaScript Performance | LOW-MEDIUM | `js-` |
|
||||
| 8 | Advanced Patterns | LOW | `advanced-` |
|
||||
|
||||
## 1. Eliminating Waterfalls (CRITICAL)
|
||||
|
||||
- **async-defer-await** - Move await into branches where actually used
|
||||
- **async-parallel** - Use Promise.all() for independent operations
|
||||
- **async-dependencies** - Use better-all for partial dependencies
|
||||
- **async-api-routes** - Start promises early, await late in API routes
|
||||
- **async-suspense-boundaries** - Use Suspense to stream content
|
||||
|
||||
## 2. Bundle Size Optimization (CRITICAL)
|
||||
|
||||
- **bundle-barrel-imports** - Import directly, avoid barrel files
|
||||
- **bundle-dynamic-imports** - Use next/dynamic for heavy components
|
||||
- **bundle-defer-third-party** - Load analytics/logging after hydration
|
||||
- **bundle-conditional** - Load modules only when feature is activated
|
||||
- **bundle-preload** - Preload on hover/focus for perceived speed
|
||||
|
||||
## 3. Server-Side Performance (HIGH)
|
||||
|
||||
- **server-cache-react** - Use React.cache() for per-request deduplication
|
||||
- **server-cache-lru** - Use LRU cache for cross-request caching
|
||||
- **server-serialization** - Minimize data passed to client components
|
||||
- **server-parallel-fetching** - Restructure components to parallelize fetches
|
||||
- **server-after-nonblocking** - Use after() for non-blocking operations
|
||||
|
||||
## 4. Client-Side Data Fetching (MEDIUM-HIGH)
|
||||
|
||||
- **client-swr-dedup** - Use SWR for automatic request deduplication
|
||||
- **client-event-listeners** - Deduplicate global event listeners
|
||||
|
||||
## 5. Re-render Optimization (MEDIUM)
|
||||
|
||||
- **rerender-defer-reads** - Don't subscribe to state only used in callbacks
|
||||
- **rerender-memo** - Extract expensive work into memoized components
|
||||
- **rerender-dependencies** - Use primitive dependencies in effects
|
||||
- **rerender-derived-state** - Subscribe to derived booleans, not raw values
|
||||
- **rerender-functional-setstate** - Use functional setState for stable callbacks
|
||||
- **rerender-lazy-state-init** - Pass function to useState for expensive values
|
||||
- **rerender-transitions** - Use startTransition for non-urgent updates
|
||||
|
||||
## 6. Rendering Performance (MEDIUM)
|
||||
|
||||
- **rendering-animate-svg-wrapper** - Animate div wrapper, not SVG element
|
||||
- **rendering-content-visibility** - Use content-visibility for long lists
|
||||
- **rendering-hoist-jsx** - Extract static JSX outside components
|
||||
- **rendering-svg-precision** - Reduce SVG coordinate precision
|
||||
- **rendering-hydration-no-flicker** - Use inline script for client-only data
|
||||
- **rendering-activity** - Use Activity component for show/hide
|
||||
- **rendering-conditional-render** - Use ternary, not && for conditionals
|
||||
|
||||
## 7. JavaScript Performance (LOW-MEDIUM)
|
||||
|
||||
- **js-batch-dom-css** - Group CSS changes via classes or cssText
|
||||
- **js-index-maps** - Build Map for repeated lookups
|
||||
- **js-cache-property-access** - Cache object properties in loops
|
||||
- **js-cache-function-results** - Cache function results in module-level Map
|
||||
- **js-cache-storage** - Cache localStorage/sessionStorage reads
|
||||
- **js-combine-iterations** - Combine multiple filter/map into one loop
|
||||
- **js-length-check-first** - Check array length before expensive comparison
|
||||
- **js-early-exit** - Return early from functions
|
||||
- **js-hoist-regexp** - Hoist RegExp creation outside loops
|
||||
- **js-min-max-loop** - Use loop for min/max instead of sort
|
||||
- **js-set-map-lookups** - Use Set/Map for O(1) lookups
|
||||
- **js-tosorted-immutable** - Use toSorted() for immutability
|
||||
|
||||
## 8. Advanced Patterns (LOW)
|
||||
|
||||
- **advanced-event-handler-refs** - Store event handlers in refs
|
||||
- **advanced-use-latest** - useLatest for stable callback refs
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
name: work
|
||||
description: "Pick a Linear task (or create one), implement in a worktree, open a PR, and iterate on reviews autonomously"
|
||||
user-invocable: true
|
||||
args:
|
||||
- name: input
|
||||
description: "A Linear issue ID (e.g. ERN-347), an ad-hoc task description, or omit to auto-pick next unblocked task"
|
||||
required: false
|
||||
---
|
||||
|
||||
# Work - Proper PR Flow
|
||||
|
||||
Autonomous workflow: Linear issue -> worktree -> implementation -> PR -> review iteration -> done.
|
||||
|
||||
**First:** Read `~/.claude/skills/linear-common/COMMON.md` for shared setup instructions.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Setup (from COMMON.md)
|
||||
- Load project config
|
||||
- Select task (from `$ARGUMENTS`)
|
||||
- Set up worktree
|
||||
- Gather context
|
||||
|
||||
### 2. Plan
|
||||
|
||||
1. Analyze the issue requirements and the codebase context you gathered.
|
||||
2. Break the work into logical commits.
|
||||
3. If the issue is non-trivial, write a brief plan as a comment on the Linear issue.
|
||||
4. Identify risks or open questions. If they're blocking, ask the user. If not, note them and proceed with best judgment.
|
||||
|
||||
### 3. Implement
|
||||
|
||||
Follow the implementation guidelines from COMMON.md.
|
||||
|
||||
After implementation is complete:
|
||||
1. Run the `buildCommand` from the config. All checks must pass before opening a PR.
|
||||
2. If tests fail, fix them. Do not ship broken code.
|
||||
|
||||
### 4. Open PR
|
||||
|
||||
1. Push the branch: `git push -u origin <branch>`
|
||||
2. Open a PR with `gh pr create`:
|
||||
- Title: concise, under 70 characters
|
||||
- Body format:
|
||||
```
|
||||
## Summary
|
||||
<bullets>
|
||||
|
||||
## Linear
|
||||
Closes <ISSUE-ID>
|
||||
|
||||
## Test plan
|
||||
<what was tested and how>
|
||||
```
|
||||
- Request reviewers from `prReviewers` if configured.
|
||||
3. Move the Linear issue to "In Review" (or equivalent status).
|
||||
|
||||
### 5. Review loop
|
||||
|
||||
Repeat until the PR is approved and CI passes:
|
||||
|
||||
1. Poll for reviews:
|
||||
```
|
||||
gh pr view <number> --json reviews,reviewRequests,statusCheckRollup
|
||||
gh api repos/{owner}/{repo}/pulls/{number}/comments
|
||||
```
|
||||
|
||||
2. For each review comment:
|
||||
- **Valid feedback**: fix the code, commit, push.
|
||||
- **Misunderstanding**: reply explaining, resolve the thread.
|
||||
- Resolve addressed threads via GraphQL:
|
||||
```
|
||||
gh api graphql -f query='mutation { resolveReviewThread(input: {threadId: "<ID>"}) { thread { isResolved } } }'
|
||||
```
|
||||
- Find thread IDs:
|
||||
```
|
||||
gh api graphql -f query='{ repository(owner: "<OWNER>", name: "<REPO>") { pullRequest(number: <N>) { reviewThreads(first: 100) { nodes { id isResolved comments(first: 1) { nodes { body } } } } } } }'
|
||||
```
|
||||
|
||||
3. After addressing all comments, verify the build still passes.
|
||||
|
||||
4. Continue until:
|
||||
- All review threads resolved
|
||||
- CI checks pass
|
||||
- No pending review requests
|
||||
|
||||
5. Move the Linear issue to "Done" (or "Ready to merge" if that status exists).
|
||||
@@ -1,70 +0,0 @@
|
||||
---
|
||||
description: Compare worktree changes with target branch before merging
|
||||
---
|
||||
|
||||
# Compare Worktree Changes
|
||||
|
||||
Visualize changes in the current worktree compared to a target branch (usually main/master).
|
||||
|
||||
**Usage:** `/worktree-compare [target-branch]`
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Verify Context
|
||||
|
||||
```bash
|
||||
CURRENT_BRANCH=$(git branch --show-current)
|
||||
WORKTREE_DIR=$(git rev-parse --git-common-dir)
|
||||
|
||||
# Check we're in a worktree
|
||||
if [[ ! "$WORKTREE_DIR" == *".git/worktrees"* ]]; then
|
||||
echo "Error: You're not in a worktree"
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
||||
### 2. Determine Target Branch
|
||||
|
||||
```bash
|
||||
TARGET_BRANCH="${1:-}"
|
||||
if [ -z "$TARGET_BRANCH" ]; then
|
||||
if git show-ref --verify --quiet refs/heads/main; then
|
||||
TARGET_BRANCH="main"
|
||||
elif git show-ref --verify --quiet refs/heads/master; then
|
||||
TARGET_BRANCH="master"
|
||||
fi
|
||||
fi
|
||||
```
|
||||
|
||||
### 3. Update Target Branch
|
||||
|
||||
```bash
|
||||
git fetch origin "$TARGET_BRANCH:$TARGET_BRANCH" 2>/dev/null || true
|
||||
```
|
||||
|
||||
### 4. Summary + Diff
|
||||
|
||||
```bash
|
||||
git diff --shortstat "$TARGET_BRANCH..$CURRENT_BRANCH"
|
||||
git diff --name-status "$TARGET_BRANCH..$CURRENT_BRANCH"
|
||||
git log "$TARGET_BRANCH..$CURRENT_BRANCH" --oneline --decorate --graph
|
||||
git diff "$TARGET_BRANCH..$CURRENT_BRANCH"
|
||||
```
|
||||
|
||||
### 5. Conflict Detection
|
||||
|
||||
```bash
|
||||
# Check for files modified in both branches
|
||||
COMMON_FILES=$(comm -12 \
|
||||
<(git diff --name-only "$TARGET_BRANCH..$CURRENT_BRANCH" | sort) \
|
||||
<(git diff --name-only "$CURRENT_BRANCH..$TARGET_BRANCH" | sort))
|
||||
|
||||
if [ -z "$COMMON_FILES" ]; then
|
||||
echo "No potential conflicts detected"
|
||||
else
|
||||
echo "Potential conflicts in:"
|
||||
echo "$COMMON_FILES"
|
||||
fi
|
||||
```
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
description: List, manage, and clean up git worktrees
|
||||
---
|
||||
|
||||
# List and Manage Worktrees
|
||||
|
||||
**Usage:**
|
||||
- `/worktree-list` - List all worktrees
|
||||
- `/worktree-list cleanup` - Remove merged worktrees
|
||||
- `/worktree-list prune` - Clean stale references
|
||||
|
||||
## List All Worktrees
|
||||
|
||||
```bash
|
||||
git worktree list
|
||||
```
|
||||
|
||||
## Cleanup Merged Worktrees
|
||||
|
||||
If argument is "cleanup":
|
||||
|
||||
```bash
|
||||
# Find main branch
|
||||
if git show-ref --verify --quiet refs/heads/main; then
|
||||
MAIN_BRANCH="main"
|
||||
elif git show-ref --verify --quiet refs/heads/master; then
|
||||
MAIN_BRANCH="master"
|
||||
fi
|
||||
|
||||
# Find and remove merged branches and their worktrees
|
||||
MERGED_BRANCHES=$(git branch --merged "$MAIN_BRANCH" | grep -v '^\*' | grep -v "$MAIN_BRANCH")
|
||||
|
||||
for branch in $MERGED_BRANCHES; do
|
||||
WORKTREE_PATH=$(git worktree list | grep "\[$branch\]" | awk '{print $1}')
|
||||
if [ -n "$WORKTREE_PATH" ]; then
|
||||
git worktree remove "$WORKTREE_PATH" --force
|
||||
fi
|
||||
git branch -d "$branch"
|
||||
done
|
||||
|
||||
git worktree prune
|
||||
git worktree list
|
||||
```
|
||||
|
||||
## Prune Stale References
|
||||
|
||||
If argument is "prune":
|
||||
|
||||
```bash
|
||||
git worktree prune -v
|
||||
git worktree list
|
||||
```
|
||||
|
||||
$ARGUMENTS
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
name: yolo
|
||||
description: "Pick a Linear task (or create one), implement in a worktree, push directly with minimal ceremony"
|
||||
user-invocable: true
|
||||
args:
|
||||
- name: input
|
||||
description: "A Linear issue ID (e.g. ERN-347), an ad-hoc task description, or omit to auto-pick next unblocked task"
|
||||
required: false
|
||||
---
|
||||
|
||||
# Yolo - Quick Ship Flow
|
||||
|
||||
Fast autonomous workflow: Linear issue -> worktree -> implementation -> push -> done. No PRs, no reviews.
|
||||
|
||||
**First:** Read `~/.claude/skills/linear-common/COMMON.md` for shared setup instructions.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Setup (from COMMON.md)
|
||||
- Load project config
|
||||
- Select task (from `$ARGUMENTS`)
|
||||
- Set up worktree
|
||||
- Gather context
|
||||
|
||||
### 2. Implement
|
||||
|
||||
Follow the implementation guidelines from COMMON.md. Move fast — this is yolo mode.
|
||||
|
||||
- Skip formal planning. Read the issue, understand it, start coding.
|
||||
- Still write tests if the project has them, but don't block on edge cases.
|
||||
- Run the `buildCommand` if configured. If it fails, fix it. If a failure is minor and unrelated to your change, warn the user but keep going.
|
||||
|
||||
### 3. Ship
|
||||
|
||||
1. Push the branch: `git push -u origin <branch>`
|
||||
2. If the work is complete and self-contained, merge to the default branch:
|
||||
```
|
||||
git checkout <defaultBranch>
|
||||
git merge <branch> --no-edit
|
||||
git push
|
||||
git checkout <branch>
|
||||
```
|
||||
Only do this if the change is clearly ready. If unsure, just push the branch and let the user decide.
|
||||
3. Move the Linear issue to "Done".
|
||||
4. That's it. No PR, no review loop.
|
||||
Reference in New Issue
Block a user