Produces a complete set of phase-by-phase artifacts for a development cycle — scout document, backend grounding doc, parallel track specifications, implementation prompts, and a post-cycle reflection — by orchestrating the other strategic-thinking skills in sequence. Use when: 'walk me through the full workflow', 'we are starting a new release cycle', 'take me from our strategic question all the way to commissioned implementation prompts', 'what did we learn this cycle and what should we formalize'.
Instrucciones de origen · Vista previa de solo lectura
name
strategic-to-tactical-workflow
model
opus
description
Produces a complete set of phase-by-phase artifacts for a development cycle — scout document, backend grounding doc, parallel track specifications, implementation prompts, and a post-cycle reflection — by orchestrating the other strategic-thinking skills in sequence. Use when: 'walk me through the full workflow', 'we are starting a new release cycle', 'take me from our strategic question all the way to commissioned implementation prompts', 'what did we learn this cycle and what should we formalize'.
category
strategic-thinking
triggers
["walk me through the full workflow","we are starting a new release cycle","take me from our strategic question all the way to commissioned implementation prompts","what did we learn this cycle and what should we formalize"]
tier
1
agents
["primary"]
tool_dependencies
["file_system","meta_skill"]
inputs
[{"name":"strategic_question","type":"string","description":"The strategic question or tension that starts the development cycle","required":true}]
outputs
[{"name":"cycle_artifacts","type":"ref","format":"cas-ref","description":"Complete set of phase-by-phase artifacts — scout, backend grounding, parallel track specs, implementation prompts, and post-cycle reflection"}]
Strategic-to-Tactical Workflow Skill
I. The Philosophy: Closing the Loop
Software development is not a linear process. It is a loop: from strategic tension to tactical execution and back again. Each cycle produces not just working software, but accumulated wisdom about how to build better, faster, and with more clarity.
This skill documents the complete workflow that emerged from the v0.0.30 and v0.0.31 development cycles. It is the meta-pattern that connects all other patterns: how we scout, how we decide, how we specify, how we parallelize, how we commission, and how we learn.
The goal is not just to execute this workflow, but to improve it with each iteration. Every time we complete the loop, we should emerge with new skills, new patterns, and new understanding.
II. When to Use This Skill
At the beginning of any major development cycle (e.g., v0.0.X releases)
When facing a strategic tension or product decision
When planning a large feature or architectural change
When you need to move from "what should we build?" to "how do we build it?"
When coordinating work across multiple agents (Manus, implementation agents like Zenflow or Claude Code)
III. The Complete Workflow
This is an 8-phase workflow from strategic tension to tactical execution.
Phase 1: Recognize the Tension
Goal: Identify and articulate the strategic tension or question that needs exploration.
Pattern: The best work begins not with a command ("build X"), but with a tension ("should we do X or Y?").
Actions:
Listen for the tension in the user's request
Articulate it as a clear, open-ended question
Resist the urge to immediately solve it
Example (v0.0.31):
Tension: "Should Dojo Genesis be a feature lab (25 pages) or a focused desktop product (single-page)?"
Not: "Build a desktop app"
Output: A clearly articulated strategic tension.
Related Skills:strategic-scout
Phase 2: Scout Multiple Routes
Goal: Explore 3-5 distinct strategic routes before committing to any one path.
Pattern:Scouting prevents waste. 30 minutes of route exploration can save weeks of misguided work.
Actions:
Use /strategic-scout to generate 3-5 routes
For each route, define: approach, risks, impact, duration
Identify tradeoffs and dependencies
Present routes without recommending one initially
Example (v0.0.31):
Route 1: Big Bang (rebuild everything)
Route 2: Incremental (gradual migration)
Route 3: Parallel Tracks (split into independent workstreams)
Route 4: Hybrid (mix of approaches)
Route 5: Minimal (smallest possible change)
Output: A set of viable routes with clear tradeoffs.
Related Skills:strategic-scout, iterative-scouting
Phase 3: Gather Feedback & Listen for Reframes
Goal: Present the routes and listen for the question behind the question.
Pattern: The first scout is for provocation, not consensus. The goal is to elicit a deeper, more insightful framing.
Actions:
Present the scouted routes
Listen not just for agreement/disagreement, but for how the feedback is framed
Identify if the user is introducing a new lens or reframe
If a reframe emerges, prepare to re-scout
Example (v0.0.31):
Initial framing: "Deprecate web app vs. keep as companion"
Reframe: "Desktop for deep work vs. Mobile for on-the-go orchestration"
Result: Re-scout with the new lens (led to mobile PWA as premium tier)
Output: Either a decision on a route, or a reframe that triggers a second scout.
Related Skills:iterative-scouting, product-positioning
Phase 4: Make the Strategic Decision
Goal: Commit to a strategic direction based on the scouting and feedback.
Pattern:Decisions unlock velocity. Once the route is chosen, move quickly to specification.
Actions:
Select the best route (or hybrid of routes)
Articulate the decision clearly
Document the why behind the decision
Identify what this decision enables (and what it rules out)
Example (v0.0.31):
Decision: Parallel Tracks approach (Route 3)
Why: Balances speed (parallelization) with risk management (clear boundaries)
Enables: 3 agents working simultaneously
Rules out: Big Bang (too risky), Incremental (too slow)
Output: A clear strategic decision with rationale.
Related Skills:strategic-scout
Phase 5: Ground in the Codebase
Goal: Before writing specifications, deeply understand the current state of the codebase.
Pattern:Grounding beats assumptions. Specs based on outdated or assumed knowledge lead to rework.
Actions:
Use /repo-context-sync to pull latest code and understand structure
Phase 1-2: Scout document (thinking/[topic]_strategic_scout.md) with tension, routes, and selected direction
Phase 5: Backend grounding document (docs/vX.X.X/[release]_backend_grounding.md) mapping API endpoints, data models, and integration points
Phase 6: Track specification documents (docs/vX.X.X/[release]_track_[N]_spec.md), one per parallel workstream
Phase 7: Implementation prompt files (docs/vX.X.X/prompts/track_[N]_prompt.md), self-contained and commission-ready
Phase 8: New skills or seeds in the knowledge base, and a compression note summarizing key learnings from the cycle
Examples
Scenario 1: "We're starting v0.0.32. We're not sure whether to prioritize the API layer or the frontend shell." → Full 8-phase run: tension named ("API completeness vs. UI polish"), 5 routes scouted, decision made (parallel tracks: API track + UI shell track), codebase grounded, two spec docs written, two implementation prompts commissioned, post-cycle reflection extracts one new pattern as a seed.
Scenario 2: "We shipped v0.0.31. What did we learn and what should we formalize?" → Phase 8 only: compression ritual surfaces 3 patterns from the cycle, one is strong enough to become a skill (written and committed), two become seeds, all artifacts committed to the repository.
Edge Cases
If the user is mid-cycle (e.g., specs are written but prompts are not), enter at the appropriate phase rather than restarting from Phase 1 — ask which phase they are on before proceeding.
If the codebase has not been read recently (Phase 5 skipped in a prior cycle), treat grounding as mandatory even if the user wants to move quickly — specs built on stale assumptions produce rework.
For small changes (a single-file bug fix or a minor UI tweak), this 8-phase workflow is overkill — redirect to strategic-scout for just the decision, then directly to an implementation prompt. Reserve the full workflow for releases that span multiple files or architectural decisions.
Anti-Patterns
Running Phase 6 (spec writing) before Phase 5 (codebase grounding) — specifications written without reading the current code routinely miss existing abstractions, causing implementation agents to rebuild what already exists.
Treating Phase 8 as optional — skipping reflection means the patterns from this cycle are not available to the next cycle, which defeats the compounding-velocity goal of the workflow.
Commissioning all parallel tracks simultaneously before Track 0 (the foundation track) is verified — always complete the dependency-order gate before releasing parallel agents.
Using this skill as a checklist to tick boxes rather than a thinking tool — the value is in the quality of the tension articulation and the depth of the codebase grounding, not in completing all 8 phases mechanically.
IX. The Vision
This workflow is not static. It will evolve with each cycle. The goal is to reach a state where:
Strategic decisions are fast and confident (because we have patterns to recognize and skills to apply)
Specifications are grounded and actionable (because we have systematic grounding processes)
Implementation is parallel and autonomous (because we have clear boundaries and comprehensive prompts)
Learning is continuous and formalized (because we extract and document patterns after every cycle)
This is the path to compounding velocity: each cycle makes the next cycle faster, clearer, and more effective.
