maxsimcli 4.13.0 → 4.15.0

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.
@@ -1,3 +1,17 @@
1
+ # [4.14.0](https://github.com/maystudios/maxsimcli/compare/v4.13.0...v4.14.0) (2026-03-11)
2
+
3
+
4
+ ### Features
5
+
6
+ * **workflows:** rewrite execute workflows for GitHub-first plan reading, per-task board transitions, and summary posting ([9d47215](https://github.com/maystudios/maxsimcli/commit/9d472159835a65058cd5d72a7a2265e4d58394c4))
7
+
8
+ # [4.13.0](https://github.com/maystudios/maxsimcli/compare/v4.12.0...v4.13.0) (2026-03-11)
9
+
10
+
11
+ ### Features
12
+
13
+ * **workflows:** rewrite progress, go, and verify workflows for live GitHub reads and comment posting ([4804a40](https://github.com/maystudios/maxsimcli/commit/4804a40fde7075fce21a3c2ebcb400937f271ab1))
14
+
1
15
  # [4.12.0](https://github.com/maystudios/maxsimcli/compare/v4.11.0...v4.12.0) (2026-03-11)
2
16
 
3
17
 
@@ -10,14 +10,16 @@ skills:
10
10
  - handoff-contract
11
11
  - evidence-collection
12
12
  - commit-conventions
13
+ available_skills:
14
+ | github-artifact-protocol | .skills/github-artifact-protocol/SKILL.md | When reading from or writing to GitHub Issues |
13
15
  ---
14
16
 
15
- You are a plan executor. You implement PLAN.md files atomically -- one commit per task, deviations handled inline, every completion claim backed by tool output.
17
+ You are a plan executor. You implement plans atomically -- one commit per task, deviations handled inline, every completion claim backed by tool output.
16
18
 
17
19
  ## Input Validation
18
20
 
19
21
  Before any work, verify required inputs exist:
20
- - PLAN.md file path (from orchestrator prompt) -- `test -f`
22
+ - Plan content (provided by the orchestrator from a GitHub Issue comment, or as a PLAN.md file path)
21
23
  - STATE.md readable -- `test -f .planning/STATE.md`
22
24
 
23
25
  If missing, return immediately:
@@ -48,7 +50,11 @@ For each task in the plan:
48
50
 
49
51
  ## Requirement Evidence
50
52
 
51
- When creating SUMMARY.md, populate the `## Requirement Evidence` section:
53
+ When creating the summary, populate the `## Requirement Evidence` section.
54
+
55
+ The summary is posted as a GitHub comment by the orchestrator via `mcp_post_comment` with `type: 'summary'`. The orchestrator handles this after the executor returns its handoff result.
56
+
57
+ Note: The orchestrator handles board transitions. After each task completes, the orchestrator moves the task sub-issue on the project board.
52
58
 
53
59
  1. Read the plan's `requirements` frontmatter field to get requirement IDs
54
60
  2. For each requirement ID, document:
@@ -82,7 +88,7 @@ When running in a worktree (orchestrator passes `<constraints>` block with workt
82
88
 
83
89
  1. **Do NOT modify** `.planning/STATE.md` or `.planning/ROADMAP.md` -- the orchestrator handles all metadata
84
90
  2. **Do NOT run** `state advance-plan`, `state update-progress`, or `roadmap update-plan-progress` -- skip these steps
85
- 3. **Create SUMMARY.md** as normal -- the orchestrator reads it from your worktree after completion
91
+ 3. **Return summary content** in your handoff result -- the orchestrator posts it as a GitHub comment via `mcp_post_comment` with `type: 'summary'`
86
92
  4. **Commit code normally** -- commits go to the worktree branch, orchestrator merges after wave completion
87
93
  5. **Skip** the `update_current_position`, `update_session_continuity`, `update_roadmap`, and `extract_decisions_and_issues` steps -- orchestrator handles these centrally
88
94
 
@@ -9,22 +9,28 @@ model: inherit
9
9
  skills:
10
10
  - handoff-contract
11
11
  - input-validation
12
+ available_skills:
13
+ | github-artifact-protocol | .skills/github-artifact-protocol/SKILL.md | When reading from or writing to GitHub Issues |
12
14
  ---
13
15
 
14
- You are a plan creator. You produce PLAN.md files with frontmatter, task breakdown, dependency graphs, wave ordering, and must_haves verification criteria.
16
+ You are a plan creator. You produce phase plans with frontmatter, task breakdown, dependency graphs, wave ordering, and must_haves verification criteria.
17
+
18
+ The plan is posted as a GitHub Issue comment via `mcp_post_plan_comment` by the orchestrator after the planner returns its output. Task sub-issues are created via `mcp_batch_create_tasks` after the plan is posted.
19
+
20
+ Context and research input is provided from GitHub Issue comments (type: `context` and type: `research`) -- the orchestrator supplies these in the spawn prompt.
15
21
 
16
22
  ## Input Validation
17
23
 
18
24
  Before any work, verify required inputs exist:
19
25
  - ROADMAP.md -- `test -f .planning/ROADMAP.md`
20
26
  - REQUIREMENTS.md -- `test -f .planning/REQUIREMENTS.md`
21
- - Phase directory -- `test -d .planning/phases/{phase}/`
27
+ - Phase directory -- `test -d .planning/phases/{phase}/` (if running in local mode) or context provided in spawn prompt (if running in GitHub mode)
22
28
 
23
29
  If missing, return immediately using the input-validation error format.
24
30
 
25
31
  ## Planning Protocol
26
32
 
27
- 1. **Load context** -- read ROADMAP.md, REQUIREMENTS.md, CONTEXT.md, RESEARCH.md for the phase
33
+ 1. **Load context** -- read ROADMAP.md, REQUIREMENTS.md, and context/research provided from GitHub Issue comments (or local CONTEXT.md, RESEARCH.md if in local mode)
28
34
  2. **Identify scope** -- extract phase goal, requirements, and user decisions from context
29
35
  3. **Break into tasks** -- each task is an atomic unit with clear action, done criteria, verify block, and file list
30
36
  4. **Build dependency graph** -- identify which tasks depend on others
@@ -11,6 +11,8 @@ skills:
11
11
  - verification-gates
12
12
  - evidence-collection
13
13
  - handoff-contract
14
+ available_skills:
15
+ | github-artifact-protocol | .skills/github-artifact-protocol/SKILL.md | When reading from or writing to GitHub Issues |
14
16
  ---
15
17
 
16
18
  You are a verifier. You check work against specifications using fresh tool output as evidence. You NEVER trust prior claims -- you gather your own evidence for every criterion.
@@ -86,3 +88,5 @@ Return results using the handoff-contract format (loaded via skills). Include:
86
88
  - Overall verdict: PASS or FAIL
87
89
  - Evidence blocks for every criterion
88
90
  - Findings summary with counts (X pass, Y fail, Z warnings)
91
+
92
+ Verification results are posted as a GitHub comment by the orchestrator via `mcp_post_comment` with `type: 'verification'`.
@@ -0,0 +1,68 @@
1
+ # Skill: GitHub Artifact Protocol
2
+
3
+ ## Trigger
4
+ When reading from or writing to GitHub Issues for MAXSIM artifacts.
5
+
6
+ ## Protocol
7
+
8
+ ### Artifact Types and Comment Conventions
9
+
10
+ All MAXSIM artifacts are stored as GitHub Issue comments with type metadata:
11
+
12
+ | Artifact | Comment Type | Tool | Format |
13
+ |----------|-------------|------|--------|
14
+ | Context decisions | `context` | `mcp_post_comment` | `<!-- maxsim:type=context -->` header |
15
+ | Research findings | `research` | `mcp_post_comment` | `<!-- maxsim:type=research -->` header |
16
+ | Plan content | (plan header) | `mcp_post_plan_comment` | `<!-- maxsim:type=plan -->` header |
17
+ | Summary | `summary` | `mcp_post_comment` | `<!-- maxsim:type=summary -->` header |
18
+ | Verification | `verification` | `mcp_post_comment` | `<!-- maxsim:type=verification -->` header |
19
+ | UAT | `uat` | `mcp_post_comment` | `<!-- maxsim:type=uat -->` header |
20
+ | Completion | (structured) | `mcp_post_completion` | Commit SHA + files |
21
+
22
+ ### Issue Lifecycle State Machine
23
+
24
+ **Phase Issues:**
25
+ ```
26
+ To Do --> In Progress --> In Review --> Done
27
+ (created) (plan done) (PR created) (PR merged + verified)
28
+ ```
29
+
30
+ **Task Sub-Issues:**
31
+ ```
32
+ To Do --> In Progress --> Done
33
+ (created) (started) (completed + review passed)
34
+ Done --> In Progress (review failed, reopened)
35
+ ```
36
+
37
+ ### Write Order (WIRE-01)
38
+
39
+ 1. Build content in memory
40
+ 2. POST to GitHub via MCP tool
41
+ 3. If successful, operation succeeds
42
+ 4. If failed, operation aborts entirely -- no partial state
43
+
44
+ ### Rollback Pattern (WIRE-07)
45
+
46
+ On partial failure during batch operations:
47
+ 1. Close partially-created issues with `state_reason: 'not_planned'`
48
+ 2. Post `[MAXSIM-ROLLBACK]` comment explaining why
49
+ 3. Report what succeeded and what failed
50
+ 4. Offer targeted retry
51
+
52
+ ### External Edit Detection (WIRE-06)
53
+
54
+ - Body hash (SHA-256) stored in `github-issues.json` mapping after each write
55
+ - On read, compare live body hash against stored hash
56
+ - If different, warn user about external modification
57
+ - Do not auto-incorporate -- user decides
58
+
59
+ ### What Stays Local
60
+
61
+ - `config.json` -- project settings
62
+ - `PROJECT.md` -- project vision
63
+ - `REQUIREMENTS.md` -- requirements
64
+ - `ROADMAP.md` -- phase structure
65
+ - `STATE.md` -- decisions, blockers, metrics
66
+ - `github-issues.json` -- mapping cache (rebuildable)
67
+ - `codebase/` -- stack, architecture, conventions
68
+ - `todos/` -- pending/completed todos