@ggdna/dna-gg 1.4.0 → 1.4.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/README.md CHANGED
@@ -39,7 +39,7 @@ All skills of this layer are prefixed with `gg-`:
39
39
  - `/gg-commit` — proposes a message and commits through `gg do commit`
40
40
  - `/gg-push` — pushes the ticket branches
41
41
  - `/gg-review` — checks the scope of every repo, writes the blog posts
42
- and opens the pull requests
42
+ and opens the pull requests, printing their URLs
43
43
  - `/gg-publish` — releases the ticket
44
44
  - `/gg-cleanup` — removes what the ticket left behind
45
45
 
@@ -39,7 +39,7 @@
39
39
  "ecosystem": null,
40
40
  "resolvedVersion": null,
41
41
  "via": null,
42
- "hash": "0xcda6ccaeb5d52dd1"
42
+ "hash": "0x958d0143021b2328"
43
43
  }
44
44
  ],
45
45
  "claude": {
@@ -83,11 +83,11 @@
83
83
  },
84
84
  {
85
85
  "path": ".claude/skills/gg-review/SKILL.md",
86
- "hash": "0x55b2f0deb18d70d4"
86
+ "hash": "0x3a4506ccd5c8e1be"
87
87
  },
88
88
  {
89
89
  "path": ".claude/skills/gg-ticket/SKILL.md",
90
- "hash": "0x0532d8ac37060521"
90
+ "hash": "0xb1095b91b3531897"
91
91
  },
92
92
  {
93
93
  "path": ".claude/skills/gg/SKILL.md",
@@ -115,7 +115,7 @@
115
115
  },
116
116
  {
117
117
  "path": "doc/guides/for-ai/ai-dev-guide.md",
118
- "hash": "0xb6eecdb4c7a1ebe8"
118
+ "hash": "0xe8182903f11a1766"
119
119
  },
