` - Sample inputs/outputs if helpful
-
-**Ordering matters:**
-1. Context first (what exists)
-2. Task second (what to do)
-3. Requirements third (how to do it)
-4. Examples last (clarifying edge cases)
-
-### 3. Enhance for Reasoning
-For complex tasks, add:
-- "Think through the approach before implementing"
-- "Consider these edge cases: ..."
-- "Explain your reasoning for key decisions"
-
-### 4. Output the Refined Prompt
-Present the improved prompt with:
-- Clear section headers
-- XML tags where beneficial
-- Specific, measurable criteria
-
-## Example Transformation
-
-**Before:**
-"Add caching to the API"
-
-**After:**
-```
-
-The /api/products endpoint currently queries the database on every request.
-Average response time is 200ms. We use Redis for other caching in the app.
-
-
-
-Add Redis caching to the /api/products endpoint to reduce database load.
-
-
-
-- Cache TTL of 5 minutes
-- Cache invalidation when products are updated
-- Graceful fallback to database if Redis is unavailable
-- Add cache hit/miss metrics logging
-
-
-
-- Don't change the response format
-- Must pass existing integration tests
-- Use our existing Redis connection from src/lib/redis.ts
-
-```
-```
-
----
-
-## GPT Models (GPT-5, GPT-5.1, Codex)
-
-GPT models excel with clear system-level context and benefit from explicit role framing.
-
-### Key Techniques for GPT
-
-
-
- GPT models respond well to clear role definitions:
-
- ```
- You are a senior TypeScript developer reviewing code for a production e-commerce platform.
- Focus on: type safety, error handling, and performance.
-
- Review this checkout flow implementation...
- ```
-
-
-
- GPT follows numbered instructions reliably:
-
- ```
- Complete these steps in order:
- 1. Read the current implementation in src/auth/
- 2. Identify all places where tokens are validated
- 3. Create a centralized token validation utility
- 4. Update all call sites to use the new utility
- 5. Add unit tests for the utility
- 6. Run the test suite and fix any failures
- ```
-
-
-
- Specify exactly what you want:
-
- ```
- Return your analysis as a markdown document with these sections:
- ## Summary (2-3 sentences)
- ## Issues Found (bulleted list)
- ## Recommended Changes (numbered, in priority order)
- ## Code Examples (if applicable)
- ```
-
-
-
-### GPT Prompt Refiner Skill
-
-Create `~/.factory/skills/prompt-refiner-gpt/SKILL.md`:
-
-```markdown
----
-name: prompt-refiner-gpt
-description: Refine prompts for GPT models (GPT-5, GPT-5.1, Codex) using OpenAI's best practices. Use when preparing complex tasks for GPT.
----
-
-# GPT Prompt Refiner
-
-## When to Use
-Invoke this skill when you have a task for GPT that:
-- Requires a specific persona or expertise
-- Involves procedural steps
-- Needs structured output
-- Benefits from explicit examples
-
-## Refinement Process
-
-### 1. Analyze the Draft Prompt
-Review for:
-- [ ] Clear role/persona definition
-- [ ] Step-by-step breakdown (if procedural)
-- [ ] Output format specification
-- [ ] Concrete examples
-
-### 2. Apply GPT-Specific Patterns
-
-**Role framing:**
-Start with "You are a [specific role] working on [specific context]..."
-
-**Numbered procedures:**
-Break complex tasks into numbered steps that build on each other.
-
-**Output specification:**
-Be explicit: "Return as JSON", "Format as markdown with headers", etc.
-
-**Chain of thought:**
-For reasoning tasks, add: "Think through this step by step."
-
-### 3. Structure the Prompt
-
-**Effective order for GPT:**
-1. Role definition (who/what)
-2. Context (background info)
-3. Task (what to do)
-4. Steps (how to do it, if procedural)
-5. Output format (what to return)
-6. Examples (optional clarification)
-
-### 4. Output the Refined Prompt
-Present with:
-- Clear role statement
-- Numbered steps where applicable
-- Explicit output requirements
-
-## Example Transformation
-
-**Before:**
-"Review this code for security issues"
-
-**After:**
-```
-You are a senior security engineer conducting a security audit of a Node.js payment processing service.
-
-Context: This service handles credit card transactions and communicates with Stripe's API. It runs in AWS ECS.
-
-Task: Review the code in src/payments/ for security vulnerabilities.
-
-Steps:
-1. Check for proper input validation on all endpoints
-2. Verify secrets are not hardcoded or logged
-3. Review authentication and authorization logic
-4. Check for SQL injection and XSS vulnerabilities
-5. Verify proper error handling that doesn't leak sensitive info
-
-Output format:
-Return a security report in markdown with:
-- **Critical**: Issues that must be fixed before deployment
-- **High**: Significant risks that should be addressed soon
-- **Medium**: Improvements to consider
-- **Recommendations**: General security enhancements
-
-For each issue, include:
-- File and line number
-- Description of the vulnerability
-- Recommended fix with code example
-```
-```
-
----
-
-## Gemini Models
-
-Gemini models handle long context well and work effectively with structured reasoning.
-
-### Key Techniques for Gemini
-
-
-
- Gemini can handle extensive context—don't be afraid to include more background:
-
- ```
- Here's the full module structure for context:
- [include relevant files]
-
- Based on these patterns, implement a new service that...
- ```
-
-
-
- Gemini supports Low and High reasoning. Use High for:
- - Architecture decisions
- - Complex debugging
- - Multi-step planning
-
- Use Low for:
- - Straightforward implementations
- - Code generation from specs
- - Routine refactoring
-
-
-
----
-
-## Model Selection Strategy
-
-Match the model to the task:
-
-| Task Type | Recommended Model | Reasoning Level |
-| --------------------------- | --------------------------- | --------------- |
-| **Complex architecture** | Opus 4.7 or Opus 4.6 | High-Max |
-| **Feature implementation** | Sonnet 4.5 or GPT-5.1-Codex | Medium |
-| **Quick edits, formatting** | Haiku 4.5 | Off/Low |
-| **Code review** | GPT-5.1-Codex-Max | High |
-| **Bulk automation** | GLM-5 (Droid Core) | None |
-| **Research/analysis** | Gemini 3 Pro | High |
-
----
-
-## Creating Your Own Prompt Refiner
-
-For team-specific needs, create a custom prompt refiner:
-
-```markdown
----
-name: prompt-refiner-team
-description: Refine prompts using our team's conventions and project context.
----
-
-# Team Prompt Refiner
-
-## Our Conventions
-- We use the repository pattern
-- All services have interfaces defined first
-- Tests use our custom test utilities from @/test-utils
-
-## Checklist for Prompts
-1. [ ] References relevant existing code
-2. [ ] Specifies which layer (API, service, repository)
-3. [ ] Mentions related tests to update
-4. [ ] Includes acceptance criteria
-
-## Template
-```
-Context: [What exists, what module/layer]
-Task: [Specific action]
-Patterns to follow: [Reference existing similar code]
-Tests: [What tests to add/update]
-Done when: [Acceptance criteria]
-```
-```
-
----
-
-## Quick Reference Card
-
-### Claude (Opus/Sonnet/Haiku)
-- ✅ XML tags for structure
-- ✅ Context before instructions
-- ✅ Examples in dedicated sections
-- ✅ "Think through..." for reasoning
-
-### GPT (GPT-5/Codex)
-- ✅ Role framing ("You are a...")
-- ✅ Numbered step procedures
-- ✅ Explicit output format
-- ✅ "Step by step" for reasoning
-
-### Gemini
-- ✅ Extensive context inclusion
-- ✅ Low/High reasoning levels
-- ✅ Structured output requests
-
----
-
-## Next Steps
-
-
-
- Complete power user configuration
-
-
- Reduce costs while maintaining quality
-
-
diff --git a/docs/guides/power-user/rules-conventions.mdx b/docs/guides/power-user/rules-conventions.mdx
deleted file mode 100644
index 03de8ebd..00000000
--- a/docs/guides/power-user/rules-conventions.mdx
+++ /dev/null
@@ -1,689 +0,0 @@
----
-title: Rules and Conventions
-description: Organize coding standards and team conventions so Droid follows them consistently across all work.
-keywords: ['rules', 'conventions', 'standards', 'coding style', 'guidelines', 'team', 'consistency']
----
-
-Rules are codified standards that Droid follows every time. Unlike memories (which capture decisions and context), rules define how code should be written. This guide shows you how to organize rules effectively for individuals and teams.
-
-
- **Works with Factory App:** These conventions work identically in both CLI and [Factory App](/web/getting-started/overview)—Droid reads the same `.factory/rules/` files regardless of interface.
-
-
----
-
-## Rules vs Other Configuration
-
-| Type | Purpose | Example |
-| ------------- | -------------------------- | -------------------------------------------------- |
-| **Rules** | How code should be written | "Use early returns instead of nested conditionals" |
-| **Memory** | What was decided and why | "We chose Zustand because Redux was too verbose" |
-| **AGENTS.md** | How to build/test/run | "Run `npm test` before completing work" |
-| **Skills** | How to do specific tasks | "Steps to implement a new API endpoint" |
-
-Rules are **prescriptive**—they tell Droid what to do. Use them for standards that should apply consistently.
-
----
-
-## Setting Up a Rules Directory
-
-### Basic Structure
-
-Create a `.factory/rules/` directory in your project:
-
-```
-.factory/
-└── rules/
- ├── typescript.md # TypeScript conventions
- ├── react.md # React patterns
- ├── testing.md # Testing requirements
- ├── api.md # API design rules
- └── security.md # Security requirements
-```
-
-For personal rules that apply across all projects:
-
-```
-~/.factory/
-└── rules/
- ├── style.md # Your personal style
- └── tools.md # Tool preferences
-```
-
-### Referencing Rules in AGENTS.md
-
-Add a section to your `AGENTS.md`:
-
-```markdown
-## Coding Standards
-
-Follow the conventions documented in `.factory/rules/`:
-- **TypeScript**: `.factory/rules/typescript.md`
-- **React**: `.factory/rules/react.md`
-- **Testing**: `.factory/rules/testing.md`
-- **API Design**: `.factory/rules/api.md`
-- **Security**: `.factory/rules/security.md`
-
-When working on a file, check the relevant rules first.
-```
-
----
-
-## Writing Effective Rules
-
-### Rule Structure
-
-Each rule should be:
-- **Specific**: Clear enough to follow without interpretation
-- **Actionable**: Tells what to do, not just what to avoid
-- **Scoped**: States when it applies
-- **Justified** (optional): Explains why for complex rules
-
-### Template
-
-```markdown
-# [Category] Rules
-
-## [Rule Name]
-**Applies to**: [file types, contexts]
-**Rule**: [specific instruction]
-**Example**: [code showing correct usage]
-**Rationale**: [why this matters - optional]
-```
-
----
-
-## Example Rules Files
-
-### TypeScript Rules
-
-Create `.factory/rules/typescript.md`:
-
-```markdown
-# TypeScript Rules
-
-## Type Definitions
-
-### Use `interface` for object shapes
-**Applies to**: All type definitions for objects
-**Rule**: Use `interface` for object types, `type` for unions, intersections, and primitives.
-
-```typescript
-// ✅ Correct
-interface User {
- id: string;
- name: string;
-}
-
-type Status = 'active' | 'inactive';
-type UserWithStatus = User & { status: Status };
-
-// ❌ Avoid
-type User = {
- id: string;
- name: string;
-};
-```
-
-### Avoid `any`
-**Applies to**: All TypeScript files
-**Rule**: Never use `any`. Use `unknown` with type guards, or define proper types.
-
-```typescript
-// ✅ Correct
-function processData(data: unknown): string {
- if (typeof data === 'string') {
- return data.toUpperCase();
- }
- throw new Error('Expected string');
-}
-
-// ❌ Avoid
-function processData(data: any): string {
- return data.toUpperCase();
-}
-```
-
-## Function Patterns
-
-### Use early returns
-**Applies to**: All functions with conditionals
-**Rule**: Return early for edge cases instead of nesting.
-
-```typescript
-// ✅ Correct
-function processUser(user: User | null): string {
- if (!user) return 'No user';
- if (!user.active) return 'User inactive';
- return `Processing ${user.name}`;
-}
-
-// ❌ Avoid
-function processUser(user: User | null): string {
- if (user) {
- if (user.active) {
- return `Processing ${user.name}`;
- } else {
- return 'User inactive';
- }
- } else {
- return 'No user';
- }
-}
-```
-
-### Named exports over default
-**Applies to**: All module exports
-**Rule**: Use named exports for better refactoring and import clarity.
-
-```typescript
-// ✅ Correct
-export function createUser() {}
-export const USER_ROLES = ['admin', 'user'] as const;
-
-// ❌ Avoid
-export default function createUser() {}
-```
-```
-
-### React Rules
-
-Create `.factory/rules/react.md`:
-
-```markdown
-# React Rules
-
-## Component Structure
-
-### Functional components only
-**Applies to**: All React components
-**Rule**: Use functional components with hooks. Never use class components.
-
-### Props interface naming
-**Applies to**: All components with props
-**Rule**: Name props interface as `{ComponentName}Props`.
-
-```tsx
-// ✅ Correct
-interface UserCardProps {
- user: User;
- onSelect: (user: User) => void;
-}
-
-export function UserCard({ user, onSelect }: UserCardProps) {
- return onSelect(user)}>{user.name}
;
-}
-```
-
-### Component file structure
-**Applies to**: All component files
-**Rule**: Order sections as: imports, types, component, exports.
-
-```tsx
-// 1. Imports (React, external, internal, types)
-import { useState } from 'react';
-import { Button } from '@/components/ui';
-import type { User } from '@/types';
-
-// 2. Types
-interface UserListProps {
- users: User[];
-}
-
-// 3. Component
-export function UserList({ users }: UserListProps) {
- const [selected, setSelected] = useState(null);
-
- return (
-
- {users.map(user => (
- - {user.name}
- ))}
-
- );
-}
-```
-
-## State Management
-
-### Zustand for client state
-**Applies to**: Client-side state that isn't server data
-**Rule**: Use Zustand stores in `src/stores/`. One store per domain.
-
-```typescript
-// src/stores/useUserStore.ts
-import { create } from 'zustand';
-
-interface UserState {
- currentUser: User | null;
- setUser: (user: User) => void;
- logout: () => void;
-}
-
-export const useUserStore = create((set) => ({
- currentUser: null,
- setUser: (user) => set({ currentUser: user }),
- logout: () => set({ currentUser: null }),
-}));
-```
-
-### React Query for server state
-**Applies to**: All data fetched from APIs
-**Rule**: Use React Query. Queries go in `src/queries/`.
-
-```typescript
-// src/queries/useUsers.ts
-import { useQuery } from '@tanstack/react-query';
-
-export function useUsers() {
- return useQuery({
- queryKey: ['users'],
- queryFn: () => fetch('/api/users').then(r => r.json()),
- });
-}
-```
-```
-
-### Testing Rules
-
-Create `.factory/rules/testing.md`:
-
-```markdown
-# Testing Rules
-
-## File Organization
-
-### Colocate test files
-**Applies to**: All tests except E2E
-**Rule**: Place test files next to source files.
-
-```
-src/
-└── components/
- └── UserCard/
- ├── UserCard.tsx
- ├── UserCard.test.tsx # ✅ Colocated
- └── index.ts
-```
-
-### E2E tests in dedicated directory
-**Applies to**: End-to-end tests
-**Rule**: Place E2E tests in `e2e/` at project root.
-
-## Test Structure
-
-### Descriptive test names
-**Applies to**: All test cases
-**Rule**: Format as "should [action] when [condition]".
-
-```typescript
-// ✅ Correct
-it('should display error message when login fails', () => {});
-it('should redirect to dashboard when login succeeds', () => {});
-
-// ❌ Avoid
-it('login error', () => {});
-it('works', () => {});
-```
-
-### One assertion per test
-**Applies to**: Unit tests
-**Rule**: Test one behavior per test case. Multiple assertions OK if testing same behavior.
-
-```typescript
-// ✅ Correct - testing one behavior
-it('should format user name correctly', () => {
- const result = formatUserName({ first: 'John', last: 'Doe' });
- expect(result).toBe('John Doe');
-});
-
-// ✅ Also correct - same behavior, multiple aspects
-it('should return complete user object', () => {
- const user = createUser('John');
- expect(user.id).toBeDefined();
- expect(user.name).toBe('John');
- expect(user.createdAt).toBeInstanceOf(Date);
-});
-
-// ❌ Avoid - testing multiple behaviors
-it('should handle user operations', () => {
- expect(createUser('John').name).toBe('John');
- expect(deleteUser('123')).toBe(true);
- expect(listUsers()).toHaveLength(0);
-});
-```
-
-## Mocking
-
-### Mock at boundaries
-**Applies to**: All mocked dependencies
-**Rule**: Mock external APIs and services, not internal functions.
-
-```typescript
-// ✅ Correct - mock external API
-vi.mock('@/lib/api', () => ({
- fetchUser: vi.fn().mockResolvedValue({ id: '1', name: 'John' }),
-}));
-
-// ❌ Avoid - mock internal implementation
-vi.mock('@/utils/formatName', () => ({
- formatName: vi.fn().mockReturnValue('John'),
-}));
-```
-
-### Use MSW for API mocking in integration tests
-**Applies to**: Integration tests that need API responses
-**Rule**: Use Mock Service Worker instead of mocking fetch directly.
-
-```typescript
-// ✅ Correct
-import { http, HttpResponse } from 'msw';
-
-const handlers = [
- http.get('/api/users', () => {
- return HttpResponse.json([{ id: '1', name: 'John' }]);
- }),
-];
-```
-```
-
-### Security Rules
-
-Create `.factory/rules/security.md`:
-
-```markdown
-# Security Rules
-
-## Secrets Management
-
-### Never hardcode secrets
-**Applies to**: All code
-**Rule**: Use environment variables for all secrets. Never commit secrets.
-
-```typescript
-// ✅ Correct
-const apiKey = process.env.API_KEY;
-
-// ❌ Never do this
-const apiKey = 'sk-1234567890abcdef';
-```
-
-### Validate environment variables
-**Applies to**: Application startup
-**Rule**: Validate required env vars exist at startup.
-
-```typescript
-// ✅ Correct
-const config = {
- apiKey: requireEnv('API_KEY'),
- dbUrl: requireEnv('DATABASE_URL'),
-};
-
-function requireEnv(name: string): string {
- const value = process.env[name];
- if (!value) throw new Error(`Missing required env var: ${name}`);
- return value;
-}
-```
-
-## Input Validation
-
-### Validate all external input
-**Applies to**: API routes, form handlers
-**Rule**: Use Zod to validate all input from users or external sources.
-
-```typescript
-// ✅ Correct
-import { z } from 'zod';
-
-const CreateUserSchema = z.object({
- email: z.string().email(),
- name: z.string().min(1).max(100),
-});
-
-export async function createUser(input: unknown) {
- const data = CreateUserSchema.parse(input);
- // data is now typed and validated
-}
-```
-
-## Error Handling
-
-### Never expose internal errors
-**Applies to**: API error responses
-**Rule**: Log detailed errors server-side; return generic messages to clients.
-
-```typescript
-// ✅ Correct
-try {
- await processPayment(data);
-} catch (error) {
- console.error('Payment failed:', error); // Detailed log
- throw new ApiError('Payment processing failed', 500); // Generic message
-}
-```
-
-## Authentication
-
-### Check authentication on every protected route
-**Applies to**: All API routes requiring auth
-**Rule**: Use middleware or guards. Never assume auth from client.
-
-```typescript
-// ✅ Correct
-export async function GET(request: Request) {
- const session = await getSession(request);
- if (!session) {
- return new Response('Unauthorized', { status: 401 });
- }
- // ... handle authenticated request
-}
-```
-```
-
----
-
-## Organizing Team Rules
-
-### Layered Rules
-
-For teams, organize rules in layers:
-
-```
-.factory/rules/
-├── _base/ # Foundation rules (everyone follows)
-│ ├── typescript.md
-│ └── security.md
-├── frontend/ # Frontend-specific
-│ ├── react.md
-│ └── styling.md
-├── backend/ # Backend-specific
-│ ├── api.md
-│ └── database.md
-└── testing/ # Testing standards
- ├── unit.md
- └── integration.md
-```
-
-Reference in AGENTS.md:
-
-```markdown
-## Rules
-- Base rules: `.factory/rules/_base/` - Apply to all code
-- Frontend rules: `.factory/rules/frontend/` - React components
-- Backend rules: `.factory/rules/backend/` - API and services
-- Testing rules: `.factory/rules/testing/` - All tests
-```
-
-### Rule Ownership
-
-Add ownership to track who maintains each rule set:
-
-```markdown
-# TypeScript Rules
-
-**Owner**: Platform Team
-**Last Updated**: 2024-02-15
-**Review Cycle**: Quarterly
-
-[rules content...]
-```
-
----
-
-## Current Limitation: No Glob Pattern Support
-
-
-Currently, Droid doesn't support conditional rule application based on file patterns (e.g., "apply these rules only to `*.tsx` files"). This is on the roadmap.
-
-
-**Workarounds:**
-
-1. **Organize by file type**: Create separate rules files and reference them contextually
-
-```markdown
-# In AGENTS.md
-When working on React components (*.tsx), follow `.factory/rules/react.md`
-When working on API routes, follow `.factory/rules/api.md`
-```
-
-2. **Use clear scoping in rules**: State applicability clearly
-
-```markdown
-## This rule applies to: React component files (*.tsx)
-```
-
-3. **Use skills for complex workflows**: Skills can encode file-type-specific instructions
-
----
-
-## Rules Maintenance
-
-### Adding New Rules
-
-When you find yourself correcting Droid repeatedly:
-
-1. Identify the pattern
-2. Write a clear rule with examples
-3. Add to appropriate rules file
-4. Update AGENTS.md if needed
-5. Test by asking Droid to do similar work
-
-### Reviewing Rules
-
-Quarterly review checklist:
-
-- [ ] Remove rules that are now enforced by linting
-- [ ] Update rules that have changed
-- [ ] Add rules for new patterns
-- [ ] Check that examples are still accurate
-- [ ] Verify AGENTS.md references are current
-
-### Deprecating Rules
-
-When a rule becomes outdated:
-
-```markdown
-## ~~Use PropTypes for type checking~~ (DEPRECATED)
-**Status**: Deprecated as of 2024-02
-**Reason**: We now use TypeScript for all type checking
-**Replacement**: See TypeScript rules for prop typing
-```
-
----
-
-## Enforcing Rules Automatically
-
-While Droid follows rules from your `.factory/rules/` files, you can add automated enforcement with [hooks](/cli/configuration/hooks-guide).
-
-### Run Linters After Edits
-
-Add a PostToolUse hook to run your linter after every file edit:
-
-```json
-{
- "hooks": {
- "PostToolUse": [
- {
- "matcher": "Create|Edit|ApplyPatch",
- "hooks": [
- {
- "type": "command",
- "command": "cd \"$FACTORY_PROJECT_DIR\" && npm run lint -- --fix 2>/dev/null || true"
- }
- ]
- }
- ]
- }
-}
-```
-
-### Validate Code Style
-
-Run Prettier or your formatter automatically:
-
-```json
-{
- "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 || true"
- }
- ]
- }
- ]
- }
-}
-```
-
-
- See [Hooks reference](/reference/hooks-reference) for more examples.
-
-
----
-
-## Quick Reference
-
-### File Locations
-
-| Scope | Location | Use For |
-| -------- | ------------------- | ---------------------- |
-| Personal | `~/.factory/rules/` | Your style preferences |
-| Project | `.factory/rules/` | Team standards |
-
-### Rule Format
-
-```markdown
-## [Rule Name]
-**Applies to**: [scope]
-**Rule**: [what to do]
-**Example**: [code]
-**Rationale**: [why - optional]
-```
-
-### Good Rules Are
-
-- ✅ Specific and unambiguous
-- ✅ Include code examples
-- ✅ State when they apply
-- ✅ Actionable (do X, not "consider X")
-- ❌ Not vague ("write clean code")
-- ❌ Not duplicating linter rules
-- ❌ Not contradicting other rules
-
----
-
-## Next Steps
-
-
-
- Complete power user configuration
-
-
- Capture decisions and context
-
-
diff --git a/docs/guides/power-user/setup-checklist.mdx b/docs/guides/power-user/setup-checklist.mdx
deleted file mode 100644
index de723570..00000000
--- a/docs/guides/power-user/setup-checklist.mdx
+++ /dev/null
@@ -1,408 +0,0 @@
----
-title: Power User Setup Checklist
-description: Complete checklist to configure Droid for maximum effectiveness with IDE integration, memory, skills, and automation.
-keywords: ['power user', 'setup', 'checklist', 'configuration', 'optimization', 'productivity', 'best practices']
----
-
-This checklist transforms a basic Droid installation into a fully optimized development environment. Each section builds on the previous one—complete them in order for best results.
-
-
- Each section can be done independently if you prefer to spread it out.
-
-
-
- **Using Factory App?** Most of this guide applies to both CLI and [Factory App](/web/getting-started/overview). Where the experience differs, we've noted the App-specific approach.
-
-
----
-
-## Level 1: Essential Setup
-
-These foundational items give you the biggest immediate impact.
-
-
-
- The IDE plugin provides real-time context—open files, errors, selections—so Droid sees what you see.
-
- **VSCode/Cursor:**
- 1. Open Extensions (`Cmd+Shift+X`)
- 2. Search "Factory"
- 3. Install and reload
-
- **Verify:** Run `droid` and check for "IDE connected" in the status bar.
-
-
-
- Create a basic [`AGENTS.md`](/cli/configuration/agents-md) at your repository root:
-
- ```markdown
- # 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
- ```
-
- Start minimal—you'll expand this as you work. See the [AGENTS.md guide](/cli/configuration/agents-md) for more examples.
-
-
-
- Set your preferred model in settings:
-
- **CLI:**
- ```bash
- droid
- > /settings
- # Navigate to Model and select your default
- ```
-
- **Factory App:** Use the model selector dropdown in the chat interface.
-
- **Recommendation:** Start with Claude Opus 4.5 (default) for complex work, switch to Haiku 4.5 or GPT-5.1-Codex for routine tasks.
-
-
-
-
- **Checkpoint:** You should now have IDE integration, basic project context, and your preferred model configured.
-
-
----
-
-## Level 2: Memory & Context
-
-Build persistent memory so Droid remembers your preferences across sessions.
-
-
-
- Create `~/.factory/memories.md` for personal preferences:
-
- ```markdown
- # 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
- ```
-
- Update this file whenever you find yourself repeating instructions to Droid.
-
-
-
- Add to your `AGENTS.md`:
-
- ```markdown
- ## Personal Preferences
- Refer to `~/.factory/memories.md` for my coding preferences and past decisions.
- ```
-
-
-
- For team projects, create `.factory/memories.md`:
-
- ```markdown
- # 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
- ```
-
-
-
-
- **Checkpoint:** Droid now has access to your preferences and project history without you repeating them.
-
-
-
- **Want automated memory capture?** Set up a hook to automatically save memories when you say "remember this:". See [Memory Management](/guides/power-user/memory-management#automatic-memory-capture) for setup instructions.
-
-
----
-
-## Level 3: Rules & Conventions
-
-Organize your coding standards so Droid follows them consistently.
-
-
-
- Create `.factory/rules/` in your project:
-
- ```
- .factory/
- └── rules/
- ├── typescript.md
- ├── testing.md
- └── security.md
- ```
-
-
-
- Create `.factory/rules/typescript.md`:
-
- ```markdown
- # 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
- ```
-
-
-
- Create `.factory/rules/testing.md`:
-
- ```markdown
- # 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`
- ```
-
-
-
- Update your `AGENTS.md`:
-
- ```markdown
- ## 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
- ```
-
-
-
-
- **Checkpoint:** Your coding standards are now documented and Droid will follow them consistently.
-
-
-
- **Enforce rules automatically:** Use [PostToolUse hooks](/cli/configuration/hooks-guide) to run linters after edits. See [Code Validation hooks](/reference/hooks-reference) for examples.
-
-
----
-
-## Level 4: Skills & Automation
-
-Add reusable skills and automation hooks.
-
-
- **Three ways to automate:**
- - **[Skills](/cli/configuration/skills)** — Droid invokes them based on task context
- - **[Hooks](/cli/configuration/hooks-guide)** — Run automatically on specific events
- - **[Custom Slash Commands](/cli/configuration/custom-slash-commands)** — You invoke with `/command-name`
-
-
-
-
- Create `~/.factory/skills/prompt-refiner/SKILL.md`:
-
- ```markdown
- ---
- 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?
- - Examples: 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..."
- ```
-
-
-
- Run `/hooks` and add a PostToolUse hook for automatic formatting:
-
- ```json
- {
- "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"
- }
- ]
- }
- ]
- }
- }
- ```
-
- This automatically formats files after Droid edits them.
-
-
-
- Run related tests after edits:
-
- ```json
- {
- "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"
- }
- ]
- }
- ]
- }
- }
- ```
-
-
-
-
- **Checkpoint:** You now have reusable skills and automatic formatting/testing.
-
-
----
-
-## Level 5: Token Optimization
-
-Fine-tune for cost efficiency without sacrificing quality.
-
-
-
- Use `Shift+Tab` or `/spec` before starting features that touch multiple files. This prevents expensive false starts.
-
-
-
- Set up a spec mode model for planning:
-
- ```bash
- droid
- > /settings
- # Set Spec Mode Model to a reasoning-heavy model
- ```
-
- Use Opus 4.5 for planning, then Sonnet or Codex for implementation.
-
-
-
- Check your project's AI-readiness:
-
- **CLI:**
- ```bash
- droid
- > /readiness-report
- ```
-
- **Factory App:** View your readiness score in the [Agent Readiness Dashboard](/web/agent-readiness/dashboard).
-
- Address high-impact items first—linting, type checking, and fast tests dramatically reduce token waste.
-
-
-
----
-
-## Quick Reference: File Locations
-
-| Purpose | Personal | Project |
-| ---------------------- | ----------------------------------- | --------------------------------- |
-| **Skills** | `~/.factory/skills//SKILL.md` | `.factory/skills//SKILL.md` |
-| **Memory** | `~/.factory/memories.md` | `.factory/memories.md` |
-| **Rules** | `~/.factory/rules/*.md` | `.factory/rules/*.md` |
-| **Settings** | `~/.factory/settings.json` | `.factory/settings.json` |
-| **Hooks** | In settings.json | In settings.json |
-| **Agent instructions** | `~/.factory/AGENTS.md` | `./AGENTS.md` |
-| **Custom droids** | `~/.factory/droids/.md` | `.factory/droids/.md` |
-
----
-
-## Verification Checklist
-
-Run through this checklist to verify your setup:
-
-- [ ] IDE plugin shows "connected" when running Droid
-- [ ] `AGENTS.md` exists with build/test commands
-- [ ] Memories file created with your preferences
-- [ ] Rules directory with at least one rules file
-- [ ] At least one custom skill created
-- [ ] Auto-formatting hook configured
-- [ ] Readiness report shows Level 2 or higher
-
----
-
-## Next Steps
-
-
-
- Learn model-specific prompting techniques
-
-
- Strategies for reducing token usage
-
-
- Advanced memory and context patterns
-
-
- Organizing team conventions effectively
-
-
diff --git a/docs/guides/power-user/token-efficiency.mdx b/docs/guides/power-user/token-efficiency.mdx
deleted file mode 100644
index 3079ac36..00000000
--- a/docs/guides/power-user/token-efficiency.mdx
+++ /dev/null
@@ -1,370 +0,0 @@
----
-title: Token Efficiency Strategies
-description: Reduce token usage while maintaining quality through project setup, model selection, and workflow optimization.
-keywords: ['tokens', 'efficiency', 'cost', 'optimization', 'usage', 'pricing', 'performance']
----
-
-Token usage isn't just about cost—it's about feedback loop speed and context window limits. This guide shows you how to get more done with fewer tokens through project optimization, smart model selection, and workflow patterns.
-
-
- **Using Factory App?** These strategies apply to both CLI and [Factory App](/web/getting-started/overview). You can view your project's readiness score in the [Agent Readiness Dashboard](/web/agent-readiness/dashboard).
-
-
----
-
-## Understanding Token Usage
-
-Tokens are consumed in three main areas:
-
-```
-┌──────────────────────────────────────────────────────────┐
-│ Token Consumption │
-├────────────────┬────────────────┬────────────────────────┤
-│ Context │ Tool Calls │ Model Output │
-│ (Input) │ (Overhead) │ (Response) │
-├────────────────┼────────────────┼────────────────────────┤
-│ • AGENTS.md │ • Read files │ • Explanations │
-│ • Memories │ • Grep/search │ • Generated code │
-│ • Conversation │ • Execute cmds │ • Analysis │
-│ • File content │ • Each retry │ • Thinking tokens │
-└────────────────┴────────────────┴────────────────────────┘
-```
-
-**High token usage often means:**
-- Too much exploration (unclear instructions)
-- Multiple attempts (missing context or failing tests)
-- Verbose output (no format constraints)
-
----
-
-## Project Setup for Efficiency
-
-The biggest token savings come from project configuration that prevents wasted cycles.
-
-### 1. Fast, Reliable Tests
-
-
- Slow or flaky tests are the #1 cause of wasted tokens. Each retry costs a full response cycle.
-
-
-| Test Characteristic | Impact on Tokens |
-| ------------------- | ---------------------------------------------------- |
-| Fast tests (< 30s) | Droid verifies changes immediately |
-| Slow tests (> 2min) | Droid may skip verification or waste context waiting |
-| Flaky tests | False failures cause debugging cycles |
-| No tests | Droid can't verify changes, more back-and-forth |
-
-**Action items:**
-```markdown
-## In your AGENTS.md
-
-## Testing
-- Run single file: `npm test -- path/to/file.test.ts`
-- Run fast smoke tests: `npm test -- --testPathPattern=smoke`
-- Full suite takes ~3 minutes, use `--bail` for early exit on failure
-```
-
-### 2. Linting and Type Checking
-
-When Droid can catch errors immediately, it fixes them in the same turn instead of waiting for you to report them.
-
-```markdown
-## In your AGENTS.md
-
-## Validation Commands
-- Lint (auto-fix): `npm run lint:fix`
-- Type check: `npm run typecheck`
-- Full validation: `npm run validate` (lint + typecheck + test)
-
-Always run `npm run lint:fix` after making changes.
-```
-
-### 3. Clear Project Structure
-
-Document your file organization so Droid doesn't waste tokens exploring:
-
-```markdown
-## In your AGENTS.md
-
-## Project Structure
-- `src/components/` - React components (one per file)
-- `src/hooks/` - Custom React hooks
-- `src/services/` - API and business logic
-- `src/types/` - TypeScript type definitions
-- `tests/` - Test files mirror src/ structure
-
-When adding a new component:
-1. Create component in `src/components/ComponentName/`
-2. Add index.ts for exports
-3. Add ComponentName.test.tsx in same directory
-```
-
----
-
-## Agent Readiness Checklist
-
-The [Agent Readiness Report](/cli/features/readiness-report) evaluates your project against criteria that directly impact token efficiency.
-
-### High-Impact Criteria
-
-| Criterion | Token Impact | Why It Matters |
-| ------------------------------- | ------------ | ----------------------------------------------- |
-| **Linter Configuration** | 🟢 High | Catches errors immediately, no debugging cycles |
-| **Type Checker** | 🟢 High | Prevents runtime errors, clearer code |
-| **Unit Tests Runnable** | 🟢 High | Verification in same turn |
-| **AGENTS.md** | 🟢 High | Context upfront, less exploration |
-| **Build Command Documentation** | 🟡 Medium | No guessing, fewer failed attempts |
-| **Dependencies Pinned** | 🟡 Medium | Reproducible builds |
-| **Pre-commit Hooks** | 🟡 Medium | Automatic quality enforcement |
-
-Run the readiness report to identify gaps:
-
-```bash
-droid
-> /readiness-report
-```
-
----
-
-## Model Selection Strategy
-
-Different models have different cost multipliers and capabilities. Match the model to the task:
-
-### Cost Multipliers
-
-See [Available Models](/models) for current model multipliers.
-
-### Task-Based Model Selection
-
-```
-Simple edit, formatting → Haiku 4.5 (0.4×)
-Implement feature from spec → GPT-5.3-Codex (0.7×)
-Debug complex issue → Sonnet 4.5 (1.2×)
-Architecture planning → Opus 4.7 (1x, 2x after 4/30) or Opus 4.6 (2×)
-Bulk file processing → Droid Core (MiniMax M2.7 at 0.12× or Kimi K2.6 at 0.4×)
-```
-
-### Reasoning Effort Impact
-
-Higher reasoning = more "thinking" tokens but often fewer retries.
-
-| Reasoning | When to Use | Token Trade-off |
-| --------- | ------------------------ | ------------------------------------ |
-| Off/None | Simple, clear tasks | Lowest per-turn, may need more turns |
-| Low | Standard implementation | Good balance |
-| Medium | Complex logic, debugging | Higher per-turn, fewer retries |
-| High | Architecture, analysis | Highest per-turn, best first-attempt |
-
-**Rule of thumb:** Use higher reasoning for tasks where a wrong first attempt would be expensive to fix.
-
-
- **Configure mixed models** to automatically use different models for planning vs implementation. See [Mixed Models](/cli/configuration/mixed-models) for setup.
-
-
----
-
-## Workflow Patterns for Efficiency
-
-### Pattern 1: Spec Mode for Complex Work
-
-Use [Specification Mode](/cli/user-guides/specification-mode) (`Shift+Tab` or `/spec`) to plan before implementing.
-
-**Without Spec Mode:**
-```
-Turn 1: Start implementing → wrong approach → wasted tokens
-Turn 2: Undo and try different approach → more tokens
-Turn 3: Finally get it right
-Total: 3 turns of implementation tokens
-```
-
-**With Spec Mode:**
-```
-Turn 1: Plan with exploration → correct approach identified
-Turn 2: Implement correctly
-Total: 1 turn of planning + 1 turn of implementation
-```
-
-
- Use Spec Mode (`Shift+Tab` or `/spec`) for any task that:
- - Touches more than 2 files
- - Requires understanding existing patterns
- - Has unclear requirements
- - Is security-sensitive
-
-
-### Pattern 2: IDE Plugin for Context
-
-Without IDE plugin, Droid must read files to understand context:
-
-```
-Read file A → Read file B → Read file C → Understand context → Work
-(4 tool calls before actual work)
-```
-
-With IDE plugin, context is immediate:
-
-```
-Work (IDE provides open files, errors, selection)
-(0 extra tool calls for context)
-```
-
-### Pattern 3: Specific Over General
-
-**Expensive prompt:**
-```
-"Fix the bug in the auth module"
-```
-→ Droid reads multiple files to find the bug, explores different possibilities
-
-**Efficient prompt:**
-```
-"Fix the timeout bug in src/auth/session.ts line 45 where the session expires after 5 minutes instead of 24 hours"
-```
-→ Droid goes directly to the issue
-
-### Pattern 4: Batch Similar Work
-
-**Expensive:**
-```
-Turn 1: "Add logging to userService"
-Turn 2: "Add logging to orderService"
-Turn 3: "Add logging to paymentService"
-(3 turns, context rebuilt each time)
-```
-
-**Efficient:**
-```
-Turn 1: "Add structured logging to all services in src/services/. Use the pattern from src/lib/logger.ts. Services: user, order, payment."
-(1 turn, pattern established once)
-```
-
----
-
-## Reducing Token Waste
-
-### Common Waste Patterns
-
-| Pattern | Cause | Fix |
-| --------------------------- | -------------------- | ---------------------- |
-| Multiple exploration cycles | Unclear requirements | Be specific upfront |
-| Repeated file reads | Missing IDE context | Install IDE plugin |
-| Failed attempts | No tests/linting | Add validation tools |
-| Verbose explanations | No format constraint | Ask for concise output |
-| Wrong architecture | Missing context | Use Spec Mode |
-
-### Format Constraints
-
-Ask for specific output formats to reduce verbosity:
-
-```
-"Add the feature. Return only the changed code, no explanations unless something is unclear."
-```
-
-```
-"Review this code. Format: bullet list of issues only, no preamble."
-```
-
-```
-"Debug this test failure. Show me the fix, then explain in 2-3 sentences."
-```
-
----
-
-## Monitoring Your Usage
-
-### Check Current Session Cost
-
-```bash
-droid
-> /cost
-```
-
-This shows token usage for the current session.
-
-### Track Over Time
-
-Review your usage patterns:
-
-1. **After each session**, note the `/cost` output
-2. **Identify expensive sessions**: What made them expensive?
-3. **Refine approach**: More context? Different model? Better prompts?
-
-### Usage Red Flags
-
-Watch for these patterns:
-
-- 🚩 **High read count**: Droid is exploring too much (add AGENTS.md context)
-- 🚩 **Multiple grep/search calls**: Unclear what to look for (be more specific)
-- 🚩 **Repeated similar edits**: Failed attempts (check tests/linting)
-- 🚩 **Very long conversations**: Scope creep (break into smaller tasks)
-
----
-
-## Quick Wins Checklist
-
-Implement these for immediate token savings:
-
-- [ ] **Install IDE plugin** - Eliminates context-gathering tool calls
-- [ ] **Create AGENTS.md** - Droid knows build/test commands upfront
-- [ ] **Configure linting** - Errors caught immediately
-- [ ] **Fast test command** - Verification in same turn
-- [ ] **Use Spec Mode** - Prevents expensive false starts
-- [ ] **Be specific** - Reduces exploration cycles
-- [ ] **Match model to task** - Don't use Opus for simple edits
-
----
-
-## Token Budget Guidelines
-
-Rough guidelines for common tasks:
-
-| Task Type | Typical Token Range | Notes |
-| ---------------------- | ------------------- | ------------------------------- |
-| Quick edit | 5k-15k | Simple, specific changes |
-| Feature implementation | 30k-80k | With Spec Mode planning |
-| Complex debugging | 50k-150k | May need multiple attempts |
-| Architecture planning | 20k-50k | High-reasoning model |
-| Code review | 30k-60k | Depends on PR size |
-| Bulk refactoring | 50k-200k | Many files, use efficient model |
-
-If you're significantly exceeding these ranges, review the waste patterns above.
-
----
-
-## Summary: The Token-Efficient Workflow
-
-```
-1. Set up your project
- └─ AGENTS.md with commands
- └─ Fast tests
- └─ Linting configured
- └─ IDE plugin installed
-
-2. Start each task right
- └─ Use Spec Mode for complex work
- └─ Be specific about the goal
- └─ Reference existing patterns
-
-3. Choose the right model
- └─ Simple → Haiku/Droid Core
- └─ Standard → Codex/Sonnet
- └─ Complex → Opus (with reasoning)
-
-4. Monitor and adjust
- └─ Check /cost periodically
- └─ Identify expensive patterns
- └─ Refine your approach
-```
-
----
-
-## Next Steps
-
-
-
- Complete power user configuration
-
-
- Evaluate your project's AI-readiness
-
-
diff --git a/docs/jp/cli/getting-started/how-to-talk-to-a-droid.mdx b/docs/jp/cli/getting-started/how-to-talk-to-a-droid.mdx
deleted file mode 100644
index 8f29e9d2..00000000
--- a/docs/jp/cli/getting-started/how-to-talk-to-a-droid.mdx
+++ /dev/null
@@ -1,225 +0,0 @@
----
-title: "Droidとの対話方法"
-description: FactoryのAIエージェントから高品質な結果を得るためのプロンプト作成テクニック。
-keywords: ['prompts', 'prompting', 'how to', 'tips', 'best practices', 'communication', 'instructions', 'context', 'effective prompts']
----
-
-Droidは明確で具体的な指示で最高のパフォーマンスを発揮します。熟練したエンジニアとペアプログラミングを行うように、コミュニケーションの質が結果に直接影響します。このガイドでは、より少ない反復でより良い結果を得るための実践的なパターンを紹介します。
-
-## 基本原則
-
-**求めることを明確に示す。**「認証システムを改善できますか？」ではなく、「middleware/rateLimit.tsのパターンに従って、指数バックオフを用いたログイン試行のレート制限を追加してください」と試してみてください。Droidは目標を明確に述べられた時に最高のパフォーマンスを発揮します。
-
-**最初にコンテキストを提供する。**エラーメッセージ、ファイルパス、スクリーンショット、または関連ドキュメントを含めてください。Jiraチケットやデザインドキュメントから何かを実装している場合は、リンクを貼り付けてください。droidはFactoryのダッシュボードで統合したプラットフォームから自動的にコンテキストを読み取ることができます。
-
-**アプローチを選択する。**複雑な機能については、自動プランニングのためのSpecification Modeの使用を検討してください。日常的なタスクについては、droidは直接進めることができますが、それでもレビューのためにすべての変更を表示します。詳細なガイダンスについては[Planning versus doing](#planning-versus-doing)セクションを参照してください。
-
-**成功を定義する。**特定のテストを実行する、サービスがクリーンに開始することを確認する、またはUIがモックアップと一致することを確認するなど、作業が完了したことを確認する方法をdroidに伝えてください。
-
-## 効果的なプロンプトの書き方
-
-最高のプロンプトは直接的で関連する詳細を含んでいます：
-
-```
-Add comprehensive error handling to the payment processor in src/payments/processor.ts.
-Catch gateway timeouts and retry up to 3 times with exponential backoff.
-Similar retry logic exists in src/notifications/sender.ts.
-Run the payment integration tests to verify it works.
-```
-
-```
-Run the build and fix all TypeScript errors. Focus on the auth module first.
-```
-
-```
-Review my uncommitted changes with git diff and suggest improvements before I commit.
-```
-
-```
-The login form allows empty submissions. Add client-side validation and return proper error messages.
-Check that localhost:3000/login shows validation errors when fields are empty.
-```
-
-```
-Refactor the database connection logic into a separate module but don't change any query interfaces.
-```
-
-これらの例に注目してください：
-
-- 最初の文で目標を明確に述べる
-- 既知の場合は特定のファイルやコマンドを含める
-- 役立つ可能性のある関連コードについて言及する
-- 結果をテストする方法を説明する
-- 会話的だが直接的に保つ
-
-## プランニング対実行
-
-複雑な機能については、実装前に自動的にプランニングとレビューを提供する[Specification Mode](/jp/cli/user-guides/specification-mode)を使用してください：
-
-```
-Add user preferences API with key-value storage following REST conventions.
-Include validation and comprehensive tests.
-```
-
-簡単なタスクについては、droidは承認のために変更を表示しながら直接進めることができます：
-
-```
-Fix the failing test in tests/auth.test.ts line 42
-```
-
-```
-Add logging to the startup sequence with appropriate log levels.
-```
-
-## コンテキストの管理
-
-**AGENTS.mdファイルを使用して**ビルドコマンド、テスト手順、コーディング標準を文書化してください。Droidはこれらを自動的に読み取るため、プロジェクトの規約を繰り返す必要がありません。詳細なセットアップ手順については[AGENTS.md guide](/jp/cli/configuration/agents-md)を参照してください。
-
-**特定のファイルを言及する**コードがどこにあるか分かっている場合。ファイルを直接参照するために`@filename`を使用するか、プロンプトにファイルパスを含めてください。これによりdroidの注意を集中させ、時間を節約できます。
-
-**変更の境界を設定する。**「authディレクトリ内のファイルのみを変更する」または「パブリックAPIを変更しない」といった指示は、スコープを制限するのに役立ちます。
-
-**外部リソースを参照する**チケット、ドキュメント、デザイン、または仕様へのURLを含めることで。Droidはこの情報を取得して使用できます。
-
-## 一般的なワークフロー
-
-**コードの理解：**
-
-```
-Explain how user authentication flows through this system.
-```
-
-```
-What are the main components in the frontend and how do they interact?
-```
-
-**機能の実装：**
-
-```
-Add a PATCH /users/:id endpoint with email uniqueness validation.
-Update the OpenAPI spec and add integration tests.
-Similar patterns exist in src/routes/users/get.ts.
-```
-
-**バグの修正：**
-
-```
-Users report file uploads fail randomly. Error in browser console: "Network timeout".
-Upload logic is in src/upload/handler.ts. Check for timeout handling.
-```
-
-**コードレビュー：**
-
-```
-Look at git diff and review these changes for security issues and maintainability.
-```
-
-**リファクタリング：**
-
-```
-Extract the email sending logic into a separate service class.
-Keep the same interfaces but make it testable in isolation.
-```
-
-## エンタープライズ統合
-
-チケットやドキュメントへのリンクを貼り付けてチームのツールを参照してください：
-
-```
-Implement the feature described in this Jira ticket: https://company.atlassian.net/browse/PROJ-123
-Follow our security standards from the compliance docs.
-```
-
-Factoryのダッシュボードでこれらのプラットフォームを統合している場合、droidはJira、Notion、Slack、その他のソースから自動的にコンテキストを読み取ることができます。追加のツール接続については、droidはMCP統合もサポートしています。
-
-セキュリティに敏感な作業については：
-
-```
-Add file upload functionality with proper validation to prevent directory traversal attacks.
-Follow the security patterns used in our document upload feature.
-```
-
-## セッション管理
-
-コンテキストが乱雑になった場合や関連しないタスクに切り替える場合は、新しい会話を開始してください。失敗した試行から蓄積されたノイズよりも、新鮮なコンテキストの方が多くの場合うまく機能します。
-
-大きなプロジェクトの場合は、作業をフェーズに分けてください：
-
-```
-First implement the database schema changes. Don't add the API endpoints yet.
-```
-
-その後のフォローアップで：
-
-```
-Now add the REST endpoints using the new schema. Include validation and error handling.
-```
-
-## 高度なテクニック
-
-**テスト駆動開発：**
-
-```
-Write comprehensive tests for the user registration flow first.
-Don't implement the actual registration logic yet.
-```
-
-**プラン駆動開発：**
-
-```
-Create a markdown file outlining the plan for updating both backend API and React components.
-Include the shared data structure and implementation order.
-Then implement each part following the documented plan.
-```
-
-## 良いプロンプトの例
-
-こちらはうまく機能する実際の例です：
-
-```
-Run git blame on the file I have open and figure out who added the rate limiting logic.
-```
-
-```
-Look at git diff staged and remove any debug statements before I commit.
-```
-
-```
-Convert these 5 React components to use TypeScript. Use proper interfaces for props.
-```
-
-```
-Find the commit that introduced the caching mechanism and explain how it works.
-```
-
-```
-Add input validation to all the forms in the admin panel. Return 400 with clear error messages.
-```
-
-```
-Check the production logs for any errors in the last hour and suggest fixes for the most common ones.
-```
-
-## うまく機能しないもの
-
-曖昧なリクエストは避けてください：
-
-- 「アプリを良くして」→ 範囲が広すぎる
-- 「データベースを修正して」→ 十分に具体的でない
-- 「フロントエンドを手伝ってもらえますか？」→ 目標が不明確
-
-droidに推測させないでください：
-
-- ファイルパスを知っている場合は、それを含める
-- 実行するコマンドを知っている場合は、それについて言及する
-- 関連するコードがある場合は、それを指摘する
-
-## より良い結果を得る
-
-droidを有能なチームメイトとして扱ってください。タスクに取り組む同僚に提供するのと同じコンテキストとガイダンスを提供してください。品質基準とビジネス要件について具体的に述べてください。
-
-droidは時間をかけてあなたの組織のパターンを学習することを覚えておいてください。コードベース内でより一貫して使用するほど、あなたの規約に従うのが上手になります。
-
-最も重要なことは、droidが提案する変更をレビューすることです。承認ワークフローを通じて完全な制御を維持しているため、変更を理解し、将来のより良い結果のためにフィードバックを提供する時間を取ってください。
-
-これらのパターンを試す準備はできましたか？[Quickstart](/jp/cli/getting-started/quickstart)に戻って、あなた自身のコードで練習してください。
diff --git a/docs/jp/guides/power-user/evaluating-context-compression.mdx b/docs/jp/guides/power-user/evaluating-context-compression.mdx
deleted file mode 100644
index 7f2aac14..00000000
--- a/docs/jp/guides/power-user/evaluating-context-compression.mdx
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: "コンテキスト圧縮の評価"
-description: 長時間実行されるAIエージェントセッション向けコンテキスト圧縮戦略に関するFactory Researchの評価概要。
-keywords: ['context compression', 'summarization', 'agents', 'memory', 'token efficiency', 'evaluation']
----
-
-このページは、Factory Researchの投稿「**[Evaluating Context Compression for AI Agents](https://factory.ai/news/evaluating-compression)**」（2025年12月16日）の要約です。
-
-
- 手法、グラフ、例の詳細は、上記リンク先の元記事を参照してください。
-
-
----
-
-## TL;DR
-
-- 長期実行エージェントセッションは、どのモデルのコンテキストウィンドウも超える可能性があるため、何らかの形の**コンテキスト圧縮**が必要です。
-- 重要な指標は*リクエストあたりのトークン数*ではなく、**タスクあたりのトークン数**です（詳細の欠落により、コストの高い再取得と再作業が発生するため）。
-- Factoryの評価において、**構造化要約**は、OpenAIの`/responses/compact`やAnthropicのSDK圧縮と同様の圧縮率で、「タスクを継続する」情報をより多く保持しました。
-
----
-
-## コンテキスト圧縮が重要な理由
-
-エージェントセッションが数百/数千ターンに及ぶと、完全なトランスクリプトは**数百万トークン**に達する可能性があります。エージェントが重要な状態（例：正確なエンドポイント、変更されたファイルパス、現在の次のステップ）を失うと、しばしば以下のことが起こります：
-
-- 既に読んだファイルを再読み込みする
-- デバッグの行き詰まりを繰り返す
-- 何が変更され、どこで変更されたかを忘れる
-
-これにより、圧縮で節約されたよりも多くの時間とトークンがかかります。
-
----
-
-## Factoryによる「コンテキスト品質」の評価方法
-
-要約類似性メトリクス（例：ROUGE）を使用する代わりに、Factoryは**プローブベース評価**を使用しました：
-
-1. 実際の長期実行本番セッションを取得する。
-2. 前の部分を圧縮する。
-3. 切り捨てられた履歴から特定のタスク関連詳細を記憶する必要があるプローブを尋ねる。
-4. 回答を機能的有用性についてグレード付けする。
-
-### プローブタイプ
-
-- **記憶**: 事実の保持（例：「元のエラーは何でしたか？」）
-- **アーティファクト**: ファイル追跡（例：「どのファイルを変更し、どのように変更しましたか？」）
-- **継続**: タスク計画（例：「次に何をすべきですか？」）
-- **決定**: 推論チェーン（例：「何を決定し、なぜですか？」）
-
-### スコア付けの観点
-
-回答は、LLM審判者（**GPT-5.2**）により以下の観点で（0-5で）スコア付けされました：
-
-- 正確性
-- コンテキスト認識
-- アーティファクト追跡
-- 完全性
-- 継続性
-- 指示従順
-
-審判者は、どの圧縮方法が回答を生成したかについて盲目化されています。
-
----
-
-## 比較された圧縮アプローチ
-
-| アプローチ | 生成される内容 | 主要なトレードオフ |
-| ------------- | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
-| **Factory** | 明示的なセクション（意図、ファイル変更、決定、次のステップ）を持つ**構造化された永続的要約**。新しく切り捨てられた範囲のみを要約し、既存の要約に**マージ**することで更新（「アンカー反復要約」）。 | 最も積極的な圧縮よりもわずかに大きな要約になるが、タスククリティカルな詳細の保持が向上。 |
-| **OpenAI** | `/responses/compact`: 再構築精度に最適化された**不透明な**圧縮表現。 | 最高の圧縮率、ただし解釈可能性が低い（何が保持されたかを検査できない）。 |
-| **Anthropic** | Claude SDK内蔵圧縮: 詳細な構造化要約（多くの場合7-12k文字）、各圧縮時に再生成。 | 高品質な要約だが、圧縮のたびに要約全体を再生成することで、反復圧縮でドリフトが発生する可能性。 |
-
----
-
-## 結果（ハイレベル）
-
-FactoryはPRレビュー、バグ修正、機能実装、リファクタリングなどのタスクにわたる本番セッションから**36,000+メッセージ**を評価したと報告しています。
-
-### 全体スコア（0-5）
-
-| 方法 | 全体 | 正確性 | コンテキスト | アーティファクト | 完全性 | 継続性 | 指示 |
-| --------- | --------: | --------: | --------: | --------: | --------: | --------: | --------: |
-| Factory | **3.70** | **4.04** | **4.01** | **2.45** | **4.44** | **3.80** | **4.99** |
-| Anthropic | 3.44 | 3.74 | 3.56 | 2.33 | 4.37 | 3.67 | 4.95 |
-| OpenAI | 3.35 | 3.43 | 3.64 | 2.19 | 4.37 | 3.77 | 4.92 |
-
-### 圧縮率 vs. 品質
-
-投稿では、方法間で類似の圧縮率が示されています：
-
-- OpenAI: **99.3%** トークン除去
-- Anthropic: **98.7%** トークン除去
-- Factory: **98.6%** トークン除去
-
-FactoryはOpenAIより約0.7パーセンテージポイント多くのトークンを保持し（より多くのコンテキストを保持）、全体品質で**+0.35**高いスコアを記録しました。
-
----
-
-## Factoryが学んだこと
-
-- **構造が重要**: 明示的なセクション（ファイル/決定/次のステップ）を強制することで、重要な詳細が時間の経過とともに「静かに消失」する可能性を減らします。
-- **圧縮率は誤解を招く目標**: 積極的な圧縮は「トークンを節約」できるが、高価な再作業を引き起こす詳細を失う可能性があります；**タスクあたりのトークン**について最適化すべきです。
-- **アーティファクト追跡は依然として困難**: すべての方法で、どのファイルが作成/変更/検査されたかの追跡で低いスコア（Factoryの最高は**2.45/5**）であり、これは要約を超えた専用の状態追跡が必要である可能性を示唆しています。
-- **プローブベース評価はエージェントの現実により近い**: 作業を効果的に継続できるかをテストするため、テキスト類似性メトリクスよりも優れています。
-
----
-
-## 関連ドキュメント
-
-- [Memory and Context Management](/jp/guides/power-user/memory-management)
-- [Token Efficiency Strategies](/jp/guides/power-user/token-efficiency)
diff --git a/docs/jp/guides/power-user/memory-management.mdx b/docs/jp/guides/power-user/memory-management.mdx
deleted file mode 100644
index 497a0a92..00000000
--- a/docs/jp/guides/power-user/memory-management.mdx
+++ /dev/null
@@ -1,521 +0,0 @@
----
-title: "メモリとコンテキスト管理"
-description: Droidがセッションをまたいで好み、判断、プロジェクト履歴を記憶できる永続メモリを構築する。
-keywords: ['memory', 'context', 'preferences', 'persistent', 'sessions', 'history', 'memories']
----
-
-Droidはセッション間で組み込みのメモリを持ちませんが、markdownファイル、AGENTS.mdの参照、およびフックを使用して強力なメモリシステムを作成できます。このガイドでは、永続化され成長するメモリの構築方法を説明します。
-
-
- **Factory Appでも利用可能:** これらのメモリパターンはCLIと[Factory App](/jp/web/getting-started/overview)の両方で同じように機能します。作業ディレクトリがリポジトリルートに設定されていることだけ確認してください。
-
-
----
-
-## メモリシステムアーキテクチャ
-
-メモリシステムは3つの層で構成されます：
-
-```
-┌─────────────────────────────────────────────────────┐
-│ AGENTS.md │
-│ (References and orchestrates memory) │
-└─────────────────────────────────────────────────────┘
- │
- ┌──────────────┼──────────────┐
- ▼ ▼ ▼
-┌─────────────────┐ ┌─────────────┐ ┌─────────────────┐
-│ Personal Memory │ │ Project │ │ Rules & │
-│ ~/.factory/ │ │ Memory │ │ Conventions │
-│ memories.md │ │ .factory/ │ │ .factory/rules/ │
-│ │ │ memories.md │ │ │
-│ • Preferences │ │ • Decisions │ │ • Standards │
-│ • Style │ │ • History │ │ • Patterns │
-│ • Tools │ │ • Context │ │ • Guidelines │
-└─────────────────┘ └─────────────┘ └─────────────────┘
-```
-
----
-
-## 個人メモリの設定
-
-個人メモリはすべてのプロジェクトで共有されます。
-
-### ステップ1：メモリファイルの作成
-
-`~/.factory/memories.md`を作成します：
-
-```markdown
-# My Development Memory
-
-## Code Style Preferences
-
-### General
-- I prefer functional programming patterns over OOP
-- I like early returns to reduce nesting
-- I use 2-space indentation (but defer to project config)
-
-### TypeScript
-- I prefer `interface` over `type` for object shapes
-- I use strict mode always
-- I avoid `enum` in favor of `as const` objects
-
-### React
-- Functional components only
-- I prefer Zustand over Redux for state
-- I use React Query for server state
-
-## Tool Preferences
-- Package manager: pnpm (prefer) > npm > yarn
-- Testing: Vitest > Jest
-- Formatting: Prettier with defaults
-- Linting: ESLint with strict TypeScript rules
-
-## Communication Style
-- I prefer concise explanations over verbose ones
-- Show me the code first, explain after if needed
-- When debugging, show me your reasoning
-
-## Past Decisions (Personal Projects)
-- [2024-01] Switched from Create React App to Vite
-- [2024-02] Adopted Tailwind CSS as default styling
-- [2024-03] Using Supabase for personal projects
-```
-
-### ステップ2：AGENTS.mdで参照
-
-`~/.factory/AGENTS.md`またはプロジェクトの`AGENTS.md`に追加します：
-
-```markdown
-## Personal Preferences
-My coding preferences and tool choices are documented in `~/.factory/memories.md`.
-Refer to this file when making decisions about code style, architecture, or tooling.
-```
-
----
-
-## プロジェクトメモリの設定
-
-プロジェクトメモリは、コードベース固有の決定とコンテキストを記録します。
-
-### ステップ1：プロジェクトメモリの作成
-
-プロジェクトルートに`.factory/memories.md`を作成します：
-
-```markdown
-# Project Memory
-
-## Project Context
-- **Name**: Acme Dashboard
-- **Type**: B2B SaaS application
-- **Stack**: Next.js 14, TypeScript, Prisma, PostgreSQL
-- **Started**: January 2024
-
-## Architecture Decisions
-
-### 2024-01-15: Database Choice
-**Decision**: PostgreSQL over MongoDB
-**Reasoning**: Strong relational data model, ACID compliance needed for financial data
-**Trade-offs**: More rigid schema, but better for reporting queries
-
-### 2024-02-01: Authentication Approach
-**Decision**: NextAuth.js with custom credentials provider
-**Reasoning**: Need to integrate with existing enterprise LDAP
-**Implementation**: See `src/lib/auth/` for setup
-
-### 2024-02-20: State Management
-**Decision**: Zustand for client state, React Query for server state
-**Reasoning**: Simpler than Redux, better separation of concerns
-**Pattern**: Store files in `src/stores/`, queries in `src/queries/`
-
-## Known Technical Debt
-- [ ] Auth refresh token logic needs refactoring (#234)
-- [ ] Dashboard queries should be optimized with proper indexes
-- [ ] Legacy API endpoints in `/api/v1/` need deprecation
-
-## Domain Knowledge
-
-### Business Rules
-- Users belong to Organizations (multi-tenant)
-- Subscription tiers: Free, Pro, Enterprise
-- Free tier limited to 3 team members
-- Data retention: 90 days for Free, unlimited for paid
-
-### Key Entities
-- `User`: Individual accounts, can belong to multiple orgs
-- `Organization`: Tenant container, has subscription
-- `Project`: Work container within an org
-- `Task`: Work items within projects
-
-## Team Conventions
-- PR titles follow conventional commits
-- All PRs need at least one approval
-- Deploy to staging on merge to `develop`
-- Deploy to production on merge to `main`
-```
-
-### ステップ2：プロジェクトAGENTS.mdで参照
-
-プロジェクトの`AGENTS.md`を更新します：
-
-```markdown
-## Project Memory
-Architecture decisions, domain knowledge, and project history are documented in `.factory/memories.md`.
-Always check this file before making significant architectural or design decisions.
-```
-
----
-
-## メモリカテゴリ
-
-メモリを有用なカテゴリに整理します：
-
-### 設定（個人）
-あなたの好みと作業方法：
-
-```markdown
-## Preferences
-- Code style choices
-- Tool preferences
-- Communication style
-- Learning style
-```
-
-### 決定（プロジェクト）
-何が決定され、その理由：
-
-```markdown
-## Decisions
-- Architecture choices with reasoning
-- Library selections with trade-offs
-- Design patterns adopted
-- Standards agreed upon
-```
-
-### コンテキスト（プロジェクト）
-背景情報：
-
-```markdown
-## Context
-- Business domain knowledge
-- Key entities and relationships
-- External integrations
-- Performance requirements
-```
-
-### 履歴（両方）
-いつ何が起こったか：
-
-```markdown
-## History
-- Major refactors completed
-- Migrations performed
-- Issues resolved
-- Lessons learned
-```
-
----
-
-## 自動メモリ取得
-
-作業中にメモリを取得するのに役立つフックを作成します。
-
-### 「これを記憶」フック
-
-「remember this:」の後にコンテンツを続けると、自動的にメモリに追加されます。
-
-メモリキャプチャは**特殊文字**または**フレーズ**のいずれかでトリガーできます。好みに基づいて選択してください：
-
-
-
- すばやく記録するには、メッセージの先頭に`#`を付けてトリガーします。
-
- **使用例:**
- - "#リポジトリパターンを使う"
- - "##早期リターンを好む"（ダブル`##`は個人用）
-
- `~/.factory/hooks/memory-capture.py`を作成します:
-
- ```python
- #!/usr/bin/env python3
- """Captures messages starting with # and appends to memories.md"""
- import json, sys, os
- from datetime import datetime
-
- def main():
- try:
- data = json.load(sys.stdin)
- prompt = data.get('prompt', '').strip()
-
- if not prompt.startswith('#'):
- return
-
- # ## = personal, # = project
- if prompt.startswith('##'):
- content = prompt[2:].strip()
- mem_file = os.path.expanduser('~/.factory/memories.md')
- else:
- content = prompt[1:].strip()
- project_dir = os.environ.get('FACTORY_PROJECT_DIR', os.getcwd())
- project_factory = os.path.join(project_dir, '.factory')
- if os.path.exists(project_factory):
- mem_file = os.path.join(project_factory, 'memories.md')
- else:
- mem_file = os.path.expanduser('~/.factory/memories.md')
-
- if content:
- timestamp = datetime.now().strftime('%Y-%m-%d')
- with open(mem_file, 'a') as f:
- f.write(f"\n- [{timestamp}] {content}\n")
-
- print(json.dumps({'systemMessage': f'✓ Saved to {mem_file}'}))
- except:
- pass
-
- if __name__ == '__main__':
- main()
- ```
-
-
-
- "remember this:"や"note:"などのフレーズでトリガーします。
-
- **使用例:**
- - "remember this: リポジトリパターンを使う"
- - "note: 認証トークンは24時間で期限切れになる"
-
- `~/.factory/hooks/memory-capture.py`を作成します:
-
- ```python
- #!/usr/bin/env python3
- """Captures 'remember this:' statements and appends to memories.md"""
- import json, sys, os
- from datetime import datetime
-
- def main():
- try:
- data = json.load(sys.stdin)
- prompt = data.get('prompt', '')
-
- triggers = ['remember this:', 'remember:', 'note:', 'save this:']
-
- for trigger in triggers:
- if trigger in prompt.lower():
- idx = prompt.lower().index(trigger)
- content = prompt[idx + len(trigger):].strip()
-
- if content:
- # Personal if specified, otherwise project
- if 'personal' in prompt.lower():
- mem_file = os.path.expanduser('~/.factory/memories.md')
- else:
- project_dir = os.environ.get('FACTORY_PROJECT_DIR', os.getcwd())
- project_factory = os.path.join(project_dir, '.factory')
- if os.path.exists(project_factory):
- mem_file = os.path.join(project_factory, 'memories.md')
- else:
- mem_file = os.path.expanduser('~/.factory/memories.md')
-
- timestamp = datetime.now().strftime('%Y-%m-%d')
- with open(mem_file, 'a') as f:
- f.write(f"\n- [{timestamp}] {content}\n")
-
- print(json.dumps({'systemMessage': f'✓ Saved to {mem_file}'}))
- break
- except:
- pass
-
- if __name__ == '__main__':
- main()
- ```
-
-
-
-実行可能にし、フックを設定します：
-
-```bash
-chmod +x ~/.factory/hooks/memory-capture.py
-```
-
-`/hooks`を使用してフック設定に追加します：
-
-```json
-{
- "hooks": {
- "UserPromptSubmit": [
- {
- "matcher": "*",
- "hooks": [
- {
- "type": "command",
- "command": "python3 ~/.factory/hooks/memory-capture.py"
- }
- ]
- }
- ]
- }
-}
-```
-
-**#プレフィックス使用：**
-- "#状態管理にはZustandを使うことに決めた"
-- "##早期リターンを好む"（ダブル`##`は個人用に保存）
-
-**フレーズトリガー使用：**
-- "remember this: 状態管理にはZustandを使うことに決めた"
-- "note: authモジュールは24時間有効なJWTを使う"
-
-### 代替案：メモリキャプチャスキル
-
-フックの代わりに、何かを記憶するように依頼したときにDroidが呼び出す[skill](/jp/cli/configuration/skills)を使用できます。これにより、カテゴリ化をよりインタラクティブに制御できます。
-
-### 代替案：カスタムスラッシュコマンド
-
-手動での素早い取得には、[custom slash command](/jp/cli/configuration/custom-slash-commands)を作成します：
-
-`~/.factory/commands/remember.md`を作成：
-
-```markdown
----
-description: Save a memory to your memories file
-argument-hint:
----
-
-Add this to my memories file (~/.factory/memories.md):
-
-$ARGUMENTS
-
-Format it appropriately based on whether it's a preference, decision, or learning. Include today's date.
-```
-
-その後、`/remember we chose PostgreSQL for better ACID compliance`を使用してメモリをオンデマンドで取得します。
-
-
- **どの方法を選ぶべきか？**
- - **フック** — 追加手順なしで自動記録したい場合に最適
- - **スキル** — Droidに分類や整形を手伝わせたい場合に最適
- - **スラッシュコマンド** — 一貫した形式ですばやく手動記録したい場合に最適
-
-
----
-
-## メモリメンテナンス
-
-定期的なメンテナンスでメモリを有用に保ちます。
-
-### 月次レビューチェックリスト
-
-```markdown
-## Monthly Memory Review
-
-### Personal Memory (~/.factory/memories.md)
-- [ ] Remove outdated preferences (tools you no longer use)
-- [ ] Update decisions that have changed
-- [ ] Add new patterns you've adopted
-- [ ] Archive old entries that are no longer relevant
-
-### Project Memory (.factory/memories.md)
-- [ ] Review architecture decisions - still valid?
-- [ ] Update technical debt items
-- [ ] Add new domain knowledge learned
-- [ ] Document recent major changes
-```
-
-### 古いメモリのアーカイブ
-
-メモリが古くなったら、アーカイブに移動します：
-
-```markdown
-# memories.md
-
-## Current Decisions
-[active decisions here]
-
-## Archive (2023)
-
-Archived decisions from 2023
-
-### 2023-06: Original Auth System
-**Decision**: Custom JWT implementation
-**Status**: Replaced by NextAuth.js in 2024-02
-**Reason for change**: Maintenance burden, security updates
-
-
-```
-
----
-
-## 上級：メモリ対応スキル
-
-メモリファイルを活用するスキルを作成します：
-
-```markdown
----
-name: context-aware-implementation
-description: Implement features using project memory and conventions.
----
-
-# Context-Aware Implementation
-
-Before implementing any feature:
-
-1. **Check project memory** (`.factory/memories.md`):
- - What architecture decisions apply?
- - What patterns should I follow?
- - What constraints exist?
-
-2. **Check personal preferences** (`~/.factory/memories.md`):
- - What code style does the user prefer?
- - What tools should I use?
-
-3. **Check rules** (`.factory/rules/`):
- - What conventions apply to this file type?
- - What testing requirements exist?
-
-Then implement following all discovered context.
-```
-
----
-
-## クイックリファレンス
-
-### ファイル場所
-
-| メモリタイプ | 場所 | スコープ |
-| -------- | ------------------------ | -------- |
-| 個人設定 | `~/.factory/memories.md` | 全プロジェクト |
-| プロジェクト決定 | `.factory/memories.md` | このプロジェクト |
-| チーム規約 | `.factory/rules/*.md` | このプロジェクト |
-
-### メモリを追加するタイミング
-
-| イベント | 記録内容 | 場所 |
-| ------------- | -------------- | ------ |
-| アーキテクチャ決定を行った | 決定 + 理由 | プロジェクト |
-| 設定を発見した | 好み | 個人 |
-| ドメイン知識を学んだ | ビジネスルール、エンティティ | プロジェクト |
-| ワークフローを変更した | 新しいツールやパターン | 個人 |
-| 複雑な問題を解決した | 解決策とコンテキスト | プロジェクト |
-
-### メモリフォーマットテンプレート
-
-```markdown
-### [Date]: [Title]
-**Decision/Preference**: [What]
-**Reasoning**: [Why]
-**Context**: [When this applies]
-**Trade-offs**: [What you gave up]
-```
-
----
-
-## 次のステップ
-
-
-
- パワーユーザー設定を完了する
-
-
- チーム規約を整理する
-
-
diff --git a/docs/jp/guides/power-user/prompt-crafting.mdx b/docs/jp/guides/power-user/prompt-crafting.mdx
deleted file mode 100644
index 8af2e787..00000000
--- a/docs/jp/guides/power-user/prompt-crafting.mdx
+++ /dev/null
@@ -1,440 +0,0 @@
----
-title: モデル別プロンプト作成
-description: Claude、GPT、その他のモデルからより良い結果を得るためのモデル固有のプロンプト技法。
-keywords: ['prompts', 'prompting', 'claude', 'gpt', 'opus', 'sonnet', 'techniques', 'best practices']
----
-
-異なるAIモデルは、異なるプロンプティングスタイルによりよく反応します。このガイドでは、モデル固有のテクニックを取り上げ、すぐに使用できるプロンプトリファイナースキルを提供します。
-
-
- **どこでも動作:** これらのプロンプティング技術は、CLIと[Factory App](/jp/web/getting-started/overview)の両方に適用されます。
-
-
----
-
-## 汎用プロンプティング原則
-
-これらの原則は、すべてのモデルで機能します：
-
-
-
- **弱い例:** "認証のバグを修正して"
-
- **強い例:** "ユーザーが5分間の非アクティブ状態後にログアウトされるログインタイムアウトバグを修正してください。セッションは24時間持続する必要があります。"
-
-
-
- **弱い例:** "エラーハンドリングを追加して"
-
- **強い例:** "このAPIエンドポイントは決済処理を処理します。現在、ネットワークエラー時にサイレントクラッシュします。エラーをログに記録し、ユーザーフレンドリーなメッセージを返し、アラートをトリガーするエラーハンドリングを追加してください。"
-
-
-
- **弱い例:** "高速化して"
-
- **強い例:** "検索クエリを最適化してください。成功基準：10k件のレコードでクエリ時間100ms未満、結果精度に変更なし、既存のテストに合格。"
-
-
-
- **弱い例:** "このコードをリファクタリングして"
-
- **強い例:** "このコードをリポジトリパターンを使用してリファクタリングしてください。制約：パブリックAPIを変更しない、後方互換性を維持する、同じテストカバレッジを保つ。"
-
-
-
----
-
-## Claude Models（Opus、Sonnet、Haiku）
-
-Claudeモデルは、構造化された明示的な指示に優れ、特定のフォーマット パターンに特によく反応します。
-
-### Claude向けの主要テクニック
-
-
-
- Claudeは、複雑なプロンプトを整理するためのXMLスタイルタグに非常によく反応します：
-
- ```
-
- This is a React application using TypeScript and Zustand for state management.
- The auth module handles user sessions and JWT tokens.
-
-
-
- Add a "remember me" checkbox to the login form that extends session duration to 30 days.
-
-
-
- - Store preference in localStorage
- - Update JWT expiration accordingly
- - Add unit tests for the new functionality
-
- ```
-
-
-
- 特定の出力形式が必要な場合は、例を示してください：
-
- ```
-
- Input: "user not found"
- Output: { code: "USER_NOT_FOUND", message: "The specified user does not exist", httpStatus: 404 }
-
-
- Now handle these error cases following the same pattern:
- - Invalid password
- - Account locked
- - Session expired
- ```
-
-
-
- 複雑な判断については、Claudeに選択肢を検討してもらいます：
-
- ```
- Before implementing, analyze:
- 1. What are the tradeoffs between approach A and B?
- 2. Which approach better fits our existing patterns?
- 3. What edge cases should we consider?
-
- Then implement the better approach.
- ```
-
-
-
-
- 以下のプロンプトリファイナースキルを `~/.factory/skills/` にコピーして使用してください。スキルについて詳しくは、[スキルドキュメント](/jp/cli/configuration/skills)をご覧ください。
-
-
-### Claude プロンプトリファイナースキル
-
-`~/.factory/skills/prompt-refiner-claude/SKILL.md` を作成してください：
-````markdown
----
-name: prompt-refiner-claude
-description: Refine prompts for Claude models (Opus, Sonnet, Haiku) using Anthropic's best practices. Use when preparing complex tasks for Claude.
----
-
-# Claude Prompt Refiner
-
-## When to Use
-Invoke this skill when you have a task for Claude that:
-- Involves multiple steps or files
-- Requires specific output formatting
-- Needs careful reasoning or analysis
-- Would benefit from structured context
-
-## Refinement Process
-
-### 1. Analyze the Draft Prompt
-Review the user's prompt for:
-- [ ] Clear outcome definition
-- [ ] Sufficient context
-- [ ] Explicit constraints
-- [ ] Success criteria
-
-### 2. Apply Claude-Specific Patterns
-
-**Structure with XML tags:**
-- `` - Background information, codebase state
-- `` - The specific action to take
-- `` - Must-have criteria
-- `` - Limitations and boundaries
-- `` - Sample inputs/outputs if helpful
-
-**Ordering matters:**
-1. Context first (what exists)
-2. Task second (what to do)
-3. Requirements third (how to do it)
-4. Examples last (clarifying edge cases)
-
-### 3. Enhance for Reasoning
-For complex tasks, add:
-- "Think through the approach before implementing"
-- "Consider these edge cases: ..."
-- "Explain your reasoning for key decisions"
-
-### 4. Output the Refined Prompt
-Present the improved prompt with:
-- Clear section headers
-- XML tags where beneficial
-- Specific, measurable criteria
-
-## Example Transformation
-
-**Before:**
-"Add caching to the API"
-
-**After:**
-```
-
-/api/products エンドポイントは現在、リクエストごとにデータベースを照会しています。
-平均応答時間は200msです。アプリの他のキャッシュにはRedisを使用しています。
-
-
-
-データベース負荷を軽減するために、/api/products エンドポイントにRedisキャッシュを追加します。
-
-
-
-- キャッシュTTLは5分
-- 商品が更新された際のキャッシュ無効化
-- Redisが利用できない場合のデータベースへの適切なフォールバック
-- キャッシュヒット/ミスメトリクスのログ追加
-
-
-
-- レスポンス形式を変更しないこと
-- 既存の統合テストを通すこと
-- src/lib/redis.ts から既存のRedis接続を使用すること
-
-```
-````
-## GPT モデル（GPT-5、GPT-5.1、Codex）
-
-GPTモデルは明確なシステムレベルのコンテキストで優秀な性能を発揮し、明示的な役割の設定から恩恵を受けます。
-
-### GPTの主要なテクニック
-
-
-
-GPTモデルは明確な役割定義によく反応します：
- ```
- You are a senior TypeScript developer reviewing code for a production e-commerce platform.
- Focus on: type safety, error handling, and performance.
-
- Review this checkout flow implementation...
- ```
-
-
-
- GPTは番号付き指示を確実に従います：
-
- ```
- Complete these steps in order:
- 1. Read the current implementation in src/auth/
- 2. Identify all places where tokens are validated
- 3. Create a centralized token validation utility
- 4. Update all call sites to use the new utility
- 5. Add unit tests for the utility
- 6. Run the test suite and fix any failures
- ```
-
-
-
- 欲しいものを正確に指定してください：
-
- ```
- Return your analysis as a markdown document with these sections:
- ## Summary (2-3 sentences)
- ## Issues Found (bulleted list)
- ## Recommended Changes (numbered, in priority order)
- ## Code Examples (if applicable)
- ```
-
-
-
-### GPT プロンプト改善スキル
-
-`~/.factory/skills/prompt-refiner-gpt/SKILL.md` を作成します:
-````markdown
----
-name: prompt-refiner-gpt
-description: Refine prompts for GPT models (GPT-5, GPT-5.1, Codex) using OpenAI's best practices. Use when preparing complex tasks for GPT.
----
-
-# GPT Prompt Refiner
-
-## When to Use
-Invoke this skill when you have a task for GPT that:
-- Requires a specific persona or expertise
-- Involves procedural steps
-- Needs structured output
-- Benefits from explicit examples
-
-## Refinement Process
-
-### 1. Analyze the Draft Prompt
-Review for:
-- [ ] Clear role/persona definition
-- [ ] Step-by-step breakdown (if procedural)
-- [ ] Output format specification
-- [ ] Concrete examples
-
-### 2. Apply GPT-Specific Patterns
-
-**Role framing:**
-Start with "You are a [specific role] working on [specific context]..."
-
-**Numbered procedures:**
-Break complex tasks into numbered steps that build on each other.
-
-**Output specification:**
-Be explicit: "Return as JSON", "Format as markdown with headers", etc.
-
-**Chain of thought:**
-For reasoning tasks, add: "Think through this step by step."
-
-### 3. Structure the Prompt
-
-**Effective order for GPT:**
-1. Role definition (who/what)
-2. Context (background info)
-3. Task (what to do)
-4. Steps (how to do it, if procedural)
-5. Output format (what to return)
-6. Examples (optional clarification)
-
-### 4. Output the Refined Prompt
-Present with:
-- Clear role statement
-- Numbered steps where applicable
-- Explicit output requirements
-
-## Example Transformation
-
-**Before:**
-"Review this code for security issues"
-
-**After:**
-```
-あなたはNode.js決済処理サービスのセキュリティ監査を実施するシニアセキュリティエンジニアです。
-
-コンテキスト: このサービスはクレジットカード取引を処理し、StripeのAPIと通信します。AWS ECSで実行されます。
-
-タスク: セキュリティ脆弱性について`src/payments/`のコードをレビューしてください。
-
-手順:
-1. すべてのエンドポイントで適切な入力検証を確認
-2. シークレットがハードコード化されていたり、ログに記録されていないことを確認
-3. 認証と認可ロジックをレビュー
-4. SQLインジェクションとXSS脆弱性を確認
-5. 機密情報を漏洩しない適切なエラーハンドリングを確認
-
-出力形式:
-以下の内容でmarkdown形式のセキュリティレポートを返してください:
-- **Critical**: デプロイ前に修正が必要な問題
-- **High**: 速やかに対処すべき重大なリスク
-- **Medium**: 検討すべき改善点
-- **Recommendations**: 一般的なセキュリティ強化策
-
-各問題について以下を含めてください:
-- ファイルと行番号
-- 脆弱性の説明
-- コード例を含む推奨修正方法
-```
-````
----
-
-## Gemini モデル
-
-Gemini モデルは長いコンテキストを適切に処理し、構造化された推論で効果的に動作します。
-
-### Gemini の主要テクニック
-
-
-
- Gemini は広範囲なコンテキストを処理できます。より多くの背景情報を含めることを恐れる必要はありません：
-
- ```
- Here's the full module structure for context:
- [include relevant files]
-
- Based on these patterns, implement a new service that...
- ```
-
-
-
- Geminiは低推論と高推論をサポートしています。高推論は以下の場合に使用してください：
- - アーキテクチャの意思決定
- - 複雑なデバッグ
- - 多段階の計画立案
-
- 低推論は以下の場合に使用してください：
- - 単純な実装
- - 仕様書からのコード生成
- - 定期的なリファクタリング
-
-
-
----
-
-## モデル選択戦略
-
-タスクに適したモデルを選択してください：
-
-| タスクタイプ | 推奨モデル | 推論レベル |
-| ---------------- | ---------------------------- | -------- |
-| **複雑なアーキテクチャ** | Opus 4.7 または Opus 4.6 | High-Max |
-| **機能実装** | Sonnet 4.5 または GPT-5.1-Codex | Medium |
-| **簡単な編集、フォーマット** | Haiku 4.5 | Off/Low |
-| **コードレビュー** | GPT-5.1-Codex-Max | High |
-| **一括自動化** | GLM-5 (Droid Core) | None |
-| **調査/分析** | Gemini 3 Pro | High |
-
----
-
-## 独自のプロンプトリファイナーの作成
-
-チーム固有のニーズに対応するため、カスタムプロンプトリファイナーを作成してください：
-````markdown
----
-name: prompt-refiner-team
-description: Refine prompts using our team's conventions and project context.
----
-
-# Team Prompt Refiner
-
-## Our Conventions
-- We use the repository pattern
-- All services have interfaces defined first
-- Tests use our custom test utilities from @/test-utils
-
-## Checklist for Prompts
-1. [ ] References relevant existing code
-2. [ ] Specifies which layer (API, service, repository)
-3. [ ] Mentions related tests to update
-4. [ ] Includes acceptance criteria
-
-## Template
-```
-コンテキスト: [何が存在するか、どのモジュール/レイヤーか]
-タスク: [具体的なアクション]
-従うべきパターン: [既存の類似コードを参考にする]
-テスト: [追加/更新すべきテスト]
-完了条件: [受け入れ基準]
-```
-````
----
-
-## クイック リファレンス カード
-
-### Claude (Opus/Sonnet/Haiku)
-- ✅ 構造化のためのXMLタグ
-- ✅ 指示の前にコンテキスト
-- ✅ 専用セクションでの例
-- ✅ 推論のための「Think through...」
-
-### GPT (GPT-5/Codex)
-- ✅ ロール設定（「You are a...」）
-- ✅ 番号付きステップ手順
-- ✅ 明示的な出力形式
-- ✅ 推論のための「Step by step」
-
-### Gemini
-- ✅ 広範囲なコンテキストの包含
-- ✅ 低/高推論レベル
-- ✅ 構造化された出力リクエスト
-
----
-
-## 次のステップ
-
-
-
- パワーユーザー設定を完了する
-
-
- 品質を保ちながらコストを削減する
-
-
diff --git a/docs/jp/guides/power-user/rules-conventions.mdx b/docs/jp/guides/power-user/rules-conventions.mdx
deleted file mode 100644
index c2e4a17e..00000000
--- a/docs/jp/guides/power-user/rules-conventions.mdx
+++ /dev/null
@@ -1,689 +0,0 @@
----
-title: "ルールと規約"
-description: Droidがすべての作業で一貫して従えるように、コーディング標準とチーム規約を整理する。
-keywords: ['rules', 'conventions', 'standards', 'coding style', 'guidelines', 'team', 'consistency']
----
-
-ルールは、Droidが毎回従う成文化された標準です。（決定と文脈を捉える）メモリーとは異なり、ルールはコードがどのように書かれるべきかを定義します。このガイドでは、個人やチームにおいて効果的にルールを整理する方法を説明します。
-
-
- **Factory Appでも利用可能:** これらの規約はCLIと[Factory App](/jp/web/getting-started/overview)の両方で同じように機能します。インターフェースに関係なく、Droidは同じ`.factory/rules/`ファイルを読み込みます。
-
-
----
-
-## ルールと他の設定の比較
-
-| タイプ | 目的 | 例 |
-|------|---------|---------|
-| **ルール** | コードがどのように書かれるべきか | "ネストした条件文の代わりに早期リターンを使用する" |
-| **メモリ** | 何が決定され、なぜそうしたか | "Reduxが冗長すぎたため、Zustandを選んだ" |
-| **AGENTS.md** | ビルド/テスト/実行の方法 | "作業完了前に `npm test` を実行する" |
-| **スキル** | 特定のタスクの実行方法 | "新しいAPIエンドポイントを実装するステップ" |
-
-ルールは**規範的**です—Droidにすべきことを指示します。一貫して適用されるべき標準に使用してください。
-
----
-
-## ルールディレクトリの設定
-
-### 基本構造
-
-プロジェクトに `.factory/rules/` ディレクトリを作成します：
-
-```
-.factory/
-└── rules/
- ├── typescript.md # TypeScript conventions
- ├── react.md # React patterns
- ├── testing.md # Testing requirements
- ├── api.md # API design rules
- └── security.md # Security requirements
-```
-
-すべてのプロジェクトに適用される個人ルールの場合：
-
-```
-~/.factory/
-└── rules/
- ├── style.md # Your personal style
- └── tools.md # Tool preferences
-```
-
-### AGENTS.mdでルールを参照する
-
-`AGENTS.md` にセクションを追加します：
-
-```markdown
-## Coding Standards
-
-Follow the conventions documented in `.factory/rules/`:
-- **TypeScript**: `.factory/rules/typescript.md`
-- **React**: `.factory/rules/react.md`
-- **Testing**: `.factory/rules/testing.md`
-- **API Design**: `.factory/rules/api.md`
-- **Security**: `.factory/rules/security.md`
-
-When working on a file, check the relevant rules first.
-```
-
----
-
-## 効果的なルールの記述
-
-### ルール構造
-
-各ルールは以下であるべきです：
-- **具体的**: 解釈の余地なく従えるほど明確
-- **実行可能**: 避けるべきことではなく、すべきことを指示
-- **スコープ化**: いつ適用されるかを明記
-- **正当化** (任意): 複雑なルールに対する理由の説明
-
-### テンプレート
-
-```markdown
-# [カテゴリ]ルール
-
-## [ルール名]
-**適用対象**: [ファイルタイプ、コンテキスト]
-**ルール**: [具体的な指示]
-**例**: [正しい使い方を示すコード]
-**理由**: [重要な理由 - 任意]
-```
-
----
-
-## ルールファイルの例
-
-### TypeScriptルール
-
-`.factory/rules/typescript.md` を作成します：
-
-```markdown
-# TypeScriptルール
-
-## Type Definitions
-
-### オブジェクト形状には`interface`を使用
-**適用対象**: オブジェクトのすべての型定義
-**ルール**: オブジェクト型には`interface`、ユニオン・インターセクション・プリミティブには`type`を使用します。
-
-```typescript
-// ✅ 正しい
-interface User {
- id: string;
- name: string;
-}
-
-type Status = 'active' | 'inactive';
-type UserWithStatus = User & { status: Status };
-
-// ❌ 避ける
-type User = {
- id: string;
- name: string;
-};
-```
-
-### `any`を避ける
-**適用対象**: すべてのTypeScriptファイル
-**ルール**: `any`は使用しません。型ガード付きの`unknown`を使うか、適切な型を定義します。
-
-```typescript
-// ✅ 正しい
-function processData(data: unknown): string {
- if (typeof data === 'string') {
- return data.toUpperCase();
- }
- throw new Error('Expected string');
-}
-
-// ❌ 避ける
-function processData(data: any): string {
- return data.toUpperCase();
-}
-```
-
-## Function Patterns
-
-### Use early returns
-**Applies to**: All functions with conditionals
-**Rule**: Return early for edge cases instead of nesting.
-
-```typescript
-// ✅ 正しい
-function processUser(user: User | null): string {
- if (!user) return 'No user';
- if (!user.active) return 'User inactive';
- return `Processing ${user.name}`;
-}
-
-// ❌ 避ける
-function processUser(user: User | null): string {
- if (user) {
- if (user.active) {
- return `Processing ${user.name}`;
- } else {
- return 'User inactive';
- }
- } else {
- return 'No user';
- }
-}
-```
-
-### Named exports over default
-**Applies to**: All module exports
-**Rule**: Use named exports for better refactoring and import clarity.
-
-```typescript
-// ✅ 正しい
-export function createUser() {}
-export const USER_ROLES = ['admin', 'user'] as const;
-
-// ❌ 避ける
-export default function createUser() {}
-```
-```
-
-### Reactルール
-
-`.factory/rules/react.md` を作成します：
-
-```markdown
-# Reactルール
-
-## Component Structure
-
-### Functional components only
-**Applies to**: All React components
-**Rule**: Use functional components with hooks. Never use class components.
-
-### Props interface naming
-**Applies to**: All components with props
-**Rule**: Name props interface as `{ComponentName}Props`.
-
-```tsx
-// ✅ 正しい
-interface UserCardProps {
- user: User;
- onSelect: (user: User) => void;
-}
-
-export function UserCard({ user, onSelect }: UserCardProps) {
- return onSelect(user)}>{user.name}
;
-}
-```
-
-### Component file structure
-**Applies to**: All component files
-**Rule**: Order sections as: imports, types, component, exports.
-
-```tsx
-// 1. インポート（React、外部、内部、型）
-import { useState } from 'react';
-import { Button } from '@/components/ui';
-import type { User } from '@/types';
-
-// 2. 型
-interface UserListProps {
- users: User[];
-}
-
-// 3. コンポーネント
-export function UserList({ users }: UserListProps) {
- const [selected, setSelected] = useState(null);
-
- return (
-
- {users.map(user => (
- - {user.name}
- ))}
-
- );
-}
-```
-
-## State Management
-
-### Zustand for client state
-**Applies to**: Client-side state that isn't server data
-**Rule**: Use Zustand stores in `src/stores/`. One store per domain.
-
-```typescript
-// src/stores/useUserStore.ts
-import { create } from 'zustand';
-
-interface UserState {
- currentUser: User | null;
- setUser: (user: User) => void;
- logout: () => void;
-}
-
-export const useUserStore = create((set) => ({
- currentUser: null,
- setUser: (user) => set({ currentUser: user }),
- logout: () => set({ currentUser: null }),
-}));
-```
-
-### React Query for server state
-**Applies to**: All data fetched from APIs
-**Rule**: Use React Query. Queries go in `src/queries/`.
-
-```typescript
-// src/queries/useUsers.ts
-import { useQuery } from '@tanstack/react-query';
-
-export function useUsers() {
- return useQuery({
- queryKey: ['users'],
- queryFn: () => fetch('/api/users').then(r => r.json()),
- });
-}
-```
-```
-
-### テストルール
-
-`.factory/rules/testing.md`を作成します:
-
-```markdown
-# テストルール
-
-## File Organization
-
-### Colocate test files
-**Applies to**: All tests except E2E
-**Rule**: Place test files next to source files.
-
-```
-src/
-└── components/
- └── UserCard/
- ├── UserCard.tsx
- ├── UserCard.test.tsx # ✅ Colocated
- └── index.ts
-```
-
-### E2E tests in dedicated directory
-**Applies to**: End-to-end tests
-**Rule**: Place E2E tests in `e2e/` at project root.
-
-## Test Structure
-
-### Descriptive test names
-**Applies to**: All test cases
-**Rule**: Format as "should [action] when [condition]".
-
-```typescript
-// ✅ 正しい
-it('should display error message when login fails', () => {});
-it('should redirect to dashboard when login succeeds', () => {});
-
-// ❌ 避ける
-it('login error', () => {});
-it('works', () => {});
-```
-
-### One assertion per test
-**Applies to**: Unit tests
-**Rule**: Test one behavior per test case. Multiple assertions OK if testing same behavior.
-
-```typescript
-// ✅ 正しい - testing one behavior
-it('should format user name correctly', () => {
- const result = formatUserName({ first: 'John', last: 'Doe' });
- expect(result).toBe('John Doe');
-});
-
-// ✅ これも正しい - 同じ振る舞いの複数側面
-it('should return complete user object', () => {
- const user = createUser('John');
- expect(user.id).toBeDefined();
- expect(user.name).toBe('John');
- expect(user.createdAt).toBeInstanceOf(Date);
-});
-
-// ❌ 避ける - testing multiple behaviors
-it('should handle user operations', () => {
- expect(createUser('John').name).toBe('John');
- expect(deleteUser('123')).toBe(true);
- expect(listUsers()).toHaveLength(0);
-});
-```
-
-## Mocking
-
-### Mock at boundaries
-**Applies to**: All mocked dependencies
-**Rule**: Mock external APIs and services, not internal functions.
-
-```typescript
-// ✅ 正しい - mock external API
-vi.mock('@/lib/api', () => ({
- fetchUser: vi.fn().mockResolvedValue({ id: '1', name: 'John' }),
-}));
-
-// ❌ 避ける - mock internal implementation
-vi.mock('@/utils/formatName', () => ({
- formatName: vi.fn().mockReturnValue('John'),
-}));
-```
-
-### Use MSW for API mocking in integration tests
-**Applies to**: Integration tests that need API responses
-**Rule**: Use Mock Service Worker instead of mocking fetch directly.
-
-```typescript
-// ✅ 正しい
-import { http, HttpResponse } from 'msw';
-
-const handlers = [
- http.get('/api/users', () => {
- return HttpResponse.json([{ id: '1', name: 'John' }]);
- }),
-];
-```
-```
-
-### セキュリティルール
-
-`.factory/rules/security.md`を作成します:
-
-```markdown
-# セキュリティルール
-
-## Secrets Management
-
-### Never hardcode secrets
-**Applies to**: All code
-**Rule**: Use environment variables for all secrets. Never commit secrets.
-
-```typescript
-// ✅ 正しい
-const apiKey = process.env.API_KEY;
-
-// ❌ 絶対にしない
-const apiKey = 'sk-1234567890abcdef';
-```
-
-### Validate environment variables
-**Applies to**: Application startup
-**Rule**: Validate required env vars exist at startup.
-
-```typescript
-// ✅ 正しい
-const config = {
- apiKey: requireEnv('API_KEY'),
- dbUrl: requireEnv('DATABASE_URL'),
-};
-
-function requireEnv(name: string): string {
- const value = process.env[name];
- if (!value) throw new Error(`Missing required env var: ${name}`);
- return value;
-}
-```
-
-## Input Validation
-
-### Validate all external input
-**Applies to**: API routes, form handlers
-**Rule**: Use Zod to validate all input from users or external sources.
-
-```typescript
-// ✅ 正しい
-import { z } from 'zod';
-
-const CreateUserSchema = z.object({
- email: z.string().email(),
- name: z.string().min(1).max(100),
-});
-
-export async function createUser(input: unknown) {
- const data = CreateUserSchema.parse(input);
- // dataは型付けされ検証済み
-}
-```
-
-## Error Handling
-
-### Never expose internal errors
-**Applies to**: API error responses
-**Rule**: Log detailed errors server-side; return generic messages to clients.
-
-```typescript
-// ✅ 正しい
-try {
- await processPayment(data);
-} catch (error) {
- console.error('Payment failed:', error); // 詳細ログ
- throw new ApiError('Payment processing failed', 500); // 汎用メッセージ
-}
-```
-
-## Authentication
-
-### Check authentication on every protected route
-**Applies to**: All API routes requiring auth
-**Rule**: Use middleware or guards. Never assume auth from client.
-
-```typescript
-// ✅ 正しい
-export async function GET(request: Request) {
- const session = await getSession(request);
- if (!session) {
- return new Response('Unauthorized', { status: 401 });
- }
- // ... handle authenticated request
-}
-```
-```
-
----
-
-## チームルールの整理
-
-### 階層化されたルール
-
-チームでは、ルールをレイヤーに分けて整理します:
-
-```
-.factory/rules/
-├── _base/ # Foundation rules (everyone follows)
-│ ├── typescript.md
-│ └── security.md
-├── frontend/ # Frontend-specific
-│ ├── react.md
-│ └── styling.md
-├── backend/ # Backend-specific
-│ ├── api.md
-│ └── database.md
-└── testing/ # テスト標準
- ├── unit.md
- └── integration.md
-```
-
-AGENTS.mdで参照します:
-
-```markdown
-## ルール
-- ベースルール: `.factory/rules/_base/` - すべてのコードに適用
-- フロントエンドルール: `.factory/rules/frontend/` - Reactコンポーネント
-- バックエンドルール: `.factory/rules/backend/` - APIとサービス
-- テストルール: `.factory/rules/testing/` - すべてのテスト
-```
-
-### ルールの所有者
-
-各ルールセットの管理者を追跡するため、オーナー情報を追加します:
-
-```markdown
-# TypeScriptルール
-
-**Owner**: Platform Team
-**Last Updated**: 2024-02-15
-**Review Cycle**: Quarterly
-
-[ルール内容...]
-```
-
----
-
-## Current Limitation: No Glob Pattern Support
-
-
-現在、Droidはファイルパターンに基づく条件付きルール適用（例: 「これらのルールを`*.tsx`ファイルにのみ適用」）をサポートしていません。これはロードマップ上にあります。
-
-
-**回避策：**
-
-1. **ファイルタイプごとに整理**: 別々のルールファイルを作成し、コンテキストに応じて参照する
-
-```markdown
-# In AGENTS.md
-When working on React components (*.tsx), follow `.factory/rules/react.md`
-When working on API routes, follow `.factory/rules/api.md`
-```
-
-2. **ルールで明確なスコープを使用**: 適用可能性を明確に述べる
-
-```markdown
-## This rule applies to: React component files (*.tsx)
-```
-
-3. **複雑なワークフローにはスキルを使用**: スキルはファイルタイプ固有の指示をエンコードできる
-
----
-
-## ルールの保守
-
-### 新しいルールの追加
-
-Droidを繰り返し修正している場合：
-
-1. パターンを特定する
-2. 例を含む明確なルールを記述する
-3. 適切なルールファイルに追加する
-4. 必要に応じてAGENTS.mdを更新する
-5. 類似の作業をDroidに依頼してテストする
-
-### ルールのレビュー
-
-四半期レビューチェックリスト：
-
-- [ ] リンティングで強制されるようになったルールを削除
-- [ ] 変更されたルールを更新
-- [ ] 新しいパターンのルールを追加
-- [ ] 例がまだ正確かチェック
-- [ ] AGENTS.mdの参照が最新かを確認
-
-### ルールの廃止
-
-ルールが時代遅れになった場合：
-
-```markdown
-## ~~Use PropTypes for type checking~~ (DEPRECATED)
-**Status**: Deprecated as of 2024-02
-**Reason**: We now use TypeScript for all type checking
-**Replacement**: See TypeScript rules for prop typing
-```
-
----
-
-## ルールの自動実行
-
-Droidは `.factory/rules/` ファイルのルールに従いますが、[フック](/jp/cli/configuration/hooks-guide) で自動実行を追加できます。
-
-### 編集後にリンターを実行
-
-ファイル編集後にリンターを自動実行するPostToolUseフックを追加します：
-
-```json
-{
- "hooks": {
- "PostToolUse": [
- {
- "matcher": "Create|Edit|ApplyPatch",
- "hooks": [
- {
- "type": "command",
- "command": "cd \"$FACTORY_PROJECT_DIR\" && npm run lint -- --fix 2>/dev/null || true"
- }
- ]
- }
- ]
- }
-}
-```
-
-### コードスタイルの検証
-
-Prettierやフォーマッターを自動実行します：
-
-```json
-{
- "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 || true"
- }
- ]
- }
- ]
- }
-}
-```
-
-
- その他の例は[自動整形フック](/jp/guides/hooks/auto-formatting)と[コード検証フック](/jp/guides/hooks/code-validation)を参照してください。
-
-
----
-
-## クイックリファレンス
-
-### ファイルの場所
-
-| スコープ | 場所 | 用途 |
-|-------|----------|---------|
-| 個人 | `~/.factory/rules/` | あなたのスタイル設定 |
-| プロジェクト | `.factory/rules/` | チーム標準 |
-
-### ルール形式
-
-```markdown
-## [ルール名]
-**Applies to**: [scope]
-**Rule**: [what to do]
-**Example**: [code]
-**Rationale**: [why - optional]
-```
-
-### 良いルールの条件
-
-- ✅ 具体的で曖昧さがない
-- ✅ コード例を含む
-- ✅ いつ適用されるかを明記
-- ✅ 実行可能（「Xを検討する」ではなく「Xを行う」）
-- ❌ 曖昧ではない（「クリーンなコードを書く」）
-- ❌ リンタールールと重複していない
-- ❌ 他のルールと矛盾していない
-
----
-
-## 次のステップ
-
-
-
- パワーユーザー設定を完了する
-
-
- 意思決定とコンテキストを記録する
-
-
diff --git a/docs/jp/guides/power-user/setup-checklist.mdx b/docs/jp/guides/power-user/setup-checklist.mdx
deleted file mode 100644
index 2f6342c6..00000000
--- a/docs/jp/guides/power-user/setup-checklist.mdx
+++ /dev/null
@@ -1,408 +0,0 @@
----
-title: "パワーユーザーセットアップチェックリスト"
-description: IDE連携、メモリ、スキル、自動化を使ってDroidを最大限活用するための完全チェックリスト。
-keywords: ['power user', 'setup', 'checklist', 'configuration', 'optimization', 'productivity', 'best practices']
----
-
-このチェックリストは、基本的なDroidインストールを完全に最適化された開発環境に変換します。各セクションは前のセクションをベースに構築されているため、最良の結果を得るためには順番通りに完了してください。
-
-
- 分けて進めたい場合は、各セクションを個別に実行できます。
-
-
-
- **Factory Appを使用していますか？** このガイドの大部分はCLIと[Factory App](/jp/web/getting-started/overview)の両方に適用されます。体験が異なる箇所では、App固有の方法を記載しています。
-
-
----
-
-## レベル1：基本セットアップ
-
-これらの基盤となる項目は、最大の即時効果をもたらします。
-
-
-
- IDEプラグインは、開いているファイル、エラー、選択範囲などのリアルタイムコンテキストを提供し、Droidがあなたと同じものを見られるようにします。
-
- **VSCode/Cursor:**
- 1. Extensionsを開きます（`Cmd+Shift+X`）
- 2. Search "Factory"
- 3. インストールして再読み込みします
-
- **確認:** `droid`を実行し、ステータスバーに"IDE connected"が表示されることを確認します。
-
-
-
- リポジトリルートに基本的な[`AGENTS.md`](/jp/cli/configuration/agents-md)を作成します:
-
- ```markdown
- # 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
- ```
-
- 最小構成から始め、作業しながら拡張します。その他の例は[AGENTS.mdガイド](/jp/cli/configuration/agents-md)を参照してください。
-
-
-
- 設定で使用するモデルを設定します:
-
- **CLI:**
- ```bash
- droid
- > /settings
- # Navigate to Model and select your default
- ```
-
- **Factory App:** チャットインターフェースのモデルセレクタードロップダウンを使用します。
-
- **推奨:** 複雑な作業ではClaude Opus 4.5（デフォルト）から始め、定型作業ではHaiku 4.5またはGPT-5.1-Codexに切り替えます。
-
-
-
-
- **チェックポイント:** これでIDE連携、基本的なプロジェクトコンテキスト、使用するモデルが設定されました。
-
-
----
-
-## レベル2：メモリ＆コンテキスト
-
-永続的なメモリを構築し、Droidがセッション間であなたの設定を記憶できるようにします。
-
-
-
- 個人の好み用に`~/.factory/memories.md`を作成します:
-
- ```markdown
- # 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
- ```
-
- Droidに同じ指示を繰り返していると気づいたら、このファイルを更新してください。
-
-
-
- `AGENTS.md`に追加します:
-
- ```markdown
- ## Personal Preferences
- Refer to `~/.factory/memories.md` for my coding preferences and past decisions.
- ```
-
-
-
- チームプロジェクトでは`.factory/memories.md`を作成します:
-
- ```markdown
- # 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
- ```
-
-
-
-
- **チェックポイント:** Droidは、あなたが繰り返さなくても好みとプロジェクト履歴にアクセスできるようになりました。
-
-
-
- **メモリ記録を自動化したいですか？** "remember this:"と言ったときにメモリを自動保存するフックを設定します。セットアップ手順は[メモリ管理](/jp/guides/power-user/memory-management#automatic-memory-capture)を参照してください。
-
-
----
-
-## レベル3：ルール＆規約
-
-コーディング標準を整理し、Droidが一貫してそれらに従うようにします。
-
-
-
- プロジェクトに`.factory/rules/`を作成します:
-
- ```
- .factory/
- └── rules/
- ├── typescript.md
- ├── testing.md
- └── security.md
- ```
-
-
-
- `.factory/rules/typescript.md`を作成します:
-
- ```markdown
- # 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
- ```
-
-
-
- `.factory/rules/testing.md`を作成します:
-
- ```markdown
- # 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`
- ```
-
-
-
- `AGENTS.md`を更新します:
-
- ```markdown
- ## 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
- ```
-
-
-
-
- **チェックポイント:** コーディング標準が文書化され、Droidが一貫して従うようになりました。
-
-
-
- **ルールを自動適用:** 編集後にリンターを実行するには[PostToolUseフック](/jp/cli/configuration/hooks-guide)を使用します。例は[フックリファレンス](/jp/reference/hooks-reference)を参照してください。
-
-
----
-
-## レベル4：スキル＆自動化
-
-再利用可能なスキルと自動化フックを追加します。
-
-
- **自動化する3つの方法:**
- - **[スキル](/jp/cli/configuration/skills)** — Droidがタスクコンテキストに基づいて呼び出します
- - **[フック](/jp/cli/configuration/hooks-guide)** — 特定イベントで自動実行されます
- - **[カスタムスラッシュコマンド](/jp/cli/configuration/custom-slash-commands)** — `/command-name`で呼び出します
-
-
-
-
- `~/.factory/skills/prompt-refiner/SKILL.md`を作成します:
-
- ```markdown
- ---
- 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フックを追加します:
-
- ```json
- {
- "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"
- }
- ]
- }
- ]
- }
- }
- ```
-
- これにより、Droidが編集した後にファイルが自動整形されます。
-
-
-
- 編集後に関連テストを実行します:
-
- ```json
- {
- "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"
- }
- ]
- }
- ]
- }
- }
- ```
-
-
-
-
- **チェックポイント:** 再利用可能なスキルと自動整形/テストが設定されました。
-
-
----
-
-## レベル5：トークン最適化
-
-品質を犠牲にすることなく、コスト効率を微調整します。
-
-
-
- 複数ファイルに触れる機能を始める前に`Shift+Tab`または`/spec`を使用します。これによりコストの高い手戻りを防げます。
-
-
-
- 計画用に仕様モードモデルを設定します:
-
- ```bash
- droid
- > /settings
- # Set Spec Mode Model to a reasoning-heavy model
- ```
-
- 計画にはOpus 4.5を使用し、実装にはSonnetまたはCodexを使用します。
-
-
-
- プロジェクトのAI準備状況を確認します:
-
- **CLI:**
- ```bash
- droid
- > /readiness-report
- ```
-
- **Factory App:** [Agent Readinessダッシュボード](/jp/web/agent-readiness/dashboard)で準備状況スコアを確認します。
-
- 影響の大きい項目から対応します。lint、型チェック、高速テストはトークンの無駄を大幅に減らします。
-
-
-
----
-
-## クイックリファレンス：ファイルの場所
-
-| 目的 | 個人用 | プロジェクト用 |
-|---------|----------|---------|
-| **スキル** | `~/.factory/skills//SKILL.md` | `.factory/skills//SKILL.md` |
-| **メモリ** | `~/.factory/memories.md` | `.factory/memories.md` |
-| **ルール** | `~/.factory/rules/*.md` | `.factory/rules/*.md` |
-| **設定** | `~/.factory/settings.json` | `.factory/settings.json` |
-| **フック** | settings.json内 | settings.json内 |
-| **エージェント指示** | `~/.factory/AGENTS.md` | `./AGENTS.md` |
-| **カスタムdroid** | `~/.factory/droids/.md` | `.factory/droids/.md` |
-
----
-
-## 検証チェックリスト
-
-セットアップを検証するために、このチェックリストを実行してください：
-
-- [ ] Droid実行時にIDEプラグインが「接続済み」を表示する
-- [ ] `AGENTS.md`がbuild/testコマンドと共に存在する
-- [ ] あなたの設定を含むメモリファイルが作成されている
-- [ ] 少なくとも1つのルールファイルがあるルールディレクトリが存在する
-- [ ] 少なくとも1つのカスタムスキルが作成されている
-- [ ] 自動フォーマットフックが設定されている
-- [ ] 準備状況レポートがレベル2以上を表示する
-
----
-
-## 次のステップ
-
-
-
- モデル別のプロンプト技法を学ぶ
-
-
- トークン使用量を減らす戦略
-
-
- 高度なメモリとコンテキストのパターン
-
-
- チーム規約を効果的に整理する
-
-
diff --git a/docs/jp/guides/power-user/token-efficiency.mdx b/docs/jp/guides/power-user/token-efficiency.mdx
deleted file mode 100644
index e9d287ff..00000000
--- a/docs/jp/guides/power-user/token-efficiency.mdx
+++ /dev/null
@@ -1,347 +0,0 @@
----
-title: トークン効率化戦略
-description: プロジェクト設定、モデル選択、ワークフロー最適化により、品質を保ちながらトークン使用量を削減する。
-keywords: ['tokens', 'efficiency', 'cost', 'optimization', 'usage', 'pricing', 'performance']
----
-
-Token使用量はコストだけの問題ではありません。フィードバックループの速度とコンテキストウィンドウの制限にも関わります。このガイドでは、プロジェクトの最適化、賢いモデル選択、ワークフローパターンを通じて、より少ないTokenでより多くのことを実現する方法を示します。
-
-
- **Factory Appを使用していますか？**これらの戦略はCLIと[Factory App](/jp/web/getting-started/overview)の両方に適用されます。[Agent Readinessダッシュボード](/jp/web/agent-readiness/dashboard)でプロジェクトの準備状況スコアを確認できます。
-
-
----
-
-## Token使用量の理解
-
-Tokenは主に3つの領域で消費されます：
-```
-┌──────────────────────────────────────────────────────────┐
-│ Token Consumption │
-├────────────────┬────────────────┬────────────────────────┤
-│ Context │ Tool Calls │ Model Output │
-│ (Input) │ (Overhead) │ (Response) │
-├────────────────┼────────────────┼────────────────────────┤
-│ • AGENTS.md │ • Read files │ • Explanations │
-│ • Memories │ • Grep/search │ • Generated code │
-│ • Conversation │ • Execute cmds │ • Analysis │
-│ • File content │ • Each retry │ • Thinking tokens │
-└────────────────┴────────────────┴────────────────────────┘
-```
-**高いトークン使用量は通常以下を意味します：**
-- 過度な探索（不明確な指示）
-- 複数回の試行（コンテキスト不足またはテストの失敗）
-- 冗長な出力（フォーマット制約なし）
-
----
-
-## 効率性のためのプロジェクトセットアップ
-
-最大のトークン節約は、無駄なサイクルを防ぐプロジェクト設定から生まれます。
-
-### 1. 高速で信頼性の高いテスト
-
-
- 遅い、または不安定なテストは、トークンの無駄の最大の原因です。各リトライは完全なレスポンスサイクルのコストがかかります。
-
-
-| テストの特徴 | トークンへの影響 |
-| ------------ | ------------------------------------ |
-| 高速テスト（30秒未満） | Droidは変更を即座に検証 |
-| 低速テスト（2分超） | Droidは検証をスキップするか、待機中にコンテキストを無駄にする可能性 |
-| 不安定なテスト | 誤った失敗がデバッグサイクルを引き起こす |
-| テストなし | Droidは変更を検証できず、より多くのやり取りが発生 |
-
-**アクション項目：**
-```markdown
-## In your AGENTS.md
-
-## Testing
-- Run single file: `npm test -- path/to/file.test.ts`
-- Run fast smoke tests: `npm test -- --testPathPattern=smoke`
-- Full suite takes ~3 minutes, use `--bail` for early exit on failure
-```
-### 2. リンティングと型チェック
-
-Droidがエラーを即座に検出できる場合、あなたからの報告を待つのではなく、同じターンで修正します。
-```markdown
-## In your AGENTS.md
-
-## Validation Commands
-- Lint (auto-fix): `npm run lint:fix`
-- Type check: `npm run typecheck`
-- Full validation: `npm run validate` (lint + typecheck + test)
-
-Always run `npm run lint:fix` after making changes.
-```
-### 3. 明確なプロジェクト構造
-
-Droidがトークンを無駄に消費して探索しないよう、ファイル構成を文書化してください：
-```markdown
-## In your AGENTS.md
-
-## Project Structure
-- `src/components/` - React components (one per file)
-- `src/hooks/` - Custom React hooks
-- `src/services/` - API and business logic
-- `src/types/` - TypeScript type definitions
-- `tests/` - Test files mirror src/ structure
-
-When adding a new component:
-1. Create component in `src/components/ComponentName/`
-2. Add index.ts for exports
-3. Add ComponentName.test.tsx in same directory
-```
----
-
-## エージェント準備チェックリスト
-
-[エージェント準備レポート](/jp/cli/features/readiness-report)は、トークン効率に直接影響する基準に対してプロジェクトを評価します。
-
-### 高影響基準
-
-| 基準 | トークンへの影響 | 重要な理由 |
-| ----------------- | -------- | ------------------------ |
-| **リンター設定** | 🟢 高 | エラーを即座にキャッチし、デバッグサイクルを削減 |
-| **型チェッカー** | 🟢 高 | 実行時エラーを防ぎ、コードをより明確に |
-| **実行可能なユニットテスト** | 🟢 高 | 同じターンでの検証 |
-| **AGENTS.md** | 🟢 高 | 事前のコンテキスト、探索の削減 |
-| **ビルドコマンドドキュメント** | 🟡 中 | 推測不要、失敗の試行を削減 |
-| **依存関係の固定** | 🟡 中 | 再現可能なビルド |
-| **プリコミットフック** | 🟡 中 | 自動品質強制 |
-
-準備レポートを実行してギャップを特定してください：
-```bash
-droid
-> /readiness-report
-```
----
-
-## モデル選択戦略
-
-異なるモデルには異なるコスト倍率と機能があります。タスクに応じてモデルを選択しましょう：
-
-### コスト倍率
-
-現在のモデル倍率は[利用可能なモデル](/jp/models)で確認できます。
-
-### タスク別モデル選択
-
-```
-Simple edit, formatting → Haiku 4.5 (0.4×)
-Implement feature from spec → GPT-5.3-Codex (0.7×)
-Debug complex issue → Sonnet 4.5 (1.2×)
-Architecture planning → Opus 4.7 (1x, 2x after 4/30) or Opus 4.6 (2×)
-Bulk file processing → Droid Core (MiniMax M2.7 at 0.12× or Kimi K2.6 at 0.4×)
-```
-
-### 推論努力の影響
-
-推論レベルが高い = より多くの「思考」トークンを使用するが、多くの場合再試行回数は減る。
-
-| 推論 | 使用タイミング | トークンのトレードオフ |
-| ----- | ------------ | ------------------------- |
-| オフ/なし | シンプルで明確なタスク | ターンあたり最少、より多くのターンが必要な場合あり |
-| 低 | 標準的な実装 | 良いバランス |
-| 中 | 複雑なロジック、デバッグ | ターンあたり高め、再試行回数は少なめ |
-| 高 | アーキテクチャ、分析 | ターンあたり最高、初回試行の成功率が最も高い |
-
-**経験則:** 初回試行を間違えた場合の修正コストが高いタスクでは、より高い推論レベルを使用する。
-
-
- **混合モデルを設定**して、計画と実装で異なるモデルを自動的に使用できます。設定については[混合モデル](/jp/cli/configuration/mixed-models)を参照してください。
-
-
----
-
-## 効率性のためのワークフローパターン
-
-### パターン1: 複雑な作業のための仕様モード
-
-実装前の計画に[仕様モード](/jp/cli/user-guides/specification-mode)（`Shift+Tab`または`/spec`）を使用します。
-
-```
-**仕様モードを使わない場合:**
-Turn 1: Start implementing → wrong approach → wasted tokens
-Turn 2: Undo and try different approach → more tokens
-Turn 3: Finally get it right
-Total: 3 turns of implementation tokens
-```
-```
-**Spec Modeで:**
-Turn 1: Plan with exploration → correct approach identified
-Turn 2: Implement correctly
-Total: 1 turn of planning + 1 turn of implementation
-```
-
- 以下のようなタスクには、Specモード（`Shift+Tab`または`/spec`）を使用してください：
- - 2つ以上のファイルに触れる
- - 既存のパターンの理解が必要
- - 要件が不明確
- - セキュリティに敏感
-
-
-### パターン2: コンテキストのためのIDEプラグイン
-
-IDEプラグインがない場合、Droidはコンテキストを理解するためにファイルを読む必要があります：
-```
-Read file A → Read file B → Read file C → Understand context → Work
-(4 tool calls before actual work)
-```
-IDE プラグインを使用すると、コンテキストが即座に利用できます：
-```
-Work (IDE provides open files, errors, selection)
-(0 extra tool calls for context)
-```
-### パターン3: 一般的なものよりも具体的なもの
-
-```
-**高コストなプロンプト:**
-"Fix the bug in the auth module"
-```
-→ Droidは複数のファイルを読み取ってバグを見つけ、さまざまな可能性を探る
-
-```
-**効率的なプロンプト：**
-"Fix the timeout bug in src/auth/session.ts line 45 where the session expires after 5 minutes instead of 24 hours"
-```
-→ Droidが直接イシューに移動します
-
-### パターン4: 類似作業のバッチ処理
-
-```
-**コストが高い:**
-Turn 1: "Add logging to userService"
-Turn 2: "Add logging to orderService"
-Turn 3: "Add logging to paymentService"
-(3 turns, context rebuilt each time)
-```
-```
-**効率的:**
-Turn 1: "Add structured logging to all services in src/services/. Use the pattern from src/lib/logger.ts. Services: user, order, payment."
-(1 turn, pattern established once)
-```
----
-
-## トークンの無駄遣いを減らす
-
-### よくある無駄遣いパターン
-
-| パターン | 原因 | 修正方法 |
-| ------------- | ------------ | ----------------- |
-| 複数回の探索サイクル | 不明確な要件 | 事前に具体的に指定する |
-| ファイルの繰り返し読み込み | IDEコンテキストの不足 | IDEプラグインをインストールする |
-| 失敗した試行 | テスト/リンティングなし | 検証ツールを追加する |
-| 冗長な説明 | フォーマット制約なし | 簡潔な出力を求める |
-| 間違ったアーキテクチャ | コンテキストの不足 | Spec Modeを使用する |
-
-### フォーマット制約
-
-冗長性を減らすため、特定の出力フォーマットを要求する：
-```
-"Add the feature. Return only the changed code, no explanations unless something is unclear."
-```
-
-```
-"Review this code. Format: bullet list of issues only, no preamble."
-```
-
-```
-"Debug this test failure. Show me the fix, then explain in 2-3 sentences."
-```
----
-
-## 使用量の監視
-
-### 現在のセッション費用を確認
-```bash
-droid
-> /cost
-```
-現在のセッションのトークン使用量を表示します。
-
-### 時間経過の追跡
-
-使用パターンを確認しましょう：
-
-1. **各セッション後**、`/cost` の出力をメモする
-2. **高コストセッションを特定**：何が高コストの原因だったか？
-3. **アプローチの改善**：より多くのコンテキスト？異なるモデル？より良いプロンプト？
-
-### 使用量の警告サイン
-
-以下のパターンに注意してください：
-
-- 🚩 **高い読み取り回数**：Droidが過剰に探索している（AGENTS.mdのコンテキストを追加）
-- 🚩 **複数のgrep/検索呼び出し**：何を探すかが不明確（より具体的に）
-- 🚩 **類似の編集の繰り返し**：失敗した試行（テスト/リンティングを確認）
-- 🚩 **非常に長い会話**：スコープの拡大（小さなタスクに分割）
-
----
-
-## 即効性チェックリスト
-
-即座にトークンを節約するために以下を実装してください：
-
-- [ ] **IDEプラグインをインストール** - コンテキスト収集のツール呼び出しを排除
-- [ ] **AGENTS.mdを作成** - Droidがビルド/テストコマンドを事前に把握
-- [ ] **リンティングを設定** - エラーを即座にキャッチ
-- [ ] **高速テストコマンド** - 同一ターンでの検証
-- [ ] **Spec Modeを使用** - 高コストな誤ったスタートを防止
-- [ ] **具体的に指示** - 探索サイクルを削減
-- [ ] **タスクに適したモデルを選択** - 単純な編集にOpusを使わない
-
----
-
-## トークン予算ガイドライン
-
-一般的なタスクの大まかなガイドライン：
-
-| タスクタイプ | 典型的なトークン範囲 | 備考 |
-| ---------- | ---------- | ------------------ |
-| 簡単な編集 | 5k-15k | シンプルで具体的な変更 |
-| 機能実装 | 30k-80k | Spec Modeプランニング込み |
-| 複雑なデバッグ | 50k-150k | 複数回の試行が必要な場合 |
-| アーキテクチャ計画 | 20k-50k | 高推論モデル |
-| コードレビュー | 30k-60k | PRサイズに依存 |
-| 一括リファクタリング | 50k-200k | 多数のファイル、効率的なモデルを使用 |
-
-これらの範囲を大幅に超えている場合は、上記の無駄なパターンを確認してください。
-
----
-
-```
-## まとめ：トークン効率的なワークフロー
-1. Set up your project
- └─ AGENTS.md with commands
- └─ Fast tests
- └─ Linting configured
- └─ IDE plugin installed
-
-2. Start each task right
- └─ Use Spec Mode for complex work
- └─ Be specific about the goal
- └─ Reference existing patterns
-
-3. Choose the right model
- └─ Simple → Haiku/Droid Core
- └─ Standard → Codex/Sonnet
- └─ Complex → Opus (with reasoning)
-
-4. Monitor and adjust
- └─ Check /cost periodically
- └─ Identify expensive patterns
- └─ Refine your approach
-```
----
-
-## 次のステップ
-
-
-
- パワーユーザー設定を完了する
-
-
- プロジェクトのAI対応状況を評価する
-
-