@prismer/runtime 2.2.55 → 2.2.63

package/built-in-skills/tasks/SKILL.md

@@ -13,7 +13,7 @@ Use this skill to drive the **workspace Kanban** end-to-end. Tasks are durable b
 When the user asks you to **assign / delegate / hand off** work to ANOTHER agent (e.g. "create kanban tasks and assign to @research-agent", "give this to Bob"):
 
 1. **Call `cloud task create --assignee-name <agent>` (or `--assignee-id`).** That is the ONLY legitimate delegation path. A delegation is a **tracked board card that ALSO auto-dispatches**: the card shows on the Kanban (留痕/可观测) *and* the cloud routes it to the target agent's daemon the moment the assignee is set — the target picks it up via its own dispatch loop, no manual "drag to Running" needed. (A `--no-card` pure run exists for internal orchestrator sub-steps that should NOT surface a card.)
-2. **STOP** as soon as `cloud task create` returns task IDs. Reply to the user with the IDs / titles. **Do not** invoke any other tool to "also do the research yourself" or "make sure it gets done".
+2. **For a delegation-only request, stop after reporting the returned IDs / titles.** If the user also requested orchestration, follow-through, or result collection, continue read-only status/result collection with bounded waits as described below. Never duplicate the assignee's work yourself.
 3. **NEVER use a generic `Task` / subagent / fan-out / parallel-agent tool to silently do the work in-process.** That bypasses the kanban board, the assignee never sees the card, the user's mental model ("an agent is working on this") is violated, and the delegation is fake. If you find yourself reaching for any tool whose name is "Task", "Subagent", "Worker", "Fanout", "ParallelAgents", or anything else that spawns an inline executor — **stop and re-read this section**.
 4. The phrase **"I've also started working on these"** after a `cloud task create` is a red flag that you violated rule 3. The correct phrase is **"Tasks created and assigned. @research-agent will pick up the cards."**
 
@@ -26,7 +26,7 @@ This is non-negotiable. Bypassing it makes the agent ecosystem look broken even
 - **要看结果，你必须主动拉**：`cloud task get <taskId>` 读 `status` / `result` / 附件。`status=completed` 才算交付；`review` 等你 approve/reject。
 - **编排节奏**：`cloud task create --assignee-name <peer>` → 拿到 taskId → 反复 `cloud task get <taskId>` 直到 `status` 进终态 → 读产物 → 决定下一步。（有 `cloud task wait <id>` 时优先用它，省手搓轮询。）
 - **「看不到对方回复 ≠ 它没在干」**。被派 agent 沉默是正常的——它在独立 context 里跑，结果只在卡上。**绝不要**因为对话里没动静就自己把活重做一遍（那就是影子执行，违反上面的 Hard rules）。
-- 派完先停、把 taskId 报给用户；之后用 `cloud task get` 跟进，而不是把委派和自办混在一条回复里。
+- 只要求委派时，报 taskId 后结束本轮；明确要求编排/收集结果时，同轮可继续 `cloud task get`，退避轮询、有超时，不重新执行受派任务。不要自行安排未来轮询或声称已有后台监控。
 
 ## When to use
 

package/built-in-skills/tdd/SKILL.md

@@ -1,10 +1,17 @@
 ---
 name: tdd
 scope: coding
+metadata:
+  nativeReplaces: [test-driven-development]
 source: https://github.com/mattpocock/skills (MIT, © 2026 Matt Pocock)
 description: Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
 ---
 
+For additional red/green examples, read references/test-driven-development/GUIDE.md.
+Use the repository's test runner and verify the failing assertion before changing
+production code. Treat upstream tool names and repository paths as examples,
+not available tools or bundled files.
+
 # Test-Driven Development
 
 ## Philosophy

package/built-in-skills/tdd/references/test-driven-development/GUIDE.md

