full-context

description="Injects context of all relevant cli files" prompt = """ The following output contains the complete source code of the gemini cli library (packages/cli), and {packages/core} and representative test files (packages/cli/src/ui/components/InputPrompt.test.tsx and packages/cli/src/ui/App.test.tsx) that best conform to the project's testing standards. Pay extremely close attention to these files. They define the project's core architecture, component patterns, and testing standards.

The source code contains the content of absolutely every source code file in packages/cli and packages/core. In addition to the source code, the following test files are included as they are test files that conform to the project's testing standards: packages/cli/src/ui/components/InputPrompt.test.tsx and packages/cli/src/ui/App.test.tsx. You should very rarely need to read any other files from packages/cli to resolve prompts.

!{find packages/cli packages/core \( -path packages/cli/dist -o -path packages/core/dist -o -name node_modules \) -prune -o -type f \( -name ".ts" -o -name ".tsx" \) ! -name ".test.ts" ! -name ".test.tsx" ! -name "*.d.ts" -exec echo "--- {} ---" \; -exec cat {} \; && echo "--- packages/cli/src/ui/components/InputPrompt.test.tsx ---" && cat packages/cli/src/ui/components/InputPrompt.test.tsx && echo "--- packages/cli/src/ui/App.test.tsx ---" && cat packages/cli/src/ui/App.test.tsx}

In addition to the code context, you MUST strictly adhere to the following frontend-specific development guidelines when writing code in packages/cli.

Testing Standards

• Async Testing: ALWAYS use waitFor from packages/cli/src/test-utils/async.ts instead of vi.waitFor to prevent flakiness and act warnings. NEVER use fixed waits (e.g., await delay(100)).
• State Changes: Wrap all blocks that change component state in act.
• Snapshots: Use toMatchSnapshot to verify rendering.
• Rendering: Use render or renderWithProviders from packages/cli/src/test-utils/render.tsx instead of ink-testing-library directly.
• Mocking:
  • Reuse existing mocks/fakes where possible.
  • Parameterized Tests: Use parameterized tests with explicit types to reduce duplication and ensure type safety.
  • Avoid mocking the file system, os, or child_process if at all possible; if you have to mock the Mock critical dependencies (fs, os, child_process) do so ONLY at the top of the file.