claude-flet-plugin: Skill for Claude Code

Flet Review Workflow

You are performing a comprehensive code review of Flet code. First, determine whether the code is a Flet app or a Flet extension, then apply the appropriate checklist.

---

Step 1: Identify Code Type

Scan the codebase to determine:

• App: Contains ft.run(main), @ft.component, page.render_views()
• Extension: Contains @ft.control("Name"), ft.Service or ft.LayoutControl
• Both: App that uses a custom extension

---

Step 2: App Checklist

If reviewing a Flet app, check all of these:

Entry Point & Rendering

• Uses ft.run(main) — NOT ft.app()
• Uses page.render_views() or page.render() — NOT page.add()
• Does NOT call page.update() manually (declarative mode handles this)
• page.render(Component) passes reference, NOT page.render(Component())

State Management

• @ft.observable comes BEFORE @dataclass (order matters)
• ft.use_state() used for local form fields (not @ft.observable)
• Observable lists use .append() / .clear() to trigger re-renders
• State created outside components in main() when handlers need access
• No direct mutation of observable list elements (items[0] = x)

Hooks

• All hooks called inside @ft.component only (never in regular functions)
• Hooks NOT inside conditionals or loops (fixed order required)
• use_effect cleanup uses cleanup= parameter (NOT return value)
• use_effect dependencies array is correct ([] for mount-only)
• use_ref used for mutable refs that shouldn't trigger re-renders

Components

• All components use @ft.component decorator
• Context accessed via ft.use_context(AppCtx) (not passing page as prop)
• Factory functions used in loops to avoid closure traps
• Async handlers use try/except for error handling

Navigation

• view_ref[0].show_drawer() used (NOT page.show_drawer())
• PAGE_BUILDERS dict maps page IDs to component functions
• Router clears page.views before adding new views
• on_view_pop handler implemented for router-based navigation