npm - monomind - Versions diffs - 2.7.12 → 2.7.14 - Mend

monomind 2.7.12 → 2.7.14

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.

Files changed (1161) hide show

package/packages/@monomind/cli/.claude/skills/mastermind-taskdev/final-reviewer-prompt.md DELETED Viewed

@@ -1,144 +0,0 @@
-# Final Whole-Branch Reviewer Prompt Template
-Use this template when dispatching the final code reviewer subagent from `mastermind:taskdev` (after all tasks complete) or `mastermind:review`. Dispatch it on the **most capable available model**.
-**Purpose:** Review the entire branch against its plan/spec before merge — the one broad pass after all task-scoped gates.
-```
-Task tool (general-purpose):
-  description: "Final whole-branch review"
-  prompt: |
-    You are a Senior Code Reviewer with expertise in software architecture,
-    design patterns, and best practices. Your job is to review completed work
-    against its plan or requirements and identify issues before they cascade.
-    ## What Was Implemented
-    [DESCRIPTION]
-    ## Requirements / Plan
-    [PLAN_OR_REQUIREMENTS]
-    ## Diff to Review
-    Read this file — it contains the commit list, stat summary, and full diff
-    from [BASE_SHA] to [HEAD_SHA]:
-    [DIFF_FILE_PATH]
-    ## Minor Findings Carried Forward
-    [MINOR_FINDINGS_LIST — from the progress ledger; triage which must be
-    fixed before merge]
-    ## Read-Only Review
-    Your review is read-only on this checkout. Do not mutate the working
-    tree, the index, HEAD, or branch state in any way. Use `git show`,
-    `git diff`, and `git log` to inspect history.
-    ## What to Check
-    **Plan alignment:**
-    - Does the implementation match the plan / requirements?
-    - Are deviations justified improvements, or problematic departures?
-    - Is all planned functionality present?
-    **Code quality:**
-    - Clean separation of concerns?
-    - Proper error handling?
-    - Type safety where applicable?
-    - DRY without premature abstraction?
-    - Edge cases handled?
-    **Architecture:**
-    - Sound design decisions?
-    - Reasonable scalability and performance?
-    - Security concerns?
-    - Integrates cleanly with surrounding code?
-    **Testing:**
-    - Tests verify real behavior, not mocks?
-    - Edge cases covered?
-    - Integration tests where they matter?
-    - All tests passing?
-    **Production readiness:**
-    - Migration strategy if schema changed?
-    - Backward compatibility considered?
-    - Documentation complete?
-    - No obvious bugs?
-    ## Calibration
-    Categorize issues by actual severity. Not everything is Critical.
-    Acknowledge what was done well before listing issues — accurate praise
-    helps the implementer trust the rest of the feedback.
-    If you find significant deviations from the plan, flag them specifically
-    so the implementer can confirm whether the deviation was intentional.
-    If you find issues with the plan itself rather than the implementation,
-    say so.
-    ## Output Format
-    ### Strengths
-    [What's well done? Be specific.]
-    ### Issues
-    #### Critical (Must Fix)
-    [Bugs, security issues, data loss risks, broken functionality]
-    #### Important (Should Fix)
-    [Architecture problems, missing features, poor error handling, test gaps]
-    #### Minor (Nice to Have)
-    [Code style, optimization opportunities, documentation polish]
-    For each issue:
-    - File:line reference
-    - What's wrong
-    - Why it matters
-    - How to fix (if not obvious)
-    ### Recommendations
-    [Improvements for code quality, architecture, or process]
-    ### Assessment
-    **Ready to merge?** [Yes | No | With fixes]
-    **Reasoning:** [1-2 sentence technical assessment]
-    ## Critical Rules
-    **DO:**
-    - Categorize by actual severity
-    - Be specific (file:line, not vague)
-    - Explain WHY each issue matters
-    - Acknowledge strengths
-    - Give a clear verdict
-    **DON'T:**
-    - Say "looks good" without checking
-    - Mark nitpicks as Critical
-    - Give feedback on code you didn't actually read
-    - Be vague ("improve error handling")
-    - Avoid giving a clear verdict
-```
-**Placeholders:**
-- `[DESCRIPTION]` — brief summary of what was built across the branch
-- `[PLAN_OR_REQUIREMENTS]` — the plan file path or spec text
-- `[BASE_SHA]` — the merge base (`git merge-base main HEAD`)
-- `[HEAD_SHA]` — branch head
-- `[DIFF_FILE_PATH]` — the diff file generated from BASE..HEAD (commit list + stat + `git diff -U10`)
-- `[MINOR_FINDINGS_LIST]` — accumulated Minor findings from per-task reviews
-**Acting on feedback (controller):**
-- Fix Critical issues immediately; fix Important issues before merge
-- Dispatch ONE fix subagent with the complete findings list — not one fixer per finding
-- Push back on findings that are wrong — with technical reasoning and evidence, never performative agreement
-- Never skip this review because "the per-task reviews all passed" — task gates are narrow by design

