Skip to content

docs: Add agentic workflow playbook for camera_android_camerax#11959

Merged
auto-submit[bot] merged 1 commit into
flutter:mainfrom
reidbaker:add-agentic-playbook
Jun 23, 2026
Merged

docs: Add agentic workflow playbook for camera_android_camerax#11959
auto-submit[bot] merged 1 commit into
flutter:mainfrom
reidbaker:add-agentic-playbook

Conversation

@reidbaker

@reidbaker reidbaker commented Jun 22, 2026

Copy link
Copy Markdown
Contributor

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.

@reidbaker reidbaker requested a review from camsim99 June 22, 2026 19:39
@flutter-dashboard flutter-dashboard Bot added the CICD Run CI/CD label Jun 22, 2026

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread packages/camera/camera_android_camerax/.agents/playbook.md
Comment thread packages/camera/camera_android_camerax/.agents/playbook.md

@camsim99 camsim99 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So this will take the place of the human leaving comments on the plan directly in the IDE?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

---

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@reidbaker reidbaker added override: no versioning needed Override the check requiring version bumps for most changes override: no changelog needed Override the check requiring CHANGELOG updates for most changes autosubmit Merge PR when tree becomes green via auto submit App labels Jun 23, 2026
@auto-submit auto-submit Bot merged commit 01fadab into flutter:main Jun 23, 2026
88 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

autosubmit Merge PR when tree becomes green via auto submit App CICD Run CI/CD override: no changelog needed Override the check requiring CHANGELOG updates for most changes override: no versioning needed Override the check requiring version bumps for most changes p: camera

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants