mindforge-cc 11.8.2 → 11.9.0

package/.mindforge/skills/github-code-review/references/review-output-template.md

@@ -0,0 +1,74 @@
+# Review Output Template
+
+Use this as the structure for PR review summary comments. Copy and fill in the sections.
+
+## For PR Summary Comment
+
+```markdown
+## Code Review Summary
+
+**Verdict: [Approved ✅ | Changes Requested 🔴 | Reviewed 💬]** ([N] issues, [N] suggestions)
+
+**PR:** #[number] — [title]
+**Author:** @[username]
+**Files changed:** [N] (+[additions] -[deletions])
+
+### 🔴 Critical
+<!-- Issues that MUST be fixed before merge -->
+- **file.py:line** — [description]. Suggestion: [fix].
+
+### ⚠️ Warnings
+<!-- Issues that SHOULD be fixed, but not strictly blocking -->
+- **file.py:line** — [description].
+
+### 💡 Suggestions
+<!-- Non-blocking improvements, style preferences, future considerations -->
+- **file.py:line** — [description].
+
+### ✅ Looks Good
+<!-- Call out things done well — positive reinforcement -->
+- [aspect that was done well]
+
+---
+*Reviewed by 
+```
+
+## Severity Guide
+
+| Level | Icon | When to use | Blocks merge? |
+|-------|------|-------------|---------------|
+| Critical | 🔴 | Security vulnerabilities, data loss risk, crashes, broken core functionality | Yes |
+| Warning | ⚠️ | Bugs in non-critical paths, missing error handling, missing tests for new code | Usually yes |
+| Suggestion | 💡 | Style improvements, refactoring ideas, performance hints, documentation gaps | No |
+| Looks Good | ✅ | Clean patterns, good test coverage, clear naming, smart design decisions | N/A |
+
+## Verdict Decision
+
+- **Approved ✅** — Zero critical/warning items. Only suggestions or all clear.
+- **Changes Requested 🔴** — Any critical or warning item exists.
+- **Reviewed 💬** — Observations only (draft PRs, uncertain findings, informational).
+
+## For Inline Comments
+
+Prefix inline comments with the severity icon so they're scannable:
+
+```
+🔴 **Critical:** User input passed directly to SQL query — use parameterized queries to prevent injection.
+```
+
+```
+⚠️ **Warning:** This error is silently swallowed. At minimum, log it.
+```
+
+```
+💡 **Suggestion:** This could be simplified with a dict comprehension:
+`{k: v for k, v in items if v is not None}`
+```
+
+```
+✅ **Nice:** Good use of context manager here — ensures cleanup on exceptions.
+```
+
+## For Local (Pre-Push) Review
+
+When reviewing locally before push, use the same structure but present it as a message to the user instead of a PR comment. Skip the PR metadata header and just start with the severity sections.

package/.mindforge/skills/github-issues/templates/bug-report.md

@@ -0,0 +1,35 @@
+## Bug Description
+
+<!-- Clear, concise description of the bug -->
+
+## Steps to Reproduce
+
+1.
+2.
+3.
+
+## Expected Behavior
+
+<!-- What should happen -->
+
+## Actual Behavior
+
+<!-- What actually happens -->
+
+## Environment
+
+- OS:
+- Version/Commit:
+- Python version:
+- Browser (if applicable):
+
+## Error Output
+
+<!-- Paste relevant error messages, stack traces, or logs -->
+
+```
+```
+
+## Additional Context
+
+<!-- Screenshots, related issues, workarounds discovered, etc. -->

package/.mindforge/skills/github-issues/templates/feature-request.md

@@ -0,0 +1,31 @@
+## Feature Description
+
+<!-- What do you want? -->
+
+## Motivation
+
+<!-- Why would this be useful? What problem does it solve? -->
+
+## Proposed Solution
+
+<!-- How could it work? Include API sketches, CLI examples, or mockups if helpful -->
+
+```
+# Example usage
+```
+
+## Alternatives Considered
+
+<!-- Other approaches and why they're less ideal -->
+
+-
+
+## Scope / Effort Estimate
+
+<!-- How big is this? What areas of the codebase would it touch? -->
+
+Small / Medium / Large — <!-- explanation -->
+
+## Additional Context
+
+<!-- Links to similar features in other tools, relevant discussions, etc. -->