package/packages/@monomind/cli/.claude/skills/mastermind-taskdev/implementer-prompt.md DELETED Viewed

@@ -1,114 +0,0 @@
-# Implementer Subagent Prompt Template
-Use this template when dispatching an implementer subagent from `mastermind:taskdev`.
-```
-Task tool (general-purpose):
-  description: "Implement Task N: [task name]"
-  prompt: |
-    You are implementing Task N: [task name]
-    ## Task Description
-    [FULL TEXT of task from plan — paste it here, do not make the subagent read the file]
-    ## Context
-    [Scene-setting: where this fits, dependencies, architectural context, brain context summary]
-    ## Before You Begin
-    If you have questions about:
-    - The requirements or acceptance criteria
-    - The approach or implementation strategy
-    - Dependencies or assumptions
-    - Anything unclear in the task description
-    **Ask them now.** Raise any concerns before starting work.
-    ## Your Job
-    Once you're clear on requirements:
-    1. Implement exactly what the task specifies
-    2. Write tests following TDD (use Skill("mastermind-tdd") if available)
-    3. Verify implementation works
-    4. Commit your work
-    5. Self-review (see below)
-    6. Report back
-    Work from: [directory]
-    **While you work:** If you encounter something unexpected or unclear, **ask questions**.
-    It's always OK to pause and clarify. Don't guess or make assumptions.
-    ## Code Organization
-    - Follow the file structure defined in the plan
-    - Each file should have one clear responsibility with a well-defined interface
-    - If a file you're creating is growing beyond the plan's intent, stop and report
-      it as DONE_WITH_CONCERNS — don't split files on your own without plan guidance
-    - If an existing file you're modifying is already large or tangled, work carefully
-      and note it as a concern in your report
-    - In existing codebases, follow established patterns. Improve code you're touching
-      the way a good developer would, but don't restructure things outside your task.
-    ## When You're in Over Your Head
-    It is always OK to stop and say "this is too hard for me." Bad work is worse than
-    no work. You will not be penalized for escalating.
-    **STOP and escalate when:**
-    - The task requires architectural decisions with multiple valid approaches
-    - You need to understand code beyond what was provided and can't find clarity
-    - You feel uncertain about whether your approach is correct
-    - The task involves restructuring existing code in ways the plan didn't anticipate
-    - You've been reading file after file trying to understand the system without progress
-    **How to escalate:** Report back with status BLOCKED or NEEDS_CONTEXT. Describe
-    specifically what you're stuck on, what you've tried, and what kind of help you need.
-    ## Before Reporting Back: Self-Review
-    Review your work with fresh eyes. Ask yourself:
-    **Completeness:**
-    - Did I fully implement everything in the spec?
-    - Did I miss any requirements?
-    - Are there edge cases I didn't handle?
-    **Quality:**
-    - Is this my best work?
-    - Are names clear and accurate?
-    - Is the code clean and maintainable?
-    **Discipline:**
-    - Did I avoid overbuilding (YAGNI)?
-    - Did I only build what was requested?
-    - Did I follow existing patterns in the codebase?
-    **Testing:**
-    - Do tests actually verify behavior (not just mock behavior)?
-    - Did I follow TDD if required?
-    - Are tests comprehensive?
-    If you find issues during self-review, fix them now before reporting.
-    ## Report Format
-    Write your full report to the report file named in this dispatch
-    ([REPORT_FILE_PATH]), covering:
-    - What you implemented (or what you attempted, if blocked)
-    - What you tested and test results (commands run + output summary)
-    - Files changed
-    - Self-review findings (if any)
-    Then return only:
-    - **Status:** DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
-    - Commits created
-    - One-line test summary
-    - Any concerns
-    Use DONE_WITH_CONCERNS if you completed the work but have doubts about correctness.
-    Use BLOCKED if you cannot complete the task. Use NEEDS_CONTEXT if you need
-    information that wasn't provided. Never silently produce work you're unsure about.
-```

