@ggdna/dna-gg 1.4.0 → 1.5.0

package/README.md

@@ -39,7 +39,7 @@ All skills of this layer are prefixed with `gg-`:
 - `/gg-commit` — proposes a message and commits through `gg do commit`
 - `/gg-push` — pushes the ticket branches
 - `/gg-review` — checks the scope of every repo, writes the blog posts
-  and opens the pull requests
+  and opens the pull requests, printing their URLs
 - `/gg-publish` — releases the ticket
 - `/gg-cleanup` — removes what the ticket left behind
 
@@ -51,10 +51,12 @@ All skills of this layer are prefixed with `gg-`:
   Claude Code in the project management repo `dnaPmRepo` names. The
   prompts wait in `~/.claude/pm-prompts/sessions/` and are committed to the
   branch `prompts` of that repo when a session starts or ends, under
-  `doc/prompts/<first name>/<yyyy-mm>/<yyyy-mm-dd>_<repo>_<session>.md`.
-  The first name comes from `doc/team/people.md` there, found by the git
+  `doc/<yyyy>-Q<n>/prompts/<first name>/<yyyy-mm-dd>_<repo>_<session>.md`,
+  the quarter of the day the session started. The first name comes from
+  `team/people.md` of the newest quarter folder there (`doc/team/people.md`
+  in a repo without quarter folders), found by the git
   user name: a first name equal to it or to its first word, or a `Git`
-  line listing it. An unknown name goes to `doc/prompts/_unknown/`. No
+  line listing it. An unknown name goes to `prompts/_unknown/`. No
   e-mail address is read or written; the commits carry the neutral author
   `pm-prompts`. Only the prompts are kept, never the answers; tokens and
   passwords are replaced by `[redacted]`. No working tree is touched: the commit is built in a bare

package/dna/_generated.json

@@ -39,7 +39,7 @@
       "ecosystem": null,
       "resolvedVersion": null,
       "via": null,