@@ -0,0 +1,356 @@
+---
+name: test-driven-development
+description: "TDD: enforce RED-GREEN-REFACTOR, tests before code."
+version: 1.1.0
+author: Hermes Agent (adapted from obra/superpowers)
+license: MIT
+platforms: [linux, macos, windows]
+metadata:
+  hermes:
+    tags: [testing, tdd, development, quality, red-green-refactor]
+    related_skills: [systematic-debugging, subagent-driven-development]
+---
+
+# Test-Driven Development (TDD)
+
+## Overview
+
+Write the test first. Watch it fail. Write minimal code to pass.
+
+**Core principle:** If you didn't watch the test fail, you don't know if it tests the right thing.
+
+**Violating the letter of the rules is violating the spirit of the rules.**
+
+## When to Use
+
+**Always:**
+- New features
+- Bug fixes
+- Refactoring
+- Behavior changes
+
+**Choose risk-appropriate validation within the user's existing authorization:**
+- Throwaway prototypes
+- Generated code
+- Configuration files
+
+Thinking "skip TDD just this once"? Stop. That's rationalization.
+
+## The Iron Law
+
+```
+NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+```
+
+For new behavior, observe a meaningful failing test before implementation.
+For existing or user-owned code, preserve it and add a focused regression test;
+use an isolated negative control to prove the test detects the defect. Never
+delete prior work to satisfy a testing ritual, and do not stage or commit unless
+the user's task explicitly requests it.
+
+## Red-Green-Refactor Cycle
+
+### RED — Write Failing Test
+
+Write one minimal test showing what should happen.
+
+**Good test:**
+```python
+def test_retries_failed_operations_3_times():
+    attempts = 0
+    def operation():
+        nonlocal attempts
+        attempts += 1
+        if attempts < 3:
+            raise Exception('fail')
+        return 'success'
+
+    result = retry_operation(operation)
+
+    assert result == 'success'
+    assert attempts == 3
+```
+Clear name, tests real behavior, one thing.
+
+**Bad test:**
+```python
+def test_retry_works():
+    mock = MagicMock()
+    mock.side_effect = [Exception(), Exception(), 'success']
+    result = retry_operation(mock)
+    assert result == 'success'  # What about retry count? Timing?
+```
+Vague name, tests mock not real code.
+
+**Requirements:**
+- One behavior per test
+- Clear descriptive name ("and" in name? Split it)
+- Real code, not mocks (unless truly unavoidable)
+- Name describes behavior, not implementation
+
+### Verify RED — Watch It Fail
+
+**MANDATORY. Never skip.**
+
+```bash
+# Use terminal tool to run the specific test
+pytest tests/test_feature.py::test_specific_behavior -v
+```
+
+Confirm:
+- Test fails (not errors from typos)
+- Failure message is expected
+- Fails because the feature is missing
+
+**Test passes immediately?** You're testing existing behavior. Fix the test.
+
+**Test errors?** Fix the error, re-run until it fails correctly.
+
+### GREEN — Minimal Code
+
+Write the simplest code to pass the test. Nothing more.
+
+**Good:**
+```python
+def add(a, b):
+    return a + b  # Nothing extra
+```
+
+**Bad:**
+```python
+def add(a, b):
+    result = a + b
+    logging.info(f"Adding {a} + {b} = {result}")  # Extra!
+    return result
+```
+
+Don't add features, refactor other code, or "improve" beyond the test.
+
+**Cheating is OK in GREEN:**
+- Hardcode return values
+- Copy-paste
+- Duplicate code
+- Skip edge cases
+
+We'll fix it in REFACTOR.
+
+### Verify GREEN — Watch It Pass
+
+**MANDATORY.**
+
+```bash
+# Run the specific test
+pytest tests/test_feature.py::test_specific_behavior -v
+
+# Then run ALL tests to check for regressions
+pytest tests/ -q
+```
+
+Confirm:
+- Test passes
+- Other tests still pass
+- Output pristine (no errors, warnings)
+
+**Test fails?** Fix the code, not the test.
+
+**Other tests fail?** Fix regressions now.
+
+### REFACTOR — Clean Up
+
+After green only:
+- Remove duplication
+- Improve names
+- Extract helpers
+- Simplify expressions
+
+Keep tests green throughout. Don't add behavior.
+
+**If tests fail during refactor:** Undo immediately. Take smaller steps.
+
+### Repeat
+
+Next failing test for next behavior. One cycle at a time.
+
+## Avoid Horizontal Slices
+
+Do **not** write all tests first and then all implementation. That is horizontal slicing: RED becomes "write a pile of imagined tests" and GREEN becomes "make the pile pass." It produces brittle tests because the tests are designed before the implementation has taught you what behavior and interface actually matter.
+
+Use vertical tracer bullets instead:
+
+```text
+WRONG:
+  RED:   test1, test2, test3, test4
+  GREEN: impl1, impl2, impl3, impl4
+
+RIGHT:
+  RED→GREEN: test1→impl1
+  RED→GREEN: test2→impl2
+  RED→GREEN: test3→impl3
+```
+
+A tracer bullet is one end-to-end behavior slice. It proves the path works, teaches you about the interface, and keeps each next test grounded in what you just learned.
+
+## Why Order Matters
+
+**"I'll write tests after to verify it works"**
+
+Tests written after code pass immediately. Passing immediately proves nothing:
+- Might test the wrong thing
+- Might test implementation, not behavior
+- Might miss edge cases you forgot
+- You never saw it catch the bug
+
+Test-first forces you to see the test fail, proving it actually tests something.
+
+**"I already manually tested all the edge cases"**
+
+Manual testing is ad-hoc. You think you tested everything but:
+- No record of what you tested
+- Can't re-run when code changes
+- Easy to forget cases under pressure
+- "It worked when I tried it" ≠ comprehensive
+
+Automated tests are systematic. They run the same way every time.
+
+**"Deleting X hours of work is wasteful"**
+
+Existing work may belong to the user or another task. Preserve it. Add a
+regression test and demonstrate a meaningful negative control in isolation;
+report what is known versus not yet verified. Deletion is not a test strategy.
+
+**"TDD is dogmatic, being pragmatic means adapting"**
+
+TDD IS pragmatic:
+- Finds bugs before commit (faster than debugging after)
+- Prevents regressions (tests catch breaks immediately)
+- Documents behavior (tests show how to use code)
+- Enables refactoring (change freely, tests catch breaks)
+
+"Pragmatic" shortcuts = debugging in production = slower.
+
+**"Tests after achieve the same goals — it's spirit not ritual"**
+
+No. Tests-after answer "What does this do?" Tests-first answer "What should this do?"
+
+Tests-after are biased by your implementation. You test what you built, not what's required. Tests-first force edge case discovery before implementing.
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
+| "I'll test after" | Tests passing immediately prove nothing. |
+| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
+| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
+| "Existing code has no test" | Preserve it and demonstrate a regression test with an isolated negative control. |
+| "Keep as reference, write tests first" | Distinguish existing behavior from a new implementation; record which validation was actually performed. |
+| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
+| "Test hard = design unclear" | Listen to the test. Hard to test = hard to use. |
+| "TDD will slow me down" | TDD faster than debugging. Pragmatic = test-first. |
+| "Manual test faster" | Manual doesn't prove edge cases. You'll re-test every change. |
+| "Existing code has no tests" | You're improving it. Add tests for the code you touch. |
+
+## Red Flags — STOP and Start Over
+
+If you catch yourself doing any of these, stop and repair the verification gap:
+
+- Code before test
+- Test after implementation
+- Test passes immediately on first run
+- Can't explain why test failed
+- Tests added "later"
+- Rationalizing "just this once"
+- "I already manually tested it"
+- "Tests after achieve the same purpose"
+- "Keep as reference" or "adapt existing code"
+- "Already spent X hours, deleting is wasteful"
+- "TDD is dogmatic, I'm being pragmatic"
+- "This is different because..."
+
+**Preserve existing changes. Add missing tests and demonstrate their sensitivity.**
+
+## Verification Checklist
+
+Before marking work complete:
+
+- [ ] Every new function/method has a test
+- [ ] Watched each test fail before implementing
+- [ ] Each test failed for expected reason (feature missing, not typo)
+- [ ] Wrote minimal code to pass each test
+- [ ] All tests pass
+- [ ] Output pristine (no errors, warnings)
+- [ ] Tests use real code (mocks only if unavoidable)
+- [ ] Edge cases and errors covered
+
+If a box cannot be checked, name the gap and its risk; do not fabricate RED evidence.
+
+## When Stuck
+
+| Problem | Solution |
+|---------|----------|
+| Don't know how to test | Write the wished-for API. Write the assertion first. Ask the user. |
+| Test too complicated | Design too complicated. Simplify the interface. |
+| Must mock everything | Code too coupled. Use dependency injection. |
+| Test setup huge | Extract helpers. Still complex? Simplify the design. |
+
+## Hermes Agent Integration
+
+### Running Tests
+
+Use the `terminal` tool to run tests at each step:
+
+```python
+# RED — verify failure
+terminal("pytest tests/test_feature.py::test_name -v")
+
+# GREEN — verify pass
+terminal("pytest tests/test_feature.py::test_name -v")
+
+# Full suite — verify no regressions
+terminal("pytest tests/ -q")
+```
+
+### With delegate_task
+
+When dispatching subagents for implementation, enforce TDD in the goal:
+
+```python
+delegate_task(
+    goal="Implement [feature] using strict TDD",
+    context="""
+    Follow test-driven-development skill:
+    1. Write failing test FIRST
+    2. Run test to verify it fails
+    3. Write minimal code to pass
+    4. Run test to verify it passes
+    5. Refactor if needed
+    6. Report scoped changes and actual verification; do not auto-commit
+
+    Project test command: pytest tests/ -q
+    Project structure: [describe relevant files]
+    """,
+    toolsets=['terminal', 'file']
+)
+```
+
+### With systematic-debugging
+
+Bug found? Write failing test reproducing it. Follow TDD cycle. The test proves the fix and prevents regression.
+
+Never fix bugs without a test.
+
+## Testing Anti-Patterns
+
+- **Testing mock behavior instead of real behavior** — mocks should verify interactions, not replace the system under test
+- **Testing implementation details** — test behavior/results, not internal method calls
+- **Happy path only** — always test edge cases, errors, and boundaries
+- **Brittle tests** — tests should verify behavior, not structure; refactoring shouldn't break them
+
+## Final Rule
+
+```
+Production code → test exists and failed first
+Otherwise → not TDD
+```
+
+Use the user's existing task authorization; ask only when a missing decision materially changes scope.

