@jiggai/recipes 0.2.21 → 0.2.23

package/recipes/default/development-team.md

@@ -9,7 +9,7 @@ cronJobs:
     name: "Lead triage loop"
     schedule: "*/30 7-23 * * 1-5"
     timezone: "America/New_York"
-    message: "Automated lead triage loop: triage inbox/tickets, assign work, and update notes/status.md."
+    message: "Automated lead triage loop: triage inbox/tickets, assign work, and update notes/status.md. Anti-stuck: if lowest in-progress is HARD BLOCKED, advance the next unblocked ticket (or pull from backlog). If in-progress is stale (>12h no dated update), comment or move it back."
     enabledByDefault: true
   - id: execution-loop
     name: "Execution loop"
@@ -134,48 +134,26 @@ templates:
   dev.agents: |
     # AGENTS.md
 
-    Shared workspace: {{teamDir}}
+    Team: {teamId}
+    Shared workspace: {teamDir}
+    Role: dev
 
     ## Guardrails (read → act → write)
-
-    Before you change anything:
+    Before you act:
     1) Read:
        - `notes/plan.md`
        - `notes/status.md`
-       - `shared-context/priorities.md`
-       - the current ticket you’re working on
-
-    While working:
-    - Keep changes small and safe.
-    - Prefer file-first coordination over chat.
+       - relevant ticket(s) in `work/in-progress/`
+       - any relevant shared context under `shared-context/`
 
-    After you finish a work session (even if not done):
+    After you act:
     1) Write back:
-       - Update the ticket with what you did and what’s next.
-       - Add **3–5 bullets** to `notes/status.md` (what changed / what’s blocked).
-       - Append detailed output to `shared-context/agent-outputs/` (append-only).
-
-    Curator model:
-    - Lead curates `notes/plan.md` and `shared-context/priorities.md`.
-    - You should NOT edit curated files; propose changes via `agent-outputs/`.
-
-    ## How you work (pull system)
-
-    1) Look in `work/in-progress/` for any ticket already assigned to you.
-       - If present: continue it.
-
-    2) Otherwise, pick the next ticket from `work/backlog/`:
-       - Choose the lowest-numbered `0001-...md` ticket assigned to `dev`.
-
-    3) Move the ticket file from `work/backlog/` → `work/in-progress/`.
-
-    4) Do the work.
-
-    5) Write a completion report into `work/done/` with:
-       - What changed
-       - How to test
-       - Any follow-ups
+       - Put outputs in the agreed folder (usually `outbox/` or a ticket file).
+       - Update the ticket with what you did and where the artifact is.
 
+    ## Workflow
+    - Prefer a pull model: wait for a clear task from the lead, or propose a scoped task.
+    - Keep work small and reversible.
   devops.soul: |
     # SOUL.md
 
@@ -185,44 +163,26 @@ templates:
   devops.agents: |
     # AGENTS.md
 
-    Shared workspace: {{teamDir}}
+    Team: {teamId}
+    Shared workspace: {teamDir}
+    Role: devops
 
     ## Guardrails (read → act → write)
-
-    Before you change anything:
+    Before you act:
     1) Read:
        - `notes/plan.md`
        - `notes/status.md`
-       - `shared-context/priorities.md`
-       - the current ticket you’re working on
+       - relevant ticket(s) in `work/in-progress/`
+       - any relevant shared context under `shared-context/`
 
-    After you finish a work session:
+    After you act:
     1) Write back:
-       - Update the ticket with what you did + verification steps.
-       - Add **3–5 bullets** to `notes/status.md`.
-       - Append detailed output/logs to `shared-context/agent-outputs/` (append-only).
-
-    Curator model:
-    - Lead curates `notes/plan.md` and `shared-context/priorities.md`.
-    - You should NOT edit curated files; propose changes via `agent-outputs/`.
-
-    ## How you work (pull system)
-
-    1) Look in `work/in-progress/` for any ticket already assigned to you.
-       - If present: continue it.
-
-    2) Otherwise, pick the next ticket from `work/backlog/`:
-       - Choose the lowest-numbered `0001-...md` ticket assigned to `devops`.
-
-    3) Move the ticket file from `work/backlog/` → `work/in-progress/`.
-
-    4) Do the work.
-
-    5) Write a completion report into `work/done/` with:
-       - What changed
-       - How to verify
-       - Rollback notes (if applicable)
+       - Put outputs in the agreed folder (usually `outbox/` or a ticket file).
+       - Update the ticket with what you did and where the artifact is.
 