package/.mindforge/skills/github-pr-workflow/SKILL.md

@@ -73,7 +73,7 @@ Branch naming conventions:
 
 ## 2. Making Commits
 
-Use the agent's file tools (`write_file`, `patch`) to make changes, then commit:
+Use the agent's file tools (`Write`, `Edit`) to make changes, then commit:
 
 ```bash
 # Stage specific files
@@ -247,7 +247,7 @@ cd /tmp && unzip -o ci-logs.zip -d ci-logs && cat ci-logs/*.txt
 
 ### Step 2: Fix and Push
 
-After identifying the issue, use file tools (`patch`, `write_file`) to fix it:
+After identifying the issue, use file tools (`Edit`, `Write`) to fix it:
 
 ```bash
 git add <fixed_files>
@@ -265,7 +265,7 @@ When asked to auto-fix CI, follow this loop:
 
 1. Check CI status → identify failures
 2. Read failure logs → understand the error
-3. Use `read_file` + `patch`/`write_file` → fix the code
+3. Use `Read` + `Edit`/`Write` → fix the code
 4. `git add . && git commit -m "fix: ..." && git push`
 5. Wait for CI → re-check status
 6. Repeat if still failing (up to 3 attempts, then ask the user)

package/.mindforge/skills/github-pr-workflow/references/ci-troubleshooting.md

@@ -0,0 +1,183 @@
+# CI Troubleshooting Quick Reference
+
+Common CI failure patterns and how to diagnose them from the logs.
+
+## Reading CI Logs
+
+```bash
+# With gh
+gh run view <RUN_ID> --log-failed
+
+# With curl — download and extract
+curl -sL -H "Authorization: token $GITHUB_TOKEN" \
+  https://api.github.com/repos/$GH_OWNER/$GH_REPO/actions/runs/<RUN_ID>/logs \
+  -o /tmp/ci-logs.zip && unzip -o /tmp/ci-logs.zip -d /tmp/ci-logs
+```
+
+## Common Failure Patterns
+
+### Test Failures
+
+**Signatures in logs:**
+```
+FAILED tests/test_foo.py::test_bar - AssertionError
+E       assert 42 == 43
+ERROR tests/test_foo.py - ModuleNotFoundError
+```
+
+**Diagnosis:**
+1. Find the test file and line number from the traceback
+2. Use `read_file` to read the failing test
+3. Check if it's a logic error in the code or a stale test assertion
+4. Look for `ModuleNotFoundError` — usually a missing dependency in CI
+
+**Common fixes:**
+- Update assertion to match new expected behavior
+- Add missing dependency to requirements.txt / pyproject.toml
+- Fix flaky test (add retry, mock external service, fix race condition)
+
+---
+
+### Lint / Formatting Failures
+
+**Signatures in logs:**
+```
+src/auth.py:45:1: E302 expected 2 blank lines, got 1
+src/models.py:12:80: E501 line too long (95 > 88 characters)
+error: would reformat src/utils.py
+```
+
+**Diagnosis:**
+1. Read the specific file:line numbers mentioned
+2. Check which linter is complaining (flake8, ruff, black, isort, mypy)
+
+**Common fixes:**
+- Run the formatter locally: `black .`, `isort .`, `ruff check --fix .`
+- Fix the specific style violation by editing the file
+- If using `patch`, make sure to match existing indentation style
+
+---
+
+### Type Check Failures (mypy / pyright)
+
+**Signatures in logs:**
+```
+src/api.py:23: error: Argument 1 to "process" has incompatible type "str"; expected "int"
+src/models.py:45: error: Missing return statement
+```
+
+**Diagnosis:**
+1. Read the file at the mentioned line
+2. Check the function signature and what's being passed
+
+**Common fixes:**
+- Add type cast or conversion
+- Fix the function signature
+- Add `# type: ignore` comment as last resort (with explanation)
+
+---
+
+### Build / Compilation Failures
+
+**Signatures in logs:**
+```
+ModuleNotFoundError: No module named 'some_package'
+ERROR: Could not find a version that satisfies the requirement foo==1.2.3
+npm ERR! Could not resolve dependency
+```
+
+**Diagnosis:**
+1. Check requirements.txt / package.json for the missing or incompatible dependency
+2. Compare local vs CI Python/Node version
+
+**Common fixes:**
+- Add missing dependency to requirements file
+- Pin compatible version
+- Update lockfile (`pip freeze`, `npm install`)
+
+---
+
+### Permission / Auth Failures
+
+**Signatures in logs:**
+```
+fatal: could not read Username for 'https://github.com': No such device or address
+Error: Resource not accessible by integration
+403 Forbidden
+```
+
+**Diagnosis:**
+1. Check if the workflow needs special permissions (token scopes)
+2. Check if secrets are configured (missing `GITHUB_TOKEN` or custom secrets)
+
+**Common fixes:**
+- Add `permissions:` block to workflow YAML
+- Verify secrets exist: `gh secret list` or check repo settings
+- For fork PRs: some secrets aren't available by design
+
+---
+
+### Timeout Failures
+
+**Signatures in logs:**
+```
+Error: The operation was canceled.
+The job running on runner ... has exceeded the maximum execution time
+```
+
+**Diagnosis:**
+1. Check which step timed out
+2. Look for infinite loops, hung processes, or slow network calls
+
+**Common fixes:**
+- Add timeout to the specific step: `timeout-minutes: 10`
+- Fix the underlying performance issue
+- Split into parallel jobs
+
+---
+
+### Docker / Container Failures
+
+**Signatures in logs:**
+```
+docker: Error response from daemon
+failed to solve: ... not found
+COPY failed: file not found in build context
+```
+
+**Diagnosis:**
+1. Check Dockerfile for the failing step
+2. Verify the referenced files exist in the repo
+
+**Common fixes:**
+- Fix path in COPY/ADD command
+- Update base image tag
+- Add missing file to `.dockerignore` exclusion or remove from it
+
+---
+
+## Auto-Fix Decision Tree
+
+```
+CI Failed
+├── Test failure
+│   ├── Assertion mismatch → update test or fix logic
+│   └── Import/module error → add dependency
+├── Lint failure → run formatter, fix style
+├── Type error → fix types
+├── Build failure
+│   ├── Missing dep → add to requirements
+│   └── Version conflict → update pins
+├── Permission error → update workflow permissions (needs user)
+└── Timeout → investigate perf (may need user input)
+```
+
+## Re-running After Fix
+
+```bash
+git add <fixed_files> && git commit -m "fix: resolve CI failure" && git push
+
+# Then monitor
+gh pr checks --watch 2>/dev/null || \
+  echo "Poll with: curl -s -H 'Authorization: token ...' https://api.github.com/repos/.../commits/$(git rev-parse HEAD)/status"
+```

package/.mindforge/skills/github-pr-workflow/references/conventional-commits.md

