Name: MIN-03-Sequence_from_Manifest
Author: FeatureFactory-io

Prompt file imported from FeatureFactory-io/mimir (.windsurf/workflows/Edda/MIN/MIN-03-Sequence_from_Manifest.md). Copyright stays with the author.

Activity: Sequence from Manifest

Activity ID: 180 Order: 3 Phase: None Dependencies: Predecessor: Activity 179 (Load Context from PIN Artifacts) Successor: Activity 181 (Execute)

Description

Sequence from Manifest

Guidance

Sequencing (authoritative): Predecessor = Load Context from PIN Artifacts (Activity 179 / MIN-02).

Purpose

Derive the execution queue from the PIN-built manifest. Do NOT rebuild the dependency graph or conflict map — PIN-02 already computed them from actual skeleton commits. This activity reads and validates.

Steps

Step 1: Parse Parallel Groups and Conflict Map

From the loaded ITER-*.yaml manifest (MIN-02 output):

Extract parallel_groups: e.g. A: [S1, S3], B: [S2]
Extract conflict_map: e.g. mcp_integration/tools.py: [S1, S2]

The conflict map was derived by PIN-02 from actual git diff --name-only per skeleton commit. Do not recompute it.

Step 2: Check Dependency State

For each scenario, check dependencies[]. Get each dependency issue one at a time:

gh issue view {dependency_issue_number} --json number,state,labels

Mark scenario as:

READY — no dependencies, or all dependency issues closed with status-done
BLOCKED — one or more dependency issues still open

Step 3: Build Ordered Execution Queue

Order: Group A → Group B → Group C … Within each group, READY scenarios before BLOCKED.

[READY]   S1 [A] {title} — #{issue}
[READY]   S3 [A] {title} — #{issue}  (parallel with S1)
[BLOCKED] S2 [B] {title} — #{issue}  (waits for S1: status-done)

Step 4: Switch to Plan Mode and Present Queue

Switch to Plan mode. Present two-level diagrams:

Outer — scenario dependencies (iteration graph):

flowchart LR
  S1["S1: {title}"] --> S2["S2: {title}"]
  S3["S3: {title}"]

Inner — for each READY scenario, feature_execution_graph node deps:

flowchart LR
  N1["N1 backend BPE-02"] --> N2["N2 frontend BPE-03"]
  N2 --> N3["N3 DoD BPE-06"]

Label parallel scenarios clearly. Note BLOCKED scenarios and unmet scenario-level dependencies.

Step 5: Output Execution Plan

=== EXECUTION QUEUE ===
Groups: {N} | Scenarios: {N} ready, {N} blocked

Group A (parallel):
  [READY] S1 #{issue} — {title} — nodes: N1→N2→…→N5
  [READY] S3 #{issue} — {title} — nodes: …

Group B (after A):
  [BLOCKED] S2 #{issue} — {title} — waiting for S1

READY nodes (next to execute across ready scenarios):
  S1/N1-backend-service [BPE-02]
  S3/N1-backend-service [BPE-02]  (parallel scenarios OK; respect conflict_map)

Conflicts: {file} shared by {S_N, S_M} — serialized in groups
Next: MIN-04 Execute (one fresh subagent per ready node)
======================

Success Criteria

parallel_groups and conflict_map parsed from manifest (not recomputed)
Each scenario dependency state checked via gh issue view (one at a time)
Execution queue ordered correctly: group order + dependency order within groups
Mermaid diagrams presented in Plan mode (scenario + inner graph for READY scenarios)
READY nodes listed for MIN-04, not scenarios alone
Ready to proceed to MIN-04

The conflict map and parallel groups were established by PIN-02 from actual skeleton commits. MIN-03 reads and validates them — it does not recompute them.

Agent

None

Skill

None

Rules

None

Artifacts Produced

None

Artifacts Consumed

None

Notes

No additional notes.

