Skip to main content
← Back to list
01Issue
FeatureShippedSwamp CLI
Assigneesstack72

Relationships

#348 Scaffold new extensions to publish-ready quality (12/12) by default

Opened by magistr · 5/13/2026· Shipped 5/22/2026

Problem

Following the documented swamp-extension-model workflow today produces an extension that scores 4/12 (33%) on swamp extension quality. The missing factors are not bugs or stylistic preferences — they're explicitly client-earnable items in the rubric:

  • has-readme (2 pt) — no README written
  • readme-example (1 pt) — README has no fenced code blocks
  • rich-readme (1 pt) — README is short
  • symbols-docs (1 pt) — no JSDoc on exported symbols
  • has-license (1 pt) — no LICENSE file
  • repository-verified (2 pt) — repository: field unset in manifest
  • (often) fast-check (1 pt) — re-exporting bare z.enum(...) / z.object(...) fails deno doc --lint

This is a real friction point. After creating @magistr/telegram-send end-to-end today, getting from 33% → 100% took an extra round trip: write README, write LICENSE, add module + symbol JSDoc, restructure exports to satisfy deno doc --lint, add a verified repository URL, re-format, re-score, dry-run, push.

All of that work is mechanical and predictable — it could be done by scaffolding at extension-creation time.

Proposed solution

Add a swamp extension new <name> (or init) subcommand that scaffolds a publish-ready skeleton from a single prompt:

swamp extension new @magistr/foo
# prompts: kind (model/workflow/vault/driver/datastore/report), license (MIT default),
#         repository URL (optional, validated against the verified-host list)

The resulting directory should reach 12/12 on swamp extension quality immediately, with TODO: markers in the spots that require human input (description, code example, repository URL if skipped).

Concretely, the scaffold should produce:

  1. manifest.yaml with name, version (from swamp extension version), description: TODO, repository: (if supplied), additionalFiles: [README.md, LICENSE.md], and the right typed-content array seeded with one entry.
  2. README.md skeleton that already meets rich-readme and readme-example thresholds — sections for Install, Setup, Usage with two fenced code blocks of placeholder commands, ≥500 characters of structure.
  3. LICENSE.md populated from the chosen SPDX identifier (MIT default), with current year and the authenticated collective name auto-filled.
  4. .gitignore and deno.json matching the existing per-extension layout convention (good-planning / issue-lifecycle style).
  5. For a model: extensions/models/<snake>.ts whose export const model carries a module-level JSDoc with @example, and whose any-exported Zod schemas have explicit type annotations so deno doc --lint passes (fast-check). The current swamp-extension-model Quick Start exports model only — that's fine; but if it grows to export schemas they should be annotated, and the template should demonstrate the safe pattern (or simply keep schemas un-exported).

Alternatives considered

  • Document-only fix. Update the swamp-extension-model SKILL.md Quick Start so it ships a polished file by default (README + LICENSE + JSDoc + repository). This raises the floor without new CLI surface area, but Claude/users still have to copy and customize four files manually for each new extension. A scaffolder is strictly better, but the SKILL.md update is a worthwhile first step on its own.
  • Quality-as-warning during extension push. Today quality is opt-in and push doesn't surface the score. Making push print a single-line "X/12 (Y%)" alongside the dry-run summary would at least make the gap visible at the moment authors care most. (Suggesting this in addition to scaffolding, not instead.)
  • Defer to per-collective templates. Some collectives might want their own LICENSE / README header. The scaffolder can accept --template <path> later; for v1 the built-in MIT/skeleton is enough.

Additional context

  • Existing swamp-extension-publish skill already encodes the publishing state machine and surfaces quality as optional. A new command would close the loop on the other end — authoring — so authors don't only learn about the rubric at push time.
  • The repository-verified factor specifically requires a public HTTPS URL on github.com/gitlab.com/codeberg.org/bitbucket.org. The scaffolder should validate the host up-front rather than letting the failure surface at push.
  • Real example for context: @magistr/telegram-send v2026.05.13.1 (https://swamp-club.com/extensions/@magistr/telegram-send) — went from 33% → 100% by adding the items listed above, no code or behavior change.
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 4 MOREREVIEW+ 3 MOREPR_MERGED+ 1 MORECONTRIBUTOR_NOTIFIED

Shipped

5/22/2026, 11:01:02 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack725/22/2026, 10:25:03 PM
Editable. Press Enter to edit.

stack72 commented 5/22/2026, 10:40:40 PM

Thanks for the detailed writeup @magistr — the friction you hit going from 33% to 100% on @magistr/telegram-send is real and the analysis of what's missing is spot-on.

After looking at this, we're taking a different approach than the proposed swamp extension new CLI command. Here's the thinking:

Several of the quality factors — README, LICENSE, repository URL, description — are authorship decisions that vary by extension and collective. Scaffolding opinionated defaults for those would be too restrictive, and the quality score already surfaces them as opt-in signals.

What we are doing:

  1. Improving the swamp-extension skill templates so the code Claude generates passes symbols-docs and fast-check out of the box (JSDoc annotations, proper type exports). Today these are the factors that trip people up because they're technical correctness issues, not content decisions.

  2. Surfacing the quality score during publish — the swamp-extension-publish workflow will show your score as a visible step before dry-run, so you see where you stand at the moment you care most. Non-blocking — it's awareness, not a gate.

The net effect: the technical quality factors land automatically when you create an extension with the skill, and the content-oriented factors (README, LICENSE, repo) stay visible through the quality score without forcing a particular structure.

stack72 commented 5/22/2026, 11:01:07 PM

Thanks @magistr for reporting this! The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.