kingmadoc 0.3.0.dev11__tar.gz → 0.3.0.dev13__tar.gz

{kingmadoc-0.3.0.dev11 → kingmadoc-0.3.0.dev13}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: kingmadoc
-Version: 0.3.0.dev11
+Version: 0.3.0.dev13
 Summary: Feature docs for AI coding agents: a plan with C4 diagrams before the code, a verification doc after.
 Project-URL: Homepage, https://github.com/ATkingma/KingmaDoc
 Project-URL: Issues, https://github.com/ATkingma/KingmaDoc/issues

{kingmadoc-0.3.0.dev11 → kingmadoc-0.3.0.dev13}/skill/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: kingmadoc
-description: Generates a Feature Design Doc (plan) before a feature is implemented and a Feature Verification Doc afterwards, with Mermaid C4 diagrams inferred from the codebase. Use when the user asks to plan, design, or scope a new feature before writing code (also "feature design", "technical design", "document over een issue/fix", "ontwerp", "plan", "hoe gaan we dit oplossen", "technisch ontwerp"), or to verify, review, or check what was built against its plan. Works without installing anything; uses the kingmadoc CLI when it is available.
+description: Generates a Feature Design Doc (plan) before a feature is implemented and a Feature Verification Doc afterwards, with Mermaid C4 diagrams inferred from the codebase. Use when the user asks to plan, design, or scope a new feature before writing code (also "feature design", "technical design", "document over een issue/fix", "ontwerp", "plan", "hoe gaan we dit oplossen", "technisch ontwerp"); for code that already exists, use the explaining-code skill, or to verify, review, or check what was built against its plan. Works without installing anything; uses the kingmadoc CLI when it is available.
 version: 1.2.0
 allowed-tools: [Read, Write, Glob, Grep, Bash]
 ---
@@ -225,7 +225,8 @@ check passed without running it.
 Write `<output_dir>/<slug>-verify.md` next to the plan in the
 [verify format](reference/formats.md#verify-doc-docsfeaturesslug-verifymd) (ask first if it exists). Set
 **Status** to `Matches plan`, `Deviations found`, or `Not verified` (when checks could
-not run). Show the user the path, the number of deviations, and any failing check.
+not run). Diagrams in the verify doc follow the same `diagrams_png` mode as the plan.
+Show the user the path, the number of deviations, and any failing check.
 
 ## Diagram rules
 

{kingmadoc-0.3.0.dev11 → kingmadoc-0.3.0.dev13}/skill/codex.md

@@ -225,7 +225,8 @@ check passed without running it.
 Write `<output_dir>/<slug>-verify.md` next to the plan in the
 [verify format](#verify-doc-docsfeaturesslug-verifymd) (ask first if it exists). Set
 **Status** to `Matches plan`, `Deviations found`, or `Not verified` (when checks could
-not run). Show the user the path, the number of deviations, and any failing check.
+not run). Diagrams in the verify doc follow the same `diagrams_png` mode as the plan.
+Show the user the path, the number of deviations, and any failing check.
 
 ## Diagram rules
 
@@ -290,6 +291,13 @@ this line: _Disabled in `.featuredoc.yml` (`diagrams`)._
 `<output_dir>/img/<slug>-<diagram>.png`, linked with `![<title>](img/<slug>-<diagram>.png)`)
 or `off` (no image, only the Mermaid block).
 
