cowork-flow 0.0.37 → 0.0.39

package/template/skills/party-mode-v2/SKILL.md

@@ -1,75 +0,0 @@
----
-name: party-mode-v2
-description: Use when the user requests a runtime-controlled multi-agent board discussion where children communicate through Party Mode V2 board APIs and the moderator only monitors or corrects drift.
----
-
-# Party Mode V2
-
-Use this skill as a thin entrypoint for the Party Mode V2 runtime board. The Python runtime is the source of truth for discussion state, board visibility, validation, round limits, and final reports.
-
-**Related:** [Party Mode](../party-mode/SKILL.md) -- manual advisory roundtable where the coordinator directly orchestrates child agents and synthesizes their output.
-
-## Boundaries
-
-See [SHARED-BOUNDARIES.md](../party-mode/SHARED-BOUNDARIES.md) for common boundaries and advisory limits.
-
-- The moderator does not forward, summarize, rewrite, or synthesize child opinions for other child agents.
-
-## Runtime First
-
-Always use the runtime controller:
-
-```text
-.cowork-flow/run party-v2 init
-.cowork-flow/run party-v2 monitor
-.cowork-flow/run party-v2 view
-.cowork-flow/run party-v2 post
-.cowork-flow/run party-v2 respond
-.cowork-flow/run party-v2 advance
-.cowork-flow/run party-v2 record-action-result
-.cowork-flow/run party-v2 finalize
-```
-
-Do not bypass a runtime rejection by manually accepting child output. Runtime validation failures must be fixed by a corrected child submission or by ending the discussion.
-
-## Board Rules
-
-- Child agents communicate through the board API.
-- Child-visible board output must be current-round only.
-- Historical board state is runtime-private and may be used only for audit or final reports.
-- Use at least three child agents unless the effective runtime config explicitly allows a different value.
-- The runtime emits host-neutral next actions. The active Host Adapter or moderator executes them for Codex, Claude Code, or OpenCode.
-- Host action results must be recorded back through `record-action-result` so `agents.json`, audit logs, and action history can prove lifecycle state.
-
-## Child Response Rules
-
-When a child sees a different position, it must choose exactly one:
-
-```text
-maintain
-revise
-concede
-```
-
-`concede` requires accepted evidence and why the prior position failed.
-`revise` requires the accepted part, rejected part, and updated position.
-`maintain` requires counter evidence or counter reasoning.
-
-Unsupported agreement, vague revision, and evidence-free rebuttal are invalid.
-
-## Moderator Role
-
-The moderator may:
-
-- run runtime commands,
-- execute host-neutral next actions through the active host,
-- record off-topic warnings through the runtime,
-- close children only when the runtime asks for closeout,
-- show runtime status or final reports to the user.
-
-The moderator must not:
-
-- forward one child opinion to another child,
-- create a claim table for child prompts,
-- vote-count as validation,
-- decide which child is correct.

package/template/skills/start/SKILL.md

@@ -1,78 +0,0 @@
----
-name: start
-description: Use when starting or resuming main-session work in a cowork-flow project, after context compression, or before repository changes.
----
-
-# Start
-
-This skill is for the main session only. Formal subagents are accepted only after runtime context binding is recorded and must not load this startup flow.
-Main repository changes follow `Plan -> Implement -> Check -> Finish`.
-Before loading state, classify only whether the current request is a
-main-session request, read-only question, command-only wrapper, or unclear
-input. Do not infer subagent identity from prompt shape. If a child has
-`cowork_runtime_context_id`, hook/plugin binding may run early; otherwise the
-child must run the explicit shim bind before formal work.
-
-## Load State
-
-1. Read `AGENTS.md`.
-2. Read `.cowork-flow/workflow.md`.
-3. Read `.cowork-flow/config.yaml` for Codex dispatch hints and lifecycle hooks.
-4. Run `.cowork-flow/run resume` or `.\.cowork-flow\run.cmd resume` on Windows.
-5. Read the active task decision-anchor.md and JSONL indexes only when a task is active.
-6. Read relevant `.cowork-flow/spec/*/index.md` files before code changes.
-
-Report active task, workflow state, blockers, and the next phase.
-
-## Route
-
-Route in stages. Before state is loaded, true question-only requests may bypass
-Load State. Repository-changing main-session requests load state first. After
-state is loaded, apply the requirement clarification gate from
-`.cowork-flow/workflow.md`, then route to the next workflow phase; clear
-multi-step implementation uses `writing-plans` before fixed-agent dispatch.
-
-New requirements that are unclear, boundary-unclear, multi-approach, behavior-changing, or missing acceptance criteria use `brainstorming` before writing decision-anchor.md, planning, or fixed-agent dispatch. Small repository changes proceed directly only when the goal, scope boundary, and acceptance criteria are already clear.
-
-- Question-only work: answer directly.
-- Small repository change with clear goal/scope/acceptance: classify by `.cowork-flow/workflow.md`, create/start a task if required, then proceed.
-- Unclear, boundary-unclear, behavior-changing, or multi-approach work: use `brainstorming`.
-- Multi-step implementation: use `writing-plans`, then dispatch fixed agents where appropriate.
-- Before coding: use `before-dev`.
-- After implementation: use `check`, then `finish-work`.
-
-## Parallel Route
-
-- Use parallel sessions for independent tasks.
-- Use a separate `git worktree` when independent sessions may write files.
-- Inside one task, dispatch parallel agents only for low-conflict slices with clear ownership.
-- After parallel slices finish, run final integrated verification before Check/Finish.
-
-## Fixed Agents
-
-The main session owns coordination:
-
-- Research: dispatch `cowork-research` through the active Host Adapter.
-- Implementation: dispatch `cowork-implement` through the active Host Adapter.
-- Verification: dispatch `cowork-check` through the active Host Adapter.
-
-Every formal dispatch uses runtime-context dispatch:
-
-```text
-cowork_runtime_context_id: <runtime_context_id>
-cowork_host_context_key: <host_context_key>
-```
-
-Before spawning a formal child, create a runtime context with
-`.cowork-flow/run subagent init` and pass the returned prompt transport through
-the active Host Adapter. The child's first step is
-`.cowork-flow/run subagent bind <runtime_context_id> <host_context_key>`; if a
-hook/plugin already bound the same key, this command is idempotent. The parent
-must verify `status=bound` and `bound_context_key=<host_context_key>` before
-accepting output. If binding is missing, closed, invalid, or mismatched, the
-child fails closed and must not run start/resume/task activation/archive/commit
-or coordinate other agents.
-
-After dispatch, use adapter wait/list/cancel primitives, review the output,
-verify deliverables, and close the runtime context with
-`.cowork-flow/run subagent close <runtime_context_id>`.

