You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: commands/create-app.toml
+26-18Lines changed: 26 additions & 18 deletions
Original file line number
Diff line number
Diff line change
@@ -11,25 +11,19 @@ We're going to build a new Flutter app.
11
11
12
12
## Problem specification
13
13
14
-
First, prompt the user for a description of the purpose and details of the package, and ask where to put it.
14
+
First, prompt the user for a description of what the purpose and details of the app will be.
15
15
16
-
If there are ambiguous elements, ask the user questions to clarify. When the goal is clear, or the user says to, then move on.
16
+
Once the user has specified the description and purpose of the app, outline the information that you will be collecting before creating the design and implementation plan, and present the list to the user, along with your first question.
17
17
18
-
## Initial Configuration
18
+
## Collecting Information
19
19
20
-
If the user didn't already give one, select a short descriptive name for the project.
20
+
Next, collect remaining information from the user, one question at a time.
21
21
22
-
Next, create a Flutter project in the desired location using the name. Unless the user specifies otherwise, the project should support all of the default platforms. Use the create_project tool to create it. For Flutter, create an empty project using the `empty` flag for the tool.
22
+
The information you need to collect includes, but might not be limited to:
23
23
24
-
Remove the boilerplate in the new project by removing the test dir, if any, and the README.md file.
25
-
26
-
Update the description of the package in the `pubspec.yaml` and set the version number to 0.1.0.
27
-
28
-
Update the README.md to include a short placeholder description of the project.
29
-
30
-
Update the CHANGELOG.md to have the initial version as 0.1.0.
31
-
32
-
Commit this empty version of the project to a new git feature branch.
24
+
- If there are ambiguous elements to the design, ask the user questions to clarify. When the goal is clear, or the user says to, then move on.
25
+
- If the user didn't already give one, select a short descriptive name for the project.
26
+
- Whether to do the work on the current git branch, or a new feature branch. Suggest a branch name.
33
27
34
28
## Design document
35
29
@@ -45,28 +39,42 @@ The design doc should (at least) include sections for:
45
39
- A summary of the design
46
40
- References to research URLs used to arrive at the design.
47
41
48
-
Have the user review this design document and approve it before moving on.
42
+
You must ask the user to review this design document and they must approve it before you continue on to create the implementation plan. They must review and approve it first because if they ask for any changes, it may affect the implementation plan.
49
43
50
44
## Implementation plan
51
45
52
-
Develop a **DETAILED** Markdown-formatted phased implementation plan of checkboxed tasks that need to be performed in order to finish developing the package. Save the implementation plan in IMPLEMENTATION.md in the top directory of the new package.
46
+
After getting explicit approval from the user for the DESIGN.md document, Develop a **DETAILED** Markdown-formatted phased implementation plan of checkboxed tasks that need to be performed in order to finish developing the package. Save the implementation plan in IMPLEMENTATION.md in the top directory of the new package.
53
47
54
48
The implementation plan should include a section for the "Journal" which will be updated after each phase.
55
49
56
50
The plan should include instructions similar to: "After completing a task, if you added any TODOs to the code or didn't fully implement anything, make sure to add new tasks so that you can come back and complete them later." to prevent leaving tasks unfinished.
57
51
52
+
In the first phase of the implementation plan, include:
53
+
54
+
- [ ] Create a Dart or Flutter project (as appropriate for the purpose) in the desired location using the name. Unless the user specifies otherwise, the project should support all of the default platforms. Use the create_project tool to create it. For Flutter projects, create an empty project using the `empty` flag for the tool.
55
+
- [ ] Remove the boilerplate in the new project by removing the test dir, if any, and the README.md file.
56
+
- [ ] Update the description of the package in the `pubspec.yaml` and set the version number to 0.1.0.
57
+
- [ ] Update the README.md to include a short placeholder description of the project.
58
+
- [ ] Update the CHANGELOG.md to have the initial version as 0.1.0.
59
+
- [ ] Commit this empty version of the project to either a new branch or the current branch based on the user's preference.
60
+
58
61
The implementation plan should specify after each phase that you should:
59
62
63
+
- [ ] Create/modify unit tests for testing the code added or modified in this phase, if relevant.
60
64
- [ ] Run the dart_fix and dart_format tools to clean up the code.
61
65
- [ ] Run the analyze_files tool one more time and fix any issues.
62
66
- [ ] Run any tests to make sure they all pass.
63
67
- [ ] Run dart_format one more time to make sure that the formatting is still correct if you made any changes during the analysis and testing steps.
64
-
- [ ] Use `git diff` to verify the changes that have been made, and create a suitable commit message for any changes, following any guidelines you have about commit messages. Be sure to properly escape dollar signs and backticks, and present the change message to the user for approval.
65
68
- [ ] Re-read the IMPLEMENTATION.md file to see what, if anything, has changed in the implementation plan, and if it has changed, take care of anything the changes imply.
66
69
- [ ] Update the IMPLEMENTATION.md file with the current state, including any learnings, surprises, or deviations in the Journal section.
70
+
- [ ] Use `git diff` to verify the changes that have been made, and create a suitable commit message for any changes, following any guidelines you have about commit messages. Be sure to properly escape dollar signs and backticks, and present the change message to the user for approval.
67
71
- [ ] Wait for approval. Don't commit the changes or move on to the next phase of implementation until the user approves the commit.
68
72
69
73
In the last phase of the plan, you should include a step to create a comprehensive README.md file for the package.
70
74
71
-
Have the user review this implementation plan and approve it before starting implementation.
75
+
You must ask the user to review this implementation plan and they must approve it before starting implementation. They must review and approve it before you begin because if they ask for any changes, they may affect the implementation.
76
+
77
+
## Implementation
78
+
79
+
After getting explicit approval from the user for the IMPLEMENTATION.md document, begin implementing the plan.
Copy file name to clipboardExpand all lines: commands/create-package.toml
+27-19Lines changed: 27 additions & 19 deletions
Original file line number
Diff line number
Diff line change
@@ -11,29 +11,23 @@ We're going to build a new Dart or Flutter package.
11
11
12
12
## Problem specification
13
13
14
-
First, prompt the user for a description of what the purpose and details of the package will be, and ask where to put it.
14
+
First, prompt the user for a description of what the purpose and details of the package will be.
15
15
16
-
If there are ambiguous elements, ask the user questions to clarify. When the goal is clear, or the user says to, then move on.
16
+
Once the user has specified the description and purpose of the package, outline the information that you will be collecting before creating the design and implementation plan, and present the list to the user, along with your first question.
17
17
18
-
## Initial Configuration
18
+
## Collecting Information
19
19
20
-
If the user didn't already give one, select a short descriptive name for the project.
20
+
Next, collect remaining information from the user, one question at a time.
21
21
22
-
Next, create a Dart or Flutter project (as appropriate for the purpose) in the desired location using the name. Unless the user specifies otherwise, the project should support all of the default platforms. Use the create_project tool to create it. For Flutter, create an empty project using the `empty` flag for the tool.
22
+
The information you need to collect includes, but might not be limited to:
23
23
24
-
Remove the boilerplate in the new project by removing the test dir, if any, and the README.md file.
25
-
26
-
Update the description of the package in the `pubspec.yaml` and set the version number to 0.1.0.
27
-
28
-
Update the README.md to include a short placeholder description of the project.
29
-
30
-
Update the CHANGELOG.md to have the initial version as 0.1.0.
31
-
32
-
Commit this empty version of the project to a new git feature branch.
24
+
- If there are ambiguous elements to the design, ask the user questions to clarify. When the goal is clear, or the user says to, then move on.
25
+
- If the user didn't already give one, select a short descriptive name for the project.
26
+
- Whether to do the work on the current git branch, or a new feature branch. Suggest a branch name.
33
27
34
28
## Design document
35
29
36
-
Develop a **DETAILED** Markdown-formatted design document that follows all of the guidance you have about Dart and/or Flutter design patterns, rules, best practices, and core principles. Save the design document in DESIGN.md in the top directory of the new package. Feel free to use your available tools to research any aspects of the design that need clarification.
30
+
Develop a **DETAILED** Markdown-formatted design document that follows all of the guidance you have about Dart and Flutter design patterns, rules, best practices, and core principles. Save the design document in DESIGN.md in the top directory of the new package. Feel free to use your available tools to research any aspects of the design that need clarification.
37
31
38
32
The design doc should (at least) include sections for:
39
33
@@ -45,28 +39,42 @@ The design doc should (at least) include sections for:
45
39
- A summary of the design
46
40
- References to research URLs used to arrive at the design.
47
41
48
-
Have the user review this design document and approve it before moving on.
42
+
You must ask the user to review this design document and they must approve it before you continue on to create the implementation plan. They must review and approve it first because if they ask for any changes, it may affect the implementation plan.
49
43
50
44
## Implementation plan
51
45
52
-
Develop a **DETAILED** Markdown-formatted phased implementation plan of checkboxed tasks that need to be performed in order to finish developing the package. Save the implementation plan in IMPLEMENTATION.md in the top directory of the new package.
46
+
After getting explicit approval from the user for the DESIGN.md document, Develop a **DETAILED** Markdown-formatted phased implementation plan of checkboxed tasks that need to be performed in order to finish developing the package. Save the implementation plan in IMPLEMENTATION.md in the top directory of the new package.
53
47
54
48
The implementation plan should include a section for the "Journal" which will be updated after each phase.
55
49
56
50
The plan should include instructions similar to: "After completing a task, if you added any TODOs to the code or didn't fully implement anything, make sure to add new tasks so that you can come back and complete them later." to prevent leaving tasks unfinished.
57
51
52
+
In the first phase of the implementation plan, include:
53
+
54
+
- [ ] Create a Dart or Flutter project (as appropriate for the purpose) in the desired location using the name. Unless the user specifies otherwise, the project should support all of the default platforms. Use the create_project tool to create it. For Flutter projects, create an empty project using the `empty` flag for the tool.
55
+
- [ ] Remove the boilerplate in the new project by removing the test dir, if any, and the README.md file.
56
+
- [ ] Update the description of the package in the `pubspec.yaml` and set the version number to 0.1.0.
57
+
- [ ] Update the README.md to include a short placeholder description of the project.
58
+
- [ ] Update the CHANGELOG.md to have the initial version as 0.1.0.
59
+
- [ ] Commit this empty version of the project to either a new branch or the current branch based on the user's preference.
60
+
58
61
The implementation plan should specify after each phase that you should:
59
62
63
+
- [ ] Create/modify unit tests for testing the code added or modified in this phase, if relevant.
60
64
- [ ] Run the dart_fix and dart_format tools to clean up the code.
61
65
- [ ] Run the analyze_files tool one more time and fix any issues.
62
66
- [ ] Run any tests to make sure they all pass.
63
67
- [ ] Run dart_format one more time to make sure that the formatting is still correct if you made any changes during the analysis and testing steps.
64
-
- [ ] Use `git diff` to verify the changes that have been made, and create a suitable commit message for any changes, following any guidelines you have about commit messages. Be sure to properly escape dollar signs and backticks, and present the change message to the user for approval.
65
68
- [ ] Re-read the IMPLEMENTATION.md file to see what, if anything, has changed in the implementation plan, and if it has changed, take care of anything the changes imply.
66
69
- [ ] Update the IMPLEMENTATION.md file with the current state, including any learnings, surprises, or deviations in the Journal section.
70
+
- [ ] Use `git diff` to verify the changes that have been made, and create a suitable commit message for any changes, following any guidelines you have about commit messages. Be sure to properly escape dollar signs and backticks, and present the change message to the user for approval.
67
71
- [ ] Wait for approval. Don't commit the changes or move on to the next phase of implementation until the user approves the commit.
68
72
69
73
In the last phase of the plan, you should include a step to create a comprehensive README.md file for the package.
70
74
71
-
Have the user review this implementation plan and approve it before starting implementation.
75
+
You must ask the user to review this implementation plan and they must approve it before starting implementation. They must review and approve it before you begin because if they ask for any changes, they may affect the implementation.
76
+
77
+
## Implementation
78
+
79
+
After getting explicit approval from the user for the IMPLEMENTATION.md document, begin implementing the plan.
0 commit comments