Skip to content

Commit efc7ba4

Browse files
committed
Add Goal issue form
1 parent 230ab8f commit efc7ba4

4 files changed

Lines changed: 160 additions & 64 deletions

File tree

.github/ISSUE_TEMPLATE/goal.md

Lines changed: 0 additions & 54 deletions
This file was deleted.

.github/ISSUE_TEMPLATE/goal.yml

Lines changed: 136 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,136 @@
1+
name: Goal
2+
description: Create a verifiable Goal workflow issue
3+
title: "[Goal] "
4+
labels:
5+
- goal
6+
body:
7+
- type: markdown
8+
attributes:
9+
value: |
10+
Use this form for one coherent Goal workflow objective with a clear stopping condition.
11+
12+
A good goal is bigger than one prompt but smaller than an open-ended backlog. It should tell the workflow what to do, what not to change, how to prove progress, and when to stop as blocked instead of guessing.
13+
14+
If the goal needs a helper script, fixture, package script, CI target, or other setup before doneness can be judged, ask an agent to use `new-goal.md` first and create the setup PR before submitting this form.
15+
16+
- type: input
17+
id: goal
18+
attributes:
19+
label: Goal
20+
description: State the desired end state in one sentence.
21+
placeholder: "Migrate tests/auth from legacyAuthHelper to createTestSession."
22+
validations:
23+
required: true
24+
25+
- type: textarea
26+
id: completion-contract
27+
attributes:
28+
label: Completion Contract
29+
description: Define exactly when Goal should add `goal-completed` and remove `goal`.
30+
placeholder: |
31+
Goal is complete only when:
32+
- Every test in tests/auth uses createTestSession.
33+
- legacyAuthHelper has no remaining call sites in tests/auth.
34+
- The auth test suite and lint pass.
35+
validations:
36+
required: true
37+
38+
- type: textarea
39+
id: evidence
40+
attributes:
41+
label: Evidence / Verification
42+
description: List the commands, scripts, artifacts, screenshots, logs, or checks that prove the completion contract.
43+
placeholder: |
44+
Run from the repository root:
45+
46+
```bash
47+
set -euo pipefail
48+
npm test -- tests/auth
49+
npm run lint
50+
! rg "legacyAuthHelper" tests/auth
51+
```
52+
53+
Completion requires every command to exit 0.
54+
validations:
55+
required: true
56+
57+
- type: textarea
58+
id: doneness-script
59+
attributes:
60+
label: Optional Inline Doneness Script
61+
description: If a compact script can judge completion, put it here. Prefer an inline script over a setup PR when it only calls existing repo commands.
62+
render: bash
63+
placeholder: |
64+
set -euo pipefail
65+
npm test -- tests/auth
66+
npm run lint
67+
! rg "legacyAuthHelper" tests/auth
68+
validations:
69+
required: false
70+
71+
- type: textarea
72+
id: scope
73+
attributes:
74+
label: Scope and Constraints
75+
description: Say what the workflow may change and what must not change or regress.
76+
placeholder: |
77+
The workflow may change:
78+
- tests/auth/**
79+
- test/helpers/auth.ts
80+
81+
The workflow must not change:
82+
- production authentication behavior
83+
- public API names
84+
- payment provider configuration
85+
validations:
86+
required: true
87+
88+
- type: textarea
89+
id: context
90+
attributes:
91+
label: Context To Read First
92+
description: Point the workflow at the files, docs, issues, PRs, logs, designs, references, or examples it should inspect before changing code.
93+
placeholder: |
94+
- tests/auth/session.test.ts
95+
- test/helpers/auth.ts
96+
- docs/testing/auth.md
97+
- #123
98+
validations:
99+
required: true
100+
101+
- type: textarea
102+
id: iteration-policy
103+
attributes:
104+
label: Iteration Policy
105+
description: Explain how the workflow should choose each next checkpoint and report progress.
106+
placeholder: |
107+
Work in one coherent test group at a time. After each run, report what changed, what was verified, what remains, and whether anything is blocked. Prefer the smallest next checkpoint that can be validated with the evidence above.
108+
validations:
109+
required: true
110+
111+
- type: textarea
112+
id: blocked-stop-condition
113+
attributes:
114+
label: Blocked Stop Condition
115+
description: Define when the workflow should stop substantive work and comment instead of guessing.
116+
placeholder: |
117+
Stop and comment if tests require unavailable secrets, fixtures, product decisions, or external services. The blocked comment should include the exact command output, what is known, and the smallest user action that would unblock the workflow.
118+
validations:
119+
required: true
120+
121+
- type: checkboxes
122+
id: readiness
123+
attributes:
124+
label: Ready To Start
125+
description: Submitting this form applies the `goal` label and may start the workflow.
126+
options:
127+
- label: This goal does not need a setup PR before the workflow starts.
128+
required: true
129+
- label: This is one coherent objective, not a loose backlog.
130+
required: true
131+
- label: The completion contract has observable evidence.
132+
required: true
133+
- label: The constraints are specific enough to prevent accidental broad rewrites.
134+
required: true
135+
- label: The workflow can tell the difference between done, not done yet, and blocked.
136+
required: true

install.md

Lines changed: 19 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -10,7 +10,7 @@ Set up Goal in this repository by:
1010

1111
1. Installing the `gh-aw` CLI extension.
1212
2. Initializing the repository for GitHub Agentic Workflows.
13-
3. Copying Goal workflow files and the issue template.
13+
3. Copying Goal workflow files and the Goal issue form.
1414
4. Compiling the workflow.
1515
5. Creating the `goal` and `goal-completed` labels.
1616
6. Adding agent instructions so generated workflow files stay fresh.
@@ -48,8 +48,8 @@ This configures the repository for Agentic Workflows.
4848

4949
## Step 3: Download Goal And Copy Files
5050

51-
Download the Goal source as a zip and copy the workflow files into this
52-
repository.
51+
Download the Goal source as a zip and copy the workflow files and issue form
52+
into this repository.
5353

5454
### Linux And macOS
5555

@@ -88,6 +88,11 @@ Remove-Item -Path "$env:TEMP\goal.zip", "$env:TEMP\goal_extract" -Recurse -Force
8888
To pin a version, replace `refs/heads/main` with `refs/tags/<tag>` and replace
8989
`goal-main` with `goal-<tag>`.
9090

91+
This installs the guided Goal issue form at `.github/ISSUE_TEMPLATE/goal.yml`.
92+
Use it when a goal is ready for the workflow to start. If the goal needs a
93+
helper script, fixture, package script, CI target, or other setup before
94+
doneness can be judged, create that setup PR first.
95+
9196
## Step 4: Compile The Workflow
9297

9398
```bash
@@ -136,7 +141,7 @@ git checkout -b install-goal
136141
git add .
137142
git commit -m "Install Goal workflow"
138143
git push -u origin install-goal
139-
gh pr create --title "Install Goal workflow" --body "Set up the Goal agentic workflow and issue template."
144+
gh pr create --title "Install Goal workflow" --body "Set up the Goal agentic workflow and issue form."
140145
```
141146

142147
Report the pull request link to the user.
@@ -151,15 +156,21 @@ Use this shaping protocol:
151156

152157
1. Restate the desired outcome in one sentence.
153158
2. Ask only for missing details that cannot be discovered from the repository.
154-
3. Turn the answer into a goal issue with these sections:
159+
3. Turn the answer into a goal issue using the installed Goal issue form, with
160+
these sections:
155161
- `Goal`
156162
- `Completion Contract`
157163
- `Evidence / Verification`
158164
- `Scope and Constraints`
165+
- `Context To Read First`
159166
- `Iteration Policy`
160167
- `Blocked Stop Condition`
161-
4. Review the draft with the user before adding the `goal` label.
162-
5. Once the user agrees, create the issue and apply the `goal` label.
168+
4. Decide whether an inline doneness script in the issue is enough, or whether a
169+
small setup PR is needed first.
170+
5. Review the draft with the user before adding the `goal` label.
171+
6. Once the user agrees and the goal is ready to run, create the issue and apply
172+
the `goal` label. If using the installed issue form, submit it only when the
173+
`goal` label can be applied immediately.
163174

164175
The distilled pattern is:
165176

@@ -174,7 +185,7 @@ report <what failed, what is known, and what would unlock progress>.
174185
A strong issue tells the workflow what "done", "not done yet", and "blocked"
175186
mean. It should include at least one concrete verification surface: a test
176187
command, build command, benchmark, screenshot requirement, artifact review,
177-
log check, or source-of-truth document.
188+
log check, inline doneness script, or source-of-truth document.
178189

179190
### Example Strong Goal
180191

new-goal.md

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -54,8 +54,11 @@ better" unless you turn them into a concrete contract.
5454
6. If not, propose the smallest setup PR that would make doneness checkable.
5555
7. Draft the goal issue.
5656
8. Ask the user to confirm any uncertain product, design, or policy detail.
57-
9. Create the issue only after the contract is strong.
58-
10. Add the `goal` label only when the workflow can safely start.
57+
9. Create the issue only after the contract is strong. If the Goal issue form is
58+
installed, use its fields so the issue body follows the same contract.
59+
10. Add the `goal` label only when the workflow can safely start. If using the
60+
installed issue form, submit it only when the label can be applied
61+
immediately.
5962

6063
## Doneness Checks
6164

0 commit comments

Comments
 (0)