ohyeh/agent-scripts

ask-nova

Interview-driven flow picker. Use when the user is unsure which skill/flow/pipeline fits — new project kickoff, cross-domain work, or a fuzzy situation. Reads the three routers live and recommends ONE flow. Not for tasks whose owner is already obvious.

First seen Aug 1, 2026

Installation

$ npx skills add ohyeh/agent-scripts --skill ask-nova

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from ohyeh/agent-scripts · top by installs.

npx skills add ohyeh/agent-scripts

Browse all from ohyeh/agent-scripts

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

License LICENSE
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 2,269 B
  • docs SUMMARY.md 270 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 124 installs

SKILL.md

Ask Nova

Conversational front door to the fleet. The user describes a situation; you interview them, then recommend ONE flow. You carry NO roster knowledge of your own — routing truth lives in the routers, read fresh every run:

  1. skills/using-skills/SKILL.md — the top-level intent map (adopted surface,

dormant list, lifecycle view).

  1. skills/using-design-skills/SKILL.md — pipelines for anything visual /

interface-shaped.

  1. skills/using-workflows/SKILL.md — loop-shaped work (audit, plan→build,

consensus, triage) and the recipe roster.

Read all three (deployed copies under ~/.agents/skills/ when not in the repo) BEFORE asking anything. Never restate or cache their rosters here.

The interview — grilling cadence

Map the situation as a decision tree and work it in rounds: each round, ask the whole current frontier at once — numbered questions, each with your recommended answer — then wait. Typical first frontier:

  • Is there a codebase already, or greenfield?
  • One session or multi-session? (multi → a .workflow/ run dir + handoff seams matter)
  • Is the deliverable visual/interface-shaped? (→ using-design-skills owns it)
  • Is the work loop-shaped — audit / consensus / triage / plan→build? (→

using-workflows owns it)

  • How settled is the idea? (fuzzy → brainstorming / grilling first)

Facts discoverable from the environment: look them up, don't ask. Decisions are the user's: ask and wait.

The recommendation

Finish with exactly ONE flow, stated as named stations from the routers, in order — e.g. grilling → using-workflows (plan-pipeline) → verification-before-completion — plus, in one line each: what was deliberately skipped and why, and where the flow's first command starts. If two flows genuinely tie, say the tie-breaker question instead of hedging. If nothing fits, say so and route to the map's NOT-FOUND rule — never improvise a half-flow.