next-step

Files (1)

• SKILL.md

SKILL.md (first lines)

# Next Step

## Purpose

Recommend the most likely next harness skill, with a short explanation and confidence level. Do not carry out the recommended skill unless the user explicitly asks you to switch to it.

## What to inspect

Read the smallest set of sources that can explain the current project state:
- `AGENTS.md`
- `README.md`
- `.harness/` if it exists, especially product, engineering, and QA docs
- `git status`, recent commits, and any obvious changed files
- package or build files that describe the current stack

If the repo has no `.harness/` docs, infer the phase from the codebase and README.

**Cross-check the three status sources before recommending.** Phase state is not stored in one place — it lives in per-feature `Status:` lines (`.harness/engineering/features.md`), phase markers in `.harness/product/roadmap.md`, and the latest `.harness/qa/report.md`. These drift: a feature can read `done` while the roadmap still calls its phase planned, or QA can report failures the specs don't reflect. If they disagree, do not silently pick one — say so in the output and recommend `/update-docs` to reconcile them before trusting any phase recommendation.

## Recommendation rules

Prefer the lowest unfinished step in the harness workflow:
- No validated idea or target user -> `/ideate`
- Idea exists, but vision is missing -> `/product-plan`
- Vision exists, but architecture or stack is unresolved -> `/dev-plan`
- Architecture is unclear only for one risky choice -> `/prototype`
- Specs exist and implementation is ready -> `/implement`
- Code changed and needs verification -> `/qa`
- QA report has outstanding failures (not just architectural gaps) -> `/task` if small and contained, else re-spec via `/dev-plan` then `/implement`
- Docs are stale after code changes -> `/update-docs`
- QA passed and docs are current, but the phase isn't released -> `/ship`
- Shipped product needs a meaningful new feature, behavior change, or extension (not a small tweak) -> `/evolve`
- Shipped product needs a small fix, tweak, or micro-feature -> `/task`
- Existing docs are scattered or outside harness structure -> `/migrate-docs`
- `.harness/` exists but isn't git-tracked (gitignored, or `git ls-files .harness` is empty) -> `/migrate-docs` to adopt doctier encrypted tracking
- Context is fragmented and a fresh agent would struggle -> `/handoff`
- You need a broader map of the area before changing code -> `/zoom-out`
- Stable codebase with architectural friction — tight coupling, shallow modules, hard-to-test seams -> `/improve-codebase-architecture`

If multiple skills fit, choose the one that removes the biggest blocker first.

## Output format

Return:
1. Recommended skill
2. Why it is the best next step
3. Evidence that led to the recommendation
4. Confidence: high / medium / low
5. One fallback skill if the recommendation is uncertain

Keep the answer short and direct.

## Example

> **Recommended**: `/qa`
> **Why**: Phase 1 features are marked `done` in `.harness/engineering/features.md` but no QA report exists yet.
> **Evidence**: `git log` shows 8 commits since the last `/implement` run; `.harness/qa/report.md` is absent.
> **Confidence**: high
> **Fallback**: `/update-docs` if the acceptance criteria turn out to already be verified.

From RubenGlez/harness, MIT.

More from RubenGlez/harness