+- **Mode comes only from `.featuredoc.yml`.** No file or no `diagrams_png` key → `embed`.
+  Never infer the mode from existing files (an `img/` folder, how an earlier doc did it).
+- **Check before you finish:** in `embed` mode every image line starts with
+  `![...](data:image/png;base64,`. A relative path such as `](img/` is an error: embed it and
+  delete the loose PNG.
+- Embed the PNG with a script (read file → base64 → replace the line), never by hand.
+
 1. Write each ` ```mermaid ` block to a temporary `.mmd` file outside the repo and run:
    `npx -y @mermaid-js/mermaid-cli -i <tmp>.mmd -o <tmp>.png -s 2 -b white -p <puppeteer.json>`
 2. Set `PUPPETEER_SKIP_DOWNLOAD=true`, and let `puppeteer.json` point at an installed

{kingmadoc-0.3.0.dev11 → kingmadoc-0.3.0.dev13}/skill/copilot.md

@@ -225,7 +225,8 @@ check passed without running it.
 Write `<output_dir>/<slug>-verify.md` next to the plan in the
 [verify format](#verify-doc-docsfeaturesslug-verifymd) (ask first if it exists). Set
 **Status** to `Matches plan`, `Deviations found`, or `Not verified` (when checks could
-not run). Show the user the path, the number of deviations, and any failing check.
+not run). Diagrams in the verify doc follow the same `diagrams_png` mode as the plan.
+Show the user the path, the number of deviations, and any failing check.
 
 ## Diagram rules
 
@@ -290,6 +291,13 @@ this line: _Disabled in `.featuredoc.yml` (`diagrams`)._
 `<output_dir>/img/<slug>-<diagram>.png`, linked with `![<title>](img/<slug>-<diagram>.png)`)
 or `off` (no image, only the Mermaid block).
 
+- **Mode comes only from `.featuredoc.yml`.** No file or no `diagrams_png` key → `embed`.
+  Never infer the mode from existing files (an `img/` folder, how an earlier doc did it).
+- **Check before you finish:** in `embed` mode every image line starts with
+  `![...](data:image/png;base64,`. A relative path such as `](img/` is an error: embed it and
+  delete the loose PNG.
+- Embed the PNG with a script (read file → base64 → replace the line), never by hand.
+
 1. Write each ` ```mermaid ` block to a temporary `.mmd` file outside the repo and run:
    `npx -y @mermaid-js/mermaid-cli -i <tmp>.mmd -o <tmp>.png -s 2 -b white -p <puppeteer.json>`
 2. Set `PUPPETEER_SKIP_DOWNLOAD=true`, and let `puppeteer.json` point at an installed

{kingmadoc-0.3.0.dev11 → kingmadoc-0.3.0.dev13}/skill/cursor.md

@@ -1,5 +1,5 @@
 ---
-description: "Generates a Feature Design Doc (plan) before a feature is implemented and a Feature Verification Doc afterwards, with Mermaid C4 diagrams inferred from the codebase. Use when the user asks to plan, design, or scope a new feature before writing code (also \"feature design\", \"technical design\", \"document over een issue/fix\", \"ontwerp\", \"plan\", \"hoe gaan we dit oplossen\", \"technisch ontwerp\"), or to verify, review, or check what was built against its plan. Works without installing anything; uses the kingmadoc CLI when it is available."
+description: "Generates a Feature Design Doc (plan) before a feature is implemented and a Feature Verification Doc afterwards, with Mermaid C4 diagrams inferred from the codebase. Use when the user asks to plan, design, or scope a new feature before writing code (also \"feature design\", \"technical design\", \"document over een issue/fix\", \"ontwerp\", \"plan\", \"hoe gaan we dit oplossen\", \"technisch ontwerp\"); for code that already exists, use the explaining-code skill, or to verify, review, or check what was built against its plan. Works without installing anything; uses the kingmadoc CLI when it is available."
 globs:
 alwaysApply: false
 ---
@@ -226,7 +226,8 @@ check passed without running it.
 Write `<output_dir>/<slug>-verify.md` next to the plan in the
 [verify format](#verify-doc-docsfeaturesslug-verifymd) (ask first if it exists). Set
 **Status** to `Matches plan`, `Deviations found`, or `Not verified` (when checks could
-not run). Show the user the path, the number of deviations, and any failing check.
+not run). Diagrams in the verify doc follow the same `diagrams_png` mode as the plan.
+Show the user the path, the number of deviations, and any failing check.
 
 ## Diagram rules
 
@@ -291,6 +292,13 @@ this line: _Disabled in `.featuredoc.yml` (`diagrams`)._
 `<output_dir>/img/<slug>-<diagram>.png`, linked with `![<title>](img/<slug>-<diagram>.png)`)
 or `off` (no image, only the Mermaid block).
 
