@ggdna/dna-gg 0.4.1 → 0.5.0

package/README.md

@@ -23,11 +23,14 @@ publish.
 
 ## Skills
 
-- `/ticket` — creates a ticket and adds the repos it needs
-- `/commit` — proposes a message and commits through `gg do commit`
-- `/push` — pushes the ticket branches
-- `/publish` — releases the ticket
-- `/cleanup` — removes what the ticket left behind
+All skills of this layer are prefixed with `gg-`:
+
+- `/gg` — lists the skills below and says which one comes next
+- `/gg-ticket` — creates a ticket and adds the repos it needs
+- `/gg-commit` — proposes a message and commits through `gg do commit`
+- `/gg-push` — pushes the ticket branches
+- `/gg-publish` — releases the ticket
+- `/gg-cleanup` — removes what the ticket left behind
 
 ## Configuration
 
@@ -37,7 +40,7 @@ publish.
 ## Scripts
 
 - `dna/scripts/delete-feature-branch.js` — the one script this layer calls
-  itself, from `/cleanup`, with the two functions it imports:
+  itself, from `/gg-cleanup`, with the two functions it imports:
   `dna/scripts/functions/colors.js` and
   `dna/scripts/functions/run-command.js`
 

package/dna/CLAUDE.md

@@ -6,5 +6,6 @@ comes next:
 
 @doc/guides/for-ai/ai-dev-guide.md
 
-The steps are also available as skills: `/ticket`, `/commit`, `/push`,
-`/publish`, `/cleanup`.
+The steps are also available as skills: `/gg-ticket`, `/gg-commit`,
+`/gg-push`, `/gg-publish`, `/gg-cleanup`. `/gg` lists them and says which
+one comes next.

package/dna/_dna.json

@@ -8,7 +8,7 @@
   // every gg repo follows. Parents first, this layer wins.
   //
   // dna_scripts is deliberately not a parent: this layer calls exactly one
-  // of its scripts — `delete-feature-branch.js` from the /cleanup skill —
+  // of its scripts — `delete-feature-branch.js` from the /gg-cleanup skill —
   // and carries its own copy of it under dna/scripts/ instead. A consumer
   // that wants the full script set lists dna_scripts itself; the copies
   // here are byte-identical, so having both layers changes nothing.

package/dna/_generated.json

@@ -31,7 +31,7 @@
       "ecosystem": null,
       "resolvedVersion": null,
       "via": null,
