feat(meta): operation-focused capability skills + skill_operations on activities

cicd-pipeline-security-audit/activities/01-scope-setup.toon

@@ -9,7 +9,6 @@ recognition[4]:
   - scan github actions
   - cicd security audit
 skills:
-  primary: meta/activity-worker
   supporting[1]:
     - execute-cicd-audit
 required: true

cicd-pipeline-security-audit/activities/02-reconnaissance.toon

@@ -8,7 +8,6 @@ recognition[3]:
   - reconnaissance
   - map triggers
 skills:
-  primary: meta/activity-worker
   supporting[1]:
     - execute-cicd-audit
 required: true

cicd-pipeline-security-audit/activities/03-primary-scan.toon

@@ -8,7 +8,6 @@ recognition[3]:
   - run detection
   - primary scan
 skills:
-  primary: meta/activity-worker
   supporting[1]:
     - execute-cicd-audit
 required: true

cicd-pipeline-security-audit/activities/04-report-generation.toon

@@ -8,7 +8,6 @@ recognition[3]:
   - consolidate findings
   - finalize report
 skills:
-  primary: meta/activity-worker
   supporting[1]:
     - execute-cicd-audit
 required: true

cicd-pipeline-security-audit/activities/05-sub-workflow-scan.toon

@@ -7,7 +7,6 @@ recognition[2]:
   - scan submodule workflows
   - run detection patterns
 skills:
-  primary: meta/activity-worker
   supporting[1]:
     - execute-sub-agent
 required: false

cicd-pipeline-security-audit/activities/06-sub-verification.toon

@@ -7,7 +7,6 @@ recognition[2]:
   - verify scan results
   - check scan completeness
 skills:
-  primary: meta/activity-worker
   supporting[1]:
     - execute-sub-agent
 required: false

cicd-pipeline-security-audit/activities/07-sub-merge.toon

@@ -7,7 +7,6 @@ recognition[2]:
   - merge findings
   - consolidate scan results
 skills:
-  primary: meta/activity-worker
   supporting[1]:
     - execute-sub-agent
 required: false

cicd-pipeline-security-audit/workflow.toon

@@ -32,7 +32,6 @@ rules[19]:
   - "AGENT OUTPUT PERSISTENCE: Every sub-agent MUST write its own structured output as a JSON file to the planning folder. The orchestrator verifies all expected files exist BEFORE dispatching V or M. If any file is missing, the orchestrator re-dispatches the agent. File naming: s{n}-{submodule}.json for scanners, verification-report.json for V, merged-findings.json and reconciliation-table.json for M."
   - "SUB-AGENT BOOTSTRAP: Every sub-agent receives workflow-server bootstrap instructions in its spawn-agent prompt (harness-compat): call start_session(session_token, agent_id) to inherit the dispatched session, then next_activity({ activity_id: <assigned> }), then follow activity steps sequentially. Sub-agents self-load their activity definition — the orchestrator does NOT inline the activity content."
 skills:
-  primary: meta/workflow-orchestrator
 variables[14]:
   - name: target_submodules
     type: string

meta/activities/00-discover-session.toon

@@ -1,7 +1,7 @@
 id: discover-session
-version: 3.0.0
+version: 7.0.0
 name: Discover Session
-description: "Identify the user's intended target workflow and search for an existing client session to resume. Calls list_workflows for the catalog, matches the user request against workflow descriptions, scans planning folders for saved client sessions matching the request's identifying context (ticket, branch, PR, work-package name), and presents resume / workflow-selection checkpoints. Always runs first — bootstrap delegates target identification and session matching here."
+description: "Identify the user's intended target workflow and search for an existing client session to resume. Always runs first — bootstrap delegates target identification and session matching here."
 problem: The meta workflow needs to determine which client workflow to dispatch and whether to resume an existing client session, before initialize-session creates or adopts the client session
 recognition[4]:
   - start a workflow
@@ -10,30 +10,31 @@ recognition[4]:
   - work on
 required: true
 estimatedTime: 1-2m
-skills:
-  primary: meta/activity-worker
-  supporting[1]:
-    - state-management
-rules[2]:
-  - "Always call list_workflows — never hardcode the workflow catalog"
+operations[5]:
+  - "workflow-engine::list-workflows"
+  - "workflow-engine::match-target-workflow"
+  - "workflow-engine::extract-identifying-context"
+  - "workflow-engine::scan-saved-sessions"
+  - "workflow-engine::match-saved-session"
+rules[1]:
   - "Match identifying context against saved sessions even when the user said 'start' — surface saved state via the resume-session checkpoint"
-steps[5]:
+steps[7]:
   - id: list-available-workflows