package/template/skills/tdd/SKILL.md

@@ -1,74 +0,0 @@
----
-name: tdd
-description: Use when implementing behavior changes, bug fixes, state transitions, protocols, CLI/runtime contracts, data format changes, or error handling that can be tested before implementation.
----
-
-# TDD
-
-Use this before editing behavior-changing code.
-
-## Red-Green-Refactor
-
-1. Map the task decision-anchor.md acceptance criteria to stable IDs such as `AC-001`.
-2. Write the smallest meaningful failing test first.
-3. Run the red command and confirm it fails because the target behavior is missing or wrong.
-4. Implement the smallest change that makes the behavior pass.
-5. Run the green command and relevant broader verification.
-6. Refactor only after the behavior is green.
-
-Do not count shallow tests as TDD evidence. Tests that only import code, assert a function exists, assert `True`, count mocks without behavior, or mirror implementation details do not satisfy red-green-refactor.
-
-## Evidence
-
-Record TDD proof in `<task>/tdd.jsonl`. Each evidence line is one JSON object:
-
-```json
-{
-  "acceptanceId": "AC-001",
-  "testFile": "tests/test_example.py",
-  "testName": "test_behavior",
-  "redCommand": "python -m unittest tests.test_example.TestCase.test_behavior -v",
-  "redExitCode": 1,
-  "redOutputExcerpt": "expected failure excerpt",
-  "failureReason": "target behavior was not implemented",
-  "whyThisTestMatters": "explains which user-visible behavior would regress",
-  "greenCommand": "python -m unittest tests.test_example.TestCase.test_behavior -v",
-  "greenExitCode": 0,
-  "broaderVerification": "python -m unittest tests.test_example -v"
-}
-```
-
-Every evidence record must map to a decision-anchor.md `acceptanceId`. The red failure must be about the target behavior, not syntax, import, environment, fixture, or setup failure.
-
-`testName` must resolve to the exact behavior test in `testFile`. Use one of:
-`test_method`, `ClassName.test_method`, or `module.ClassName.test_method`.
-Do not point evidence at a class, module, or a name that only exists in a command string.
-
-## Exemption
-
-Pure documentation, comment-only, or formatting-only tasks may use an exemption record instead of red/green evidence:
-
-```json
-{
-  "type": "exemption",
-  "acceptanceId": "AC-001",
-  "exemptionType": "docs-only",
-  "reason": "Only documentation wording changed; runtime behavior is untouched.",
-  "verificationCommand": "git diff --check"
-}
-```
-
-Do not use an exemption for runtime, CLI, protocol, state, data format, permission, or error-handling changes.
-
-## Anti-Rationalization
-
-> The following excuses do not exempt the TDD evidence requirement. Each has an actionable alternative.
-
-| Agent psychology | Rebuttal | Alternative |
-|---|---|---|
-| "This logic is simple, no test needed" | Simple logic also breaks on edge cases and later modifications. Simplicity is not grounds to skip evidence. | Write a coverage test asserting core behavior — takes < 2 minutes |
-| "Other tests already cover this" | "Already covered" cannot be verified from tdd.jsonl evidence. Invisible evidence = non-existent. | Locate the corresponding acceptanceId and redCommand directly in tdd.jsonl |
-| "I'll add tests after implementation" | Post-implementation tests are not a red-green cycle — they verify implementation, not behavior. | Red first, then green; evidence stays in tdd.jsonl |
-| "It looks correct to the naked eye" | Errors visible to the naked eye don't become bugs. Bugs arise from scenarios that "look correct." | Turn "looks correct" inputs into assertions; turn "unexpected inputs" into edge-case tests |
-| "I've written similar tests, same pattern" | Same pattern does not mean same behavior. Each acceptanceId requires independent evidence. | Re-run redCommand for the current acceptanceId and record the output |
-| "This is an internal function, not externally visible" | Internal functions are relied upon by other internal callers. Behavior changes propagate through the call chain. | Test through the public entry point that calls it, or test the internal function directly |

