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
Require brief output to keep full source artifact coverage, label inferred impacts, avoid fallback claims from non-goals, and stay standalone with system fonts and project-neutral branding.
Copy file name to clipboardExpand all lines: docs/opsx.md
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -209,6 +209,8 @@ Creates all planning artifacts at once. Use when you have a clear picture of wha
209
209
```
210
210
Reads the change artifacts and writes `brief.html` in the change directory. Use this optional workflow when you want a concise review surface before applying tasks. The original artifacts remain the source of truth.
211
211
212
+
The generated brief is standalone local HTML. It should not depend on remote fonts, CDN assets, network resources, unrelated branding, or agent-specific labels, and it should show source attribution for substantive claims.
Copy file name to clipboardExpand all lines: openspec/changes/add-brief-workflow/design.md
+7Lines changed: 7 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,11 +34,18 @@ Alternative considered: add `openspec brief`. That would either be a weak determ
34
34
35
35
The requested review surface is browser-readable HTML. A second `brief.md` output would create synchronization questions without being needed for the MVP.
36
36
37
+
### Decision: Keep generated HTML self-contained and project-neutral
38
+
39
+
The workflow should instruct agents to use inline CSS and system fonts only. It should not pull Google Fonts, CDN assets, remote images, or any other network resources into `brief.html`.
40
+
41
+
The generated page should also avoid unrelated product names, project names, footers, and agent-specific implementation labels unless those details come from the source artifacts. This keeps the workflow portable across OpenSpec users and prevents local helper templates from leaking repo- or harness-specific branding into official output.
42
+
37
43
## Risks / Trade-offs
38
44
39
45
-[Risk] Agent-generated summaries can be inaccurate. -> Mitigation: require source attribution, require missing information to be called out, and state that original artifacts remain authoritative.
40
46
-[Risk]`open` behavior is platform-specific. -> Mitigation: document best-effort opener commands and treat opener failure as non-fatal.
41
47
-[Risk] Adding a workflow id can affect profile drift detection and generated command cleanup. -> Mitigation: update workflow maps and targeted tests around profile, generation, and tool detection.
48
+
-[Risk] Local or agent-specific brief templates can leak unrelated branding or external assets. -> Mitigation: require standalone, project-neutral HTML and explicitly forbid remote fonts, CDN links, network assets, unrelated footers, and harness-specific labels unless sourced from artifacts.
Copy file name to clipboardExpand all lines: openspec/changes/add-brief-workflow/proposal.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,8 @@ The workflow needs an optional agent-generated review surface that summarizes th
8
8
9
9
- Add an optional `/opsx:brief` workflow that produces a one-page HTML brief for an existing change.
10
10
- The workflow reads the change status and apply context from the OpenSpec CLI, then reads the artifact files listed in `contextFiles`.
11
-
- The agent synthesizes a concise human-readable brief with source attribution, risks, questions, implementation order, and verification plan.
11
+
- The agent synthesizes a concise human-readable brief with source attribution, full source artifact coverage, risks, questions, implementation order, and verification plan.
12
+
- The generated HTML is standalone and generic to the OpenSpec change: no external fonts, CDN links, network assets, unrelated branding, or agent-specific implementation labels.
12
13
- The workflow writes `brief.html` inside the change directory and best-effort opens it with the host OS.
13
14
- The workflow is selectable through the custom profile but is not included in the default `core` profile.
Copy file name to clipboardExpand all lines: src/core/templates/workflows/brief-change.ts
+13-1Lines changed: 13 additions & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -59,6 +59,12 @@ ${STORE_SELECTION_GUIDANCE}
59
59
60
60
Create a concise, human-readable review surface. The brief should help a user understand the change in about 3 minutes without reading every artifact.
61
61
62
+
Before writing HTML, build a short internal outline from the artifacts:
63
+
- Source artifact index: every file path returned in \`contextFiles\`, grouped by artifact ID
64
+
- Delta spec coverage: every spec file from \`contextFiles.specs\`
65
+
- Task coverage: task groups aligned with the numbered headings in the tasks artifact; if tasks are summarized, say so
66
+
- Impact list: affected modules or file areas stated by the artifacts; mark inferred impacts as "Inference"
67
+
62
68
Include these sections:
63
69
- What this change does
64
70
- Explicit non-goals
@@ -73,8 +79,11 @@ ${STORE_SELECTION_GUIDANCE}
73
79
**Accuracy rules**
74
80
- The original OpenSpec artifacts remain the source of truth. The brief is only a review surface.
75
81
- Every substantive claim must include source attribution such as \`Source: proposal.md\`, \`Source: design.md\`, \`Source: specs/<capability>/spec.md\`, or \`Source: tasks.md\`.
82
+
- The source artifact index must include every file path returned in \`contextFiles\`; do not silently drop delta specs or schema-specific artifacts.
76
83
- If a section is not specified by the source artifacts, write "Not specified in source artifacts" instead of inventing content.
77
84
- Separate direct source facts from your inference. Label inference as "Inference".
85
+
- Do not turn non-goals into fallback plans or implied future work unless the source artifacts explicitly say so.
86
+
- Do not add affected files, modules, user-visible behavior, risks, or questions unless they are sourced or clearly labeled as inference.
78
87
- Keep the page concise. Prefer short bullets and compact tables over long prose.
79
88
80
89
6. **Write static HTML**
@@ -86,8 +95,11 @@ ${STORE_SELECTION_GUIDANCE}
86
95
87
96
The HTML must be:
88
97
- standalone static HTML
89
-
- no external JavaScript, CSS, fonts, images, or network resources
98
+
- no external JavaScript, CSS, fonts, images, CDN links, or network resources
99
+
- use system fonts only; do not import Google Fonts or other remote fonts
90
100
- professional and readable in a browser
101
+
- generic to the current OpenSpec change; do not include unrelated product names, project names, footers, or branding unless they appear in the source artifacts
102
+
- agent-agnostic; do not hardcode tool-specific paths or labels such as \`.codex\`, \`.agents\`, Claude, Codex, or any harness-specific implementation detail unless the source artifacts explicitly mention them
91
103
- safe for artifact text: escape \`&\`, \`<\`, \`>\`, \`"\`, and \`'\` if you include source excerpts or user-provided content
92
104
93
105
Use inline \`<style>\` only. Do not create additional files.
0 commit comments