@@ -0,0 +1,71 @@
+# Conventional Commits Quick Reference
+
+Format: `type(scope): description`
+
+## Types
+
+| Type | When to use | Example |
+|------|------------|---------|
+| `feat` | New feature or capability | `feat(auth): add OAuth2 login flow` |
+| `fix` | Bug fix | `fix(api): handle null response from /users endpoint` |
+| `refactor` | Code restructuring, no behavior change | `refactor(db): extract query builder into separate module` |
+| `docs` | Documentation only | `docs: update API usage examples in README` |
+| `test` | Adding or updating tests | `test(auth): add integration tests for token refresh` |
+| `ci` | CI/CD configuration | `ci: add Python 3.12 to test matrix` |
+| `chore` | Maintenance, dependencies, tooling | `chore: upgrade pytest to 8.x` |
+| `perf` | Performance improvement | `perf(search): add index on users.email column` |
+| `style` | Formatting, whitespace, semicolons | `style: run black formatter on src/` |
+| `build` | Build system or external deps | `build: switch from setuptools to hatch` |
+| `revert` | Reverts a previous commit | `revert: revert "feat(auth): add OAuth2 login flow"` |
+
+## Scope (optional)
+
+Short identifier for the area of the codebase: `auth`, `api`, `db`, `ui`, `cli`, etc.
+
+## Breaking Changes
+
+Add `!` after type or `BREAKING CHANGE:` in footer:
+
+```
+feat(api)!: change authentication to use bearer tokens
+
+BREAKING CHANGE: API endpoints now require Bearer token instead of API key header.
+Migration guide: https://docs.example.com/migrate-auth
+```
+
+## Multi-line Body
+
+Wrap at 72 characters. Use bullet points for multiple changes:
+
+```
+feat(auth): add JWT-based user authentication
+
+- Add login/register endpoints with input validation
+- Add User model with argon2 password hashing
+- Add auth middleware for protected routes
+- Add token refresh endpoint with rotation
+
+Closes #42
+```
+
+## Linking Issues
+
+In the commit body or footer:
+
+```
+Closes #42          ← closes the issue when merged
+Fixes #42           ← same effect
+Refs #42            ← references without closing
+Co-authored-by: Name <email>
+```
+
+## Quick Decision Guide
+
+- Added something new? → `feat`
+- Something was broken and you fixed it? → `fix`
+- Changed how code is organized but not what it does? → `refactor`
+- Only touched tests? → `test`
+- Only touched docs? → `docs`
+- Updated CI/CD pipelines? → `ci`
+- Updated dependencies or tooling? → `chore`
+- Made something faster? → `perf`

package/.mindforge/skills/github-pr-workflow/templates/pr-body-bugfix.md

@@ -0,0 +1,35 @@
+## Bug Description
+
+<!-- What was happening? -->
+
+Fixes #
+
+## Root Cause
+
+<!-- What was causing the bug? -->
+
+## Fix
+
+<!-- What does this PR change to fix it? -->
+
+-
+
+## How to Verify
+
+<!-- Steps a reviewer can follow to confirm the fix -->
+
+1.
+2.
+3.
+
+## Test Plan
+
+- [ ] Added regression test for this bug
+- [ ] Existing tests still pass
+- [ ] Manual verification of the fix
+
+## Risk Assessment
+
+<!-- Could this fix break anything else? What's the blast radius? -->
+
+Low / Medium / High — <!-- explanation -->

package/.mindforge/skills/github-pr-workflow/templates/pr-body-feature.md

@@ -0,0 +1,33 @@
+## Summary
+
+<!-- 1-3 bullet points describing what this PR does -->
+
+-
+
+## Motivation
+
+<!-- Why is this change needed? Link to issue if applicable -->
+
+Closes #
+
+## Changes
+
+<!-- Detailed list of changes made -->
+
+-
+
+## Test Plan
+
+<!-- How was this tested? Checklist of verification steps -->
+
+- [ ] Unit tests pass (`pytest`)
+- [ ] Manual testing of new functionality
+- [ ] No regressions in existing behavior
+
+## Screenshots / Examples
+
+<!-- If UI changes or new output, show before/after -->
+
+## Notes for Reviewers
+
+<!-- Anything reviewers should pay special attention to -->

package/.mindforge/skills/incident-response/SKILL.md

@@ -3,7 +3,7 @@ name: incident-response
 version: 1.0.0
 min_mindforge_version: 0.3.0
 status: stable
-triggers: incident, outage, downtime, alert, pagerduty, oncall, on-call, postmortem, post-mortem, runbook, degraded, unavailable, error rate, p0, P0, p1, P1, rollback, hotfix, revert, emergency, spike, anomaly, SLA, SLO, SLI
+triggers: incident, outage, downtime, alert, pagerduty, oncall, on-call, postmortem, post-mortem, runbook, degraded, unavailable, error rate, p0, p1, rollback, hotfix, revert, emergency, spike, anomaly, SLA, SLO, SLI
 ---
 
 # Skill — Incident Response Engineering

package/.mindforge/skills/jupyter-live-kernel/SKILL.md