120
120
  {
121
121
  "path": "doc/guides/index-guide.md",
@@ -8,31 +8,43 @@ found in the LICENSE file in the root of this package.
8
8
 
9
9
  # Development guide for AIs
10
10
 
11
- ## Ask the developer for the ticket infos
11
+ ## Ask the developer what the ticket should do
12
12
 
13
- Ask for these one after the other and give the developer a single input
14
- field per answer — one question per field, never all of them in one
15
- question and never as a plain prose question:
13
+ Ask a single question: what should the ticket do? One free-text answer is
14
+ enough — never ask for a ticket id, a title or a description separately.
16
15
 
17
- - Ask for the ticket ID
18
- - Ask for the ticket title
19
- - Ask for the ticket description
20
-
21
- ## Replace in this document
16
+ ## Create a ticket
22
17
 
23
- - Replace `~/dev/` by the workspace directory from the memory
24
- - Ask for the workspace directory if none is known
25
- - Replace `DnaJiraPrefix-145` by the ticket ID you asked for
26
- - Replace `Fix issue abc` by the ticket title you asked for
18
+ Derive from the answer, without asking anything else:
27
19
 
28
- ## Create a ticket
20
+ - **id** — a short, descriptive slug in `snake_case`, 2-5 plain ASCII words
21
+ (transliterate non-ASCII, drop punctuation and emoji), e.g.
22
+ `fix_login_crash`. Never a sequential number: several tickets are usually
23
+ worked on in parallel, and a counter collides between them. List the
24
+ existing ticket folders of the workspace root and, if the slug is taken,
25
+ append `_2`, `_3`, … until it is free. If `gg do create ticket` still
26
+ rejects it as taken (e.g. another agent just created the same slug),
27
+ bump the suffix and retry.
28
+ - **message** — one imperative line to one short sentence describing the
29
+ change, for `-m`.
29
30
 
30
31
  ```bash
31
32
  cd ~/dev/ # workspace
32
- gg do create ticket DnaJiraPrefix-145 -m"Fix issue abc"
33
- cd tickets/DnaJiraPrefix-145
33
+ gg do create ticket fix_login_crash -m"Fix issue abc"
34
+ cd fix_login_crash
34
35
  ```
35
36
 
37
+ Tell the developer the id and the message right after creating the ticket —
38
+ both can be changed any time, e.g. by renaming the folder before anything
39
+ else is added to it, or by editing `ticket.json`.
40
+
41
+ ## Replace in this document
42
+
43
+ - Replace `~/dev/` by the workspace directory from the memory
44
+ - Ask for the workspace directory if none is known
45
+ - Replace `fix_login_crash` by the ticket id you derived
46
+ - Replace `Fix issue abc` by the ticket message you derived
47
+
36
48
  ## Choose the project management repo — or work without one
37
49
 
38
50
  A ticket may belong to a project management repo. It holds the plans,
@@ -62,8 +74,9 @@ repositories. The ticket then carries no plan of its own.
62
74
 
63
75
  ## Add git repositories
64
76
 
65
- Ask the user how the repos are chosen, as a single question with two
66
- options: automatically or manually.
77
+ Ask the user how the repos are chosen, as a single question with the
78
+ options below. Offer **only the project management repo** only when one was
79
+ added above — without one there is nothing to be "only" about.
67
80
 
68
81
  Manually: ask in a second single input field which repos the ticket needs,
69
82
  e.g. `repo1 repo2`. Check each name against the repos in .ocean and ask
@@ -80,8 +93,10 @@ Also explain to the user what you roughly want to change in which repo to
80
93
  implement the ticket and let them confirm that the corresponding repos are
81
94
  added to the ticket.
82
95
 
83
- If the ticket is only planned (see below), the project management repo may
84
- be the only repo of the ticket.
96
+ Only the project management repo: no code repo at all; the ticket stays
97
+ pure planning, and the project management repo added above is everything
98
+ it carries. If the ticket is only planned (see below), this is the way to
99
+ go — the project management repo may be the only repo of the ticket.
85
100
 
86
101
  After the user's confirmation, add the repos to the ticket:
87
102
 
@@ -321,8 +336,8 @@ gg do review
321
336
  ```
322
337
 
323
338
  gg creates pull requests for each repo and prints the URLs to the
324
- terminal. Print every URL to the user, one line per repo, and open each
325
- pull request without auto-merge in the browser.
339
+ terminal. Print every URL to the user, one line per repo. Do not open the
340
+ pull requests in the browser — leave that to the user.
326
341
 
327
342
  Afterwards load the review-light skill and execute it.
328
343
 
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: gg-review
3
- description: Writes the blog posts of the ticket, opens the pull requests with `gg do review` and reviews the changes. Use when the user says "/gg-review" or asks to review the current ticket.
3
+ description: Writes the blog posts of the ticket, opens the pull requests with `gg do review` and prints their URLs, and reviews the changes. Use when the user says "/gg-review" or asks to review the current ticket.
4
4
  ---
5
5
 
6
6
  # Review
@@ -57,21 +57,16 @@ output, so pass the URLs on:
57
57
  - Print every URL to the user, one line per repo: `<repo>: <url>`. Name
58
58
  each repo that gg reports as `No pull request for <repo>`, with the
59
59
  reason
60
- - Open every pull request without auto-merge in the browser. Ask the
61
- provider whether auto-merge is set:
62
- - GitHub: `gh pr view <url> --json autoMergeRequest` — `null` means off
63
- - Azure DevOps: `az repos pr show --id <id> --query autoCompleteSetBy`
64
- — empty means off
65
- - Open the URL with `start "" "<url>"` on Windows, `open "<url>"` on
66
- macOS and `xdg-open "<url>"` on Linux
60
+ - Do not open the pull requests in the browser — print the URLs and leave
61
+ opening them to the user.
67
62
 
68
63
  ## 4. Review the changes
69
64
 
70
65
  Load the `/review-light` skill and execute it.
71
66
 
72
67
  A fix goes through `/gg-commit` and `/gg-push`, then run `gg do review`
73
- again. Print and open its pull request URLs as in step 3. Update the blog
74
- post of the repo when the fix changes what it describes.
68
+ again. Print its pull request URLs as in step 3. Update the blog post of
69
+ the repo when the fix changes what it describes.
75
70
 
76
71
  ## Important
77
72
 
@@ -80,3 +75,4 @@ post of the repo when the fix changes what it describes.
80
75
  the project management repo.
81
76
  - Never start `gg do review` without the user's confirmation.
82
77
  - Always print the pull request URLs after `gg do review`.
78
+ - Never open a pull request in the browser on your own.
@@ -8,24 +8,36 @@ description: Creates a gg ticket and adds the repos it needs. Use when the user
8
8
  All `gg do` commands run inside the workspace. Ask for the workspace
9
9
  directory if none is known.
10
10
 
11
- ## 1. Ask for the ticket data
11
+ ## 1. Ask what the ticket should do
12
12
 
13
- Ask for these three, one after the other, and give the user a single input
14
- field per answer — one question per field, never all three in one question
15
- and never as a plain prose question:
16
-
17
- - Ticket ID, e.g. `DnaJiraPrefix-145`
18
- - Title, one imperative line, e.g. `Fix issue abc`
19
- - Description, one or two sentences on what the ticket changes
13
+ Ask a single question: what should the ticket do? One free-text answer is
14
+ enough — never ask for a ticket id, a title or a description separately.
20
15
 
21
16
  ## 2. Create the ticket
22
17
 
18
+ Derive from the answer, without asking anything else:
19
+
20
+ - **id** — a short, descriptive slug in `snake_case`, 2-5 plain ASCII words
21
+ (transliterate non-ASCII, drop punctuation and emoji), e.g.
22
+ `fix_login_crash`. Never a sequential number: several tickets are usually
23
+ worked on in parallel, and a counter collides between them. List the
24
+ existing ticket folders of the workspace root and, if the slug is taken,
25
+ append `_2`, `_3`, … until it is free. If `gg do create ticket` still
26
+ rejects it as taken (e.g. another agent just created the same slug),
27
+ bump the suffix and retry.
28
+ - **message** — one imperative line to one short sentence describing the
29
+ change, for `-m`.
30
+
23
31
  ```bash
24
32
  cd ~/dev/ # workspace
25
- gg do create ticket DnaJiraPrefix-145 -m"Fix issue abc"
26
- cd tickets/DnaJiraPrefix-145
33
+ gg do create ticket fix_login_crash -m"Fix issue abc"
34
+ cd fix_login_crash
27
35
  ```
28
36
 
37
+ Tell the user the id and the message right after creating the ticket — both
38
+ can be changed any time, e.g. by renaming the folder before anything else is
39
+ added to it, or by editing `ticket.json`.
40
+
29
41
  ## 3. Choose the project management repo — or work without one
30
42
 
31
43
  A ticket may belong to a project management repo: plans, decisions and blog
@@ -52,8 +64,9 @@ Call it the "project management repo" whenever you write to the user, never
52
64
 
53
65
  ## 4. Choose the code repos
54
66
 
55
- Ask the user how the code repos are chosen, as a single question with two
56
- options:
67
+ Ask the user how the code repos are chosen, as a single question with the
68
+ options below. Offer **only the project management repo** only when one was
69
+ added in step 3 — without one there is nothing to be "only" about.
57
70
 
58
71
  - **automatically** — Claude finds the repos. Read the `index.jsonc` of
59
72
  the candidate repos in `.ocean`. Tell the user which repos the ticket
@@ -65,6 +78,9 @@ options:
65
78
  field which repos the ticket needs, e.g. `repo1 repo2`. Check each name
66
79
  against the repos in `.ocean` and ask again for names that do not exist
67
80
  there. The entered list is the confirmation.
81
+ - **only the project management repo** — no code repo at all; the ticket
82
+ stays pure planning, and the project management repo added in step 3 is
83
+ everything it carries.
68
84
 
69
85
  A ticket that is only planned may need no code repo at all.
70
86
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@ggdna/dna-gg",
3
- "version": "1.4.0",
3
+ "version": "1.4.1",
4
4
  "description": "DNA layer: gg CLI workflow guides, repo setup scripts and CI check",
5
5
  "keywords": [
6
6
  "dna",