kiro-discovery

Guide project-context analysis to determine spec extension or creation paths.

Updated Jan 26, 2026
One-click install
npx skills add https://github.com/miyamo2/braider --skill kiro-discovery-miyamo2
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kiro-discovery
Source: https://github.com/miyamo2/braider/tree/main/.gemini/skills/kiro-discovery
Command: npx skills add https://github.com/miyamo2/braider --skill kiro-discovery-miyamo2

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill guides teams through discovery to determine the best action path for new work, clarifying whether to update an existing spec, create a new spec, perform a mixed decomposition, or proceed without a new spec.

Core Features & Use Cases

  • Action-path determination: Evaluates project context and identifies the correct discovery path (Path A–E) for the request.
  • Structured dialogue: Facilitates sequential clarifying questions to define boundaries and reduce ambiguity.
  • Operational output: Produces concrete next steps (spec initiation, batching, or direct implementation) and written briefs when required.

Quick Start

Provide a concise prompt describing the work to begin discovery.

Frequently Asked Questions about kiro-discovery

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I decide whether to extend an existing spec or create a new one during project discovery?

Project discovery determines whether to update an existing spec or create a new one by analyzing project context, scope boundaries, and task decomposition to produce structured roadmaps and briefs.

What is the best way to define clear boundaries and reduce ambiguity for a new feature request?

Defining clear boundaries involves facilitating structured dialogue with sequential clarifying questions during discovery, evaluating project context to identify the correct action path and reduce ambiguity.

How do I start task decomposition and scoping for a complex software roadmap?

Start task decomposition by providing a concise prompt describing the work to begin discovery, which then evaluates boundaries and outputs concrete next steps like spec initiation or direct implementation.

Do I need a written brief for every project scope or only for mixed decomposition paths?

Written briefs are produced when required by the discovery process, specifically guiding teams through action-path determination to decide whether to update specs, create new ones, or perform mixed decomposition.

When should I proceed with direct implementation without creating a new spec?

Proceed with direct implementation without a new spec when discovery determines the request fits existing boundaries, outputting concrete next steps that bypass spec initiation or batching.