Add third_party/ directory to contain sample skills and symlink those to camera_android_camerax#11895
Add third_party/ directory to contain sample skills and symlink those to camera_android_camerax#11895camsim99 wants to merge 5 commits into
third_party/ directory to contain sample skills and symlink those to camera_android_camerax#11895Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces several skill documentation files under packages/third_party/skills/ and adds corresponding symlinks under packages/camera/camera_android_camerax/skills/. The added files cover topics such as Android CLI usage, Dart unit testing, coverage collection, mock generation, static analysis, Flutter integration testing, and code review reception. Review feedback indicates that almost all of the newly added markdown files are truncated at the end, resulting in incomplete sentences, headings, and code blocks that need to be completed.
| ## Screenshot | ||
| `android screen capture -o <file path>` saves a PNG of the current device screen to `<file path>` | ||
|
|
||
| Use `screen capture` as a secondary me |
| ```<action>Search for soda and add the first result to the cart</action>``` | ||
| This should be evaluated as: | ||
| ``` | ||
| <action>Search for soda</a |
| flutter pub add dev:coverage | ||
| ``` | ||
|
|
||
| ### 2. Collect Coverag |
|
|
||
| - **Stubbing:** Configure mock behavior before interacting with the system under test. | ||
| - Use `when(mock.method()).thenReturn(value)` for synchronous methods. | ||
| - **CRITICAL:** Always use `thenAnswer((_) async => value)` for methods |
|
|
||
| When a diagnostic (lint or warning) yields a false positive or applies to generated code, suppress it explicitly. | ||
|
|
||
| - **File-level Exclusion:** Use the `analyzer: exclude:` node in `analysis_options.yaml` to exclude enti |
| - Create a dedicated `integration_test/` directory at the project root. | ||
| - Name all test files using the `<name>_test.dart` convention. | ||
| - Initialize the binding by calling `IntegrationTestWidgetsFlutterBinding.ensureInitialized();` at the start of `main()`. | ||
| - Load the application UI using `await tester.pumpWidget(MyApp()); |
| description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me". | ||
| --- | ||
|
|
||
| Interview me relentlessly about every aspect of this plan until we reach a shared |
There was a problem hiding this comment.
The sentence is truncated at the end of the file. It should be completed (e.g., 'until we reach a shared understanding.').
| Interview me relentlessly about every aspect of this plan until we reach a shared | |
| Interview me relentlessly about every aspect of this plan until we reach a shared understanding. |
| grep codebase for actual usage | ||
|
|
||
| IF unused: "This endpoint isn't called. Remove it (YAGNI)?" | ||
| IF used: Then |
|
Hm, usually third-party code needs a LICENSE and METADATA file for each source. There's currently no code here, so I'm not sure how this works, especially since presumably we need a structure that will work for cases where there are scripts associated with a skill. Please email third-party-help@ and point them to this PR to ask how this should be structured. |
|
It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging. If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group. |
Setup the new agent skills architecture for camera_android_camerax: Taking over from #11895 - **Remotely managed Skills**: Third-party are in a top level directory pr remote repo so that licenses can be included. Then they are symlinked into packages that want them. - **Published Skills**: Added a new empty directory for skills that are for users of camera_android_camerax. - **Contributor Skills**: Added a new directory for contributor skills and authored an internal `check-readiness` skill configured to enforce repository hygiene. - **Linter & Safety**: Pinned `dart_skills_lint` to the newly supported `individual_skills` hash. Added `EnforceTrackedSkillsPreventPublishingRule` in tests to enforce that tracked skills are strictly configured with the `prevent-skills-sh-publishing` rule in `dart_skills_lint.yaml` to prevent accidental publishing. Tooling changes: Future changes: * migrate bash script to dart * make analyze run on .agents/skills/* directories * update the tooling to not need changelog and versioning if you modify .agents/skills ## Pre-Review Checklist [^1]: Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling.
Creates a
third_party/skillsdirectory in the repository to add third party open source skills for package development. In thethird_party/skills/.agents/skillsdirectory, I added the following skills that are planned for use in go/flutter-project-one-shot-torch and symlinks them to thecamera_android_cameraxpackage for development purposes:Flutter/Dart-authored skills
3P-authored skills
Pre-Review Checklist
[shared_preferences]///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.Footnotes
Regular contributors who have demonstrated familiarity with the repository guidelines only need to comment if the PR is not auto-exempted by repo tooling. ↩ ↩2