package/built-in-skills/tdd/references/test-driven-development/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Nous Research
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/built-in-skills/tdd/references/test-driven-development/LICENSE.superpowers

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Jesse Vincent
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/built-in-skills/tdd/references/test-driven-development/NOTICE.md

@@ -0,0 +1,37 @@
+MIT License
+
+Copyright (c) 2025 Nous Research
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+## Engineering adaptation (2026-09-23)
+
+Source: https://github.com/NousResearch/hermes-agent/tree/1a1f4a59e252e1dc0137e7b2e7bcc8b0381d19c4/skills/software-development/test-driven-development
+
+Upstream authors: Hermes Agent; obra/superpowers (Jesse Vincent).
+Hermes MIT copyright (c) 2025 Nous Research is preserved in LICENSE.
+All bundled references/templates/scripts remain covered by that notice unless
+an additional license is explicitly supplied. External CLI binaries, services,
+accounts and downloaded assets are not redistributed by this skill and retain
+their own terms. No API keys or third-party runtime packages are bundled.
+
+Prismer modifications: unique discovery/ownership mapping where applicable,
+resource-path and authorization corrections, bounded helpers, honest readiness
+and verification states. See docs/bugfix223/implementation-engineering.md in the
+source repository for resource mapping, tests and remaining live acceptance.