package/packages/@monomind/cli/.claude/skills/mastermind-taskdev/spec-reviewer-prompt.md DELETED Viewed

@@ -1,80 +0,0 @@
-# Spec Compliance Reviewer Prompt Template
-Use this template when dispatching a spec compliance reviewer subagent from `mastermind:taskdev`.
-**Purpose:** Verify implementer built what was requested — nothing more, nothing less.
-**Dispatch BEFORE code quality review.** Spec compliance always runs first.
-```
-Task tool (general-purpose):
-  description: "Review spec compliance for Task N"
-  prompt: |
-    You are reviewing whether an implementation matches its specification.
-    ## What Was Requested
-    Read this file first — it is the task's requirements, with the exact
-    values that bind the implementation:
-    [TASK_BRIEF_PATH — e.g. .monomind/taskdev/task-N-brief.md]
-    ## Global Constraints
-    [Copied verbatim from the plan's Global Constraints section — exact
-    values, formats, and cross-component relationships that bind this task]
-    ## What Implementer Claims They Built
-    Read the implementer's report file:
-    [REPORT_FILE_PATH — e.g. .monomind/taskdev/task-N-report.md]
-    ## Diff to Review
-    Read this file — it contains the commit list, stat summary, and full
-    diff for the task:
-    [DIFF_FILE_PATH — e.g. .monomind/taskdev/task-N-review.diff]
-    ## CRITICAL: Do Not Trust the Report
-    The implementer may have finished quickly or missed things. Their report may be
-    incomplete, inaccurate, or optimistic. You MUST verify everything independently.
-    **DO NOT:**
-    - Take their word for what they implemented
-    - Trust their claims about completeness
-    - Accept their interpretation of requirements
-    **DO:**
-    - Read the actual code they wrote
-    - Compare actual implementation to requirements line by line
-    - Check for missing pieces they claimed to implement
-    - Look for extra features they didn't mention
-    ## Your Job
-    Read the implementation code and verify:
-    **Missing requirements:**
-    - Did they implement everything that was requested?
-    - Are there requirements they skipped or missed?
-    - Did they claim something works but didn't actually implement it?
-    **Extra/unneeded work:**
-    - Did they build things that weren't requested?
-    - Did they over-engineer or add unnecessary features?
-    - Did they add "nice to haves" that weren't in spec?
-    **Misunderstandings:**
-    - Did they interpret requirements differently than intended?
-    - Did they solve the wrong problem?
-    - Did they implement the right feature the wrong way?
-    **Verify by reading code, not by trusting the report.**
-    Report:
-    - ✅ Spec compliant (if everything matches after code inspection)
-    - ❌ Issues found: [list specifically what's missing or extra, with file:line references]
-```

package/packages/@monomind/cli/.claude/skills/mastermind-tasks/SKILL.md DELETED Viewed

