drewbarontini/equilio-coding

equilio-frame

Define a software problem and its desired outcome before committing to a solution; use for a rough request, proposed feature, bug, or unclear issue.

View source

How to use

  1. Copy the installation command and review the source package before installing it in your own agent environment.
  2. Check the source document for required tools, credentials and supported hosts.
  3. Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/drewbarontini/equilio-coding --skill equilio-frame

Before you start

  • Installation does not include a model subscription, API allowance or permission to access your files.
  • Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document

Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.

Frame

Turn an initial signal into an issue-ready account of the problem. Establish what already exists: a request, issue, local file, prototype, or code. Match the depth to the work's impact and uncertainty.

Investigate who is affected, what is happening, evidence, desired outcome, constraints, proposed solutions, and open questions. Test whether a proposed solution addresses the underlying problem before treating it as settled. Distinguish observations from assumptions and decisions.

Write a local Markdown draft the user can inspect. Keep it readable as an emerging issue, not a questionnaire with empty sections. If the project already has an issue, revise the draft against that issue and preserve its useful history and links. When framing is ready, use the project's chosen GitHub, Linear, or local Markdown issue; establish the destination before creating or changing a remote issue. Bring consequential framing to the user for review when appropriate, without making every small edit a gate.

Leave a clear problem, desired outcome, known evidence, current direction if any, and the questions that could alter it. Carry accepted conclusions into the shared issue in prose rather than copying the whole draft. If work stays local, the Markdown issue itself can be the shared account. Never imply a solution or shipment is validated before it is.

Related by task