renatocaliari/stelow-product-tech-planning

Tech Planning Sequencing

Tools: See references/cli-tools/subagents.md for subagent patterns, references/cli-tools/goals.md for goal commands.

This skill executes the Tech Planning phase.

How to Load

Via Orchestrator (recommended)

The orchestrator reads this file directly when needed.

Standalone

This skill works standalone. Use the Input Detection section below to tell the skill what technical context to plan from. Follow the instructions inline.

Prerequisites

Security check: Read the YAML frontmatter of spec-product.md:

head -10 spec-product_{v}.md | grep "approved:"

• ✅ approved: true → proceed
• ❌ No approved: true → GO BACK to Gate stage (Plannotator visual review). Do not proceed.

This check is deterministic — does not depend on memory.

AI-Aware Testing Check

For software products, also check product_type:

head -10 spec-product_{v}.md | grep "product_type:"

• ✅ product_type: software or product_type: hybrid → activate stelow-product-testing-ai-code
• ❌ product_type: service → skip testing strategy

References Index

Read the references/ files to guide the process:

| File | Covers | When to read | |---|---|---| | references/tech-context.md | Tech planning context, prerequisites, workflow position | Before starting — sets planning context | | references/scopes-and-sequencing.md | Scope types (feature/optimization/spike + test-*), executor routing, sequencing principles | During generation — defines scope structure | | references/tech-output.md | Tech plan output format, frontmatter, receipts | After generation — formats output | | stelow-product-coding-standards (skill) | Universal coding standards (KISS, DRY, LoB, SoC, Fail Fast, YAGNI) | During generation — guides implementation |

How scopes & tasks flow between planning and execution

The split (Shape Up hill chart collapsed into scopes):

| Layer | Owned by | Lifetime | Purpose | |---|---|---|---| | Scope | stelow-product-tech-planning (this skill) | Workflow lifetime (stelow.json) | Atomic delivery unit. Appetite ceiling: Lean ≤2, Core ≤5, Complete ~10. Cannot be created during execution — must be planned. | | Task | stelow-product-scope-executor Step 3e-ter (runtime) | Scope lifetime (wf.scopes[i].tasks) | Sub-item checklist inside a scope. Seeds from spec-tech.md table; can be added during execution as source: 'discovered'. |

At planning time (this skill):

• The scope body in spec-tech_{v}.md contains a Tasks table — the initial hill-chart breakdown per scope. This table is the input to runtime tracking.
• You do NOT add a tasks: [] field to wf.scopes[i] at planning time. The executor parses the table at scope start and seeds the field.

At execution time (scope-executor Step 3e-ter):

• Scope start: parse the Tasks table, seed each row as source: 'planned', status: 'pending'.
• During execution: when the child LLM discovers new work (test flake, missing index, refactor needed for an AC), append a task with source: 'discovered', note: <trigger>.
• At scope close: the final tasks[] snapshot is the executable proof of what actually happened. discovered_tasks_count aggregates the count.