-    name: List Available Workflows
-    description: "Call list_workflows (no session token required) to retrieve the catalog of available workflows with their titles, descriptions, and recognition tags. Cache the catalog for the match step."
-  - id: identify-target
-    name: Identify Target Workflow and Context
-    description: "Compare the user's request against the workflow catalog. Match on title, description keywords, and recognition tags. Set target_workflow_id to the matched workflow. If multiple workflows could match, set workflow_match_ambiguous = true so the workflow-selection checkpoint fires. Also extract identifying context — ticket number (GitHub #N, Jira PROJ-123), branch name, PR number, or work-package description — for the saved-session match step."
+    description: "workflow-engine::list-workflows()"
+  - id: match-target
+    description: "workflow-engine::match-target-workflow(user_request: {user_request}, catalog: {workflow_catalog})"
+  - id: extract-context
+    description: "workflow-engine::extract-identifying-context(user_request: {user_request})"
   - id: scan-planning-folders
-    name: Scan Planning Folders for Saved Sessions
-    description: "List directories under .engineering/artifacts/planning/. For each directory containing a workflow-state.toon file, read it and extract: saved sessionToken, workflowId, planningFolder, and key state variables (issue_number, branch_name, pr_number, work-package description). Collect all candidates whose workflowId matches target_workflow_id."
-    skill: state-management
+    description: "workflow-engine::scan-saved-sessions(target_workflow_id: {target_workflow_id})"
   - id: match-session
-    name: Match Saved Session to User Request
-    description: "Compare the identifying context from identify-target against the candidate saved sessions. Match on issue_number, branch_name, pr_number, or directory name containing the ticket identifier. If multiple matches, prefer the most recently updated by savedAt. If no matches, set has_saved_state = false."
-  - id: prepare-result
-    name: Prepare Discovery Result
-    description: "If a match was found: set has_saved_state = true, saved_session_token = matched session's sessionToken, planning_folder_path = matched session's planningFolder. If no match: set has_saved_state = false. Set is_resuming = false by default; the resume-session checkpoint may flip it to true."
+    description: "workflow-engine::match-saved-session(context: {identifying_context}, candidates: {saved_session_candidates})"
+  - id: record-match
+    description: "Set has_saved_state = true; copy saved_session_token and planning_folder_path from the matched candidate."
+    when: "has_saved_state == true"
+  - id: record-no-match
+    description: "Set has_saved_state = false; the resume-session checkpoint will not fire."
+    when: "has_saved_state == false"
 checkpoints[2]:
   - id: workflow-selection
     name: Workflow Selection

meta/activities/01-initialize-session.toon

@@ -1,55 +1,34 @@
 id: initialize-session
-version: 1.0.0
+version: 4.0.0
 name: Initialize Session
-description: "Create or adopt the client workflow's session as a child of the meta session. If discover-session matched a saved client session, adopt it via start_session and restore variables from disk. Otherwise, create a fresh child session via start_session({ workflow_id, parent_session_token }) and initialize the planning folder. Sets client_session_token, planning_folder_path, and the session-recovery flags."
+description: "Create or adopt the client workflow's session as a child of the meta session. Restore variables on resume; create the planning folder on fresh starts."
 problem: The client workflow needs a valid session token before its orchestrator can be dispatched, and saved state must be restored before activities resume
-skills:
-  primary: meta/activity-worker
-  supporting[3]:
-    - session-protocol
-    - state-management
-    - version-control
 required: true
 estimatedTime: 1-2m
-rules[3]:
-  - "When creating a fresh client session, ALWAYS pass parent_session_token so trace correlation links the meta session to the client workflow"
-  - "When adopting a saved session, treat the saved token as opaque — never decode or modify it"
-  - "If start_session returns recovered: true, the saved payload was corrupted — variables MUST be reconstructed from the on-disk state file before any activity runs"
-steps[5]:
-  - id: start-or-adopt-session
-    name: Start or Adopt Client Session
-    description: "If has_saved_state: call start_session({ session_token: saved_session_token, agent_id: 'orchestrator' }) to adopt the saved client session. Otherwise: call start_session({ workflow_id: target_workflow_id, parent_session_token: session_token, agent_id: 'orchestrator' }) to create a fresh child session. Save the returned token as client_session_token."
-    skill: session-protocol
+operations[5]:
+  - "workflow-engine::adopt-session"
+  - "workflow-engine::create-session"
+  - "workflow-engine::restore"
+  - "workflow-engine::persist"
+  - "version-control::initialize-folder"
+steps[6]:
+  - id: adopt-saved-session
+    description: "workflow-engine::adopt-session(saved_session_token: {saved_session_token})"
+    when: "has_saved_state == true"
+  - id: create-fresh-session
+    description: "workflow-engine::create-session(workflow_id: {target_workflow_id}, parent_session_token: {session_token})"
+    when: "has_saved_state == false"
   - id: detect-recovery