-      "hash": "0x5b707abead2f6ae7"
+      "hash": "0x80c6dc9dbb7e23c3"
     }
   ],
   "claude": {
@@ -42,32 +42,36 @@
   "baseHash": "0x6883da335b415f9d",
   "instances": [
     {
-      "path": ".claude/skills/cleanup/SKILL.md",
-      "hash": "0xeaa18dbc86a24731"
+      "path": ".claude/skills/gg-cleanup/SKILL.md",
+      "hash": "0x4a6903a51168486a"
     },
     {
-      "path": ".claude/skills/commit/SKILL.md",
-      "hash": "0xad0e75ab4d725133"
+      "path": ".claude/skills/gg-commit/SKILL.md",
+      "hash": "0xd2e82c49f737093b"
     },
     {
-      "path": ".claude/skills/index/SKILL.md",
-      "hash": "0xc47429e51622cd7b"
+      "path": ".claude/skills/gg-publish/SKILL.md",
+      "hash": "0xaa7d82e9b407f561"
     },
     {
-      "path": ".claude/skills/install/SKILL.md",
-      "hash": "0x29c4ded946b50053"
+      "path": ".claude/skills/gg-push/SKILL.md",
+      "hash": "0x140e1b8d6cbe222e"
+    },
+    {
+      "path": ".claude/skills/gg-ticket/SKILL.md",
+      "hash": "0x06f83f4f73c9fb42"
     },
     {
-      "path": ".claude/skills/publish/SKILL.md",
-      "hash": "0xb8e70eff3563f75d"
+      "path": ".claude/skills/gg/SKILL.md",
+      "hash": "0x0e643054f49cf6a2"
     },
     {
-      "path": ".claude/skills/push/SKILL.md",
-      "hash": "0x76c357ca9933317d"
+      "path": ".claude/skills/index/SKILL.md",
+      "hash": "0xc47429e51622cd7b"
     },
     {
-      "path": ".claude/skills/ticket/SKILL.md",
-      "hash": "0x1c257bb5b8471026"
+      "path": ".claude/skills/install/SKILL.md",
+      "hash": "0x29c4ded946b50053"
     },
     {
       "path": ".github/workflows/quick_check.yaml",
@@ -75,7 +79,7 @@
     },
     {
       "path": "doc/guides/develop-guide.md",
-      "hash": "0xbd9fa5efab7af735"
+      "hash": "0xc31d5f25f496a9d6"
     },
     {
       "path": "doc/guides/develop-without-ai-guide.md",
@@ -83,7 +87,7 @@
     },
     {
       "path": "doc/guides/for-ai/ai-dev-guide.md",
-      "hash": "0x5e0118ec27bc8d6a"
+      "hash": "0xbbaf82081767678b"
     },
     {
       "path": "doc/guides/index-guide.md",

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

@@ -27,15 +27,17 @@ claude
 Start the development in Claude
 
 ```bash
-/ticket
+/gg-ticket
 ```
 
 Use the following skills in Claude
 
 ```bash
-/commit
-/push
+/gg-commit
+/gg-push
 /review
-/publish
-/cleanup
+/gg-publish
+/gg-cleanup
 ```
+
+`/gg` lists the skills of the workflow and says which one comes next.

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

@@ -10,6 +10,10 @@ found in the LICENSE file in the root of this package.
 
 ## Ask the developer for the ticket infos
 
+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 for the ticket ID
 - Ask for the ticket title
 - Ask for the ticket description
@@ -29,26 +33,32 @@ gg do create ticket dnaJiraPrefix-145 -m"Fix issue abc"
 cd tickets/dnaJiraPrefix-145
 ```
 
-## Choose the project management repo
+## Choose the project management repo — or work without one
 
-Every ticket belongs to a project management (PM) repo. It holds the plans,
-decisions and blog posts of a project, but no code.
+A ticket may belong to a project management repo. It holds the plans,
+decisions and blog posts of a project, but no code. It is optional: ask the
+user whether this ticket uses one. Write "project management repo" whenever
+you write to the user, never "PM repo".
 
-Look at the `index.jsonc` of each repo in .ocean and find the PM repo the
-ticket belongs to: its summary or domain talks about project management or
-planning, not about code. If one fits, propose it to the user. If none fits,
-ask the user which repo to use, or whether to create a new PM repo.
+With a project management repo: look at the `index.jsonc` of each repo in
+.ocean and find the one the ticket belongs to — its summary or domain talks
+about project management or planning, not about code. If one fits, propose
+it to the user. If none fits, ask the user which repo to use, or whether to
+create a new one.
 
-After the user's confirmation, add the PM repo to the ticket **before** any
-other repo:
+After the user's confirmation, add it to the ticket **before** any other
+repo:
 
 ```bash
 gg do add pm_repo
 ```
 
-If the PM repo has `doc/guides/pm-repo-guide.md`, read it: it describes how
-the PM repo is structured and how planning works there. If the file does not
-exist, follow the guides the PM repo has.
+If it has `doc/guides/pm-repo-guide.md`, read it: it describes how the repo
+is structured and how planning works there. If the file does not exist,
+follow the guides that repo has.
+
+Without a project management repo: skip this step and continue with the git
+repositories. The ticket then carries no plan of its own.
 
 ## Add git repositories
 
@@ -61,8 +71,8 @@ Ask the user about this. 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 PM repo may be the only repo
-of the ticket.
+If the ticket is only planned (see below), the project management repo may
+be the only repo of the ticket.
 
 After the user's confirmation, add the repos to the ticket:
 
@@ -80,9 +90,10 @@ gg do code
 
 Ask the user whether the ticket is planned before it is implemented.
 
-If yes, write the plan into the PM repo, following its
+If yes, write the plan into the project management repo, following its
 `doc/guides/pm-repo-guide.md` if present, otherwise its other guides: the
-goal, the affected repos, the rough steps and open questions. Let the user
+goal, the affected repos, the rough steps and open questions. Without a
+project management repo, put the plan into the ticket itself. Let the user
 review the plan and revise it until they confirm it.
 
 ## Implement (optional)
@@ -92,8 +103,8 @@ planned. Some tickets are only planned; the implementation follows in a later
 ticket.
 
 - Implement: implement your features based on the guides
-- Plan only: skip this step. The following steps then apply to the PM repo
-  only.
+- Plan only: skip this step. The following steps then apply to the project
+  management repo only.
 
 ## Commit
 
@@ -101,6 +112,15 @@ ticket.
 gg do commit
 ```
 
+`gg do commit` and `gg can commit` act on all repos of the ticket. When you
+are inside a single repo instead of the ticket folder, use the standalone
+form on that repo:
+
+```bash
+gg one can commit
+gg one do commit
+```
+
 ## Push
 
 ```bash
@@ -125,7 +145,7 @@ Afterwards load the review-light skill and execute it.
 - Create a blog post for the current ticket
 - Update the index.jsonc and README.md
 - Create the configuration for gg do publish
-- If the ticket was only planned, publish the PM repo only
+- If the ticket was only planned, publish the project management repo only
 
 Ask the user to run the following command **manually**:
 

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

@@ -0,0 +1,38 @@
+---
+name: gg
+description: Lists the skills of the gg workflow and says which one comes next. Use when the user says "/gg", asks which gg skills exist, or asks how the gg workflow continues.
+---
+
+# The gg workflow skills
+
+Every skill of this workflow carries the `gg-` prefix. Print the list
+below, in this order — it is the order of a ticket's life.
+
+- `/gg-ticket` — creates a ticket and adds the repos it needs
+- `/gg-commit` — proposes a message and commits through `gg do commit`,
+  or `gg one do commit` inside a single repo
+- `/gg-push` — pushes the ticket branches with `gg do push`
+- `/gg-publish` — prepares the release and hands `gg do publish` over to
+  the user
+- `/gg-cleanup` — removes what the published ticket left behind
+
+A repo may carry more `gg-` skills than these. Look at
+`.claude/skills/gg-*` and add what you find there, with the `description`
+of its `SKILL.md` as the text.
+
+## Say which skill comes next
+
+Read the state of the current ticket and name the next step:
+
+- No ticket folder yet → `/gg-ticket`
+- Uncommitted work → `/gg-commit`
+- Committed, not pushed → `/gg-push`
+- Pushed and the pull requests are green → `/gg-publish`
+- Published → `/gg-cleanup`
+
+The review between push and publish is `gg do review` plus the
+`/review-light` skill, not a `gg-` skill of this layer.
+
+## Important
+
+- Only list the skills, never run one of them unasked.

package/dna/dot-claude/skills/{cleanup → gg-cleanup}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: cleanup
-description: Removes what a published ticket left behind — feature branches, the ticket folder, and a stale workspace. Use when the user says "/cleanup" or asks to clean up after a release.
+name: gg-cleanup
+description: Removes what a published ticket left behind — feature branches, the ticket folder, and a stale workspace. Use when the user says "/gg-cleanup" or asks to clean up after a release.
 ---
 
 # Clean up after the publish

package/dna/dot-claude/skills/{commit → gg-commit}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: commit
-description: Commits the ticket's work in every repo with `gg do commit`. Use when the user says "/commit" or asks to commit the current changes.
+name: gg-commit
+description: Commits the ticket's work with `gg do commit`, or a standalone repo with `gg one do commit`. Use when the user says "/gg-commit" or asks to commit the current changes.
 ---
 
 # Commit
@@ -8,13 +8,23 @@ description: Commits the ticket's work in every repo with `gg do commit`. Use wh
 `gg do commit` runs the checks of each repo and commits only when they are
 green. The message also becomes the `CHANGELOG.md` entry.
 
-## 1. Propose a message
+## 1. Pick the command for where you are
+
+- **In the ticket folder** — `gg can commit` and `gg do commit` act on
+  every repo of the ticket.
+- **Inside a single repo**, a standalone one or one repo of a ticket —
+  `gg one can commit` and `gg one do commit` act on that repo alone.
+
+The rest of this skill writes `gg do commit`; use the `gg one` form
+whenever you are inside a repo.
+
+## 2. Propose a message
 
 Look at `git status` and `git diff` in the repos of the ticket. Propose one
 imperative one-liner that says what the step does, not which files changed.
 Let the user confirm it.
 
-## 2. Commit
+## 3. Commit
 
 From the ticket folder:
 
@@ -22,9 +32,15 @@ From the ticket folder:
 gg do commit -m"<message>"
 ```
 
+From a single repo:
+
+```bash
+gg one do commit -m"<message>"
+```
+
 Add `-l` when the message must not land in `CHANGELOG.md`.
 
-## 3. On a failing check
+## 4. On a failing check
 
 `gg do commit` stops at the first red check. Fix the cause, never the check,
 then run the command again. Files generated by the DNA are committed
@@ -34,4 +50,4 @@ its source under `dna/` instead.
 ## Important
 
 - Never commit without the confirmed message.
-- Never push here — that is `/push`.
+- Never push here — that is `/gg-push`.

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

@@ -1,6 +1,6 @@
 ---
-name: publish
-description: Prepares the release of a reviewed ticket and hands `gg do publish` over to the user. Use when the user says "/publish" or asks to release the ticket.
+name: gg-publish
+description: Prepares the release of a reviewed ticket and hands `gg do publish` over to the user. Use when the user says "/gg-publish" or asks to release the ticket.
 ---
 
 # Publish
@@ -31,7 +31,7 @@ gg do publish
 ```
 
 It asks whether the ticket and the remote feature branches may be deleted.
-If the user declines, run `/cleanup` afterwards.
+If the user declines, run `/gg-cleanup` afterwards.
 
 ## Important
 

package/dna/dot-claude/skills/{push → gg-push}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: push
-description: Pushes the ticket's commits with `gg do push`. Use when the user says "/push" or asks to push the current ticket.
+name: gg-push
+description: Pushes the ticket's commits with `gg do push`. Use when the user says "/gg-push" or asks to push the current ticket.
 ---
 
 # Push
@@ -13,7 +13,7 @@ gg do push
 
 `gg do push` pushes the repos of the ticket in dependency order and refuses
 repos that still carry uncommitted work. If it reports such a repo, run
-`/commit` first and push again.
+`/gg-commit` first and push again.
 
 ## Important
 

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

@@ -0,0 +1,86 @@
+---
+name: gg-ticket
+description: Creates a gg ticket and adds the repos it needs. Use when the user says "/gg-ticket", "new ticket", "fix bug X", or "implement feature Y".
+---
+
+# Create a ticket
+
+All `gg do` commands run inside the workspace. Ask for the workspace
+directory if none is known.
+
+## 1. Ask for the ticket data
+
+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
+
+## 2. Create the ticket
+
+```bash
+cd ~/dev/ # workspace
+gg do create ticket DnaJiraPrefix-145 -m"Fix issue abc"
+cd tickets/DnaJiraPrefix-145
+```
+
+## 3. Choose the project management repo — or work without one
+
+A ticket may belong to a project management repo: plans, decisions and blog
+posts of a project, no code. It is optional, so ask the user which way this
+ticket runs:
+
+- **with a project management repo** — read the `index.md` of the repos in
+  `.ocean`, propose the one the ticket belongs to, and after the
+  confirmation add it **before** any other repo:
+
+  ```bash
+  gg do add pm_repo
+  ```
+
+  Read `doc/guides/pm-repo-guide.md` of that repo if it exists: it says how
+  the repo is structured and how planning works there. If none of the repos
+  fits, ask whether to create one.
+
+- **without a project management repo** — skip this step and go straight to
+  the code repos. The ticket then carries no plan of its own.
+
+Call it the "project management repo" whenever you write to the user, never
+"PM repo".
+
+## 4. Choose the code repos
+
+Read the `index.md` of the candidate repos in `.ocean`. Tell the user which
+repos the ticket needs and what you roughly want to change in each one. If a
+part belongs to a domain that has no repo yet, say so and ask whether to
+create one. A ticket that is only planned may need no code repo at all.
+
+After the confirmation:
+
+```bash
+gg do add repo1 repo2
+```
+
+## 5. Open the workspace
+
+```bash
+gg do code
+```
+
+## 6. Plan or implement
+
+Ask the user whether the ticket is planned first. If yes, write the plan
+into the project management repo as its `pm-repo-guide.md` describes (or as
+its other guides do) and let the user confirm it. Without a project
+management repo, put the plan into the ticket itself and let the user
+confirm it there. Then ask whether the ticket is implemented now or only
+planned — in the latter case the ticket ends with the project management
+repo alone.
+
+## Important
+
+- Never add repos without confirmation. Rather too few than too many — more
+  can be added later.
+- Do not start the implementation unasked.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ggdna/dna-gg",
-  "version": "0.4.1",
+  "version": "0.5.0",
   "description": "DNA layer: gg CLI workflow guides, repo setup scripts and CI check",
   "keywords": [
     "dna",
@@ -32,8 +32,8 @@
     "@ggdna/dna-install": "^0.1.1"
   },
   "devDependencies": {
-    "@types/node": "^26.6.1",
-    "prettier": "^3.9.6"
+    "@types/node": "^26.6.2",
+    "prettier": "^3.9.8"
   },
   "scripts": {
     "test:dart": "dart test",

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

@@ -1,71 +0,0 @@
----
-name: ticket
-description: Creates a gg ticket and adds the repos it needs. Use when the user says "/ticket", "new ticket", "fix bug X", or "implement feature Y".
----
-
-# Create a ticket
-
-All `gg do` commands run inside the workspace. Ask for the workspace
-directory if none is known.
-
-## 1. Ask for the ticket data
-
-- Ticket ID, e.g. `DnaJiraPrefix-145`
-- Title, one imperative line, e.g. `Fix issue abc`
-
-## 2. Create the ticket
-
-```bash
-cd ~/dev/ # workspace
-gg do create ticket DnaJiraPrefix-145 -m"Fix issue abc"
-cd tickets/DnaJiraPrefix-145
-```
-
-## 3. Choose the project management repo
-
-Every ticket belongs to a project management (PM) repo: plans, decisions and
-blog posts of a project, no code. Read the `index.md` of the repos in
-`.ocean` and propose the PM repo the ticket belongs to. If none fits, ask
-which repo to use or whether to create one.
-
-After the confirmation, add it **before** any other repo:
-
-```bash
-gg do add pm_repo
-```
-
-Read `doc/guides/pm-repo-guide.md` of the PM repo if it exists: it says how
-the PM repo is structured and how planning works there.
-
-## 4. Choose the code repos
-
-Read the `index.md` of the candidate repos in `.ocean`. Tell the user which
-repos the ticket needs and what you roughly want to change in each one. If a
-part belongs to a domain that has no repo yet, say so and ask whether to
-create one. A ticket that is only planned may need no code repo at all.
-
-After the confirmation:
-
-```bash
-gg do add repo1 repo2
-```
-
-## 5. Open the workspace
-
-```bash
-gg do code
-```
-
-## 6. Plan or implement
-
-Ask the user whether the ticket is planned first. If yes, write the plan into
-the PM repo as its `pm-repo-guide.md` describes (or as its other guides do)
-and let the user confirm it. Then ask whether the ticket is
-implemented now or only planned — in the latter case the ticket ends with
-the PM repo alone.
-
-## Important
-
-- Never add repos without confirmation. Rather too few than too many — more
-  can be added later.
-- Do not start the implementation unasked.