-      "hash": "0xcda6ccaeb5d52dd1"
+      "hash": "0xff6654f75712aad8"
     }
   ],
   "claude": {
@@ -59,7 +59,7 @@
     },
     {
       "path": ".claude/hooks/pm-prompts.mjs",
-      "hash": "0xf4266eea17b3b9c1"
+      "hash": "0x6b8fdf7bbbf7c1a5"
     },
     {
       "path": ".claude/settings.json",
@@ -75,7 +75,7 @@
     },
     {
       "path": ".claude/skills/gg-publish/SKILL.md",
-      "hash": "0xcdef2684fcaaac5a"
+      "hash": "0x806b4c1fd5f6f654"
     },
     {
       "path": ".claude/skills/gg-push/SKILL.md",
@@ -83,11 +83,11 @@
     },
     {
       "path": ".claude/skills/gg-review/SKILL.md",
-      "hash": "0x55b2f0deb18d70d4"
+      "hash": "0x3a4506ccd5c8e1be"
     },
     {
       "path": ".claude/skills/gg-ticket/SKILL.md",
-      "hash": "0x0532d8ac37060521"
+      "hash": "0x8f9f5eb3d5567659"
     },
     {
       "path": ".claude/skills/gg/SKILL.md",
@@ -107,7 +107,7 @@
     },
     {
       "path": "doc/guides/develop-guide.md",
-      "hash": "0xed4328d138fe76ef"
+      "hash": "0x4c378a55b3c4773b"
     },
     {
       "path": "doc/guides/develop-without-ai-guide.md",
@@ -115,7 +115,7 @@
     },
     {
       "path": "doc/guides/for-ai/ai-dev-guide.md",
-      "hash": "0xb6eecdb4c7a1ebe8"
+      "hash": "0xa7bc4ac78f9387d6"
     },
     {
       "path": "doc/guides/index-guide.md",

package/dna/doc/guides/develop-guide.md

@@ -45,10 +45,12 @@ Use the following skills in Claude
 ## Your prompts
 
 When the repo belongs to a project management repo, every prompt you write
-to Claude Code is kept there, under `doc/prompts/<your first name>/` on the
-branch `prompts`. Only the prompts, not the answers. Tokens and passwords
+to Claude Code is kept there, under
+`doc/<yyyy>-Q<n>/prompts/<your first name>/` on the branch `prompts`. Only the prompts, not the answers. Tokens and passwords
 are replaced by `[redacted]`. Your first name comes from
-`doc/team/people.md` in the project management repo: the person whose
+`team/people.md` of the newest quarter folder `doc/<yyyy>-Q<n>` in the
+project management repo: the person whose
 first name is your git user name or its first word, or whose `Git` line
 lists your git user name. Otherwise your prompts land in
-`doc/prompts/_unknown/`. Your e-mail address never goes there.
+`doc/<yyyy>-Q<n>/prompts/_unknown/`. Your e-mail address never goes
+there.

package/dna/doc/guides/for-ai/ai-dev-guide.md

@@ -8,31 +8,43 @@ found in the LICENSE file in the root of this package.
 
 # Development guide for AIs
 
-## Ask the developer for the ticket infos
+## Ask the developer what the ticket should do
 
-Ask for these one after the other and give the developer a single input
-field per answer — one question per field, never all of them in one
-question and never as a plain prose question:
+Ask a single question: what should the ticket do? One free-text answer is
+enough — never ask for a ticket id, a title or a description separately.
 
-- Ask for the ticket ID
-- Ask for the ticket title
-- Ask for the ticket description
-
-## Replace in this document
+## Create a ticket
 
-- Replace `~/dev/` by the workspace directory from the memory
-- Ask for the workspace directory if none is known
-- Replace `DnaJiraPrefix-145` by the ticket ID you asked for
-- Replace `Fix issue abc` by the ticket title you asked for
+Derive from the answer, without asking anything else:
 
-## Create a ticket
+- **id** — a short, descriptive slug in `snake_case`, 2-5 plain ASCII words
+  (transliterate non-ASCII, drop punctuation and emoji), e.g.
+  `fix_login_crash`. Never a sequential number: several tickets are usually
+  worked on in parallel, and a counter collides between them. List the
+  existing ticket folders of the workspace root and, if the slug is taken,
+  append `_2`, `_3`, … until it is free. If `gg do create ticket` still
+  rejects it as taken (e.g. another agent just created the same slug),
+  bump the suffix and retry.
+- **message** — one imperative line to one short sentence describing the
+  change, for `-m`.
 
 ```bash
 cd ~/dev/ # workspace
-gg do create ticket DnaJiraPrefix-145 -m"Fix issue abc"
-cd tickets/DnaJiraPrefix-145
+gg do create ticket fix_login_crash -m"Fix issue abc"
+cd fix_login_crash
 ```
 
+Tell the developer the id and the message right after creating the ticket —
+both can be changed any time, e.g. by renaming the folder before anything
+else is added to it, or by editing `ticket.json`.
+
+## Replace in this document
+
+- Replace `~/dev/` by the workspace directory from the memory
+- Ask for the workspace directory if none is known
+- Replace `fix_login_crash` by the ticket id you derived
+- Replace `Fix issue abc` by the ticket message you derived
+
 ## Choose the project management repo — or work without one
 
 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.
 
 ## Add git repositories
 
-Ask the user how the repos are chosen, as a single question with two
-options: automatically or manually.
+Ask the user how the repos are chosen, as a single question with the
+options below. Offer **only the project management repo** only when one was
+added above — without one there is nothing to be "only" about.
 
 Manually: ask in a second single input field which repos the ticket needs,
 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
 implement the ticket and let them confirm that the corresponding repos are
 added to the ticket.
 
-If the ticket is only planned (see below), the project management repo may
-be the only repo of the ticket.
+Only the project management repo: no code repo at all; the ticket stays
+pure planning, and the project management repo added above is everything
+it carries. If the ticket is only planned (see below), this is the way to
+go — the project management repo may be the only repo of the ticket.
 
 After the user's confirmation, add the repos to the ticket:
 
@@ -143,7 +158,8 @@ gg do code
 ## Plan (optional)
 
 Requirements come before the plan. If the project management repo keeps
-requirements (`doc/requirements`) and none of its accepted requirements
+requirements (`doc/<yyyy>-Q<n>/requirements`, in the newest quarter
+folder) and none of its accepted requirements
 covers the ticket, engineer them with the user first — with
 `/gg-plan-requirements` if the repo has it — and plan the ticket only after
 that. Bug tickets are the exception, they name their bug file.
@@ -321,8 +337,8 @@ gg do review
 ```
 
 gg creates pull requests for each repo and prints the URLs to the
-terminal. Print every URL to the user, one line per repo, and open each
-pull request without auto-merge in the browser.
+terminal. Print every URL to the user, one line per repo. Do not open the
+pull requests in the browser — leave that to the user.
 
 Afterwards load the review-light skill and execute it.
 

package/dna/dot-claude/hooks/pm-prompts.mjs

@@ -17,8 +17,10 @@ import { fileURLToPath, pathToFileURL } from 'node:url';
 /** The branch of the project management repo holding the prompts. */
 export const promptsBranch = 'prompts';
 
-const promptsDir = 'doc/prompts';
-const peopleFile = 'doc/team/people.md';
+// Everything a project management repo plans lives in quarter folders
+// doc/<yyyy>-Q<n>; repos not moved yet keep doc/team.
+const quarterDir = /^doc\/(\d{4}-Q[1-4])$/;
+const legacyPeopleFile = 'doc/team/people.md';
 const configFile = path.join('.claude', 'hooks', 'pm-prompts.json');
 
 // A session that ended without an end event counts as ended after a week.
@@ -330,12 +332,32 @@ export function personOf(gitName, peopleMd) {
   );
 }
 
+/** The quarter folder name of a local date: 2026-11-06 → 2026-Q4. */
+export function quarterOf(date) {
+  const month = Number(date.slice(5, 7));
+  return `${date.slice(0, 4)}-Q${Math.floor((month - 1) / 3) + 1}`;
+}
+
 /** Where the prompts of a session go in the project management repo. */
 export function promptsPath(meta, person) {
   const date = localDate(meta.started);
   const folder = person ? slug(person) : '_unknown';
   const id = String(meta.session).slice(0, 8);
-  return `${promptsDir}/${folder}/${date.slice(0, 7)}/${date}_${slug(meta.folder) || 'session'}_${id}.md`;
+  const name = `${date}_${slug(meta.folder) || 'session'}_${id}.md`;
+  return `doc/${quarterOf(date)}/prompts/${folder}/${name}`;
+}
+
+/**
+ * The files people.md may be in, best first: the team of the newest quarter
+ * folder among the [entries] of doc, then the one of a repo not moved yet.
+ */
+export function peopleFiles(entries) {
+  const quarters = entries
+    .map((e) => quarterDir.exec(e.trim())?.[1])
+    .filter(Boolean)
+    .sort()
+    .reverse();
+  return [...quarters.map((q) => `doc/${q}/team/people.md`), legacyPeopleFile];
 }
 
 /** The head of the file a session's prompts start. */
@@ -392,7 +414,12 @@ function ensureCache(url) {
 function readPeople(dir) {
   const fetched = git(['-C', dir, 'fetch', '-q', '--depth=1', 'origin', 'HEAD']);
   if (!fetched.ok) throw new Error(`fetch HEAD: ${fetched.err}`);
-  return git(['-C', dir, 'show', `FETCH_HEAD:${peopleFile}`]).out;
+  const ls = git(['-C', dir, 'ls-tree', '--name-only', 'FETCH_HEAD', 'doc/']);
+  for (const file of peopleFiles(ls.ok ? ls.out.split('\n') : [])) {
+    const shown = git(['-C', dir, 'show', `FETCH_HEAD:${file}`]);
+    if (shown.ok) return shown.out;
+  }
+  return '';
 }
 
 // The tip of the prompts branch, '' while it does not exist yet.

package/dna/dot-claude/skills/gg-publish/SKILL.md

@@ -13,7 +13,8 @@ creates and pushes the version tags. It is interactive — the user runs it.
 - Every repo of the ticket is committed and pushed.
 - The pull requests created by `gg do review` are green.
 - Every repo with `doc/guides/blog-guide.md` holds the post of this ticket
-  in `doc/blog/<yyyy>`. If one is missing, go back to `/gg-review`.
+  in `doc/blog/<yyyy>`, a project management repo in
+  `doc/<yyyy>-Q<n>/blog`. If one is missing, go back to `/gg-review`.
 
 ## 2. Configure the publish
 

package/dna/dot-claude/skills/gg-review/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: gg-review
-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.
+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.
 ---
 
 # Review
@@ -57,21 +57,16 @@ output, so pass the URLs on:
 - Print every URL to the user, one line per repo: `<repo>: <url>`. Name
   each repo that gg reports as `No pull request for <repo>`, with the
   reason
-- Open every pull request without auto-merge in the browser. Ask the
-  provider whether auto-merge is set:
-  - GitHub: `gh pr view <url> --json autoMergeRequest` — `null` means off
-  - Azure DevOps: `az repos pr show --id <id> --query autoCompleteSetBy`
-    — empty means off
-- Open the URL with `start "" "<url>"` on Windows, `open "<url>"` on
-  macOS and `xdg-open "<url>"` on Linux
+- Do not open the pull requests in the browser — print the URLs and leave
+  opening them to the user.
 
 ## 4. Review the changes
 
 Load the `/review-light` skill and execute it.
 
 A fix goes through `/gg-commit` and `/gg-push`, then run `gg do review`
-again. Print and open its pull request URLs as in step 3. Update the blog
-post of the repo when the fix changes what it describes.
+again. Print its pull request URLs as in step 3. Update the blog post of
+the repo when the fix changes what it describes.
 
 ## Important
 
@@ -80,3 +75,4 @@ post of the repo when the fix changes what it describes.
   the project management repo.
 - Never start `gg do review` without the user's confirmation.
 - Always print the pull request URLs after `gg do review`.
+- Never open a pull request in the browser on your own.

package/dna/dot-claude/skills/gg-ticket/SKILL.md

@@ -8,24 +8,36 @@ description: Creates a gg ticket and adds the repos it needs. Use when the user
 All `gg do` commands run inside the workspace. Ask for the workspace
 directory if none is known.
 
-## 1. Ask for the ticket data
+## 1. Ask what the ticket should do
 
-Ask for these three, one after the other, and give the user a single input
-field per answer — one question per field, never all three in one question
-and never as a plain prose question:
-
-- Ticket ID, e.g. `DnaJiraPrefix-145`
-- Title, one imperative line, e.g. `Fix issue abc`
-- Description, one or two sentences on what the ticket changes
+Ask a single question: what should the ticket do? One free-text answer is
+enough — never ask for a ticket id, a title or a description separately.
 
 ## 2. Create the ticket
 
+Derive from the answer, without asking anything else:
+
+- **id** — a short, descriptive slug in `snake_case`, 2-5 plain ASCII words
+  (transliterate non-ASCII, drop punctuation and emoji), e.g.
+  `fix_login_crash`. Never a sequential number: several tickets are usually
+  worked on in parallel, and a counter collides between them. List the
+  existing ticket folders of the workspace root and, if the slug is taken,
+  append `_2`, `_3`, … until it is free. If `gg do create ticket` still
+  rejects it as taken (e.g. another agent just created the same slug),
+  bump the suffix and retry.
+- **message** — one imperative line to one short sentence describing the
+  change, for `-m`.
+
 ```bash
 cd ~/dev/ # workspace
-gg do create ticket DnaJiraPrefix-145 -m"Fix issue abc"
-cd tickets/DnaJiraPrefix-145
+gg do create ticket fix_login_crash -m"Fix issue abc"
+cd fix_login_crash
 ```
 
+Tell the user the id and the message right after creating the ticket — both
+can be changed any time, e.g. by renaming the folder before anything else is
+added to it, or by editing `ticket.json`.
+
 ## 3. Choose the project management repo — or work without one
 
 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
 
 ## 4. Choose the code repos
 
-Ask the user how the code repos are chosen, as a single question with two
-options:
+Ask the user how the code repos are chosen, as a single question with the
+options below. Offer **only the project management repo** only when one was
+added in step 3 — without one there is nothing to be "only" about.
 
 - **automatically** — Claude finds the repos. Read the `index.jsonc` of
   the candidate repos in `.ocean`. Tell the user which repos the ticket
@@ -65,6 +78,9 @@ options:
   field which repos the ticket needs, e.g. `repo1 repo2`. Check each name
   against the repos in `.ocean` and ask again for names that do not exist
   there. The entered list is the confirmation.
+- **only the project management repo** — no code repo at all; the ticket
+  stays pure planning, and the project management repo added in step 3 is
+  everything it carries.
 
 A ticket that is only planned may need no code repo at all.
 
@@ -87,8 +103,9 @@ Run it only when the user asks for it.
 
 ## 6. Plan or implement
 
-If the project management repo keeps requirements (`doc/requirements`)
-and no accepted requirement covers the ticket, engineer them with the user
+If the project management repo keeps requirements
+(`doc/<yyyy>-Q<n>/requirements`, in the newest quarter folder) and no
+accepted requirement covers the ticket, engineer them with the user
 first — with `/gg-plan-requirements` if the repo has it — before any plan or
 code. Bug tickets are the exception, they name their bug file.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ggdna/dna-gg",
-  "version": "1.4.0",
+  "version": "1.5.0",
   "description": "DNA layer: gg CLI workflow guides, repo setup scripts and CI check",
   "keywords": [
     "dna",