Next step

Skill RubenGlez/harness/skills/next-step

My personal development harness for Claude Code and Codex. Use at your own risk.

Install

npx -y skills add RubenGlez/harness --skill next-step

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Recommends the next harness skill to use by inspecting the repo, docs, git state, and recent work. Use when asking what to do next, which skill comes next, or when the workflow phase is unclear.

SKILL.md

3.4 KB, as published. Nobody here has run it

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/), 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:

Recommended skill
Why it is the best next step
Evidence that led to the recommendation
Confidence: high / medium / low
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/ 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.