Install MIN-03-Sequence_from_Manifest and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Activity: Sequence from Manifest **Activity ID**: 180 **Order**: 3 **Phase**: None **Dependencies**: Predecessor: Activity 179 (Load Context from PIN Artifacts) Successor: Activity 181 (Execute) ## Description Sequence from Manifest ## Guidance **Sequencing (authoritative):** Predecessor = Load Context from PIN Artifacts (Activity 179 / MIN-02). ## Purpose Derive the execution queue from the PIN-built manifest. Do NOT rebuild the dependency graph or conflict map — PIN-02 already computed them from actual skeleton commits. This activity reads and validates. ## Steps ### Step 1: Parse Parallel Groups and Conflict Map From the loaded ITER-*.yaml manifest (MIN-02 output): - Extract `parallel_groups`: e.g. `A: [S1, S3]`, `B: [S2]` - Extract `conflict_map`: e.g. `mcp_integration/tools.py: [S1, S2]` > The conflict map was derived by PIN-02 from actual `git diff --name-only` per skeleton commit. Do not recompute it. ### Step 2: Check Dependency State For each scenario, check `dependencies[]`. Get each dependency issue one at a time: ```bash gh issue view {dependency_issue_number} --json number,state,labels ``` Mark scenario as: - **READY** — no dependencies, or all dependency issues closed with `status-done` - **BLOCKED** — one or more dependency issues still open ### Step 3: Build Ordered Execution Queue Order: Group A → Group B → Group C … Within each group, READY scenarios before BLOCKED. ``` [READY] S1 [A] {title} — #{issue} [READY] S3 [A] {title} — #{issue} (parallel with S1) [BLOCKED] S2 [B] {title} — #{issue} (waits for S1: status-done) ``` ### Step 4: Switch to Plan Mode and Present Queue Switch to **Plan mode**. Present **two-level** diagrams: **Outer** — scenario dependencies (iteration graph): ```mermaid flowchart LR S1["S1: {title}"] --> S2["S2: {title}"] S3["S3: {title}"] ``` **Inner** — for each READY scenario, `feature_execution_graph` node deps: ```mermaid flowchart LR N1["N1 backend BPE-02"] --> N2["N2 frontend BPE-03"] N2 --> N3["N3 DoD BPE-06"] ``` Label parallel scenarios clearly. Note BLOCKED scenarios and unmet scenario-level dependencies. ### Step 5: Output Execution Plan ``` === EXECUTION QUEUE === Groups: {N} | Scenarios: {N} ready, {N} blocked Group A (parallel): [READY] S1 #{issue} — {title} — nodes: N1→N2→…→N5 [READY] S3 #{issue} — {title} — nodes: … Group B (after A): [BLOCKED] S2 #{issue} — {title} — waiting for S1 READY nodes (next to execute across ready scenarios): S1/N1-backend-service [BPE-02] S3/N1-backend-service [BPE-02] (parallel scenarios OK; respect conflict_map) Conflicts: {file} shared by {S_N, S_M} — serialized in groups Next: MIN-04 Execute (one fresh subagent per ready node) ====================== ``` ## Success Criteria - `parallel_groups` and `conflict_map` parsed from manifest (not recomputed) - Each scenario dependency state checked via `gh issue view` (one at a time) - Execution queue ordered correctly: group order + dependency order within groups - Mermaid diagrams presented in Plan mode (scenario + inner graph for READY scenarios) - READY **nodes** listed for MIN-04, not scenarios alone - Ready to proceed to MIN-04 > The conflict map and parallel groups were established by PIN-02 from actual skeleton commits. > MIN-03 reads and validates them — it does not recompute them. ## Agent None ## Skill None ## Rules None ## Artifacts Produced None ## Artifacts Consumed None ## Notes No additional notes.