+- **Mode comes only from `.featuredoc.yml`.** No file or no `diagrams_png` key → `embed`.
+  Never infer the mode from existing files (an `img/` folder, how an earlier doc did it).
+- **Check before you finish:** in `embed` mode every image line starts with
+  `![...](data:image/png;base64,`. A relative path such as `](img/` is an error: embed it and
+  delete the loose PNG.
+- Embed the PNG with a script (read file → base64 → replace the line), never by hand.
+
 1. Write each ` ```mermaid ` block to a temporary `.mmd` file outside the repo and run:
    `npx -y @mermaid-js/mermaid-cli -i <tmp>.mmd -o <tmp>.png -s 2 -b white -p <puppeteer.json>`
 2. Set `PUPPETEER_SKIP_DOWNLOAD=true`, and let `puppeteer.json` point at an installed

{kingmadoc-0.3.0.dev11 → kingmadoc-0.3.0.dev13}/skill/explaining-code/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: explaining-code
-description: "Explains existing code with rendered diagrams (C4 in Simon Brown's notation; UML sequence, state, class, activity, use case; ER; data flow) and short tables, as an arc42 or compact C4 document, one file or split into a functional and a technical design (FO/TO) with a threat model. Fixes code blindness. Scope: a feature, a branch or PR, a whole project, or a folder, service or module. Use when the user asks to explain, describe, document, map, diagram, draw, visualise or give an overview of existing code or architecture; asks how something works, what it does, how the parts fit together, where something happens, or what a branch, PR, commit or task changed; wants onboarding, a walkthrough, a codebase tour, an architecture or design document, arc42, a functional or technical design (FO, TO, or only one of them), C4, UML, sequence, ER or deployment diagrams of existing code; or no longer understands the code. The request may be in any language. Not for features that are not built yet."
+description: "Explains existing code with rendered diagrams and short tables, as an arc42 or compact C4 document, one file or split into a functional and a technical design (FO/TO) with a threat model. Fixes code blindness. Scope: a feature, a branch or PR, a whole project, a folder, service or module, or only the classes or files the user names. Use when the user asks to explain, describe, document, map, diagram, draw, visualise or give an overview of existing code or architecture; asks how something works, what it does, how the parts fit together, where something happens, or what a branch, PR, commit or task changed or wants a new pattern in it explained; wants onboarding, a walkthrough, a codebase tour, an architecture or design document, arc42, a functional or technical design (FO, TO, or only one of them), C4, UML, sequence, ER or deployment diagrams of existing code; or no longer understands the code. The request may be in any language. Not for features that are not built yet."
 version: 6.0.0
 allowed-tools: [Read, Write, Glob, Grep, Bash]
 ---
@@ -19,6 +19,7 @@ it fits together, often because an agent wrote it. This skill gives that insight
 | to know what a branch or task changed          | branch  | `branch <branch>`    |
 | an overview of a whole project                 | project | `Project`            |
 | to understand a folder, service or module      | part    | `<folder or module>` |
+| only named classes or files (often from git)   | part    | `<main class>`       |
 
 Each subject has its own folder `docs/explain/<NNNN>-<slug>/README.md` (the explainer,
 or its cover page when split) with `img/`; `docs/explain/README.md` lists them.
@@ -66,6 +67,13 @@ Rules:
 
 ## Step 1. Pin down the scope, the format and the documents
 
+**Named classes or files** ("see git, only A, B, C; document this, mainly show the new
+pattern"): the scope is exactly those (find them with `git status`, `git diff` and
+`git log`; also the uncommitted changes), their direct collaborators only as context.
+A focus the user names ("the extension of the new pattern") leads: the first figures
+show it (class diagram: what is new or extends what; sequence: how a call flows
+through it), the rest stays short.
+
 Decide the scope (table above); if unclear, search, take the most likely candidate and
 name the others at hand-over. Act on the request directly, without asking back (any
 language):

{kingmadoc-0.3.0.dev11 → kingmadoc-0.3.0.dev13}/skill/reference/diagram-rules.md

@@ -61,6 +61,13 @@ this line: _Disabled in `.featuredoc.yml` (`diagrams`)._
 `<output_dir>/img/<slug>-<diagram>.png`, linked with `![<title>](img/<slug>-<diagram>.png)`)
 or `off` (no image, only the Mermaid block).
 
+- **Mode comes only from `.featuredoc.yml`.** No file or no `diagrams_png` key → `embed`.
+  Never infer the mode from existing files (an `img/` folder, how an earlier doc did it).
+- **Check before you finish:** in `embed` mode every image line starts with
+  `![...](data:image/png;base64,`. A relative path such as `](img/` is an error: embed it and
+  delete the loose PNG.
+- Embed the PNG with a script (read file → base64 → replace the line), never by hand.
+
 1. Write each ` ```mermaid ` block to a temporary `.mmd` file outside the repo and run:
    `npx -y @mermaid-js/mermaid-cli -i <tmp>.mmd -o <tmp>.png -s 2 -b white -p <puppeteer.json>`
 2. Set `PUPPETEER_SKIP_DOWNLOAD=true`, and let `puppeteer.json` point at an installed

{kingmadoc-0.3.0.dev11 → kingmadoc-0.3.0.dev13}/tests/test_skill_explaining_code.py

@@ -103,7 +103,8 @@ def test_description_triggers_on_the_ways_people_ask() -> None:
     for trigger in (
         "explain", "document", "diagram", "overview", "how something works", "what it does",
         "PR", "onboarding", "walkthrough", "C4", "UML", "any language",
-        "Not for features that are not built yet",
+        "Not for features that are not built yet", "only the classes or files the user names",
+        "new pattern",
     ):
         assert trigger in description, trigger