agentleFS
iha2iha2/superlite/skills/writing-specs/SKILL.md

writing-specs

Skill249 starsChanged 15 days agoMITView on GitHub

Use when agent_specs is on (or the user asks for a spec) to write what done looks like and why before a plan or implementation.

8 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use writing-plans.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • OpenAISkill

    writing-plans

    Use when you have a spec or requirements for a multi-step task, before touching code

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 0 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 8 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Check bash "$CLI" agent_specs status.

    line 12
  2. Very specific:

    Feature flow (default): write one feature-sized spec before implementers code (and before or beside the .feature.md / machine plan as the …

    line 13
  3. Very specific:

    No human gate on task-local notes.

    line 14
  4. Very specific:

    When status shows open_in_harness: on, after writing the file, open it for the user (superlite:drafting, After writing.

    line 27

“Common” is measured: kept by at least 6 in 10 of the 8 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Writing specs

A spec defines what “done” looks like and why. A plan chooses how to get there. One spec can outlive many plans: rewrite or replace the plan without rewriting success criteria. The spec is durable authority; if a plan drifts, fix the plan or report DONE_WITH_CONCERNS—never silently override the spec.

When

  • Check bash "$CLI" agent_specs status. If off, skip unless the user asked for a spec.
  • Feature flow (default): write one feature-sized spec before implementers code (and before or beside the .feature.md / machine plan as the success criteria). Optional task-local notes under .superlite/specs/<plan-topic>/ refine how for a long-running task; they must stay consistent with the feature spec.
  • No human gate on task-local notes. Feature-level specs and plans may be opened for the user when open_in_harness is on.

Paths

  • Feature (or sub-feature) spec: docs/plans/YYYY-MM-DD-<topic>.spec.md (or the path the user names).
  • Task-local note (optional): .superlite/specs/<plan-topic>/T<N>-<slug>.md.

Shape

Use templates/feature-spec.md. Prefer diagrams and tables; keep prose outside fences and tables ≤ 150 words for task-local notes. Feature specs may be longer but stay dense: intent/why, goals and non-goals, constraints, what “done” looks like (acceptance), decided vs left to the builder. Mermaid first for structure, flow, or state.

Open in harness

When status shows open_in_harness: on, after writing the file, open it for the user (superlite:drafting, After writing; the harness's open row is in using-superlite/references/<harness>-tools.md). The flag now covers plans and specs. superlite-cli agent_specs open off turns it off without disabling specs.

Style (flows §9)

RuleInstead of
Diagram first for structure, flow, or stateParagraphs of boxes and arrows
Tables for contracts, options, edge casesLong bullet prose
Precise technical registerVague paraphrase
Every sentence a fact, constraint, or decisionFiller and restatement

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.