strip agents.md sections that duplicate global claude.md
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Tommy Chow
parent
dad0a3e270
commit
c34654c2a5
2 changed files with 0 additions and 124 deletions
56
AGENTS.md
56
AGENTS.md
|
|
@ -4,73 +4,17 @@
|
|||
|
||||
# Author Preferences
|
||||
|
||||
## Behavior
|
||||
|
||||
- When asked to add items to a list (models, emotes, constants, etc.), be thorough on the first pass. Read the source data completely and add ALL relevant items, not just the first few.
|
||||
- In plan mode, interview thoroughly — ask about technical implementation, UI/UX, tradeoffs, and edge cases before coding. Don't begin implementation until all important details are resolved. For refactors: summary → trade-offs → next steps.
|
||||
- When implementing new code, search the codebase for existing usages and follow established patterns.
|
||||
- When new code supersedes existing functionality, find and remove everything it makes redundant.
|
||||
- When asked to "verify", always use web search to check current documentation and sources before responding. Do not rely solely on training data.
|
||||
- Favor parallel tool calls and subagents when tasks are independent.
|
||||
|
||||
## Code Opinions
|
||||
|
||||
- Package imports (`import 'package:frosty/...'`), not relative imports
|
||||
- `UPPER_SNAKE_CASE` for constants
|
||||
- Derive state where possible — avoid duplicating what can be computed (MobX `@computed`)
|
||||
- Trailing commas always
|
||||
- Single quotes
|
||||
- Inline until a pattern repeats 3+ times, then extract
|
||||
- Extract related/grouped logic (state, reactions, actions) into dedicated stores when it improves readability — keep widgets focused on rendering
|
||||
|
||||
## Quality Priorities
|
||||
|
||||
In order: **correctness → user experience → simplicity → security**.
|
||||
|
||||
Not priorities: WCAG compliance (easy wins only), public accessibility, SEO, progressive enhancement.
|
||||
|
||||
## Tool Preferences
|
||||
|
||||
- Prefer LSP over Grep for semantic navigation:
|
||||
- `findReferences` before changing a function/widget signature (no false positives)
|
||||
- `hover` to resolve inferred/computed types (generics, MobX computed properties)
|
||||
- `goToDefinition` to navigate through re-exports and barrel files
|
||||
- `incomingCalls`/`outgoingCalls` to trace call chains across screens, stores, widgets
|
||||
- When debugging third-party packages, **read the package source in the pub cache first** — don't speculate about behavior. Check for validation, protocol restrictions, and attribute filtering before writing code.
|
||||
|
||||
## UI Patterns
|
||||
|
||||
- When UI visibility depends on an async operation (modals, banners, gates), default to hidden and only show after loading completes — never let a default value flash the UI while a request is in flight.
|
||||
- Adapt external designs (Figma specs, reference implementations) to codebase conventions before implementing. External descriptions may contain AI-generated rough drafts — always cross-reference against actual codebase patterns.
|
||||
|
||||
## Infrastructure Checklist
|
||||
|
||||
When creating new infrastructure (screens, API clients, stores), use exploration findings as a **checklist** — systematically verify each convention is followed before writing code.
|
||||
|
||||
## Code Review
|
||||
|
||||
- Label severity: `critical` / `major` / `minor`
|
||||
- Prefer minimal, tightly scoped diffs — don't switch layout strategies (e.g., Column to Stack) unless explicitly asked, as it often breaks dependent sizing
|
||||
- Flag unnecessary complexity with a simpler alternative
|
||||
|
||||
## Testing
|
||||
|
||||
- Suggest tests when changes touch logic, but don't write tests unless asked.
|
||||
- Run targeted tests for relevant files, not the full suite.
|
||||
- After finishing implementation that touches logic or adds new code paths, present a concrete list of test cases that should be added or updated. List each as a one-line description (happy path, sad path, edge cases). Surface this clearly, don't bury it.
|
||||
|
||||
## Commit Convention
|
||||
|
||||
Lowercase, no prefixes (e.g., `fix landscape bottom padding in chat bottom bar`). Keep commits tightly scoped.
|
||||
|
||||
## Branching
|
||||
|
||||
New branches: prefix with `tommy/` (e.g., `tommy/add-auth-flow`).
|
||||
|
||||
## Aliases
|
||||
|
||||
- **"vet"** means: review code for correctness/quality, verify claims against external sources (web search), and flag anything suspicious.
|
||||
|
||||
## Never
|
||||
|
||||
- Never edit `.g.dart` files directly — always regenerate with `dart run build_runner build`
|
||||
|
|
|
|||
|
|
@ -4,78 +4,10 @@
|
|||
|
||||
# Author Preferences
|
||||
|
||||
## Behavior
|
||||
|
||||
- When asked to add items to a list (models, emotes, constants, etc.), be thorough on the first pass. Read the source data completely and add ALL relevant items, not just the first few.
|
||||
- In plan mode, interview thoroughly — ask about technical implementation, UI/UX, tradeoffs, and edge cases before coding. Don't begin implementation until all important details are resolved. For refactors: summary → trade-offs → next steps.
|
||||
- When implementing new code, search the codebase for existing usages and follow established patterns.
|
||||
- When new code supersedes existing functionality, find and remove everything it makes redundant.
|
||||
- When asked to "verify", always use web search to check current documentation and sources before responding. Do not rely solely on training data.
|
||||
- Favor parallel tool calls and subagents when tasks are independent.
|
||||
|
||||
## Code Opinions
|
||||
|
||||
- Named exports only — no default exports except where required by Next.js (page, layout, route, etc.)
|
||||
- `satisfies` over `as` for type validation
|
||||
- `UPPER_SNAKE_CASE` for constants
|
||||
- Derive state where possible — avoid duplicating what can be computed
|
||||
- Avoid `useRef` unless DOM access or imperative work
|
||||
- Inline until a pattern repeats 3+ times, then extract
|
||||
- Extract related/grouped logic (state, effects, handlers) into dedicated custom hooks when it improves readability — keep components focused on rendering
|
||||
- For new components/hooks/APIs: include a usage example
|
||||
|
||||
## Quality Priorities
|
||||
|
||||
In order: **correctness → user experience → simplicity → security**.
|
||||
|
||||
Not priorities: WCAG compliance (easy wins only), public accessibility, SEO, progressive enhancement.
|
||||
|
||||
## Tool Preferences
|
||||
|
||||
- Prefer LSP over Grep for semantic navigation:
|
||||
- `findReferences` before changing a function/component signature (no false positives)
|
||||
- `hover` to resolve inferred/computed types (tRPC routers, Drizzle schemas, generics)
|
||||
- `goToDefinition` to navigate through re-exports and barrel files
|
||||
- `incomingCalls`/`outgoingCalls` to trace call chains across routes, hooks, components
|
||||
- When debugging third-party libraries, **read the extension source in `node_modules` first** — don't speculate about behavior. Check for validation, protocol restrictions, and attribute filtering before writing code.
|
||||
|
||||
## UI Patterns
|
||||
|
||||
- When UI visibility depends on an async query (modals, banners, gates), default to hidden and only show after loading completes — never let `defaultValue` flash the UI while the query is in flight.
|
||||
- Adapt external designs (Figma specs, reference implementations) to codebase conventions before implementing. External descriptions may contain AI-generated rough drafts — always cross-reference against actual codebase patterns.
|
||||
|
||||
## Infrastructure Checklist
|
||||
|
||||
When creating new infrastructure (routes, API handlers, providers), use exploration findings as a **checklist** — systematically verify each convention is followed before writing code.
|
||||
|
||||
## Code Review
|
||||
|
||||
- Label severity: `critical` / `major` / `minor`
|
||||
- Prefer minimal, tightly scoped diffs — don't switch layout strategies (e.g., grid to flex) unless explicitly asked, as it often breaks dependent sizing
|
||||
- Flag unnecessary complexity with a simpler alternative
|
||||
|
||||
## Testing
|
||||
|
||||
- Suggest tests when changes touch logic, but don't write tests unless asked.
|
||||
- Run targeted tests for relevant files, not the full suite.
|
||||
- After finishing implementation that touches backend logic or adds new code paths, present a concrete list of test cases that should be added or updated. List each as a one-line description (happy path, sad path, edge cases). Surface this clearly, don't bury it.
|
||||
|
||||
## Commit Convention
|
||||
|
||||
Lowercase, no prefixes (e.g., `remove marquee emote background from hero section`). Keep commits tightly scoped.
|
||||
|
||||
## Branching
|
||||
|
||||
New branches: prefix with `tommy/` (e.g., `tommy/add-auth-flow`).
|
||||
|
||||
## Aliases
|
||||
|
||||
- **"vet"** means: review code for correctness/quality, verify claims against external sources (web search), and flag anything suspicious.
|
||||
|
||||
## Never
|
||||
|
||||
- Never use `npm`, `npx`, or `yarn` — always use `pnpm` / `pnpx`
|
||||
|
||||
---
|
||||
|
||||
# Project
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue