mindforge-cc 8.2.0 → 9.0.0

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/skills/mindforge-plan-phase_extended/SKILL.md

@@ -1,152 +0,0 @@
----
-name: mindforge-plan-phase_extended
-description: Use when you have a spec or requirements for a multi-step task, before touching code
----
-
-# Writing Plans
-
-## Overview
-
-Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste. Document everything they need to know: which files to touch for each task, code, testing, docs they might need to check, how to test it. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.
-
-Assume they are a skilled developer, but know almost nothing about our toolset or problem domain. Assume they don't know good test design very well.
-
-**Announce at start:** "I'm using the mindforge-plan-phase_extended skill to create the implementation plan."
-
-**Context:** This should be run in a dedicated worktree (created by brainstorming skill).
-
-**Save plans to:** `docs/mindforge/plans/YYYY-MM-DD-<feature-name>.md`
-- (User preferences for plan location override this default)
-
-## Scope Check
-
-If the spec covers multiple independent subsystems, it should have been broken into sub-project specs during brainstorming. If it wasn't, suggest breaking this into separate plans — one per subsystem. Each plan should produce working, testable software on its own.
-
-## File Structure
-
-Before defining tasks, map out which files will be created or modified and what each one is responsible for. This is where decomposition decisions get locked in.
-
-- Design units with clear boundaries and well-defined interfaces. Each file should have one clear responsibility.
-- You reason best about code you can hold in context at once, and your edits are more reliable when files are focused. Prefer smaller, focused files over large ones that do too much.
-- Files that change together should live together. Split by responsibility, not by technical layer.
-- In existing codebases, follow established patterns. If the codebase uses large files, don't unilaterally restructure - but if a file you're modifying has grown unwieldy, including a split in the plan is reasonable.
-
-This structure informs the task decomposition. Each task should produce self-contained changes that make sense independently.
-
-## Bite-Sized Task Granularity
-
-**Each step is one action (2-5 minutes):**
-- "Write the failing test" - step
-- "Run it to make sure it fails" - step
-- "Implement the minimal code to make the test pass" - step
-- "Run the tests and make sure they pass" - step
-- "Commit" - step
-
-## Plan Document Header
-
-**Every plan MUST start with this header:**
-
-```markdown
-# [Feature Name] Implementation Plan
-
-> **For agentic workers:** REQUIRED SUB-SKILL: Use mindforge:swarm-execution (recommended) or mindforge:execute-phase_extended to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
-
-**Goal:** [One sentence describing what this builds]
-
-**Architecture:** [2-3 sentences about approach]
-
-**Tech Stack:** [Key technologies/libraries]
-
----
-```
-
-## Task Structure
-
-````markdown
-### Task N: [Component Name]
-
-**Files:**
-- Create: `exact/path/to/file.py`
-- Modify: `exact/path/to/existing.py:123-145`
-- Test: `tests/exact/path/to/test.py`
-
-- [ ] **Step 1: Write the failing test**
-
-```python
-def test_specific_behavior():
-    result = function(input)
-    assert result == expected
-```
-
-- [ ] **Step 2: Run test to verify it fails**
-
-Run: `pytest tests/path/test.py::test_name -v`
-Expected: FAIL with "function not defined"
-
-- [ ] **Step 3: Write minimal implementation**
-
-```python
-def function(input):
-    return expected
-```
-
-- [ ] **Step 4: Run test to verify it passes**
-
-Run: `pytest tests/path/test.py::test_name -v`
-Expected: PASS
-
-- [ ] **Step 5: Commit**
-
-```bash
-git add tests/path/test.py src/path/file.py
-git commit -m "feat: add specific feature"
-```
-````
-
-## No Placeholders
-
-Every step must contain the actual content an engineer needs. These are **plan failures** — never write them:
-- "TBD", "TODO", "implement later", "fill in details"
-- "Add appropriate error handling" / "add validation" / "handle edge cases"
-- "Write tests for the above" (without actual test code)
-- "Similar to Task N" (repeat the code — the engineer may be reading tasks out of order)
-- Steps that describe what to do without showing how (code blocks required for code steps)
-- References to types, functions, or methods not defined in any task
-
-## Remember
-- Exact file paths always
-- Complete code in every step — if a step changes code, show the code
-- Exact commands with expected output
-- DRY, YAGNI, TDD, frequent commits
-
-## Self-Review
-
-After writing the complete plan, look at the spec with fresh eyes and check the plan against it. This is a checklist you run yourself — not a subagent dispatch.
-
-**1. Spec coverage:** Skim each section/requirement in the spec. Can you point to a task that implements it? List any gaps.
-
-**2. Placeholder scan:** Search your plan for red flags — any of the patterns from the "No Placeholders" section above. Fix them.
-
-**3. Type consistency:** Do the types, method signatures, and property names you used in later tasks match what you defined in earlier tasks? A function called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.
-
-If you find issues, fix them inline. No need to re-review — just fix and move on. If you find a spec requirement with no task, add the task.
-
-## Execution Handoff
-
-After saving the plan, offer execution choice:
-
-**"Plan complete and saved to `docs/mindforge/plans/<filename>.md`. Two execution options:**
-
-**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks, fast iteration
-
-**2. Inline Execution** - Execute tasks in this session using mindforge-execute-phase_extended, batch execution with checkpoints
-
-**Which approach?"**
-
-**If Subagent-Driven chosen:**
-- **REQUIRED SUB-SKILL:** Use mindforge:swarm-execution
-- Fresh subagent per task + two-stage review
-
-**If Inline Execution chosen:**
-- **REQUIRED SUB-SKILL:** Use mindforge:execute-phase_extended
-- Batch execution with checkpoints for review

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/skills/mindforge-plan-phase_extended/plan-document-reviewer-prompt.md

@@ -1,49 +0,0 @@
-# Plan Document Reviewer Prompt Template
-
-Use this template when dispatching a plan document reviewer subagent.
-
-**Purpose:** Verify the plan is complete, matches the spec, and has proper task decomposition.
-
-**Dispatch after:** The complete plan is written.
-
-```
-Task tool (general-purpose):
-  description: "Review plan document"
-  prompt: |
-    You are a plan document reviewer. Verify this plan is complete and ready for implementation.
-
-    **Plan to review:** [PLAN_FILE_PATH]
-    **Spec for reference:** [SPEC_FILE_PATH]
-
-    ## What to Check
-
-    | Category | What to Look For |
-    |----------|------------------|
-    | Completeness | TODOs, placeholders, incomplete tasks, missing steps |
-    | Spec Alignment | Plan covers spec requirements, no major scope creep |
-    | Task Decomposition | Tasks have clear boundaries, steps are actionable |
-    | Buildability | Could an engineer follow this plan without getting stuck? |
-
-    ## Calibration
-
-    **Only flag issues that would cause real problems during implementation.**
-    An implementer building the wrong thing or getting stuck is an issue.
-    Minor wording, stylistic preferences, and "nice to have" suggestions are not.
-
-    Approve unless there are serious gaps — missing requirements from the spec,
-    contradictory steps, placeholder content, or tasks so vague they can't be acted on.
-
-    ## Output Format
-
-    ## Plan Review
-
-    **Status:** Approved | Issues Found
-
-    **Issues (if any):**
-    - [Task X, Step Y]: [specific issue] - [why it matters for implementation]
-
-    **Recommendations (advisory, do not block approval):**
-    - [suggestions for improvement]
-```
-
-**Reviewer returns:** Status, Issues (if any), Recommendations

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/skills/mindforge-plant-seed/SKILL.md

@@ -1,22 +0,0 @@
----
-name: mindforge-plant-seed
-description: Capture a forward-looking idea with trigger conditions — surfaces automatically at the right milestone
----
-
-
-<objective>
-Capture an idea that's too big for now but should surface automatically when the right
-milestone arrives. Seeds solve context rot: instead of a one-liner in Deferred that nobody
-reads, a seed preserves the full WHY, WHEN to surface, and breadcrumbs to details.
-
-Creates: .planning/seeds/SEED-NNN-slug.md
-Consumed by: /mindforge-new-milestone (scans seeds and presents matches)
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-plant-seed.md
-</execution_context>
-
-<process>
-Execute the plant-seed workflow from @.agent/workflows/mindforge-plant-seed.md end-to-end.
-</process>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/skills/mindforge-pr-branch/SKILL.md

@@ -1,21 +0,0 @@
----
-name: mindforge-pr-branch
-description: Create a clean PR branch by filtering out .planning/ commits — ready for code review
----
-
-
-<objective>
-Create a clean branch suitable for pull requests by filtering out .planning/ commits
-from the current branch. Reviewers see only code changes, not MindForge planning artifacts.
-
-This solves the problem of PR diffs being cluttered with PLAN.md, SUMMARY.md, STATE.md
-changes that are irrelevant to code review.
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-pr-branch.md
-</execution_context>
-
-<process>
-Execute the pr-branch workflow from @.agent/workflows/mindforge-pr-branch.md end-to-end.
-</process>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/skills/mindforge-profile-user/SKILL.md

@@ -1,38 +0,0 @@
----
-name: mindforge-profile-user
-description: Generate developer behavioral profile and create Claude-discoverable artifacts
----
-
-
-<objective>
-Generate a developer behavioral profile from session analysis (or questionnaire) and produce artifacts (USER-PROFILE.md, /mindforge-dev-preferences, GEMINI.md section) that personalize the agent's responses.
-
-Routes to the profile-user workflow which orchestrates the full flow: consent gate, session analysis or questionnaire fallback, profile generation, result display, and artifact selection.
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-profile-user.md
-@.agent/references/ui-brand.md
-</execution_context>
-
-<context>
-Flags from $ARGUMENTS:
-- `--questionnaire` -- Skip session analysis entirely, use questionnaire-only path
-- `--refresh` -- Rebuild profile even when one exists, backup old profile, show dimension diff
-</context>
-
-<process>
-Execute the profile-user workflow end-to-end.
-
-The workflow handles all logic including:
-1. Initialization and existing profile detection
-2. Consent gate before session analysis
-3. Session scanning and data sufficiency checks
-4. Session analysis (profiler agent) or questionnaire fallback
-5. Cross-project split resolution
-6. Profile writing to USER-PROFILE.md
-7. Result display with report card and highlights
-8. Artifact selection (dev-preferences, GEMINI.md sections)
-9. Sequential artifact generation
-10. Summary with refresh diff (if applicable)
-</process>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/skills/mindforge-progress/SKILL.md

@@ -1,19 +0,0 @@
----
-name: mindforge-progress
-description: Check project progress, show context, and route to next action (execute or plan)
----
-
-<objective>
-Check project progress, summarize recent work and what's ahead, then intelligently route to the next action - either executing an existing plan or creating the next one.
-
-Provides situational awareness before continuing work.
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-progress.md
-</execution_context>
-
-<process>
-Execute the progress workflow from @.agent/workflows/mindforge-progress.md end-to-end.
-Preserve all routing logic (Routes A through F) and edge case handling.
-</process>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/skills/mindforge-quick/SKILL.md

@@ -1,38 +0,0 @@
----
-name: mindforge-quick
-description: Execute a quick task with MindForge guarantees (atomic commits, state tracking) but skip optional agents
----
-
-<objective>
-Execute small, ad-hoc tasks with MindForge guarantees (atomic commits, STATE.md tracking).
-
-Quick mode is the same system with a shorter path:
-- Spawns mindforge-planner (quick mode) + mindforge-executor(s)
-- Quick tasks live in `.planning/quick/` separate from planned phases
-- Updates STATE.md "Quick Tasks Completed" table (NOT ROADMAP.md)
-
-**Default:** Skips research, discussion, plan-checker, verifier. Use when you know exactly what to do.
-
-**`--discuss` flag:** Lightweight discussion phase before planning. Surfaces assumptions, clarifies gray areas, captures decisions in CONTEXT.md. Use when the task has ambiguity worth resolving upfront.
-
-**`--full` flag:** Enables plan-checking (max 2 iterations) and post-execution verification. Use when you want quality guarantees without full milestone ceremony.
-
-**`--research` flag:** Spawns a focused research agent before planning. Investigates implementation approaches, library options, and pitfalls for the task. Use when you're unsure of the best approach.
-
-Flags are composable: `--discuss --research --full` gives discussion + research + plan-checking + verification.
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-quick.md
-</execution_context>
-
-<context>
-$ARGUMENTS
-
-Context files are resolved inside the workflow (`init quick`) and delegated via `<files_to_read>` blocks.
-</context>
-
-<process>
-Execute the quick workflow from @.agent/workflows/mindforge-quick.md end-to-end.
-Preserve all workflow gates (validation, task description, planning, execution, state updates, commits).
-</process>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/skills/mindforge-reapply-patches/SKILL.md

@@ -1,124 +0,0 @@
----
-name: mindforge-reapply-patches
-description: Reapply local modifications after a MindForge update
----
-
-
-<purpose>
-After a MindForge update wipes and reinstalls files, this command merges user's previously saved local modifications back into the new version. Uses intelligent comparison to handle cases where the upstream file also changed.
-</purpose>
-
-<process>
-
-## Step 1: Detect backed-up patches
-
-Check for local patches directory:
-
-```bash
-# Global install — detect runtime config directory
-if [ -d "$HOME/.config/opencode/mindforge-local-patches" ]; then
-  PATCHES_DIR="$HOME/.config/opencode/mindforge-local-patches"
-elif [ -d "$HOME/.opencode/mindforge-local-patches" ]; then
-  PATCHES_DIR="$HOME/.opencode/mindforge-local-patches"
-elif [ -d "$HOME/.gemini/mindforge-local-patches" ]; then
-  PATCHES_DIR="$HOME/.gemini/mindforge-local-patches"
-else
-  PATCHES_DIR=".agent/mindforge-local-patches"
-fi
-# Local install fallback — check all runtime directories
-if [ ! -d "$PATCHES_DIR" ]; then
-  for dir in .config/opencode .opencode .gemini .claude; do
-    if [ -d "./$dir/mindforge-local-patches" ]; then
-      PATCHES_DIR="./$dir/mindforge-local-patches"
-      break
-    fi
-  done
-fi
-```
-
-Read `backup-meta.json` from the patches directory.
-
-**If no patches found:**
-```
-No local patches found. Nothing to reapply.
-
-Local patches are automatically saved when you run /mindforge-update
-after modifying any MindForge workflow, command, or agent files.
-```
-Exit.
-
-## Step 2: Show patch summary
-
-```
-## Local Patches to Reapply
-
-**Backed up from:** v{from_version}
-**Current version:** {read VERSION file}
-**Files modified:** {count}
-
-| # | File | Status |
-|---|------|--------|
-| 1 | {file_path} | Pending |
-| 2 | {file_path} | Pending |
-```
-
-## Step 3: Merge each file
-
-For each file in `backup-meta.json`:
-
-1. **Read the backed-up version** (user's modified copy from `mindforge-local-patches/`)
-2. **Read the newly installed version** (current file after update)
-3. **Compare and merge:**
-
-   - If the new file is identical to the backed-up file: skip (modification was incorporated upstream)
-   - If the new file differs: identify the user's modifications and apply them to the new version
-
-   **Merge strategy:**
-   - Read both versions fully
-   - Identify sections the user added or modified (look for additions, not just differences from path replacement)
-   - Apply user's additions/modifications to the new version
-   - If a section the user modified was also changed upstream: flag as conflict, show both versions, ask user which to keep
-
-4. **Write merged result** to the installed location
-5. **Report status:**
-   - `Merged` — user modifications applied cleanly
-   - `Skipped` — modification already in upstream
-   - `Conflict` — user chose resolution
-
-## Step 4: Update manifest
-
-After reapplying, regenerate the file manifest so future updates correctly detect these as user modifications:
-
-```bash
-# The manifest will be regenerated on next /mindforge-update
-# For now, just note which files were modified
-```
-
-## Step 5: Cleanup option
-
-Ask user:
-- "Keep patch backups for reference?" → preserve `mindforge-local-patches/`
-- "Clean up patch backups?" → remove `mindforge-local-patches/` directory
-
-## Step 6: Report
-
-```
-## Patches Reapplied
-
-| # | File | Status |
-|---|------|--------|
-| 1 | {file_path} | ✓ Merged |
-| 2 | {file_path} | ○ Skipped (already upstream) |
-| 3 | {file_path} | ⚠ Conflict resolved |
-
-{count} file(s) updated. Your local modifications are active again.
-```
-
-</process>
-
-<success_criteria>
-- [ ] All backed-up patches processed
-- [ ] User modifications merged into new version
-- [ ] Conflicts resolved with user input
-- [ ] Status reported for each file
-</success_criteria>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/skills/mindforge-remove-phase/SKILL.md

@@ -1,26 +0,0 @@
----
-name: mindforge-remove-phase
-description: Remove a future phase from roadmap and renumber subsequent phases
----
-
-<objective>
-Remove an unstarted future phase from the roadmap and renumber all subsequent phases to maintain a clean, linear sequence.
-
-Purpose: Clean removal of work you've decided not to do, without polluting context with cancelled/deferred markers.
-Output: Phase deleted, all subsequent phases renumbered, git commit as historical record.
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-remove-phase.md
-</execution_context>
-
-<context>
-Phase: $ARGUMENTS
-
-Roadmap and state are resolved in-workflow via `init phase-op` and targeted reads.
-</context>
-
-<process>
-Execute the remove-phase workflow from @.agent/workflows/mindforge-remove-phase.md end-to-end.
-Preserve all validation gates (future phase check, work check), renumbering logic, and commit.
-</process>

package/.mindforge/mirrors/mirror-sre-776a1cf9/.agent/skills/mindforge-remove-workspace/SKILL.md

@@ -1,22 +0,0 @@
----
-name: mindforge-remove-workspace
-description: Remove a MindForge workspace and clean up worktrees
----
-
-<context>
-**Arguments:**
-- `<workspace-name>` (required) — Name of the workspace to remove
-</context>
-
-<objective>
-Remove a workspace directory after confirmation. For worktree strategy, runs `git worktree remove` for each member repo first. Refuses if any repo has uncommitted changes.
-</objective>
-
-<execution_context>
-@.agent/workflows/mindforge-remove-workspace.md
-@.agent/references/ui-brand.md
-</execution_context>
-
-<process>
-Execute the remove-workspace workflow from @.agent/workflows/mindforge-remove-workspace.md end-to-end.
-</process>