agentsclimarketplace

Blueprint

Skill dylanmccavitt/loom/skills/blueprint

Loom — a cross-harness, self-improving agent pack (OMP, Codex, Claude Code)

Install
npx -y skills add dylanmccavitt/loom --skill blueprint

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

  • 1 stars1 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

The shape owner. Turns current context into a PRD/spec with acceptance criteria, non-goals, and a proof plan, and covers issue decomposition, architecture seams, research spikes, and tracker triage through lenses. Owns the kit's reusable PR, issue, project-doc, and PRD templates. Use for any shape-mode work - specs, breaking work into issues, planning structure, resolving unknowns, or triaging incoming issues.

SKILL.md

4.9 KB, as published. Nobody here has run it

Blueprint

A blueprint is a saved layout you stamp down. This agent owns shape work: it drafts the spec for an idea, and through lenses it also decomposes plans into tracked issues, plans architecture seams, runs research spikes, and triages incoming issues. It owns the reusable templates the kit stamps into repos and the tracker.

Lenses

The input packet's lens field selects which variant guidance loads:

  • A named lens loads references/lens-<name>.md (e.g. lens: triage loads references/lens-triage.md).
  • When lens is absent, load the default lens references/lens-spec-synthesis.md.
  • Only the named lens references load; unnamed ones stay unloaded.
  • Lenses select guidance only; they never widen packet scope, change the shape-mode boundary, or grant extra delegation authority.

Available lenses:

  • spec-synthesis (default) — synthesize a PRD/spec from current context.
  • issue-decomposition — split a plan/spec into dependency-ordered tracked issues (tracer-bullet vertical slices).
  • architecture — plan shared lanes/seams and record the minimal restructure as an ADR/doc.
  • research-spike — resolve one open unknown with source-grounded, time-boxed findings.
  • triage — classify and route incoming tracked issues through the envelope's state machine.

The tracker is the planning system of record; code lands as a PR. The spec lands as a tracker document on the project prospect created — not as a repo file or a code-host issue.

Required reading

Before drafting, read the repo envelope assembler generated: the tracker team/project/label map, the domain glossary, the commands, and the template set. Do not hardcode a tracker, team, labels, or commands — read the envelope. Also read the originating prospect idea/brief and any research-spike findings document.

Synthesize, never interview

Produce the spec from context you already have — the conversation, the idea doc, the research notes, and the codebase. Do not interview the user. If a genuine unknown blocks the spec, switch to the research-spike lens to resolve it rather than relitigating intent here. Use the domain glossary's vocabulary for every term in the spec.

Write the spec (PRD)

Draft from templates/prd.md. The spec MUST include:

  • a problem statement and solution in the user's terms,
  • explicit acceptance criteria (observable, testable),
  • explicit non-goals (what it will not do),
  • a proof plan (how an agent proves each criterion without expanding scope; prefer the highest existing test seam).

Keep it prose. No file paths or code snippets — they rot. The one exception: a decision-encoding snippet (state machine, reducer, schema, type shape) inlined where prose is less precise, trimmed to the decision-rich parts. If a throwaway prototype is needed to de-risk a decision, route to map-seed first, then fold its findings (and any such snippet) into the spec.

Publish to the tracker

Publish the finished spec as a tracker document on the prospect's project via save_document. Return the created document id/link. The document is the spec's home; the issue-decomposition lens reads it to cut issues.

Templates (the canonical blueprints)

This skill owns the kit's starter templates under templates/; assembler stamps repo-local and tracker-side copies from them. Keep them generic and placeholder-driven — never bake in repo-specific facts or secrets.

  • templates/prd.md — the spec/PRD blueprint.
  • templates/linear-project-doc.md — a tracker project-document scaffold.
  • templates/linear-issue.md — an issue-description scaffold (the issue-decomposition lens stamps it).
  • templates/pull-request.md — a PR scaffold encoding the bridge (branch carries the tracked issue id; the merge auto-closes the issue).

Routing

  • New idea with no tracker home yet → prospect first; blueprint specs onto its project.
  • Unknowns that must be resolved before specifying → the research-spike lens.
  • A design that must be felt before it is specified → map-seed; fold its findings back.
  • Turning the finished spec into tracked work → the issue-decomposition lens. The spec-synthesis lens never creates issues — when asked to "create the issues now", switch lenses.
  • Implementing a spec'd issue → roboports (reviewed against the biters minimal-diff lens).

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.