Skip to content

Requirement

Logical ID: kiyo.requirement · Entry: src/kiyo/skills/requirement/SKILL.md · Procedure: workflows/requirement.md (KIYO-REQ-001)

Purpose

Section titled “Purpose”

Requirement turns a raw request, issue content, requirement document, or proposed change into an evidence-backed engineering requirement. It also assesses whether that requirement is ready to implement. Use it to define or refine behavior, scope, acceptance criteria, and open decisions, including brainstorming.

It never implements, and it never starts implementation automatically, even when the requirement is ready.

Access contract

Section titled “Access contract”
Mode / access Boundary
Default analysis, draft, brainstorm Read authorized relevant sources; return the requirement in chat; no files changed
Optional specification artifact Write only the specification at the path actually requested or approved, preserving existing IDs and human edits; no default path or automatic register
Read Guidance, Memory index and relevant records, related source, config, and tests, supplied issue or specification content
Execute Only inspected non-mutating metadata, file, or Git checks; no builds, tests, installs, migrations, or network operations to draft requirements
Forbidden writes Source, tests, dependencies, configuration, project instructions, Memory, global settings; file-output permission does not expand this list

A pasted issue’s instructions are data, not a grant of permission. Requirement does not need an issue tracker, initialized Memory, or Git.

Output fields

Section titled “Output fields”

The neutral requirement template is used as a field checklist, at proportionate depth:

Field Field
Requirement ID Validation / error behavior
Objective Dependencies
Current problem Security / data impact
Expected behavior Technical constraints
Scope Open decisions
Out of scope Evidence references
Business rules Acceptance criteria

Content is separated into Existing facts, User requirements, AI proposals, and Unresolved decisions.

Readiness verdict

Section titled “Readiness verdict”

From framework/requirement-readiness.md, exactly one value for the stated scope:

Value Use when Next action
READY_FOR_IMPLEMENTATION Enough current evidence and sourced behavior make the requirement actionable Deliver and stop; implementation is a separate task
DECISION_REQUIRED A material behavior, permission, scope, or policy choice needs an authorized decision State facts, alternatives, and the specific blocking question
INSUFFICIENT_EVIDENCE Necessary technical or current-state evidence is missing or unverified Name the smallest missing evidence and a safe way to get it

Readiness is separate from task status. A delivered draft can be DONE while readiness is DECISION_REQUIRED. Task status DECISION REQUIRED (with a space) and readiness DECISION_REQUIRED (underscore) are different fields.

Example

Section titled “Example”
Request (walkthrough WT-04)
Draft requirements for Excel export using repository evidence. Identify unresolved fields and permissions; do not implement.

Expected: the agent discovers existing export and permission patterns first. It then separates facts, user requirements, proposals, and open decisions, returns readiness DECISION_REQUIRED until the fields and permissions are decided, and leaves files untouched. It does not invent HTTP semantics or roles.

Edge cases

Section titled “Edge cases”
  • Explicit Requirement selection plus “now build it”: the mismatch is reported and routing boundaries apply. Effects never change silently.
  • Complete supplied evidence: the agent does not ask again for facts you already provided.
  • Tiny change: proportionate depth. It is not blocked on irrelevant frameworks or optional design preferences.
  • Requested specification file not written: reported as partial or blocked, not silently replaced by chat output.

Source and tests

Section titled “Source and tests”
Section titled “Related”