semantu-agents 1.1.0 → 1.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "semantu-agents",
-  "version": "1.1.0",
+  "version": "1.2.0",
   "description": "Reusable Claude Code skills and hooks for Semantu projects",
   "type": "module",
   "bin": {

package/skills/public/ideation/SKILL.md

@@ -17,7 +17,9 @@ Run this mode only after the user explicitly confirms ideation mode for the curr
 
 ### 1. Understand context
 
-Read relevant code, tests, and docs. Summarise the problem space and goals back to the user in chat to confirm shared understanding.
+Spawn one or more subagents to explore the codebase concurrently. Give each subagent a focused research question — e.g. "find all files related to authentication and summarize the current flow", "read the test suite for module X and report what it covers". Do not read large files or trace dependencies directly in the main agent; let subagents do the heavy lifting and report back.
+
+Synthesize subagent findings into the Context section of the ideation doc. Summarise the problem space and goals back to the user in chat to confirm shared understanding.
 
 ### 2. Create the ideation document
 
@@ -67,6 +69,8 @@ For each decision point, present in chat:
 
 **Progress indicator:** Always tell the user where they are — e.g. "Decision 2 of 5" or "Gap 3 of 4" — so they know how many remain before the next mode.
 
+When assessing the viability of a specific approach requires reading code or checking feasibility, spawn a research subagent for that investigation and incorporate its findings into the discussion. Do not spawn subagents for the creative work of generating approaches — that stays with the main agent.
+
 Wait for the user's input before moving to the next decision. Do not batch multiple decisions into one message.
 
 ### 5. Record as you go

package/skills/public/review/SKILL.md

@@ -17,6 +17,12 @@ Run only when the user explicitly confirms review mode.
 4. Identify gaps or risks in the current implementation.
 5. Identify likely future work required for fuller completeness.
 
+## Parallel review via subagents
+
+When the implementation spans multiple modules or many files, spawn subagents to review different areas concurrently. For example: one agent reviews API surface correctness, another checks test coverage against the plan, another checks for dead code or missing error handling.
+
+Each review subagent receives: the relevant plan section, the list of files in its review area, and the specific review questions to answer. Subagents report findings; the main agent synthesizes results into the gap list presented to the user.
+
 ## Output
 
 Review findings must be emitted in chat first.

package/skills/public/tasks/SKILL.md

@@ -27,6 +27,7 @@ Phases should be designed for maximum parallelism — different agents may imple
 - **Stub boundaries**: When a phase depends on another phase's output, note what stubs or mocks are needed so it can proceed independently. For example: "Agent B can stub `irToAlgebra()` with hand-crafted algebra objects to test `algebraToString()` independently."
 - **Mark parallel groups**: Use explicit notation in the task breakdown to indicate which phases can run simultaneously. For example: "Phase 2a, 2b, 2c can run in parallel after Phase 1."
 - **Integration phase last**: After all parallel phases complete, include an explicit integration phase that: (1) replaces stubs with real wiring between components, (2) verifies all parts compile and work together, (3) runs end-to-end / golden tests that exercise the full pipeline. This phase must be planned even when stubs seem trivial — it catches type mismatches, import issues, and cross-component edge cases that unit tests miss.
+- **Subagent-ready descriptions**: Each phase description must be self-contained enough to serve as a subagent prompt without needing to re-read the plan or gather additional context. Include: file paths to create/modify, types/contracts it depends on, stubs to use for dependencies on other phases, validation commands with expected results, and any relevant code snippets or patterns to follow.
 
 ## Validation specification
 

package/skills/public/wrapup/SKILL.md

@@ -14,7 +14,7 @@ Also treat any user request to prepare/open/update a PR, or draft PR title/body/
 
 ### Code review pass (do this FIRST, before report/commit/PR)
 
-1. **Review all changes on the current branch** by diffing against the base branch (e.g. `git diff main...HEAD`). Read through every changed file.
+1. **Review all changes on the current branch** by diffing against the base branch (e.g. `git diff main...HEAD`). Read through every changed file. For branches with many changed files, spawn subagents to review different file groups concurrently — each subagent gets its list of files, what to check (readability, dead code, comment quality), and the context of what was implemented. Subagents report issues found; the main agent applies fixes and makes final judgment calls.
 2. **Readability check** — for each changed file, verify the code is readable and easy to follow. Add comments wherever the logic isn't self-evident: non-obvious algorithms, workarounds, important constraints, "why" behind a choice.
 3. **Remove dead code** related to the implemented scope.
 4. Consolidate remaining tradeoffs/choices into final decisions made and rationale.