Why this split: scopes are committed up front (Shape Up's "you can change the hill chart but not the scope shape"). Tasks emerge from reality — they're the visible, low-cost-by-design artifacts of "what we learned by building".

Rule: if a discovered task grows large enough to be its own delivery unit, escalate it as a new scope. Do not bloat the current scope. The hill chart's job is to make scope size honest, not to encourage scope creep in disguise.

See also:

• skills/stelow-product-scope-executor/SKILL.md#3e-ter — task seeding, append, mark-done.
• skills/stelow-product-tech-planning/references/scopes-and-sequencing.md#Scope Detail Template — the markdown table format.

Process

tech:5 — Discover Stack

Before any scopes are generated, determine the tech stack. Stack is a technical decision — owned by Tech Planning, not Shape Up. Shape Up only takes "tech hints" (mobile/web/API), final stack is here.

Detect from existing project:

STACK_SOURCE=""
if [ -f "go.mod" ]; then
  STACK_SOURCE="existing:go"
  MODULE=$(head -1 go.mod | awk '{print $2}')
elif [ -f "package.json" ]; then
  STACK_SOURCE="existing:node"
  NODE_DEPS=$(jq -r '.dependencies? // {} | keys[]' package.json 2>/dev/null | head -10)
  HAS_NEXT=$(echo "$NODE_DEPS" | grep -i next || echo "")
  HAS_REACT=$(echo "$NODE_DEPS" | grep -i react || echo "")
elif [ -f "Cargo.toml" ]; then
  STACK_SOURCE="existing:rust"
elif [ -f "Gemfile" ]; then
  STACK_SOURCE="existing:ruby"
elif [ -f "requirements.txt" ] || [ -f "pyproject.toml" ]; then
  STACK_SOURCE="existing:python"
elif [ -f "composer.json" ]; then
  STACK_SOURCE="existing:php"
elif [ -f "pubspec.yaml" ]; then
  STACK_SOURCE="existing:flutter"
elif [ -f "CMakeLists.txt" ]; then
  STACK_SOURCE="existing:cpp"
fi

If existing project detected ($STACK_SOURCE is set):

• Stack is inferred. No questions asked.
• To get updated docs for the established stack, doc-search (see below) is available during execution. Not required now — noted for reference.

If new project (no existing source):

Use web_search in parallel to research current best options:

Parallel queries:
  A: "best web tech stack 2026 production ready"
  B: "supabase vs pocketbase 2026 comparison pricing"
  C: "react vs svelte vs solid 2026 production adoption"
  D: "[derived from context] best stack for {domain}"

Consolidate into a recommendation with alternatives. Use ask_user_question (see references/cli-tools/ask.md) to present:

Recommendation: {chosen stack} (Recommended) Alternatives: {alt1} | {alt2} Justification: {why this fits the product}

If user confirms: proceed. If user picks alternative: use their choice. If user customizes: note their choice, proceed.

Save stack to spec-tech frontmatter:

tech_stack:
  primary: "go 1.26 + templ + datastar"
  database: "sqlite (turso)"
  deployment: "docker"
  stack_source: "$(STACK_SOURCE:-"new:web_search")"

doc-search + stack-skills: See references/cli-tools/doc-search.md and references/cli-tools/stack-skills.md for usage during execution phase.

---

planning:10 — Scope Generation

Use the references above to generate technical scopes.

Delegate to a planner subagent (see references/cli-tools/subagents.md):

• Agent: planner (note: pi-subagents' packaged planner defaults to fork — always pass context: "fresh" explicitly)
• Task: generate typed scopes (feature/optimization/spike) from the approved spec-product.md
• Follow steps: strategic stability check → codebase awareness → risk analysis → spike identification → scope definition → sequencing → DoD + ACs → formatting
• Output: .stelow/{YYYY-MM-DD}/{_dir}/plans/spec-tech_{v}.md
• Inputs (all via reads:):
  • .stelow/{YYYY-MM-DD}/{_dir}/plans/spec-product_{v}.md (canonical product spec)
  • .stelow/{YYYY-MM-DD}/{_dir}/interfaces/selected-interface.md (user's chosen interface direction from int-gate — exists by this stage; absent only if interface stage was skipped via Review Mode)
  • context/tech-recon.md (tech constraints from shape:12)
• context: "fresh" — planner must NOT inherit orchestrator's deliberation

⚡ Estimation Bias Correction: The planner subagent may tend to generate conservative scopes or suggest cuts by overestimating complexity (bias from human training data). Rules:

1. Do not cut scope out of fear of complexity — distrust your own bias.
2. If a feature seems "too complex", justify why and present an alternative without assuming the estimate is correct.
3. Scope count vs appetite is an indicator, not a gate. 4 well-defined Lean scopes is not a violation.
4. Prefer quality solutions over "cheap" ones. The model should not avoid complexity — it should manage it.

planning:10.5 — Codebase Feature Recon (brownfield only)

Before generating scopes, investigate existing features the new scope must integrate with or might duplicate. Appetite controls depth, not whether recon runs — the floor is cymbal search --text (does it exist?) at every appetite to prevent scope duplication.

• Lean: cymbal search --text — "does it exist?" (Quality Floor)
• Core: search + cymbal refs — where is it, who connects
• Complete: search + refs + cymbal impact — blast radius

# Detect brownfield
if [ ! -f "go.mod" ] && [ ! -f "package.json" ] && \
   [ ! -f "Cargo.toml" ] && [ ! -f "requirements.txt" ] && \
   [ ! -f "pyproject.toml" ] && [ ! -f "Gemfile" ]; then
  echo "Greenfield — skipping Codebase Feature Recon"
  exit 0
fi

# Read appetite from workflow config (canonical source via helper)
# shellcheck disable=SC1091
source "$(dirname "${BASH_SOURCE[0]:-$0}")/../../stelow-product-orchestrator/references/cli-tools/read-config.sh"
APPETITE=$(stelow_read_appetite)

# Read spec-product for IN scope concepts
SPEC_PRODUCT=$(ls .stelow/*/*/plans/spec-product*.md 2>/dev/null | head -1)

if [ -n "$SPEC_PRODUCT" ]; then
  # Extract key concepts from IN scope
  IN_SCOPES=$(grep -A30 '## IN scope' "$SPEC_PRODUCT" 2>/dev/null | head -30)
  
  # 1. Search each concept (RUNS ON ANY APPETITE)
  echo "$IN_SCOPES" | while read -r line; do
    [ -n "$line" ] && cymbal search --text "$line" 2>/dev/null | head -10 >> context/feature-locations.md
  done
  
  # 2. Search by workflow name (RUNS ON ANY APPETITE)
  cymbal search --text "$(grep -oP '"name":\s*"([^"]+)"' .stelow/*/*/index.json 2>/dev/null | head -1 | grep -oP '"[^"]+"$' | tr -d '"')" 2>/dev/null | head -20 >> context/feature-locations.md
  
  # 3. refs — CORE and COMPLETE only
  if [ "$APPETITE" = "Core" ] || [ "$APPETITE" = "Complete" ]; then
    for symbol in $(head -20 context/feature-locations.md | grep -oP '\b[A-Z][a-zA-Z]+\b' | sort -u | head -10); do
      cymbal refs "$symbol" 2>/dev/null >> context/feature-refs.md
    done
  fi
  
  # 4. impact — COMPLETE only
  if [ "$APPETITE" = "Complete" ]; then
    for module in $(cat context/feature-locations.md | grep -oP '^[^:]+?\.(go|ts|rs|py|js)' | sort -u | head -10); do
      cymbal impact "$module" 2>/dev/null >> context/feature-impact.md
    done
  fi
fi

Output: context/feature-locations.md (always), context/feature-refs.md (Core+Complete), context/feature-impact.md (Complete).

How the planner subagent uses it: reads these files before generating scopes.

• "Module pricing.go already implements similar logic — reuse instead of recreating"
• "Feature checkout connects to payment.go and inventory.go — new scope must respect existing interfaces"
• "Business rule max_items in cart.go conflicts with scope 3 proposal"

Fallback: if cymbal is unavailable, skip silently.

planning:10.10 — Output Validation Guard

After the subagent writes spec-tech.md, validate every scope has required fields:

SPEC_TECH=".stelow/{YYYY-MM-DD}/{_dir}/plans/spec-tech_{v}.md"
VALID=true

# Check each scope for required fields
for SCOPE_LINE in $(grep -n "^### " "$SPEC_TECH" | sed 's/:.*//'); do
  # Each scope must have TYPE, DoD, and AC
  tail -n +$SCOPE_LINE "$SPEC_TECH" | head -50 | grep -q "TYPE:" || {
    echo "VALIDATION_FAILED: scope at line $SCOPE_LINE missing TYPE"; VALID=false;
  }
  tail -n +$SCOPE_LINE "$SPEC_TECH" | head -50 | grep -q -E "(DoD|Definition of Done)" || {
    echo "VALIDATION_FAILED: scope at line $SCOPE_LINE missing DoD"; VALID=false;
  }
  tail -n +$SCOPE_LINE "$SPEC_TECH" | head -50 | grep -q -E "(AC|Acceptance Criteria)" || {
    echo "VALIDATION_FAILED: scope at line $SCOPE_LINE missing AC"; VALID=false;
  }
  # Tasks table is recommended (Shape Up hill chart collapse).
  # Not a hard requirement — empty table is allowed when the scope is
  # small enough that the DoD itself is the task list. WARN, not FAIL.
  if ! tail -n +$SCOPE_LINE "$SPEC_TECH" | head -80 | grep -q "^| # .* Task "; then
    echo "VALIDATION_WARN: scope at line $SCOPE_LINE has no Tasks table (Shape Up hill chart). Consider adding one for runtime tracking."
  fi
done

# Check for circular dependencies (>5 levels of nesting = probable error)
if grep -q "depends_on.*depends_on.*depends_on.*depends_on.*depends_on" "$SPEC_TECH" 2>/dev/null; then
  echo "VALIDATION_WARN: possible circular or deeply nested dependencies"
fi

if [ "$VALID" = false ]; then
  echo "Required scope fields missing. Regenerating with validation errors flagged..."
  # Feed validation errors back to planner and regenerate once
fi

# Check appetite violation: scope count vs appetite
APPETITE=$(grep -oP '^appetite:\s*\K\S+' .stelow/{YYYY-MM-DD}/{_dir}/plans/spec-product_{v}.md 2>/dev/null || echo "Core")
SCOPE_COUNT=$(grep -c "^### " "$SPEC_TECH")

# Appetite boundary check: scope count should stay within appetite
# Lean ≤ 2, Core ≤ 5, Complete > 5
case "$APPETITE" in
  Lean) [ "$SCOPE_COUNT" -gt 2 ] && echo "APPETITE_VIOLATION: Lean appetite but $SCOPE_COUNT scopes. Consolidate or split into multiple cycles." ;;
  Core)  [ "$SCOPE_COUNT" -gt 5 ] && echo "APPETITE_VIOLATION: Core appetite but $SCOPE_COUNT scopes. Consider reducing scope." ;;
  Complete)  ;;  # Complete has no upper limit by scope count alone
esac

Rationale: Scopes missing TYPE, DoD, or ACs will fail at Execution time. Catching this at planning time saves wasted executor cycles.

⚠️ FALLBACK — if subagent fails or is unavailable: Generate spec-tech.md INLINE using the same process. Read the references files (tech-context.md, scopes-and-sequencing.md, tech-output.md) and read stelow-product-coding-standards for universal coding principles, then produce the spec-tech artifact directly in the current context.

planning:15 — Bidirectional Alignment Check (mode-gated)

After scopes are generated and validated, check whether the tech plan aligns with the product spec — or reveals constraints that invalidate it. This is the feedback loop that prevents "tech discovered too late" problems.

Standalone awareness: inside stelow, reads mode from stelow.json#workflows[].config.review_mode and specs from .stelow/. When standalone, defaults to Full mode (maximum interaction) and reads specs from current directory or prompts for paths.

Read mode + locate specs:

WF_DIR="$(ls -td .stelow/*/*/ 2>/dev/null | head -1)"
REVIEW_MODE="Product Spec + Interface + Scopes"
SPEC_PRODUCT=""
SPEC_TECH=""

# shellcheck disable=SC1091
source "$(dirname "${BASH_SOURCE[0]:-$0}")/../../stelow-product-orchestrator/references/cli-tools/read-config.sh" 2>/dev/null || true
if [ -n "$WF_DIR" ] && [ -f "stelow.json" ]; then
  REVIEW_MODE=$(stelow_read_review_mode 2>/dev/null || echo "Product Spec + Interface + Scopes")
  SPEC_PRODUCT=".stelow/{YYYY-MM-DD}/{_dir}/plans/spec-product_{v}.md"
  SPEC_TECH=".stelow/{YYYY-MM-DD}/{_dir}/plans/spec-tech_{v}.md"
  STELOW_MODE=true
else
  # Standalone: look for spec files in current dir, prompt if missing
  SPEC_PRODUCT=$(ls -t spec-product*.md 2>/dev/null | head -1)
  SPEC_TECH=$(ls -t spec-tech*.md 2>/dev/null | head -1)
  STELOW_MODE=false
fi

If both SPEC_PRODUCT and SPEC_TECH are empty (standalone + no spec files found): Prompt the user for paths or skip the alignment check.

ask tool: {question: "No spec files found. Provide paths to spec-product.md and spec-tech.md, or skip alignment check?", options: [
  {label: "Skip alignment check", description: "Proceed without bidirectional validation. Tech planning output is final."},
  {label: "Provide paths", description: "Specify paths to spec-product.md and spec-tech.md for alignment check."}
]}

If skipped, log: context/alignment-skipped.md with reason.

LLM compares spec-tech against spec-product. Classify as:

| Classification | Meaning | |--------------|---------| | aligned | Tech plan fits product spec. No changes needed. | | product_needs_update | Tech reveals constraint/opportunity that changes IN/OUT, scope, or design. Spec-product should be updated. | | blocking | Tech plan contradicts product spec fundamentally. Must reshape product spec. |

Mode-dependent behavior:

| Mode | aligned | product_needs_update | blocking | |------|-----------|----------------------|-----------| | Auto | Segue | Auto-update spec-product v+1. Segue. | Auto-update spec-product v+1. Segue. | | Product Spec Gate | Segue | Auto-update spec-product v+1. Log change in artifact. | Auto-update spec-product v+1. Log change in artifact. | | Product Spec + Interface Gates | Segue | Flag user (ask tool): "Tech planning suggests updating scope. Allow?" Recom: update. | Flag user: "Tech plan contradicts product spec. Reshape required?" Recom: reshape. | | Product Spec + Interface + Scopes | Segue | Ask user: show diff, let them choose update/ignore/reshape. | Ask user: show contradiction. Offer reshape or abort. | | Product Spec + Interface + Tech Review | Segue | Ask user with detailed tech impact. | Ask user with detailed tech impact. |

Appetite affects check depth:

| Appetite | Check depth | |----------|------------| | Lean | Quick: only check if any IN scope is technically impossible. | | Core | Standard: compare IN/OUT scopes vs feasibility. Check NFR constraints. | | Complete | Deep: check each scope's ACs vs codebase reality. Include performance, security, dependencies. |

If product_needs_update or blocking and Review Mode >= Product Spec + Interface Gates:

Use ask_user_question (see references/cli-tools/ask.md):

ask tool: {
  question: `Tech planning reveals: ${DISCREPANCY}

Current IN: ${IN_SCOPES}
Tech constraint: ${CONSTRAINT}

What do you want to do?`,
  header: "Alignment",
  options: [
    { label: "Update product spec (Recommended)", description: "Accept tech feedback. Spec-product will be updated to v+1. The new version reflects what's feasible and valuable." },
    { label: "Ignore, proceed as-is", description: "Keep current product spec. Tech planning continues with original scope. Risk: execution may uncover same constraint." },
    { label: "Reshape required", description: "Stop tech planning. Return to shape stage with tech constraints as input for a new proposal." }
  ]
}

If user chooses "Update product spec":

1. Read CURRENT spec-product.md
2. Update IN/OUT, scope, or design notes based on tech feedback
3. Save as spec-product_{v+1}.md
4. Update the spec-tech frontmatter to reference the new product spec version
5. Proceed with planning:20

If user chooses "Reshape required":

1. Log the blocking constraint to context/blocking-constraints.md — this file is consumed by shape:10 on the next cycle.
2. Save checkpoint at planning:15 with reshape_requested: true and constraints_ref: context/blocking-constraints.md.
3. Reset phase via existing command:

   /sw-setphase phasename=Shape
   

   This reuses the existing /sw-setphase mechanism — no new command needed. The currentPhase in stelow.json resets to Shape (index 4) and planning stage is reopened.
4. Inform user: "Blocking constraint saved to context/blocking-constraints.md. The workflow has been reset to the Shape stage. The orchestrator will now run shape:10 — it reads blocking-constraints.md automatically and resumes shaping with these constraints as input."

On next shape cycle: shape:10 checks for context/blocking-constraints.md automatically. If found, constraints are read and the file is removed to prevent stale context.

If user chooses "Ignore":

1. Log the warning to context/deferred-constraints.md
2. Proceed with planning:20
3. Constraint may surface again in audit stage

planning:20 — AI-Aware Testing Strategy (Software Only)

If product_type: software or product_type: hybrid:

1. Generate testing-strategy.md via subagent:

   Delegate to a testing-strategy subagent (see references/cli-tools/subagents.md):

   • Agent: stelow-product-testing-ai-code or equivalent
   • Input: spec-product.md frontmatter with product_type: software
   • Output: .stelow/{YYYY-MM-DD}/{_dir}/plans/testing-strategy.md
   • Content: risk-based coverage targets, tech stack detection, CI/CD gates, anti-patterns

   ⚠️ FALLBACK — if subagent fails or is unavailable (API key missing, agent not found): Generate testing-strategy.md INLINE. Read the stelow-product-testing-ai-code skill and produce the testing-strategy.md artifact directly in the current context. Do NOT skip — the testing strategy gates are required for execution.

2. Add test- scopes to spec-tech.md based on appetite:*

| Appetite | Add test scopes | |----------|----------------| | Lean | test-behavior (1 E2E test for happy path); test-unit for critical business logic; optional test-integration only when an external seam is in IN scope; test-security only for auth/payment/data in IN scope. | | Core | test-behavior (E2E for happy path + key variations); test-unit for main logic; test-integration for DB/API/external services; test-security for sensitive paths. | | Complete | test-behavior (full E2E coverage + edge cases); test-unit, test-integration, test-security. |

Note on TDD: Research shows TDD alone is insufficient for AI-generated code.

• Use TDD for critical business logic (isolated, deterministic)
• Use Test-After + risk-based tests for standard paths
• Never use same AI for both code AND test generation

planning:30 — Tech Planning Review Gate

⚠️ MANDATORY — ALWAYS run gate. Never skip.

Spec-tech is a distinct artifact: scopes, sequencing, dependencies, DoDs, and testing strategy were never reviewed visually in earlier phases. Prior gates (spec-product, interfaces) do NOT cover spec-tech content.

Run Plannotator gate for the tech plan BEFORE generating goals:

Prefer the plannotator tool. Fall back to bash CLI if tool unavailable:

# Primary (tool):
plannotator filePath=.stelow/{YYYY-MM-DD}/{_dir}/plans/spec-tech_v{N}.md

# Fallback (bash):
plannotator annotate .stelow/{YYYY-MM-DD}/{_dir}/plans/spec-tech_v{N}.md --gate --json

See references/cli-tools/plannotator.md for command format, after-approval workflow, and frozen file rules.

| Scenario | Action | |---------|--------| | Always | Run Plannotator gate for spec-tech | | Plannotator unavailable | Fallback: use ask_user_question to present scopes, sequencing, DoDs, and ask for explicit approval |

If approved:

1. Stamp approved: true, approved_at: ... in spec-tech frontmatter
2. Receipt is auto-created by the tool at .plannotator/approvals/{_dir}/gate-approved.md
3. Proceed to Goal Generation

If user requests changes:

1. Adjust the tech plan
2. Re-submit via the Plannotator gate command (see references/cli-tools/plannotator.md)
3. Repeat until approved

planning:40 — Goal Generation

After tech plan approval, convert each scope into a goal using the goals tool (see references/cli-tools/goals.md). Goals are mandatory — never use simple todo lists as a substitute; goals carry DoD, ACs, dependencies, verification commands, and evidence types that todo items cannot express.

For each feature/test scope in the approved spec-tech.md:

Create a goal using the goals tool (see references/cli-tools/goals.md). The goals reference documents acceptance patterns, evidence types, verify commands, and CLI fallbacks.

Optimization scopes with metrics: These become optimization goals using the goals tool (see references/cli-tools/goals.md → Optimization Goals section).

Rules:

• Scopes with dependencies: create goal AFTER the dependency is complete
• Use the goal pause command (see references/cli-tools/goals.md) if a scope gets blocked
• Use the goal tweak command (see references/cli-tools/goals.md) for scope adjustments during execution
• ⚠️ Never substitute todo items for goals — goals carry structured DoDs, ACs, and dependency tracking

Output

Tech plan is saved to:

.stelow/{YYYY-MM-DD}/{_dir}/plans/spec-tech_{v}.md

After Tech Planning — EXECUTE AUTOMATICALLY

DO NOT ask user what to do next. Execution is automatic.

⛔ STOP — Mandatory Scope Executor Routing

Before implementing ANY scope, route through the scope executor. The scope executor determines the correct tool and execution mode for each scope type. Do NOT start implementing scopes directly — always go through scope executor first.

planning:50.10 — Load the scope executor skill

Read the stelow-product-scope-executor skill for routing rules.

planning:50.20 — Route each scope by type

| Scope type | Route to | |------------|----------| | feature | worker + iteration loop (see scope-executor Step 3 — implement → verify → review → quality, repeat) + supervision (see references/cli-tools/supervise.md) | | optimization | subagent + acceptance with benchmark verify (see references/cli-tools/goals.md → Optimization Goals) | | spike | scout + researcher (see references/cli-tools/subagents.md) | | test-* | subagent + acceptance (see references/cli-tools/goals.md) with testing gates |

See stages/execution.md for full execution flow.

⚠️ DoD Verification — Mandatory Before Completion

After executing a scope, before marking it complete, verify EVERY item in the DoD and acceptance criteria:

1. Read the DoD and ACs from spec-tech.md for this scope
2. Verify each item with concrete evidence (build output, test results, file existence)
3. Only mark complete if ALL DoD items and ACs pass
4. If any DoD item fails → scope is NOT complete, fix the gap
5. If a scope has manual test steps in its DoD → EXECUTE them, do not skip

Failure to verify DoD = scope is still in_progress. The goal system enforces this.

Testing Gates (test-* scopes)

For test-* scopes, the execution includes hard blocks:

• test-security: security_findings == 0 on critical paths → BLOCK if found
• test-integration: flaky_rate < 5% → WARN if above

See the stelow-product-testing-ai-code skill

Related Skills

• stelow-product-shape-up: Produces the shaped proposal
• stelow-product-plan-critique: Reviews the proposal before tech planning
• stelow (orchestrator): Coordinates this skill with execution

Input Detection (Standalone Mode)

When called outside the workflow with no pre-approved spec-product.md:

Input:
  ├── User provided a spec-product*.md path?
  │   └→ Read it and extract scope, requirements, product_type
  ├── User described the feature verbally?
  │   └→ Extract: what needs to be built, tech stack, constraints
  └── No structured input?
      └→ Ask: "What software feature do you want to plan?
         Describe the requirements, tech stack, and any non-functional
         constraints (performance, security, scale)."

Note: Standalone mode requires the product_type check — ask the user if it's software, service, or hybrid so the AI-Aware Testing Strategy can activate correctly.

Environment Adaptation

If a tool is unavailable, check: references/cli-tools/