package/built-in-skills/team/SKILL.md

@@ -10,7 +10,7 @@ Use this skill when work needs another human in the loop. The workspace + projec
 
 ## ⛔ Hard rules — human-in-loop
 
-1. **Never auto-send an invite.** Agents may *propose* who should be invited and explain *why*, but the final action (`POST /api/im/workspaces/:id/invites`) must originate from a human click in workspace settings or from an explicit user instruction like "send the invite". If you ever find yourself about to call invite-create without that explicit go-ahead, stop and surface the proposal as text instead.
+1. **Never auto-send an invite.** Agents may propose who should be invited and why. This skill's supported route for the final action is the human click in workspace settings. Even when the user asks to send an invite, route them to that UI; do not invent an invite CLI or bypass the supported confirmation path with a raw endpoint.
 2. **Never expose member emails.** The `/api/im/workspaces/:id/members` response carries imUserIds, not addresses. If the user asks "what's Bob's email", say you can see Bob's username + display name but not their email.
 3. **Distinguish workspace member from project member.** Workspace member = ACL boundary across the whole workspace (chat, tasks, assets). Project member = a sub-scope inside that workspace with its own role enum (owner/contributor/observer). Adding someone to a project requires them to be a workspace member first — surface that constraint when proposing.
 4. **Never silently re-add a removed member.** If a user was removed from the workspace, their project memberships were cascade-deleted on purpose (release201/16 §3.2.3). Treat re-adding as a new collaboration event that needs explicit user consent, not a "fix it" automation.

