パワーユーザーセットアップチェックリスト

# Project Guidelines

## Build & Test
- Build: `npm run build`
- Test: `npm test`
- Lint: `npm run lint`

## Code Style
- Use TypeScript strict mode
- Prefer functional components in React
- Write tests for new features

droid
> /settings
# Navigate to Model and select your default

# My Development Preferences

## Code Style
- I prefer arrow functions over function declarations
- I like early returns over nested conditionals
- I use 2-space indentation

## Testing
- I use React Testing Library, not Enzyme
- I prefer integration tests over unit tests for components
- Mock external APIs, not internal modules

## Past Decisions
- [2024-01] Chose Zustand over Redux for state management
- [2024-02] Using Tailwind CSS for styling

## Personal Preferences
Refer to `~/.factory/memories.md` for my coding preferences and past decisions.

# Project Memories

## Architecture Decisions
- We use the repository pattern for data access
- All API routes go through the /api/v1 prefix
- Feature flags are managed via LaunchDarkly

## Known Issues
- The auth service has a 5-second timeout issue (#123)
- Legacy users table uses snake_case columns

.factory/
└── rules/
    ├── typescript.md
    ├── testing.md
    └── security.md

# TypeScript Conventions

## General
- Use `interface` for object types, `type` for unions/intersections
- Avoid `any` - use `unknown` with type guards instead
- Export types alongside their implementations

## React Components
- Use functional components with TypeScript FC type
- Props interfaces should be named `{ComponentName}Props`
- Use `React.ReactNode` for children, not `React.ReactChild`

## Imports
- Group imports: React, external libs, internal modules, types
- Use absolute imports from `@/` prefix
- Avoid barrel files (index.ts re-exports) for performance

# Testing Conventions

## File Organization
- Test files live next to source: `Component.tsx` → `Component.test.tsx`
- Integration tests go in `__tests__/integration/`
- E2E tests go in `e2e/`

## Test Structure
- Use descriptive test names: "should [action] when [condition]"
- One assertion per test when possible
- Use `beforeEach` for common setup, not `beforeAll`

## Mocking
- Mock at the boundary (API calls, not internal functions)
- Use MSW for API mocking in integration tests
- Reset mocks in `afterEach`

## Coding Standards
Follow the conventions documented in:
- `.factory/rules/typescript.md` - TypeScript and React patterns
- `.factory/rules/testing.md` - Testing conventions
- `.factory/rules/security.md` - Security requirements

---
name: prompt-refiner
description: Improve prompts before sending them to get better results. Use when you want to refine a task description.
---

# Prompt Refiner

## Instructions

When the user wants to refine a prompt:

1. Ask for their draft prompt or task description
2. Analyze it for:
   - Clarity: Is the goal specific and measurable?
   - Context: Does it include relevant background?
   - Constraints: Are requirements and limitations stated?
   - 例: Would examples help clarify expectations?
3. Suggest an improved version with explanations
4. Offer to iterate if needed

## Good Prompt Patterns

- Start with the outcome: "Create a..." not "I want you to..."
- Include acceptance criteria: "The result should..."
- Specify format: "Return as JSON/markdown/code"
- Mention constraints: "Must be compatible with...", "Should not modify..."

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Create|Edit|ApplyPatch",
        "hooks": [
          {
            "type": "command",
            "command": "cd \"$FACTORY_PROJECT_DIR\" && npx prettier --write \"$(jq -r '.tool_input.file_path' 2>/dev/null || echo '')\" 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|ApplyPatch",
        "hooks": [
          {
            "type": "command",
            "command": "cd \"$FACTORY_PROJECT_DIR\" && jq -r '.tool_input.file_path' | xargs -I {} npm test -- --findRelatedTests {} --passWithNoTests 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

droid
> /settings
# Set Spec Mode Model to a reasoning-heavy model

droid
> /readiness-report