{ "prompt": "# Activity: Sequence from Manifest\n\n**Activity ID**: 180\n**Order**: 3\n**Phase**: None\n**Dependencies**: Predecessor: Activity 179 (Load Context from PIN Artifacts)\nSuccessor: Activity 181 (Execute)\n\n## Description\n\nSequence from Manifest\n\n## Guidance\n\n**Sequencing (authoritative):** Predecessor = Load Context from PIN Artifacts (Activity 179 / MIN-02).\n\n## Purpose\nDerive the execution queue from the PIN-built manifest. Do NOT rebuild the dependency graph or conflict map — PIN-02 already computed them from actual skeleton commits. This activity reads and validates.\n\n## Steps\n\n### Step 1: Parse Parallel Groups and Conflict Map\nFrom the loaded ITER-*.yaml manifest (MIN-02 output):\n- Extract `parallel_groups`: e.g. `A: [S1, S3]`, `B: [S2]`\n- Extract `conflict_map`: e.g. `mcp_integration/tools.py: [S1, S2]`\n\n> The conflict map was derived by PIN-02 from actual `git diff --name-only` per skeleton commit. Do not recompute it.\n\n### Step 2: Check Dependency State\nFor each scenario, check `dependencies[]`. Get each dependency issue one at a time:\n```bash\ngh issue view {dependency_issue_number} --json number,state,labels\n```\nMark scenario as:\n- **READY** — no dependencies, or all dependency issues closed with `status-done`\n- **BLOCKED** — one or more dependency issues still open\n\n### Step 3: Build Ordered Execution Queue\nOrder: Group A → Group B → Group C … Within each group, READY scenarios before BLOCKED.\n\n```\n[READY] S1 [A] {title} — #{issue}\n[READY] S3 [A] {title} — #{issue} (parallel with S1)\n[BLOCKED] S2 [B] {title} — #{issue} (waits for S1: status-done)\n```\n\n### Step 4: Switch to Plan Mode and Present Queue\nSwitch to **Plan mode**. Present **two-level** diagrams:\n\n**Outer** — scenario dependencies (iteration graph):\n\n```mermaid\nflowchart LR\n S1[\"S1: {title}\"] --> S2[\"S2: {title}\"]\n S3[\"S3: {title}\"]\n```\n\n**Inner** — for each READY scenario, `feature_execution_graph` node deps:\n\n```mermaid\nflowchart LR\n N1[\"N1 backend BPE-02\"] --> N2[\"N2 frontend BPE-03\"]\n N2 --> N3[\"N3 DoD BPE-06\"]\n```\n\nLabel parallel scenarios clearly. Note BLOCKED scenarios and unmet scenario-level dependencies.\n\n### Step 5: Output Execution Plan\n```\n=== EXECUTION QUEUE ===\nGroups: {N} | Scenarios: {N} ready, {N} blocked\n\nGroup A (parallel):\n [READY] S1 #{issue} — {title} — nodes: N1→N2→…→N5\n [READY] S3 #{issue} — {title} — nodes: …\n\nGroup B (after A):\n [BLOCKED] S2 #{issue} — {title} — waiting for S1\n\nREADY nodes (next to execute across ready scenarios):\n S1/N1-backend-service [BPE-02]\n S3/N1-backend-service [BPE-02] (parallel scenarios OK; respect conflict_map)\n\nConflicts: {file} shared by {S_N, S_M} — serialized in groups\nNext: MIN-04 Execute (one fresh subagent per ready node)\n======================\n```\n\n## Success Criteria\n- `parallel_groups` and `conflict_map` parsed from manifest (not recomputed)\n- Each scenario dependency state checked via `gh issue view` (one at a time)\n- Execution queue ordered correctly: group order + dependency order within groups\n- Mermaid diagrams presented in Plan mode (scenario + inner graph for READY scenarios)\n- READY **nodes** listed for MIN-04, not scenarios alone\n- Ready to proceed to MIN-04\n\n> The conflict map and parallel groups were established by PIN-02 from actual skeleton commits.\n> MIN-03 reads and validates them — it does not recompute them.\n\n## Agent\n\nNone\n\n## Skill\n\nNone\n\n## Rules\n\nNone\n\n## Artifacts Produced\n\nNone\n\n## Artifacts Consumed\n\nNone\n\n## Notes\n\nNo additional notes.", "variables": [], "notes": "Sequence from Manifest", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/FeatureFactory-io/mimir", "path": ".windsurf/workflows/Edda/MIN/MIN-03-Sequence_from_Manifest.md", "ref": "850a123927f83a3ed209f39a5a3590bfe21aeb92", "url": "https://github.com/FeatureFactory-io/mimir/blob/850a123927f83a3ed209f39a5a3590bfe21aeb92/.windsurf/workflows/Edda/MIN/MIN-03-Sequence_from_Manifest.md", "key": "FeatureFactory-io/mimir/.windsurf/workflows/Edda/MIN/MIN-03-Sequence_from_Manifest.md" } } }

MIN-03-Sequence_from_Manifest

About

Activity: Sequence from Manifest

Description

Guidance

Purpose

Steps

Step 1: Parse Parallel Groups and Conflict Map

Step 2: Check Dependency State

Step 3: Build Ordered Execution Queue

Step 4: Switch to Plan Mode and Present Queue

Step 5: Output Execution Plan

Success Criteria

Agent

Skill

Rules

Artifacts Produced

Artifacts Consumed

Notes

Install MIN-03-Sequence_from_Manifest and it becomes one more candidate the router can pick - when it fits.

Use it

Manifest

Reviews