{"owner":"flwrlabs","repo":"flower","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\n## PR review philosophy\n\nWhen reviewing or generating code, apply this checklist:\n\n1. Necessity\n   - Ask whether each added block is required for the requested behavior.\n   - Flag speculative abstractions, premature generalization, and dead paths.\n\n2. Simplicity\n   - Prefer less code when readability and correctness are preserved.\n   - Suggest idiomatic code for the language in that module only if it makes the result easier to understand.\n   - Avoid \"clever\" one-liners that reduce maintainability.\n\n3. Readability\n   - Prefer explicit names, small functions, shallow nesting, and linear control flow.\n   - Flag dense logic that would be easier to read if split or renamed.\n\n4. Local consistency\n   - Compare with nearby modules and existing patterns before proposing structure/style changes.\n   - Follow existing naming, error-handling, typing, and test conventions.\n\n5. PR sizing\n   - Flag PRs that combine unrelated concerns.\n   - Suggest a split when refactoring, behavior changes, and cleanup are mixed together.\n\n## Review output format\n\nWhen reviewing a PR, output:\n- Critical issues\n- Simplicity/readability suggestions\n- Consistency concerns\n- Whether the PR should be split\n- A brief overall verdict\n\n## Development Patterns\n\n### Database Migrations\n\nPython services with databases use Alembic:\n\n```bash\ncd framework\nuv run --no-sync --python=3.11.14 python -m dev.generate_migration \"Description\"\n```\n\nFor Alembic-backed services, do not write a new migration file from scratch when\nthe intended change is a schema diff. Help the user use\n`python -m dev.generate_migration` from the `framework/` directory instead, then\nreview the generated revision and make only the minimal adjustments needed. This\nhelps avoid schema drift between SQLAlchemy models and committed migrations.\n\nThe migration generator is Alembic-branch aware. It upgrades the temporary\ndatabase to all heads, then autogenerates a revision against the selected branch\nhead. The default branch head is `flwr@head`; these commands are equivalent:\n\n```bash\ncd framework\nuv run --no-sync --python=3.11.14 python -m dev.generate_migration \"Widen integer columns\"\n```\n\n```bash\ncd framework\nuv run --no-sync --python=3.11.14 python -m dev.generate_migration --head flwr@head \"Widen integer columns\"\n```\n\nAfter autogeneration:\n\n- Confirm the new revision has the intended `down_revision`.\n- Confirm the generated operations match the SQLAlchemy metadata change.\n- Review generated `batch_alter_table` blocks for SQLite compatibility.\n- Update generated schema documentation if table metadata changed.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\n## PR review philosophy\n\nWhen reviewing or generating code, apply this checklist:\n\n1. Necessity\n   - Ask whether each added block is required for the requested behavior.\n   - Flag speculative abstractions, premature generalization, and dead paths.\n\n2. Simplicity\n   - Prefer less code when readability and correctness are preserved.\n   - Suggest idiomatic code for the language in that module only if it makes the result easier to understand.\n   - Avoid \"clever\" one-liners that reduce maintainability.\n\n3. Readability\n   - Prefer explicit names, small functions, shallow nesting, and linear control flow.\n   - Flag dense logic that would be easier to read if split or renamed.\n\n4. Local consistency\n   - Compare with nearby modules and existing patterns before proposing structure/style changes.\n   - Follow existing naming, error-handling, typing, and test conventions.\n\n5. PR sizing\n   - Flag PRs that combine unrelated concerns.\n   - Suggest a split when refactoring, behavior changes, and cleanup are mixed together.\n\n## Review output format\n\nWhen reviewing a PR, output:\n- Critical issues\n- Simplicity/readability suggestions\n- Consistency concerns\n- Whether the PR should be split\n- A brief overall verdict\n\n## Development Patterns\n\n### Database Migrations\n\nPython services with databases use Alembic:\n\n```bash\ncd framework\nuv run --no-sync --python=3.11.14 python -m dev.generate_migration \"Description\"\n```\n\nFor Alembic-backed services, do not write a new migration file from scratch when\nthe intended change is a schema diff. Help the user use\n`python -m dev.generate_migration` from the `framework/` directory instead, then\nreview the generated revision and make only the minimal adjustments needed. This\nhelps avoid schema drift between SQLAlchemy models and committed migrations.\n\nThe migration generator is Alembic-branch aware. It upgrades the temporary\ndatabase to all heads, then autogenerates a revision against the selected branch\nhead. The default branch head is `flwr@head`; these commands are equivalent:\n\n```bash\ncd framework\nuv run --no-sync --python=3.11.14 python -m dev.generate_migration \"Widen integer columns\"\n```\n\n```bash\ncd framework\nuv run --no-sync --python=3.11.14 python -m dev.generate_migration --head flwr@head \"Widen integer columns\"\n```\n\nAfter autogeneration:\n\n- Confirm the new revision has the intended `down_revision`.\n- Confirm the generated operations match the SQLAlchemy metadata change.\n- Review generated `batch_alter_table` blocks for SQLite compatibility.\n- Update generated schema documentation if table metadata changed.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\n## PR review philosophy\n\nWhen reviewing or generating code, apply this checklist:\n\n1. Necessity\n   - Ask whether each added block is required for the requested behavior.\n   - Flag speculative abstractions, premature generalization, and dead paths.\n\n2. Simplicity\n   - Prefer less code when readability and correctness are preserved.\n   - Suggest idiomatic code for the language in that module only if it makes the result easier to understand.\n   - Avoid \"clever\" one-liners that reduce maintainability.\n\n3. Readability\n   - Prefer explicit names, small functions, shallow nesting, and linear control flow.\n   - Flag dense logic that would be easier to read if split or renamed.\n\n4. Local consistency\n   - Compare with nearby modules and existing patterns before proposing structure/style changes.\n   - Follow existing naming, error-handling, typing, and test conventions.\n\n5. PR sizing\n   - Flag PRs that combine unrelated concerns.\n   - Suggest a split when refactoring, behavior changes, and cleanup are mixed together.\n\n## Review output format\n\nWhen reviewing a PR, output:\n- Critical issues\n- Simplicity/readability suggestions\n- Consistency concerns\n- Whether the PR should be split\n- A brief overall verdict\n\n## Development Patterns\n\n### Database Migrations\n\nPython services with databases use Alembic:\n\n```bash\ncd framework\nuv run --no-sync --python=3.11.14 python -m dev.generate_migration \"Description\"\n```\n\nFor Alembic-backed services, do not write a new migration file from scratch when\nthe intended change is a schema diff. Help the user use\n`python -m dev.generate_migration` from the `framework/` directory instead, then\nreview the generated revision and make only the minimal adjustments needed. This\nhelps avoid schema drift between SQLAlchemy models and committed migrations.\n\nThe migration generator is Alembic-branch aware. It upgrades the temporary\ndatabase to all heads, then autogenerates a revision against the selected branch\nhead. The default branch head is `flwr@head`; these commands are equivalent:\n\n```bash\ncd framework\nuv run --no-sync --python=3.11.14 python -m dev.generate_migration \"Widen integer columns\"\n```\n\n```bash\ncd framework\nuv run --no-sync --python=3.11.14 python -m dev.generate_migration --head flwr@head \"Widen integer columns\"\n```\n\nAfter autogeneration:\n\n- Confirm the new revision has the intended `down_revision`.\n- Confirm the generated operations match the SQLAlchemy metadata change.\n- Review generated `batch_alter_table` blocks for SQLite compatibility.\n- Update generated schema documentation if table metadata changed.\n","category":"root","tokens":647}]}