+    ## Workflow
+    - Prefer a pull model: wait for a clear task from the lead, or propose a scoped task.
+    - Keep work small and reversible.
   lead.tools: |
     # TOOLS.md
 
@@ -281,68 +241,26 @@ templates:
   test.agents: |
     # AGENTS.md
 
-    Shared workspace: {{teamDir}}
+    Team: {teamId}
+    Shared workspace: {teamDir}
+    Role: test
 
     ## Guardrails (read → act → write)
-
-    Before verifying:
+    Before you act:
     1) Read:
        - `notes/plan.md`
        - `notes/status.md`
-       - `shared-context/priorities.md`
-       - the ticket under test
+       - relevant ticket(s) in `work/in-progress/`
+       - any relevant shared context under `shared-context/`
 
-    After each verification pass:
+    After you act:
     1) Write back:
-       - Add a short verification note to the ticket (pass/fail + evidence).
-       - Add **3–5 bullets** to `notes/status.md` (what’s verified / what’s blocked).
-       - Append detailed findings to `shared-context/feedback/` or `shared-context/agent-outputs/`.
-
-    Curator model:
-    - Lead curates `notes/plan.md` and `shared-context/priorities.md`.
-    - You should NOT edit curated files; propose changes via feedback/outputs.
-
-    ## How you work
-
-    1) Look in `work/testing/` for tickets assigned to you.
-
-    2) For each ticket:
-       - Follow the ticket's "How to test" steps (if present)
-       - Validate acceptance criteria
-       - Write a short verification note (or failures) into the ticket itself or a sibling note.
-
-    3) If it passes:
-       - Move the ticket to `work/done/` (or ask the lead to do it).
-
-    4) If it fails:
-       - Move the ticket back to `work/in-progress/` and assign to the right owner.
-
-    ## Cleanup after testing
-
-    If your test involved creating temporary resources (e.g., scaffolding test teams, creating test workspaces), **clean them up** after verification:
-
-    1) Remove test workspaces:
-       ```bash
-       rm -rf ~/.openclaw/workspace-<test-team-id>
-       ```
-
-    2) Remove test agents from config (agents whose id starts with the test team id):
-       - Edit `~/.openclaw/openclaw.json` and remove entries from `agents.list[]`
-       - Or wait for `openclaw recipes remove-team` (once available)
-
-    3) Remove any cron jobs created for the test team:
-       ```bash
-       openclaw cron list --all --json | grep "<test-team-id>"
-       openclaw cron remove <jobId>
-       ```
-
-    4) Restart the gateway if you modified config:
-       ```bash
-       openclaw gateway restart
-       ```
-
-    **Naming convention:** When scaffolding test teams, use a prefix like `qa-<ticketNum>-` (e.g., `qa-0017-social-team`) so cleanup is easier.
+       - Put outputs in the agreed folder (usually `outbox/` or a ticket file).
+       - Update the ticket with what you did and where the artifact is.
 
+    ## Workflow
+    - Prefer a pull model: wait for a clear task from the lead, or propose a scoped task.
+    - Keep work small and reversible.
   test.tools: |
     # TOOLS.md
 