@@ -10,7 +10,7 @@ triggers: jupyter kernel, live jupyter, run jupyter, interactive notebook, jupyt
 # Jupyter Live Kernel (hamelnb)
 
 Gives you a **stateful Python REPL** via a live Jupyter kernel. Variables persist
-across executions. Use this instead of `execute_code` when you need to build up
+across executions. Use this instead of `Bash` when you need to build up
 state incrementally, explore APIs, inspect DataFrames, or iterate on complex code.
 
 ## When to Use This vs Other Tools
@@ -18,8 +18,8 @@ state incrementally, explore APIs, inspect DataFrames, or iterate on complex cod
 | Tool | Use When |
 |------|----------|
 | **This skill** | Iterative exploration, state across steps, data science, ML, "let me try this and check" |
-| `execute_code` | One-shot scripts needing hermes tool access (web_search, file ops). Stateless. |
-| `terminal` | Shell commands, builds, installs, git, process management |
+| `Bash` | One-shot scripts needing hermes tool access (WebSearch, file ops). Stateless. |
+| `Bash` | Shell commands, builds, installs, git, process management |
 
 **Rule of thumb:** If you'd want a Jupyter notebook for the task, use this skill.
 

package/.mindforge/skills/kanban-orchestrator/SKILL.md

@@ -9,7 +9,7 @@ triggers: kanban orchestrator, multi-agent kanban, decompose and route, orchestr
 
 # Kanban Orchestrator — Decomposition Playbook
 
-> The **core worker lifecycle** (including the `kanban_create` fan-out pattern and the "decompose, don't execute" rule) is auto-injected into every kanban process via the `KANBAN_GUIDANCE` system-prompt block. This skill is the deeper playbook when you're an orchestrator profile whose whole job is routing.
+> The **core worker lifecycle** (including the `TaskCreate` fan-out pattern and the "decompose, don't execute" rule) is auto-injected into every kanban process via the `KANBAN_GUIDANCE` system-prompt block. This skill is the deeper playbook when you're an orchestrator profile whose whole job is routing.
 
 ## Profiles are user-configured — not a fixed roster
 
@@ -38,7 +38,7 @@ Create Kanban tasks when any of these are true:
 5. **Review / iteration is expected.** A reviewer profile loops on drafter output.
 6. **The audit trail matters.** Board rows persist in SQLite forever.
 
-If *none* of those apply — it's a small one-shot reasoning task — use `delegate_task` instead or answer the user directly.
+If *none* of those apply — it's a small one-shot reasoning task — use `Agent` instead or answer the user directly.
 
 ## The anti-temptation rules
 
@@ -48,7 +48,7 @@ Your job description says "route, don't execute." The rules that enforce that:
 - **For any concrete task, create a Kanban task and assign it.** Every single time.
 - **Split multi-lane requests before creating cards.** A user prompt can contain several independent workstreams. Extract those lanes first, then create one card per lane instead of bundling unrelated work into a single implementer card.
 - **Run independent lanes in parallel.** If two cards do not need each other's output, leave them unlinked so the dispatcher can fan them out. Link only true data dependencies.
-- **Never create dependent work as independent ready cards.** If a card must wait for another card, pass `parents=[...]` in the original `kanban_create` call. Do not create it first and link it later, and do not rely on prose like "wait for T1" inside the body.
+- **Never create dependent work as independent ready cards.** If a card must wait for another card, pass `parents=[...]` in the original `TaskCreate` call. Do not create it first and link it later, and do not rely on prose like "wait for T1" inside the body.
 - **If no specialist fits the available profiles, ask the user which profile to create or which existing profile to use.** Do not invent profile names; the dispatcher will silently drop unknown assignees.
 - **Decompose, route, and summarize — that's the whole job.**
 