package/built-in-skills/web-artifacts-builder/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: web-artifacts-builder
 scope: coding
-description: Suite of tools for creating elaborate, multi-component claude.ai HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, or shadcn/ui components - not for simple single-file HTML/JSX artifacts.
+description: Suite of tools for creating elaborate, multi-component Prismer HTML artifacts using modern frontend web technologies (React, Tailwind CSS, shadcn/ui). Use for complex artifacts requiring state management, routing, or shadcn/ui components - not for simple single-file HTML/JSX artifacts.
 license: Complete terms in LICENSE.txt
 ---
 
@@ -28,7 +28,7 @@ registers the asset so the chat renderer can offer a preview/open button.
 
 # Web Artifacts Builder
 
-To build powerful frontend claude.ai artifacts, follow these steps:
+To build powerful frontend Prismer artifacts, follow these steps:
 1. Initialize the frontend repo using `scripts/init-artifact.sh`
 2. Develop your artifact by editing the generated code
 3. Bundle all code into a single HTML file using `scripts/bundle-artifact.sh`
@@ -80,7 +80,7 @@ To bundle the React app into a single HTML artifact:
 bash scripts/bundle-artifact.sh
 ```
 
-This creates `bundle.html` - a self-contained artifact with all JavaScript, CSS, and dependencies inlined. This file can be directly shared in Claude conversations as an artifact.
+This creates `bundle.html` - a self-contained artifact with all JavaScript, CSS, and dependencies inlined. This file can be directly shared in Prismer conversations as an artifact.
 
 **Requirements**: Your project must have an `index.html` in the root directory.
 

package/built-in-skills/web-artifacts-builder/scripts/bundle-artifact.sh

@@ -1,5 +1,5 @@
 #!/bin/bash
-set -e
+set -euo pipefail
 
 echo "📦 Bundling React app to single HTML artifact..."
 
@@ -31,17 +31,19 @@ if [ ! -f ".parcelrc" ]; then
 EOF
 fi
 
-# Clean previous build
-echo "🧹 Cleaning previous build..."
-rm -rf dist bundle.html
+# Only clean the directory created by this invocation.
+BUILD_DIR=$(mktemp -d "./.artifact-build.XXXXXX")
+trap 'rm -rf -- "$BUILD_DIR"' EXIT
 
 # Build with Parcel
 echo "🔨 Building with Parcel..."
-pnpm exec parcel build index.html --dist-dir dist --no-source-maps
+pnpm exec parcel build index.html --dist-dir "$BUILD_DIR/dist" --no-source-maps
 
 # Inline everything into single HTML
 echo "🎯 Inlining all assets into single HTML file..."
-pnpm exec html-inline dist/index.html > bundle.html
+pnpm exec html-inline "$BUILD_DIR/dist/index.html" > "$BUILD_DIR/bundle.html"
+test -s "$BUILD_DIR/bundle.html"
+mv -- "$BUILD_DIR/bundle.html" bundle.html
 
 # Get file size
 FILE_SIZE=$(du -h bundle.html | cut -f1)
@@ -51,4 +53,4 @@ echo "✅ Bundle complete!"
 echo "📄 Output: bundle.html ($FILE_SIZE)"
 echo ""
 echo "You can now use this single HTML file as an artifact in Claude conversations."
-echo "To test locally: open bundle.html in your browser"
+echo "To test locally: open bundle.html in your browser"