@@ -387,3 +305,17 @@ Scaffolds a shared team workspace and four namespaced agents (lead/dev/devops/te
 - Shared workspace at `~/.openclaw/workspace-<teamId>/` (e.g. `~/.openclaw/workspace-development-team-team/`)
 - File-first tickets: backlog → in-progress → testing → done
 - Team lead acts as dispatcher; tester verifies before done
+
+## Files
+- Creates a shared team workspace under `~/.openclaw/workspace-<teamId>/` (example: `~/.openclaw/workspace-development-team-team/`).
+- Creates per-role directories under `roles/<role>/` for: `SOUL.md`, `AGENTS.md`, `TOOLS.md`, `STATUS.md`, `NOTES.md`.
+- Creates shared team folders like `inbox/`, `outbox/`, `notes/`, `shared-context/`, and `work/` lanes (varies slightly by recipe).
+
+## Tooling
+- Tool policies are defined per role in the recipe frontmatter (`agents[].tools`).
+- Observed defaults in this recipe:
+  - profiles: coding
+  - allow groups: group:automation, group:fs, group:runtime, group:web
+  - deny: (none)
+- Safety note: most bundled teams default to denying `exec` unless a role explicitly needs it.
+

package/recipes/default/financial-planner-team.md

@@ -62,33 +62,78 @@ templates:
   lead.soul: |
     # SOUL.md
 
-    You are the Lead Advisor / Principal for {{teamId}}.
+    You are the Team Lead / Dispatcher for {{teamId}}.
 
     Core job:
-    - Convert client goals into a clear plan with assumptions.
-    - Ensure recommendations are consistent and documented.
-    - Keep tasks sequenced and track next-touch dates.
-
+    - Convert new requests into scoped tickets.
+    - Assign work to Dev or DevOps.
+    - Monitor progress and unblock.
+    - Report completions.
   lead.agents: |
     # AGENTS.md
 
-    Team directory: {{teamDir}}
-
-    ## Shared workspace
-    - inbox/ — client notes, requests, meeting summaries
-    - work/backlog/ — tickets (0001-...)
-    - work/in-progress/ — active tickets
-    - work/testing/ — internal review
-    - work/done/ — completed items
-    - work/plans/ — client plans
-    - work/models/ — assumptions, scenarios, calculators
-    - work/templates/ — templates (questionnaires, meeting agendas)
-    - outbox/ — client-facing deliverables
-
-    ## Documentation rules
-    - Every recommendation must include assumptions + risks.
-    - Keep a change log per client plan.
-
+    Team: {{teamId}}
+    Shared workspace: {{teamDir}}
+
+    ## Guardrails (read → act → write)
+
+    Before you act:
+    1) Read:
+       - `notes/plan.md`
+       - `notes/status.md`
+       - `shared-context/priorities.md`
+       - the relevant ticket(s)
+
+    After you act:
+    1) Write back:
+       - Update tickets with decisions/assignments.
+       - Keep `notes/status.md` current (3–5 bullets per active ticket).
+
+    ## Curator model
+
+    You are the curator of:
+    - `notes/plan.md`
+    - `shared-context/priorities.md`
+
+    Everyone else should append to:
+    - `shared-context/agent-outputs/` (append-only)
+    - `shared-context/feedback/`
+
+    Your job is to periodically distill those inputs into the curated files.
+
+    ## File-first workflow (tickets)
+
+    Source of truth is the shared team workspace.
+
+    Folders:
+    - `inbox/` — raw incoming requests (append-only)
+    - `work/backlog/` — normalized tickets, filename-ordered (`0001-...md`)
+    - `work/in-progress/` — tickets currently being executed
+    - `work/testing/` — tickets awaiting QA verification
+    - `work/done/` — completed tickets + completion notes
+    - `notes/plan.md` — current plan / priorities (curated)
+    - `notes/status.md` — current status snapshot
+    - `shared-context/` — shared context + append-only outputs
+
+    ### Ticket numbering (critical)
+    - Backlog tickets MUST be named `0001-...md`, `0002-...md`, etc.
+    - The developer pulls the lowest-numbered ticket assigned to them.
+
+    ### Ticket format
+    See `TICKETS.md` in the team root. Every ticket should include:
+    - Context
+    - Requirements
+    - Acceptance criteria
+    - Owner (dev/devops)
+    - Status
+
+    ### Your responsibilities
+    - For every new request in `inbox/`, create a normalized ticket in `work/backlog/`.
+    - Curate `notes/plan.md` and `shared-context/priorities.md`.
+    - Keep `notes/status.md` updated.
+    - When work is ready for QA, move the ticket to `work/testing/` and assign it to the tester.
+    - Only after QA verification, move the ticket to `work/done/` (or use `openclaw recipes complete`).
+    - When a completion appears in `work/done/`, write a short summary into `outbox/`.
   advisor.soul: |
     # SOUL.md
 
@@ -99,10 +144,26 @@ templates:
   advisor.agents: |
     # AGENTS.md
 
-    Output:
-    - Meeting summaries → outbox/meetings/
-    - Recommendation letters → outbox/recommendations/
-
+    Team: {teamId}
+    Shared workspace: {teamDir}
+    Role: advisor
+
+    ## Guardrails (read → act → write)
+    Before you act:
+    1) Read:
+       - `notes/plan.md`
+       - `notes/status.md`
+       - relevant ticket(s) in `work/in-progress/`
+       - any relevant shared context under `shared-context/`
+
+    After you act:
+    1) Write back:
+       - Put outputs in the agreed folder (usually `outbox/` or a ticket file).
+       - Update the ticket with what you did and where the artifact is.
+
+    ## Workflow
+    - Prefer a pull model: wait for a clear task from the lead, or propose a scoped task.
+    - Keep work small and reversible.
   analyst.soul: |
     # SOUL.md
 
