Skip to main content
← Back to list
01Issue
FeatureOpenSwamp CLIPublic
AssigneesNone

Relationships

#1968 Add intent and scope discovery to extension creation skill

Opened by stack72 · 9/2/2026

Problem

The extension creation skill (references/extension/guide.md) jumps straight to "Determine Extension Type" → search registry → scaffold → build. It has two gaps:

  1. No intent discovery — It never asks the user what problem they're trying to solve. "I want to automate Stripe invoice creation" is very different from "I want full Stripe coverage in swamp." The flow discovers what the API offers before it discovers what the user actually needs.

  2. No scope discovery — Given the intent, the flow doesn't determine how much of the API the user needs. Extensions can cover an entire API surface (common) or just a single method to prove value (rarer but valid). The current flow assumes full coverage every time.

Proposed Solution

Add a scope discovery gate at the top of the extension creation flow, modeled on the interactive state-machine pattern already used by swamp-getting-started (gate/action/verify/on-failure blocks):

Step 0: Intent — "What are you trying to accomplish with this extension?" (open-ended). This comes first because it naturally informs scope.

Step 1: Scope — Only if intent is ambiguous, ask whether the user wants:

  • Full API coverage (multiple methods, typed schemas, the works)
  • A focused subset of methods for their use case
  • A single method proof-of-value to validate the integration works

If the intent already implies narrow scope (e.g., "I need to post messages to Slack channels"), confirm rather than ask — skip the scope question entirely.

Then the existing flow kicks in, but searches the API surface with the user's intent as a lens rather than cataloguing everything.

Implementation Notes

  • Use AskUserQuestion for structured scope choices (supports 2-4 options with descriptions)
  • The "single method" track should skip quality scoring, manifest polish, and full README
  • Each track could be a separate reference file (track-full.md vs track-single.md) to keep SKILL.md lean
  • The getting-started and issue-lifecycle skills both prove the state-machine pattern works well for this kind of interactive flow

Alternatives

  • Do nothing: users who want a single method have to manually short-circuit the full flow
  • Add scope as a flag to swamp extension init: too rigid, doesn't capture intent
02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED

Open

9/2/2026, 7:00:52 PM

No activity in this phase yet.

03Sludge Pulse

Sign in to post a ripple.