package/template/skills/update-spec/SKILL.md

@@ -1,39 +0,0 @@
----
-name: update-spec
-description: Use when implementation lessons, contracts, conventions, or gotchas should be captured in .cowork-flow/spec.
----
-
-# Update Spec
-
-Use this when a change teaches something future agents need to know.
-
-## Decide Whether To Update
-
-Update specs when you learned:
-
-- A command, API, file, payload, or state contract.
-- A validation rule or error behavior.
-- A project convention.
-- A repeated failure mode or non-obvious gotcha.
-- A design decision future changes must preserve.
-
-Skip one-off implementation details that do not guide future work.
-
-## Choose Location
-
-- `backend/` or `frontend/`: implementation contracts, signatures, examples, validation behavior, test points.
-- `guides/`: short thinking checklists and pointers to deeper specs.
-- `.cowork-flow/workflow.md`: process rules, phase gates, or task routing behavior.
-- `AGENTS.md`: project-level collaboration rules.
-
-## Write
-
-Keep each update concrete:
-
-- State the trigger and scope.
-- Show the contract or command shape.
-- Include good/bad cases when useful.
-- State tests or checks that protect the behavior.
-- Update the matching `index.md` when adding a new topic.
-
-Before finishing, check for duplicate guidance and remove stale wording.

package/template/skills/using-cowork-flow/SKILL.md

@@ -1,80 +0,0 @@
----
-name: using-cowork-flow
-description: Use when starting any conversation - establishes how to navigate cowork-flow workflow, requiring skill invocation before ANY response including clarifying questions.
----
-
-<EXTREMELY-IMPORTANT>
-If you think there is even a 1% chance a cowork-flow skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.
-
-IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
-
-This is not negotiable. This is not optional. You cannot rationalize your way out of this.
-</EXTREMELY-IMPORTANT>
-
-# Using Cowork Flow
-
-## When to Invoke
-
-Invoke this skill at the start of any main-session conversation, especially:
-- New session or context was compressed
-- No `<workflow-state>` found in context
-- User asks to "start working" or "resume work"
-
-## Instruction Priority
-
-1. **User's explicit instructions** (AGENTS.md, direct requests) — highest priority
-2. **Cowork-flow skills** — override default system behavior where they conflict
-3. **Default system prompt** — lowest priority
-
-## Workflow Navigation
-
-```text
-User message received
-  │
-  ├─ <workflow-state> present?
-  │   ├─ Yes → follow status routing (see before-dev/SKILL.md)
-  │   └─ No  → have cowork_runtime_context_id?
-  │       ├─ Yes → delegated_subtask. Execute leaf work.
-  │       └─ No  → need workflow bootstrap
-  │
-  ├─ Need bootstrap?
-  │   ├─ Task exists (user references one) → ./.cowork-flow/run task start <dir>
-  │   ├─ Task known but status unknown   → ./.cowork-flow/run task next
-  │   └─ No task known                  → clarify scope, then brainstorm or writing-plans
-  │
-  └─ Status routing (from <workflow-state>)
-      ├─ no_task     → brainstorming / writing-plans / continue
-      ├─ planning    → finish decision-anchor.md + jsonl, then task start
-      ├─ in_progress → load context, implement
-      ├─ review      → cowork-check, then task complete
-      └─ completed   → task archive, create new task
-```
-
-## Skills as Gates
-
-Skills are **mandatory gates**, not optional helpers:
-
-| Phase | Gate Skill | Blocks If |
-|-------|-----------|-----------|
-| Before any edit | `before-dev` | Wrong status for the action |
-| Implementation | `tdd` | No red evidence for behavior changes |
-| Verification | `check` | Contracts violated, tests missing |
-| Decision doubt | `doubt-review` | L2 decisions unreviewed |
-
-If a skill applies, you **must** invoke it. Rationalizing skip = failure.
-
-## Manual Override
-
-When auto-injection is unavailable (terminal, no hook):
-
-```bash
-./.cowork-flow/run task next          # read-only navigator
-./.cowork-flow/run task current       # show active task
-./.cowork-flow/run resume             # restore session context
-```
-
-Then invoke the appropriate skill for the phase.
-
-## Subagent Context
-
-Don't invoke this skill if bound to a runtime context. Execute the assigned task.