-    name: Detect Server-Restart Recovery
-    description: "Inspect the start_session response. If recovered: true, the saved token failed signature verification AND its payload was corrupted — set session_recovered = true so the next step reconstructs variables from disk. If adopted: true, the token was re-signed but its payload was preserved — set session_adopted = true (no reconstruction needed). Otherwise both flags remain false."
+    description: "Inspect the start_session response. Set session_recovered when it carries recovered: true; set session_adopted when it carries adopted: true."
   - id: restore-state
-    name: Restore Variables from Disk
-    description: "If is_resuming: call restore_state({ session_token: client_session_token, file_path: '{planning_folder_path}/workflow-state.toon' }) to load the saved variables and apply each to the client session. This step covers both adopted and recovered sessions — for recovered sessions it is the only source of truth for state."
-    condition:
-      type: simple
-      variable: is_resuming
-      operator: "=="
-      value: true
-    skill: state-management
+    description: "workflow-engine::restore(session_token: {client_session_token}, file_path: {planning_folder_path}/workflow-state.toon)"
+    when: "is_resuming == true"
   - id: derive-planning-folder
-    name: Derive Planning Folder Path
-    description: "If fresh session and planning_folder_path is not yet set, derive it from the user's request context: .engineering/artifacts/planning/YYYY-MM-DD-{initiative-name}/ where initiative-name is kebab-cased from issue title, work-package description, or other identifying context. Store as planning_folder_path."
-    condition:
-      type: simple
-      variable: is_resuming
-      operator: "!="
-      value: true
-    skill: version-control
-  - id: initialize-folder
-    name: Initialize Planning Folder
-    description: "If fresh session: create the planning folder at planning_folder_path (mkdir -p), then call save_state({ session_token: client_session_token, planning_folder_path }) to write the initial workflow-state.toon containing the client session token and default variables. This guarantees the token is on disk before any activity is dispatched."
-    condition:
-      type: simple
-      variable: is_resuming
-      operator: "!="
-      value: true
-    skill: state-management
+    description: "version-control::initialize-folder(initiative_name: <kebab-case from issue title or work-package description>)"
+    when: "is_resuming == false"
+  - id: initialize-state
+    description: "workflow-engine::persist(session_token: {client_session_token}, planning_folder_path: {planning_folder_path})"
+    when: "is_resuming == false"
 transitions[1]:
   - to: resolve-target
     isDefault: true

meta/activities/02-resolve-target.toon

@@ -1,33 +1,27 @@
 id: resolve-target
-version: 1.0.0
+version: 4.0.0
 name: Resolve Target
-description: "Detect the target repository structure (regular directory vs. submodule monorepo) and resolve target_path. Skipped when target_path was already restored from saved state. Sets is_monorepo and target_path for downstream activities that perform git operations on the user's codebase."
+description: "Detect the target repository structure (regular directory vs. submodule monorepo) and resolve target_path."
 problem: Workflows that operate on a target codebase need to know whether the working directory is a regular repo or a submodule monorepo, and which submodule is the target
-skills:
-  primary: meta/activity-worker
 required: true
 estimatedTime: 1-2m
-rules[2]:
-  - "Skip detection when target_path was already restored from saved state (target_path != '.')"
+operations[2]:
+  - "version-control::detect-repo-type"
+  - "version-control::list-submodules"
+rules[1]:
   - "target_path MUST resolve to a directory containing a working git tree"
 entryActions[1]:
   - action: log
     message: "Resolving target repository structure"
 steps[3]:
   - id: detect-monorepo
-    name: Detect Repository Type
-    description: "Check whether the working directory contains a .gitmodules file (test -f .gitmodules). If present, this is a submodule monorepo. If absent, this is a regular repository and target_path defaults to the repository root."
+    description: "version-control::detect-repo-type()"
   - id: list-submodules
-    name: List Submodules
-    description: "If is_monorepo is true (set by the repo-type-confirmed checkpoint): parse .gitmodules to extract the submodule paths and present them as a numbered list, including a brief description of each (from the submodule's README first paragraph or its path)."
-    condition:
-      type: simple
-      variable: is_monorepo
-      operator: "=="
-      value: true
-  - id: capture-target-path
-    name: Capture Target Path
-    description: "If is_monorepo: ask the user to select a submodule, set target_path to its path, and verify the directory exists. If not is_monorepo: set target_path to '.'."
+    description: "version-control::list-submodules()"
+    when: "is_monorepo == true"
+  - id: capture-submodule-target
+    description: "Ask the user to select a submodule from the listed entries. Set target_path to the chosen path."
+    when: "is_monorepo == true"
 checkpoints[1]:
   - id: repo-type-confirmed
     name: Repository Type Confirmation