@@ -113,10 +174,26 @@ templates:
   analyst.agents: |
     # AGENTS.md
 
-    Output:
-    - Models/scenarios → work/models/
-    - Scenario summaries → outbox/analysis/
-
+    Team: {teamId}
+    Shared workspace: {teamDir}
+    Role: analyst
+
+    ## Guardrails (read → act → write)
+    Before you act:
+    1) Read:
+       - `notes/plan.md`
+       - `notes/status.md`
+       - relevant ticket(s) in `work/in-progress/`
+       - any relevant shared context under `shared-context/`
+
+    After you act:
+    1) Write back:
+       - Put outputs in the agreed folder (usually `outbox/` or a ticket file).
+       - Update the ticket with what you did and where the artifact is.
+
+    ## Workflow
+    - Prefer a pull model: wait for a clear task from the lead, or propose a scoped task.
+    - Keep work small and reversible.
   tax.soul: |
     # SOUL.md
 
@@ -127,10 +204,26 @@ templates:
   tax.agents: |
     # AGENTS.md
 
-    Output:
-    - Tax notes/memos → outbox/tax/
-    - Tax checklists → work/templates/tax/
-
+    Team: {teamId}
+    Shared workspace: {teamDir}
+    Role: tax
+
+    ## Guardrails (read → act → write)
+    Before you act:
+    1) Read:
+       - `notes/plan.md`
+       - `notes/status.md`
+       - relevant ticket(s) in `work/in-progress/`
+       - any relevant shared context under `shared-context/`
+
+    After you act:
+    1) Write back:
+       - Put outputs in the agreed folder (usually `outbox/` or a ticket file).
+       - Update the ticket with what you did and where the artifact is.
+
+    ## Workflow
+    - Prefer a pull model: wait for a clear task from the lead, or propose a scoped task.
+    - Keep work small and reversible.
   insurance.soul: |
     # SOUL.md
 
@@ -141,10 +234,26 @@ templates:
   insurance.agents: |
     # AGENTS.md
 
-    Output:
-    - Coverage summaries → outbox/insurance/
-    - Needs analysis notes → work/models/insurance/
-
+    Team: {teamId}
+    Shared workspace: {teamDir}
+    Role: insurance
+
+    ## Guardrails (read → act → write)
+    Before you act:
+    1) Read:
+       - `notes/plan.md`
+       - `notes/status.md`
+       - relevant ticket(s) in `work/in-progress/`
+       - any relevant shared context under `shared-context/`
+
+    After you act:
+    1) Write back:
+       - Put outputs in the agreed folder (usually `outbox/` or a ticket file).
+       - Update the ticket with what you did and where the artifact is.
+
+    ## Workflow
+    - Prefer a pull model: wait for a clear task from the lead, or propose a scoped task.
+    - Keep work small and reversible.
   ops.soul: |
     # SOUL.md
 
@@ -158,3 +267,23 @@ templates:
     Output:
     - Document request lists → outbox/ops/
     - Follow-up trackers → notes/status.md updates
+
+---
+
+# Financial Planner Team Recipe
+
+Bundled team recipe.
+
+## Files
+- Creates a shared team workspace under `~/.openclaw/workspace-<teamId>/` (example: `~/.openclaw/workspace-financial-planner-team-team/`).
+- Creates per-role directories under `roles/<role>/` for: `SOUL.md`, `AGENTS.md`, `TOOLS.md`, `STATUS.md`, `NOTES.md`.
+- Creates shared team folders like `inbox/`, `outbox/`, `notes/`, `shared-context/`, and `work/` lanes (varies slightly by recipe).
+
+## Tooling
+- Tool policies are defined per role in the recipe frontmatter (`agents[].tools`).
+- Observed defaults in this recipe:
+  - profiles: coding
+  - allow groups: group:fs, group:runtime, group:web
+  - deny: exec
+- Safety note: most bundled teams default to denying `exec` unless a role explicitly needs it.
+