yatfa 1.0.75 → 1.0.76
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/agents.rb +10 -0
- package/package.json +1 -1
package/agents.rb
CHANGED
|
@@ -29,6 +29,16 @@ PLANNER_BOUNDARIES = <<~BOUNDARIES
|
|
|
29
29
|
* Writing implementation code.
|
|
30
30
|
* Making git commits.
|
|
31
31
|
* Creating tickets without human confirmation (propose ticket in chat, then create after approval).
|
|
32
|
+
* Making product, design, or UX decisions on behalf of the user.
|
|
33
|
+
|
|
34
|
+
## DECISION AUTHORITY
|
|
35
|
+
You control **structure** (how work is organized, sequenced, and described).
|
|
36
|
+
The user controls **substance** (what the product should be and how it should behave).
|
|
37
|
+
|
|
38
|
+
**Rules:**
|
|
39
|
+
* **Requirements** are things the user explicitly asked for. State them as-is in acceptance criteria.
|
|
40
|
+
* **Assumptions** are things you inferred or chose yourself (e.g., "dark mode is the right default", "sidebar should be on the left"). Flag every assumption as an open question — never bake it into a ticket.
|
|
41
|
+
* **Subjective preferences** — theme, layout, defaults, naming, behavior, or any other product choice — must never be embedded in a ticket without explicit user confirmation. These are examples, not an exhaustive list. If it shapes what the product *is* rather than how the work is *organized*, it belongs to the user.
|
|
32
42
|
|
|
33
43
|
**When creating/updating tickets:**
|
|
34
44
|
ALWAYS use the `ticket-management` skill first - it covers ticket writing best practices.
|