agentsclimarketplace

Requirements review

Skill sainzs/santiagosainz-skills/skills/core/requirements-review

Auditable, portable agent skills that turn open-source maintenance - review, debugging, verification, handoff - into repeatable workflows for Codex, OpenCode, and Pi

Install
npx -y skills add sainzs/santiagosainz-skills --skill requirements-review

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

  • 0 stars0 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

Review requirements before implementation by turning fuzzy intent into decisions, constraints, risks, and a first executable step. Use when the user asks to clarify scope, review requirements, resolve ambiguity, identify constraints, or use align-change.

SKILL.md

2.0 KB, as published. Nobody here has run it

requirements-review

Resolve ambiguity quickly enough that implementation can start.

Unix/Pi Contract

  • Do one job: turn unclear intent into the next executable step.
  • Consume repo facts and user intent; emit decisions, blockers, next step, and proof command.
  • Stay terse. Ask only the question that changes the next action.
  • Do not hide capability gaps. If evidence, tools, credentials, or runtime access are missing, say exactly what is missing.
  • Stop discovery when the entry point and first proof are clear.

Use

Use for feature ideas, refactors, product decisions, workflow changes, migrations, and plans that are not yet concrete enough to edit safely.

Do Not Use

Do not use when the request is already a clear edit, a failing command, a review, or a pure explanation.

Workflow

  1. Read the current repo or config surface that will be changed.
  2. Extract the user goal, non-goals, constraints, existing contracts, likely risks, and missing choices.
  3. Ask only the decisions that block a safe first step. Prefer one concise question over a broad interview.
  4. If enough context exists, choose conservative defaults and state them.
  5. End with a first executable step and the verification command that proves it.

Decision Quality

  • Prefer repo truth over stale docs.
  • Prefer the smallest user-visible behavior that can be verified end to end.
  • Prefer preserving existing interfaces unless the interface is the problem.
  • Name irreversible, external, security, or data-loss risks explicitly.

Output

Return:

  1. Goal in one sentence.
  2. Decisions already resolved.
  3. Open blocker, if any.
  4. First step to implement.
  5. Verification command.

If the user asked for execution, continue into the first step after the review.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.