mapify-cli 3.31.0__tar.gz → 3.31.1__tar.gz

{mapify_cli-3.31.0 → mapify_cli-3.31.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: mapify-cli
-Version: 3.31.0
+Version: 3.31.1
 Summary: MAP Framework installer - Modular Agentic Planner for Claude Code
 Project-URL: Homepage, https://github.com/azalio/map-framework
 Project-URL: Repository, https://github.com/azalio/map-framework.git

{mapify_cli-3.31.0 → mapify_cli-3.31.1}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "mapify-cli"
-version = "3.31.0"
+version = "3.31.1"
 description = "MAP Framework installer - Modular Agentic Planner for Claude Code"
 authors = [{ name = "MAP Framework Contributors" }]
 readme = "README.md"

{mapify_cli-3.31.0 → mapify_cli-3.31.1}/src/mapify_cli/__init__.py

@@ -23,7 +23,7 @@ Or install globally:
     mapify check
 """
 
-__version__ = "3.31.0"
+__version__ = "3.31.1"
 
 # MUST stay the first import: it turns "this interpreter is older than 3.11" into
 # a message that says so, instead of the ImportError raised by `from datetime

{mapify_cli-3.31.0 → mapify_cli-3.31.1}/src/mapify_cli/templates/codex/skills/map-explain/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: map-explain
-description: "Explain code, a diff, or the whole project the way a knowledgeable colleague would — result and main scenario first, then participants, flow, mechanisms, rules and constraints in progressive depth, with Mermaid diagrams; for a PR or diff, exactly the change against the base with new behavior separated from existing context, documentation clarifications and unimplemented plans. Use when learning unfamiliar code, onboarding to a system, or auditing what a PR really does."
+description: "Explain code, a diff, or the whole project the way a knowledgeable colleague would — result and main scenario first, then participants, flow, mechanisms, rules and constraints in progressive depth, with ASCII diagrams; for a PR or diff, exactly the change against the base with new behavior separated from existing context, documentation clarifications and unimplemented plans. Use when learning unfamiliar code, onboarding to a system, or auditing what a PR really does."
 ---
 ## MAP update preflight
 
@@ -202,19 +202,35 @@ Before writing, choose the key diagrams that convey the essence of the material.
 
 Spread the diagrams through the narrative: from the result and the big picture to the internal mechanisms. Do not collect them into a gallery at the end.
 
+Draw every diagram as plain-text ASCII (box-drawing characters allowed) inside a code fence tagged `text` — never Mermaid or any other renderer syntax: the walkthrough must read the same in a terminal, a diff and a raw file. Keep lines under ~100 columns and align columns with spaces, not tabs.
+
 Pick the form by meaning:
 
 | Question the diagram answers | Form |
 |---|---|
-| How participants interact over time | Mermaid `sequenceDiagram` |
-| Dependencies and relationships | Mermaid `graph` |
-| Conditions and branches | Mermaid `flowchart` |
-| Flow through layers or stages | Mermaid `flowchart LR` with `subgraph` |
-| Lifecycle and status transitions | Mermaid `stateDiagram-v2` |
+| How participants interact over time | ASCII sequence: participant columns, labeled `──►` / `◄──` arrows |
+| Dependencies and relationships | ASCII box-and-arrow graph |
+| Conditions and branches | ASCII flowchart with labeled `yes` / `no` branches |
+| Flow through layers or stages | ASCII left-to-right boxes grouped under a layer label |
+| Lifecycle and status transitions | ASCII state diagram: `[state] ──event──► [state]` |
 | Combinations of settings | table |
 | Before / after | comparison table |
 
-If the result is achieved through an exchange of requests and data between participants, use a `sequenceDiagram`. Show the initiator, the recipients, the data passed, the responses, and the final result. Show essential alternatives and errors as separate branches.
+A minimal ASCII sequence diagram looks like this:
+
+```text
+ CLI               Runner              Git
+  │   run(task)      │                  │
+  │────────────────► │                  │
+  │                  │ diff base..HEAD  │
+  │                  │────────────────► │
+  │                  │  changed files   │
+  │                  │ ◄────────────────│
+  │   report         │                  │
+  │ ◄────────────────│                  │
+```
+
+If the result is achieved through an exchange of requests and data between participants, use an ASCII sequence diagram. Show the initiator, the recipients, the data passed, the responses, and the final result. Show essential alternatives and errors as separate branches.
 
 Respect abstraction levels: first the interaction of the main participants, then — if needed — a separate diagram of an internal mechanism. Do not mix the system overview with call-level details.
 

{mapify_cli-3.31.0 → mapify_cli-3.31.1}/src/mapify_cli/templates/skills/map-explain/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: map-explain
 description: |
-  Explain code, a diff, or the whole project the way a knowledgeable colleague would — a coherent walkthrough that builds a mental model: the practical result and main usage scenario first, then participants, data/control flow, mechanisms, rules, side effects and constraints in progressive depth, with Mermaid diagrams for the key flows. For a PR, branch or diff it explains exactly the change against the base and separates new behavior from existing context, documentation clarifications and unimplemented plans. Use when learning unfamiliar code, onboarding to a system, or auditing what a PR really does. Do NOT use to plan or implement; use map-plan or map-efficient.
+  Explain code, a diff, or the whole project the way a knowledgeable colleague would — a coherent walkthrough that builds a mental model: the practical result and main usage scenario first, then participants, data/control flow, mechanisms, rules, side effects and constraints in progressive depth, with ASCII diagrams for the key flows. For a PR, branch or diff it explains exactly the change against the base and separates new behavior from existing context, documentation clarifications and unimplemented plans. Use when learning unfamiliar code, onboarding to a system, or auditing what a PR really does. Do NOT use to plan or implement; use map-plan or map-efficient.
 effort: medium
 disable-model-invocation: true
 argument-hint: "[file path | symbol | PR ref | code snippet | empty for branch diff vs origin/main (fallback origin/master), or project overview on main/master]"
@@ -191,19 +191,35 @@ Before writing, choose the key diagrams that convey the essence of the material.
 
 Spread the diagrams through the narrative: from the result and the big picture to the internal mechanisms. Do not collect them into a gallery at the end.
 
+Draw every diagram as plain-text ASCII (box-drawing characters allowed) inside a code fence tagged `text` — never Mermaid or any other renderer syntax: the walkthrough must read the same in a terminal, a diff and a raw file. Keep lines under ~100 columns and align columns with spaces, not tabs.
+
 Pick the form by meaning:
 
 | Question the diagram answers | Form |
 |---|---|
-| How participants interact over time | Mermaid `sequenceDiagram` |
-| Dependencies and relationships | Mermaid `graph` |
-| Conditions and branches | Mermaid `flowchart` |
-| Flow through layers or stages | Mermaid `flowchart LR` with `subgraph` |
-| Lifecycle and status transitions | Mermaid `stateDiagram-v2` |
+| How participants interact over time | ASCII sequence: participant columns, labeled `──►` / `◄──` arrows |
+| Dependencies and relationships | ASCII box-and-arrow graph |
+| Conditions and branches | ASCII flowchart with labeled `yes` / `no` branches |
+| Flow through layers or stages | ASCII left-to-right boxes grouped under a layer label |
+| Lifecycle and status transitions | ASCII state diagram: `[state] ──event──► [state]` |
 | Combinations of settings | table |
 | Before / after | comparison table |
 
-If the result is achieved through an exchange of requests and data between participants, use a `sequenceDiagram`. Show the initiator, the recipients, the data passed, the responses, and the final result. Show essential alternatives and errors as separate branches.
+A minimal ASCII sequence diagram looks like this:
+
+```text
+ CLI               Runner              Git
+  │   run(task)      │                  │
+  │────────────────► │                  │
+  │                  │ diff base..HEAD  │
+  │                  │────────────────► │
+  │                  │  changed files   │
+  │                  │ ◄────────────────│
+  │   report         │                  │
+  │ ◄────────────────│                  │
+```
+
+If the result is achieved through an exchange of requests and data between participants, use an ASCII sequence diagram. Show the initiator, the recipients, the data passed, the responses, and the final result. Show essential alternatives and errors as separate branches.
 
 Respect abstraction levels: first the interaction of the main participants, then — if needed — a separate diagram of an internal mechanism. Do not mix the system overview with call-level details.
 

{mapify_cli-3.31.0 → mapify_cli-3.31.1}/src/mapify_cli/templates/skills/skill-rules.json

@@ -146,7 +146,7 @@
       "skillClass": "task",
       "enforcement": "manual",
       "priority": "medium",
-      "description": "Knowledgeable-colleague walkthrough of code, a PR/diff, or the project that builds a mental model — result and main scenario first, then participants, data/control flow, mechanisms, rules and constraints in progressive depth, with Mermaid diagrams; for PRs, exactly the change against the base with new behavior separated from existing context, documentation clarifications and unimplemented plans.",
+      "description": "Knowledgeable-colleague walkthrough of code, a PR/diff, or the project that builds a mental model — result and main scenario first, then participants, data/control flow, mechanisms, rules and constraints in progressive depth, with ASCII diagrams; for PRs, exactly the change against the base with new behavior separated from existing context, documentation clarifications and unimplemented plans.",
       "promptTriggers": {
         "keywords": [
           "map-explain",

{mapify_cli-3.31.0 → mapify_cli-3.31.1}/src/mapify_cli/templates_src/codex/skills/map-explain/SKILL.md.jinja

@@ -1,6 +1,6 @@
 ---
 name: map-explain
-description: "Explain code, a diff, or the whole project the way a knowledgeable colleague would — result and main scenario first, then participants, flow, mechanisms, rules and constraints in progressive depth, with Mermaid diagrams; for a PR or diff, exactly the change against the base with new behavior separated from existing context, documentation clarifications and unimplemented plans. Use when learning unfamiliar code, onboarding to a system, or auditing what a PR really does."
+description: "Explain code, a diff, or the whole project the way a knowledgeable colleague would — result and main scenario first, then participants, flow, mechanisms, rules and constraints in progressive depth, with ASCII diagrams; for a PR or diff, exactly the change against the base with new behavior separated from existing context, documentation clarifications and unimplemented plans. Use when learning unfamiliar code, onboarding to a system, or auditing what a PR really does."
 ---
 [% include "_partials/auto-update-preflight.md.jinja" %]
 
@@ -197,19 +197,35 @@ Before writing, choose the key diagrams that convey the essence of the material.
 
 Spread the diagrams through the narrative: from the result and the big picture to the internal mechanisms. Do not collect them into a gallery at the end.
 
+Draw every diagram as plain-text ASCII (box-drawing characters allowed) inside a code fence tagged `text` — never Mermaid or any other renderer syntax: the walkthrough must read the same in a terminal, a diff and a raw file. Keep lines under ~100 columns and align columns with spaces, not tabs.
+
 Pick the form by meaning:
 
 | Question the diagram answers | Form |
 |---|---|
-| How participants interact over time | Mermaid `sequenceDiagram` |
-| Dependencies and relationships | Mermaid `graph` |
-| Conditions and branches | Mermaid `flowchart` |
-| Flow through layers or stages | Mermaid `flowchart LR` with `subgraph` |
-| Lifecycle and status transitions | Mermaid `stateDiagram-v2` |
+| How participants interact over time | ASCII sequence: participant columns, labeled `──►` / `◄──` arrows |
+| Dependencies and relationships | ASCII box-and-arrow graph |
+| Conditions and branches | ASCII flowchart with labeled `yes` / `no` branches |
+| Flow through layers or stages | ASCII left-to-right boxes grouped under a layer label |
+| Lifecycle and status transitions | ASCII state diagram: `[state] ──event──► [state]` |
 | Combinations of settings | table |
 | Before / after | comparison table |
 
-If the result is achieved through an exchange of requests and data between participants, use a `sequenceDiagram`. Show the initiator, the recipients, the data passed, the responses, and the final result. Show essential alternatives and errors as separate branches.
+A minimal ASCII sequence diagram looks like this:
+
+```text
+ CLI               Runner              Git
+  │   run(task)      │                  │
+  │────────────────► │                  │
+  │                  │ diff base..HEAD  │
+  │                  │────────────────► │
+  │                  │  changed files   │
+  │                  │ ◄────────────────│
+  │   report         │                  │
+  │ ◄────────────────│                  │
+```
+
+If the result is achieved through an exchange of requests and data between participants, use an ASCII sequence diagram. Show the initiator, the recipients, the data passed, the responses, and the final result. Show essential alternatives and errors as separate branches.
 
 Respect abstraction levels: first the interaction of the main participants, then — if needed — a separate diagram of an internal mechanism. Do not mix the system overview with call-level details.
 

{mapify_cli-3.31.0 → mapify_cli-3.31.1}/src/mapify_cli/templates_src/skills/map-explain/SKILL.md.jinja

@@ -1,7 +1,7 @@
 ---
 name: map-explain
 description: |
-  Explain code, a diff, or the whole project the way a knowledgeable colleague would — a coherent walkthrough that builds a mental model: the practical result and main usage scenario first, then participants, data/control flow, mechanisms, rules, side effects and constraints in progressive depth, with Mermaid diagrams for the key flows. For a PR, branch or diff it explains exactly the change against the base and separates new behavior from existing context, documentation clarifications and unimplemented plans. Use when learning unfamiliar code, onboarding to a system, or auditing what a PR really does. Do NOT use to plan or implement; use map-plan or map-efficient.
+  Explain code, a diff, or the whole project the way a knowledgeable colleague would — a coherent walkthrough that builds a mental model: the practical result and main usage scenario first, then participants, data/control flow, mechanisms, rules, side effects and constraints in progressive depth, with ASCII diagrams for the key flows. For a PR, branch or diff it explains exactly the change against the base and separates new behavior from existing context, documentation clarifications and unimplemented plans. Use when learning unfamiliar code, onboarding to a system, or auditing what a PR really does. Do NOT use to plan or implement; use map-plan or map-efficient.
 effort: medium
 disable-model-invocation: true
 argument-hint: "[file path | symbol | PR ref | code snippet | empty for branch diff vs origin/main (fallback origin/master), or project overview on main/master]"
@@ -186,19 +186,35 @@ Before writing, choose the key diagrams that convey the essence of the material.
 
 Spread the diagrams through the narrative: from the result and the big picture to the internal mechanisms. Do not collect them into a gallery at the end.
 
+Draw every diagram as plain-text ASCII (box-drawing characters allowed) inside a code fence tagged `text` — never Mermaid or any other renderer syntax: the walkthrough must read the same in a terminal, a diff and a raw file. Keep lines under ~100 columns and align columns with spaces, not tabs.
+
 Pick the form by meaning:
 
 | Question the diagram answers | Form |
 |---|---|
-| How participants interact over time | Mermaid `sequenceDiagram` |
-| Dependencies and relationships | Mermaid `graph` |
-| Conditions and branches | Mermaid `flowchart` |
-| Flow through layers or stages | Mermaid `flowchart LR` with `subgraph` |
-| Lifecycle and status transitions | Mermaid `stateDiagram-v2` |
+| How participants interact over time | ASCII sequence: participant columns, labeled `──►` / `◄──` arrows |
+| Dependencies and relationships | ASCII box-and-arrow graph |
+| Conditions and branches | ASCII flowchart with labeled `yes` / `no` branches |
+| Flow through layers or stages | ASCII left-to-right boxes grouped under a layer label |
+| Lifecycle and status transitions | ASCII state diagram: `[state] ──event──► [state]` |
 | Combinations of settings | table |
 | Before / after | comparison table |
 
-If the result is achieved through an exchange of requests and data between participants, use a `sequenceDiagram`. Show the initiator, the recipients, the data passed, the responses, and the final result. Show essential alternatives and errors as separate branches.
+A minimal ASCII sequence diagram looks like this:
+
+```text
+ CLI               Runner              Git
+  │   run(task)      │                  │
+  │────────────────► │                  │
+  │                  │ diff base..HEAD  │
+  │                  │────────────────► │
+  │                  │  changed files   │
+  │                  │ ◄────────────────│
+  │   report         │                  │
+  │ ◄────────────────│                  │
+```
+
+If the result is achieved through an exchange of requests and data between participants, use an ASCII sequence diagram. Show the initiator, the recipients, the data passed, the responses, and the final result. Show essential alternatives and errors as separate branches.
 
 Respect abstraction levels: first the interaction of the main participants, then — if needed — a separate diagram of an internal mechanism. Do not mix the system overview with call-level details.
 

{mapify_cli-3.31.0 → mapify_cli-3.31.1}/src/mapify_cli/templates_src/skills/skill-rules.json.jinja

@@ -146,7 +146,7 @@
       "skillClass": "task",
       "enforcement": "manual",
       "priority": "medium",
-      "description": "Knowledgeable-colleague walkthrough of code, a PR/diff, or the project that builds a mental model — result and main scenario first, then participants, data/control flow, mechanisms, rules and constraints in progressive depth, with Mermaid diagrams; for PRs, exactly the change against the base with new behavior separated from existing context, documentation clarifications and unimplemented plans.",
+      "description": "Knowledgeable-colleague walkthrough of code, a PR/diff, or the project that builds a mental model — result and main scenario first, then participants, data/control flow, mechanisms, rules and constraints in progressive depth, with ASCII diagrams; for PRs, exactly the change against the base with new behavior separated from existing context, documentation clarifications and unimplemented plans.",
       "promptTriggers": {
         "keywords": [
           "map-explain",