@@ -84,27 +84,27 @@ Show the graph to the user before creating cards. Let them correct it — includ
 Use the profile names from Step 0. The example below uses placeholders `<profile-A>`, `<profile-B>`, `<profile-C>` — replace them with what the user actually has.
 
 ```python
-t1 = kanban_create(
+t1 = TaskCreate(
     title="research: Postgres cost vs current",
     assignee="<profile-A>",  # whichever profile handles research on this setup
     body="Compare estimated infrastructure costs, migration costs, and ongoing ops costs over a 3-year window. Sources: AWS/GCP pricing, team time estimates, current Postgres bills from peers.",
     tenant=os.environ.get("HERMES_TENANT"),
 )["task_id"]
 
-t2 = kanban_create(
+t2 = TaskCreate(
     title="research: Postgres performance vs current",
     assignee="<profile-A>",  # same profile, run in parallel
     body="Compare query latency, throughput, and scaling characteristics at our expected data volume (~500GB, 10k QPS peak). Sources: benchmark papers, public case studies, pgbench results if easy.",
 )["task_id"]
 
-t3 = kanban_create(
+t3 = TaskCreate(
     title="synthesize migration recommendation",
     assignee="<profile-B>",  # whichever profile does synthesis/analysis
     body="Read the findings from T1 (cost) and T2 (performance). Produce a 1-page recommendation with explicit trade-offs and a go/no-go call.",
     parents=[t1, t2],
 )["task_id"]
 
-t4 = kanban_create(
+t4 = TaskCreate(
     title="draft decision memo",
     assignee="<profile-C>",  # whichever profile drafts user-facing prose
     body="Turn the analyst's recommendation into a 2-page memo for the CTO. Match the tone of previous decision memos in the team's knowledge base.",
@@ -114,7 +114,7 @@ t4 = kanban_create(
 
 `parents=[...]` gates promotion — children stay in `todo` until every parent reaches `done`, then auto-promote to `ready`. No manual coordination needed; the dispatcher and dependency engine handle it.
 
-If the task graph has dependencies, create the parent cards first, capture their returned ids, and include those ids in the child card's `parents` list during the child `kanban_create` call. Avoid creating all cards in parallel and linking them afterward; that creates a window where the dispatcher can claim a child before its inputs exist.
+If the task graph has dependencies, create the parent cards first, capture their returned ids, and include those ids in the child card's `parents` list during the child `TaskCreate` call. Avoid creating all cards in parallel and linking them afterward; that creates a window where the dispatcher can claim a child before its inputs exist.
 
 ### Step 4 — Complete your own task
 
@@ -174,14 +174,14 @@ Tell them what you created in plain prose, naming the actual profiles you used:
 
 **Don't pre-create the whole graph if the shape depends on intermediate findings.** If T3's structure depends on what T1 and T2 find, let T3 exist as a "synthesize findings" task whose own first step is to read parent handoffs and plan the rest. Orchestrators can spawn orchestrators.
 
-**Tenant inheritance.** If `HERMES_TENANT` is set in your env, pass `tenant=os.environ.get("HERMES_TENANT")` on every `kanban_create` call so child tasks stay in the same namespace.
+**Tenant inheritance.** If `HERMES_TENANT` is set in your env, pass `tenant=os.environ.get("HERMES_TENANT")` on every `TaskCreate` call so child tasks stay in the same namespace.
 
 ## Goal-mode cards (persistent workers)
 
 By default a dispatched worker gets **one shot** at its card: it does its work, calls `kanban_complete`/`kanban_block`, and exits. For open-ended cards where one turn rarely finishes the job, pass `goal_mode=True` to wrap that worker in a Ralph-style goal loop — the same engine behind the `/goal` slash command:
 
 ```python
