@dreb/coding-agent 2.55.0 → 2.55.1
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/package.json +1 -1
- package/skills/mach6-issue/SKILL.md +25 -3
package/package.json
CHANGED
|
@@ -111,10 +111,13 @@ If templates exist, read them and select the most appropriate one.
|
|
|
111
111
|
|
|
112
112
|
If codebase context is needed, use Explore subagents only for bounded evidence such as locating named behavior, files, tests, call sites, or exact snippets. The primary agent must interpret that evidence and own the issue's requirements, proposed behavior, scope, and technical conclusions.
|
|
113
113
|
|
|
114
|
-
### Step 2: Draft the issue
|
|
114
|
+
### Step 2: Draft and approve the issue
|
|
115
|
+
|
|
116
|
+
An initial request to "create," "post," or "open" an issue is a request to draft it, **not approval to post it**. Never create an issue in the same turn as that initial request, regardless of how imperative or complete it is.
|
|
115
117
|
|
|
116
118
|
Create a structured issue with:
|
|
117
119
|
- **Title**: Clear, concise, action-oriented (under 80 chars, imperative form)
|
|
120
|
+
- **Original Request**: A clearly identified block quote containing the user's original request/input verbatim; do not paraphrase, correct, or omit any part of it
|
|
118
121
|
- **Summary**: 2-3 sentences describing the problem or feature
|
|
119
122
|
- **Current Behavior** (for bugs/improvements): What happens now
|
|
120
123
|
- **Proposed Behavior**: What should happen
|
|
@@ -123,16 +126,35 @@ Create a structured issue with:
|
|
|
123
126
|
- **Technical Notes**: Implementation hints, relevant files, architectural considerations
|
|
124
127
|
- **Labels**: Suggest appropriate labels based on the issue type
|
|
125
128
|
|
|
126
|
-
|
|
129
|
+
Keep the issue limited to what the user explicitly requested. Before adding any acceptance criterion that the user did not explicitly ask for, present the proposed criterion separately with `ask_user` and obtain explicit confirmation that it is valid scope. Do not include an unrequested criterion without that confirmation, and do not treat approval of the completed issue draft as retroactive scope confirmation.
|
|
130
|
+
|
|
131
|
+
Determine the candidate target repository as an exact `owner/repo`; do not rely on ambient `gh` context when posting. Use `ask_user` to present one Markdown-formatted approval question containing all of the following without summarizing or truncating them:
|
|
132
|
+
- The exact target `owner/repo`
|
|
133
|
+
- The complete issue title
|
|
134
|
+
- The complete Markdown issue body, including the verbatim **Original Request** block quote
|
|
135
|
+
- The complete proposed label list, or an explicit statement that no labels are proposed
|
|
136
|
+
|
|
137
|
+
The question must offer exactly these three options and allow free-text discussion:
|
|
138
|
+
- **Approve**
|
|
139
|
+
- **Deny/Discuss**
|
|
140
|
+
- **Detailed Explanation with minimal jargon of each acceptance criteria**
|
|
141
|
+
|
|
142
|
+
Only an explicit selection of **Approve** authorizes posting. Free text, a skipped or unanswered question, cancellation, **Deny/Discuss**, or the explanation option are not approval and must never fall through to issue creation.
|
|
143
|
+
|
|
144
|
+
If the user selects **Deny/Discuss**, discuss or revise the draft without posting. If the user requests the detailed explanation, explain every acceptance criterion with minimal jargon without posting. After either path, present the complete draft, target, and proposed labels through this approval gate again before posting. Any change to the title, body, target repository, or proposed labels invalidates prior approval and requires a fresh approval.
|
|
145
|
+
|
|
146
|
+
Stop and wait for the distinct `ask_user` response before continuing to Step 3. The non-interactive `gh` rule applies only to CLI execution; it does not replace this human approval gate.
|
|
127
147
|
|
|
128
148
|
### Step 3: Create the issue
|
|
129
149
|
|
|
150
|
+
Proceed only after the approval gate in Step 2 returned **Approve** for the exact title, body, target, and proposed labels used below.
|
|
151
|
+
|
|
130
152
|
```bash
|
|
131
153
|
GH_BODY="$(mktemp /tmp/gh-body.$$.XXXXXXXX)"
|
|
132
154
|
cat > "$GH_BODY" << 'MACH6_EOF'
|
|
133
155
|
<body>
|
|
134
156
|
MACH6_EOF
|
|
135
|
-
gh issue create --title "<title>" --body-file "$GH_BODY" [--label "<labels>"]
|
|
157
|
+
gh issue create --repo "<owner/repo>" --title "<title>" --body-file "$GH_BODY" [--label "<labels>"]
|
|
136
158
|
```
|
|
137
159
|
|
|
138
160
|
Report the issue number and URL. Suggest next step: `/skill:mach6-plan <number>`
|