docs: Add agentic workflow playbook for camera_android_camerax#11959
Conversation
There was a problem hiding this comment.
Code Review
This pull request introduces a playbook (playbook.md) detailing a one-shot agentic development workflow structured into planning and execution phases. The review feedback suggests generalizing platform-specific slash commands and replacing generic readiness checks with repository-specific tools like flutter doctor and flutter_plugin_tools.dart.
camsim99
left a comment
There was a problem hiding this comment.
I think this is a great foundation for the playbook! Left some miscellaneous thoughts on things we can add now/later.
| To gather consensus across multiple technical voices/reviewers: | ||
| 1. **Commit and Push:** Commit the plan artifact to a git branch and open a Pull Request (PR). | ||
| 2. **Review:** Human reviewers add comments directly on the plan in the PR. | ||
| 3. **Iterative Updates:** The agent is responsible for reading the PR comments and updating the plan until all comments are addressed and the plan is approved. |
There was a problem hiding this comment.
So this will take the place of the human leaving comments on the plan directly in the IDE?
There was a problem hiding this comment.
This will hopefully take the place of having the human have to manually prompt the agent with either the comments or "go fetch the comments and address them".
Practically will win out here for whatever allows us to make progress. That said having a record of the types of feedback and how the agent responds might help us with evals later.
|
|
||
| ```mermaid | ||
| graph TD | ||
| A[Start: Define Feature/Issue] --> B[Phase 1: Generate Execution Plan] |
There was a problem hiding this comment.
Maybe not now but eventually we could add a section on the "define feature/issue" piece where we describe what kind of issues (in my mind, clearly scoped issues at least for now) would work best for this oneshot approach.
There was a problem hiding this comment.
yeah, I agree but we will need to learn that from experience.
| 3. **Iterative Updates:** The agent is responsible for reading the PR comments and updating the plan until all comments are addressed and the plan is approved. | ||
|
|
||
| > [!NOTE] | ||
| > Utilizing PRs for plan review is the most effective mechanism for achieving consensus on design decisions before modifying production code. |
There was a problem hiding this comment.
Also it's great to track the changes over the iterations!
| > [!NOTE] | ||
| > Utilizing PRs for plan review is the most effective mechanism for achieving consensus on design decisions before modifying production code. | ||
|
|
||
| --- |
There was a problem hiding this comment.
Also a potential do-later (and maybe this is better fit for a skill): we can add some notes on what folks might want to look out for when reviewing the plan. Some examples:
- If you want integration testing, make sure it lists out how it will find + launch an emulator
- In the spirit of test-driven development, make sure it proposes unit tests that break initially but will not break after the fix before it starts development
- Make sure it will run the pre-push skill before creating a PR
This PR adds the playbook describing the planning and one-shot execution/validation flow for camera_android_camerax.
If you want to view the graph you can see it here https://github.com/reidbaker/packages/blob/66b6c4446d10fcac7e61f18ebd3fd294a595ae08/packages/camera/camera_android_camerax/.agents/playbook.md
The current content are a high level of the way we have designed project one shot to work. Additionally I think the specifics will change as we advance in our experience. For example we may check in and merge the design reviews then have the design review docs deleted as part of the work. Or we may add the design docs to the issue and have the artifact be preserved that way.