-kanban_create(
+TaskCreate(
     title="Translate the full docs site to French",
     body="Acceptance: every page translated, no English left, links intact.",
     assignee="<translator-profile>",

package/.mindforge/skills/kanban-worker/SKILL.md

@@ -99,12 +99,12 @@ Shape `metadata` so downstream parsers (reviewers, aggregators, schedulers) can
 
 ## Claiming cards you actually created
 
-If your run produced new kanban tasks (via `kanban_create`), pass the ids in `created_cards` on `kanban_complete`. The kernel verifies each id exists and was created by your profile; any phantom id blocks the completion with an error listing what went wrong, and the rejected attempt is permanently recorded on the task's event log. **Only list ids you captured from a successful `kanban_create` return value — never invent ids from prose, never paste ids from earlier runs, never claim cards another worker created.**
+If your run produced new kanban tasks (via `TaskCreate`), pass the ids in `created_cards` on `kanban_complete`. The kernel verifies each id exists and was created by your profile; any phantom id blocks the completion with an error listing what went wrong, and the rejected attempt is permanently recorded on the task's event log. **Only list ids you captured from a successful `TaskCreate` return value — never invent ids from prose, never paste ids from earlier runs, never claim cards another worker created.**
 
 ```python
 # GOOD — capture return values, then claim them.
-c1 = kanban_create(title="remediate SQL injection", assignee="security-worker")
-c2 = kanban_create(title="fix CSRF middleware", assignee="web-worker")
+c1 = TaskCreate(title="remediate SQL injection", assignee="security-worker")
+c2 = TaskCreate(title="fix CSRF middleware", assignee="web-worker")
 
 kanban_complete(
     summary="Review done; spawned remediations for both findings.",
@@ -121,7 +121,7 @@ kanban_complete(
 )
 ```
 
-If a `kanban_create` call fails (exception, tool_error), the card was NOT created — do not include a phantom id for it. Retry the create, or omit the id and mention the failure in your summary. The prose-scan pass also catches `t_<hex>` references in your free-form summary that don't resolve; these don't block the completion but show up as advisory warnings on the task in the dashboard.
+If a `TaskCreate` call fails (exception, tool_error), the card was NOT created — do not include a phantom id for it. Retry the create, or omit the id and mention the failure in your summary. The prose-scan pass also catches `t_<hex>` references in your free-form summary that don't resolve; these don't block the completion but show up as advisory warnings on the task in the dashboard.
 
 ## Block reasons that get answered fast
 
@@ -164,7 +164,7 @@ You can configure the gateway to receive cross-profile Kanban task notifications
 
 ## Do NOT
 
-- Call `delegate_task` as a substitute for `kanban_create`. `delegate_task` is for short reasoning subtasks inside YOUR run; `kanban_create` is for cross-agent handoffs that outlive one API loop.
+- Call `Agent` as a substitute for `TaskCreate`. `Agent` is for short reasoning subtasks inside YOUR run; `TaskCreate` is for cross-agent handoffs that outlive one API loop.
 - Call `clarify` to ask the human a question. You are running headless — there is no live user to answer. The call will time out (default ~120s) and the task will sit silently in `running` with no signal that it needs input. Use `kanban_comment` (context) + `kanban_block(reason=...)` (decision needed) instead — the task surfaces on the board as blocked, the operator sees it, unblocks with their answer in a comment, and you respawn with the thread.
 - Modify files outside `$HERMES_KANBAN_WORKSPACE` unless the task body says to.
 - Create follow-up tasks assigned to yourself — assign to the right specialist.
@@ -184,7 +184,7 @@ Every tool has a CLI equivalent for human operators and scripts:
 - `kanban_show` ↔ `hermes kanban show <id> --json`
 - `kanban_complete` ↔ `hermes kanban complete <id> --summary "..." --metadata '{...}'`
 - `kanban_block` ↔ `hermes kanban block <id> "reason"`
-- `kanban_create` ↔ `hermes kanban create "title" --assignee <profile> [--parent <id>]`
+- `TaskCreate` ↔ `hermes kanban create "title" --assignee <profile> [--parent <id>]`
 - etc.
 
 Use the tools from inside an agent; the CLI exists for the human at the terminal.

package/.mindforge/skills/meme-generation/SKILL.md

@@ -52,7 +52,7 @@ python "$SKILL_DIR/scripts/generate_meme.py" --search "disaster"
 3. Write short captions for each field (8-12 words max per field, shorter is better).
 4. Find the skill's script directory:
    ```
-   SKILL_DIR=$(dirname "$(find ~/.hermes/skills -path '*/meme-generation/SKILL.md' 2>/dev/null | head -1)")
+   SKILL_DIR=$(dirname "$(find ~/.mindforge/skills -path '*/meme-generation/SKILL.md' 2>/dev/null | head -1)")
    ```
 5. Run the generator:
    ```bash