Feasibility Probe

SkillDev tools

Use when you need to validate whether a spec is technically viable before implementing it.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Feasibility Probe skill

What this skill tells your AI

The instructions your AI receives, as published by gonzalezpazmonica/savia in .claude/skills/feasibility-probe/SKILL.md and read by ahel’s review.

Validates a spec by attempting a time-boxed prototype. Produces a viability report that feeds sprint planning with evidence-based estimates.

Decision Checklist

Before running the probe:

  1. Is the spec approved (status: approved)? If NO -> abort, spec needs review first.
  2. Does the spec have testable acceptance criteria? If NO -> abort, spec is too vague.
  3. Are external dependencies documented? If NO -> warn, will mock everything.
  4. Is the budget appropriate for spec size? If >20 requirements -> suggest splitting.
  5. Has this spec been probed before? If YES -> show previous score, ask if re-probe.

Parameters

ParamRequiredDefaultDescription
spec_pathYes-Path to the spec file
budget_minutesNo15Max time for prototype attempt (time-box, orthogonal to model thinking)

Thinking budget (SE-067 — Opus 4.7 adaptive): Fixed budget_tokens removed. Opus 4.7 uses adaptive thinking — the model decides when and how much to think per step. Simple probes get fast responses, complex reasoning steps get deep thought. Over a multi-step probe run this adds up to lower token usage vs the old fixed 50000-token budget with no quality loss.

To steer thinking rate when needed, append to the probe prompt:

  • More thinking: "Think carefully and step-by-step; this is harder than it looks."
  • Less thinking: "Prioritize responding quickly rather than thinking deeply."

Execution Flow

1. Read spec -> extract requirements checklist
2. Launch feasibility-probe agent (Task) with budget
3. Agent attempts prototype in /tmp/
4. Agent writes report to output/feasibility/
5. Parse score and route:
   - >= 80: "Ready for sprint planning"
   - 40-79: "Recommend decomposition" + suggestions
   - < 40:  "Requires research" + escalate to human
6. Store report in memory for model-upgrade-audit tracking

Output

Report saved to: output/feasibility/{spec-id}-probe.yaml

Summary shown in chat:

Feasibility: {score}/100 | {resolved}/{total} requirements
Complexity: {level} | Time: {minutes}m
Blocking: {list of blocked sections}
Recommendation: {action}

Integration Points

  • Pre-sprint: Run on all specs before sprint planning
  • SDD pipeline: Optional gate between spec-approve and dev-session
  • Memory: Results stored for longitudinal tracking
  • Model audit: SPEC-002 consumes historical probe data

Scoring Formula

score = (resolved * 100 + partial * 50) / total_requirements
complexity = score >= 90 ? "trivial"
           : score >= 70 ? "low"
           : score >= 50 ? "medium"
           : score >= 30 ? "high"
           : "requires-research"

Signals

GitHub stars
50
Forks
12
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
feasibility-probe-gonzalezpazmonica
Source
github.com/gonzalezpazmonica/savia