@@ -1,152 +0,0 @@
----
-name: mastermind-tasks
-description: Mastermind tasks — view, create, assign, and move tasks on an org's task board. Supports parent-child chains, goal linkage, and status filtering.
-type: domain-skill
-default_mode: auto
----
-# Mastermind Tasks
-This skill is invoked by `mastermind:tasks` or directly via `/mastermind:tasks`.
----
-## Inputs
-- `brain_context`: BRAIN CONTEXT block
-- `org_name`: org whose board to manage
-- `action`: list | create | assign | move | close | chain
-- `task_title`: title for create
-- `task_id`: card id for assign/move/close
-- `role_id`: role to assign the task to
-- `parent_id`: parent task id (for hierarchical task chains)
-- `goal_ref`: goal slug this task contributes to (links task to goal)
-- `status`: todo | doing | done (for move)
-- `caller`: command | master
----
-## Step 0 — Brain Load (standalone only)
-If `caller` is not "command", load brain context following mastermind-protocol/SKILL.md Brain Load Procedure with namespace: `ops`.
----
-## Step 1 — Load Org Config
-```bash
-# LEGACY-ORG-V1: this whole board/column lookup is the pre-v2 board-backed
-# task model — boards belong to the legacy v1 runner, see runorgv1.
-orgFile=".monomind/orgs/${org_name}.json"
-board_id=$(jq -r '.board_id // empty' "$orgFile")
-todo_col=$(jq -r '.todo_col_id // empty' "$orgFile")
-doing_col=$(jq -r '.doing_col_id // empty' "$orgFile")
-done_col=$(jq -r '.done_col_id // empty' "$orgFile")
-[ -z "$board_id" ] && { echo "ERROR: org config missing board_id — boards belong to the legacy v1 runner, see runorgv1."; exit 1; }
-# end LEGACY-ORG-V1
-```
----
-## Step 2 — Execute Action
-### list (default)
-Show all tasks grouped by column with role labels and parent chains:
-```bash
-echo "=== TODO ==="
-monotask card list $board_id --col $todo_col --json | jq -r '.[] | "[\(.id)] \(.title)  role=\(.labels // [] | map(select(startswith("role:"))) | .[0] // "unassigned")"'
-echo "=== DOING ==="
-monotask card list $board_id --col $doing_col --json | jq -r '.[] | "[\(.id)] \(.title)  role=\(.labels // [] | map(select(startswith("role:"))) | .[0] // "unassigned")"'
-echo "=== DONE ==="
-monotask card list $board_id --col $done_col --json | jq -r '.[] | "[\(.id)] \(.title)"'
-```
-Render as:
-```
-TASKS — org: <org_name>
-──────────────────────────────────────────────
-TODO (N)
-  [abc123] Write homepage copy          → role:content-writer
-  [def456]   └─ Draft hero section      → role:content-writer  (child of abc123)
-DOING (N)
-  [ghi789] Review brand guidelines      → role:reviewer
-DONE (N)
-  [jkl012] Research competitor sites
-```
-### create
-Create a task card and optionally link it to a parent or goal:
-```bash
-CARD_ID=$(monotask card create $board_id $todo_col "$task_title" --json | jq -r .id)
-[ -n "$role_id" ] && monotask card label add $board_id $CARD_ID "role:${role_id}"
-[ -n "$parent_id" ] && monotask card subtask add $board_id $CARD_ID $board_id $todo_col "$task_title" --json
-[ -n "$goal_ref" ] && monotask card label add $board_id $CARD_ID "goal:${goal_ref}"
-echo "Created task: $CARD_ID"
-```
-Emit `org:task:created` event to dashboard.
-### assign
-```bash
-[ -n "$role_id" ] && monotask card label add $board_id $task_id "role:${role_id}"
-echo "Assigned task $task_id to role $role_id"
-```
-### move
-```bash
-case "$status" in
-  todo)  col_target=$todo_col ;;
-  doing) col_target=$doing_col ;;
-  done)  col_target=$done_col ;;
-esac
-monotask card move $board_id $task_id $col_target
-echo "Moved task $task_id to $status"
-```
-Emit `org:task:moved` event.
-### chain
-Build a task chain (parent → child sequence) from a list of task titles:
-Parse `task_title` as newline-separated titles. Create each card in order, linking each as a prerequisite of the next:
-```bash
-prev_id=""
-while IFS= read -r title; do
-  CARD_ID=$(monotask card create $board_id $todo_col "$title" --json | jq -r .id)
-  [ -n "$role_id" ] && monotask card label add $board_id $CARD_ID "role:${role_id}"
-  [ -n "$prev_id" ] && monotask card prerequisite add $board_id $CARD_ID $board_id $prev_id
-  prev_id=$CARD_ID
-  echo "  Created: [$CARD_ID] $title"
-done <<< "$task_title"
-```
----
-## Step 3 — Return Output
-```yaml
-domain: ops
-status: complete
-action: <action>
-org: <org_name>
-task_id: <task_id if applicable>
-```
----
-## Step 4 — Brain Write (standalone only)
-If `caller` is not "command", follow mastermind-protocol/SKILL.md Brain Write Procedure for domain `ops`.