Claude Skill

suede-directory-submissions

Suede-affiliated directory distribution strategy for selecting listings, sequencing submissions, tailoring positioning, and verifying backlinks. Use when a product needs startup, SaaS, AI, MCP, marketplace, or review-directory submissions and a measurable tracker. NOT FOR: broade

LLM Mart · 0 points · 13 0 0

Virus-scanned Reviewed automatically before listing.

Full trust report

Download JasonColapietro-suede-creator-skills-skills_suede-directory-submissions-f192517.zip · 18 KB

jasoncolapietro/suede-creator-skills 125 12 forks MIT Updated 1d ago

Part of jasoncolapietro/suede-creator-skills — 70 skills

Install

skills CLI npx skills add https://github.com/JasonColapietro/suede-creator-skills/tree/main/skills/suede-directory-submissions

Claude Code

claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install jasoncolapietro-suede-creator-skills@llmmart

Git git clone https://github.com/JasonColapietro/suede-creator-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole jasoncolapietro/suede-creator-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Suede Directory Distribution

Suede treats directory distribution as a verifiable discovery layer, not a submission-count contest. Build the user's backlink and buyer-discovery foundation by selecting the right directories, sequencing them around real launch moments, adapting truthful positioning, and checking that each listing and backlink actually landed.

Iron Law — approval is per destination:

No external submission, account creation, paid placement, or review request
happens without explicit approval for that exact destination, copy, assets,
timing, and maximum cost. Approval for research or for another destination
never transfers. Any delta is re-approved before it ships.

Before Starting

Check for product marketing context first: If .agents/product-marketing.md exists (or .claude/product-marketing.md, or the legacy product-marketing-context.md filename, in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.

Core Philosophy

Directory submissions can add discovery surfaces, referral paths, and backlinks, but their value varies by product, directory, listing quality, and current platform rules. Treat each benefit as a hypothesis to verify with listing status, referral analytics, search data, and qualified outcomes. A directory plan complements destination pages and other distribution; it does not guarantee authority, citation, traffic, ranking, or leads.

The full directory catalog lives in references/directory-list.md. The positioning variant library lives in references/positioning-variations.md. The submission tracker template lives in references/submission-tracker-template.csv.

Three Operating Rules

Rule 1: Foundation before submission

Before recommending a submission, verify the directory's current official requirements and record the source URL and check date. The linked page should be publicly reachable, truthful, useful to the directory's audience, and measurable. Prepare only the assets the current form requires, using real product screenshots and approved brand files. Add pricing, legal pages, video, schema, or additional formats when the product, jurisdiction, or verified directory rules call for them; do not invent universal prerequisites.

Rule 2: Destination pages before directories

Choose the most relevant verified destination for each audience: a homepage, use-case page, integration page, comparison page, template, or documentation page. It must accurately fulfill the listing promise and have a measurable next step. Do not impose a fixed page count or block a suitable listing merely because an unrelated content type does not exist.

Rule 3: Positioning varies by directory type

Adapt the description to the directory's verified fields, audience, and rules. Reuse approved facts, but change emphasis when that improves relevance; do not claim that duplicate descriptions trigger a search or AI penalty without current evidence. See references/positioning-variations.md for templates.

Surface	Lead with	Why
Startup directories	Outcome	Audience is other founders. They care what it does.
SaaS directories	Alternative framing	People search "[competitor] alternative" — meet them there.
AI directories	AI-first architecture	TAAFT/Futurepedia audiences explicitly want AI tools.
Agent/MCP directories	Agent/MCP angle	Use only for a live compatible capability.
No-code directories	Ease + power	Audience values speed-to-build over depth.
Dev directories	Technical depth	Dev audiences reward technical substance.
B2B review sites	ROI + use case	Buyers want outcomes and case studies.

Workflow

Step 1: Readiness assessment (Phase 0)

Assess the selected directory against current requirements:

Is the product publicly accessible (no password wall)?
Is there a pricing page (even "free while in beta")?
Are privacy policy + terms live?
Are the required approved logo, screenshot, and video assets available?
Does the destination page match the proposed listing copy and CTA?
Is referral and conversion measurement configured?
Does the current directory policy allow this product, claim set, and category?
For review sites, are there genuine eligible users and a policy-compliant ask?
Who has authority to create the account, accept terms, and submit?

A missing current platform requirement, truthful destination, or submission authority is a hard block for that directory. At the block: stop work on that directory, name the blocker in one line ("

Step 2: Choose the tiers

Full catalog in references/directory-list.md. Summary:

Tier	When	Illustrative candidates to verify
Flagship launch	Around a relevant launch	Product Hunt, BetaList, HN Show HN, Fazier, DevHunt
Startup/SaaS	Launch and rolling	AlternativeTo, SaaSHub, G2, Capterra, F6S
AI directories	If the product has a substantiated AI capability	TAAFT, Futurepedia, Toolify, Future Tools
Agent/MCP registries	If a live compatible integration exists	Glama, APITracker, LF MCP Registry
No-code directories	If the product genuinely serves that audience	NoCodeFinder, No Code MBA
Integration marketplaces	When the integration ships	The integration owner's official marketplace
Profiles and vertical directories	When audience and category fit	Relevant company profiles or industry-specific catalogs

Triage rule: Only submit where the product is a genuine fit under the platform's current eligibility and category rules.

Step 3: Prepare asset variations

For each tier, prep distinct variants from references/positioning-variations.md only after inspecting the destination's current form:

Tagline sized to the verified field limit
Short description sized to the verified field limit
Long description sized to the verified field limit
Category tags limited to the verified taxonomy and product fit
Logo assets
Screenshots + demo video URL
Founder story (2–3 sentences)

Keep facts consistent and approved. Adapt length and emphasis to each verified form without inventing features, customers, outcomes, or platform support.

Step 4: Batch submit

Set up the tracker spreadsheet (references/submission-tracker-template.csv). Work in evidence-backed approval batches of 3–5 directories. At the cap, submit, verify, and report that batch's results before opening the next one. Every submission is gated by the Iron Law: show the exact public copy, assets, account, destination, timing, and maximum cost first.

Per submission:

Verify the current form, rules, price, and account identity.
Prepare the exact field values and assets as a reviewable draft.
Obtain explicit approval for that destination (Iron Law).
Fill and upload only the approved values.
Pause before any changed price, upsell, or materially different rendered preview; re-approve the delta.
Submit once, then capture confirmation.
Log: date, URL, status, moderator notes.
Once live, fetch the canonical listing URL, locate the anchor pointing at the destination in the rendered HTML, and record its rel value, redirect behavior, resolved destination, and the check date in the tracker. Absence of rel in response headers does not prove link attributes — inspect the rendered page, and log the method used.

Reporting rule: a listing is reported live only when the tracker's Live URL, Rendered Link Attributes, and Destination Verified cells are all filled with a check date. Anything else is reported as submitted, unverified.

Flagship Launch Listing

For any time-sensitive launch surface, research the platform before building the plan. Use its current official help, submission form, and community rules; record the URLs and check date. Do not present remembered algorithm behavior, ideal launch times, asset dimensions, hunter effects, or engagement thresholds as facts.

Preparation milestones

Confirm eligibility, account standing, moderation rules, scheduling options, required assets, and prohibited promotion.
Draft truthful positioning, an approved maker story, real product visuals, and a working destination CTA in the exact current form limits.
Preview the listing and test the product, signup, analytics, and support path.
Build a communication plan from channels the user owns or is authorized to use.
Assign a responder for genuine questions and feedback.

Launch and follow-through

Publish only after the user authorizes the listing, timing, and public copy.
Follow current solicitation and outreach policies. Do not manipulate voting, fabricate engagement, or message people without a legitimate relationship and authorization.
Respond helpfully, log referrals and qualified outcomes, and capture lessons.
Share a recap only where current community rules permit it.

Reviews Playbook

Review directories can help buyers evaluate products, but eligibility, incentive, moderation, badge, report, and paid-plan rules change. Before recommending a campaign:

Read the current official review and incentive policy for the chosen platform.
Record the source URL, check date, eligibility rules, deadlines, and maximum verified cost.
Identify real users with firsthand product experience; never manufacture, gate, pre-score, or script reviews.
Get explicit authorization for the recipient list, wording, channel, cadence, and any incentive before outreach.
Track requests, completed reviews, moderation status, referral outcomes, and complaints. Set targets from the actual eligible pool and user goals.

Do not claim a badge threshold, report cutoff, ownership relationship, incentive permission, plan price, or expected response rate unless it was verified from a current authoritative source. A small customer base is a planning constraint, not automatic proof that a listing is worthless.

Destination Pages Strategy (What the Backlinks Point At)

Match each listing to the most useful truthful page available. A homepage can be appropriate when it satisfies the audience and promise; a specialized page may be better when evidence supports it.

Page type	Build it when
Alternatives page (`/alternatives/[competitor]`)	Current customer or search evidence shows comparison intent
Use-case / ICP page (`/for/[audience]`, `/use-cases/[use-case]`)	Demand and product evidence justify a dedicated page
Template or asset gallery (`/templates/[slug]`)	Templates carry standalone value and activation is measurable
Self-authored category roundup	The team can research the category and disclose its methodology
Integration page	The integration is live and the page explains setup, capabilities, and limits

On any comparison or roundup page: verify material competitor claims, state clearly when each option fits, date the comparison, and correct it when the facts change. Set output volume from quality capacity and measured demand, not a borrowed traffic or revenue story, and do not promise ranking or AI citation.

Page production at scale belongs to suede-programmatic-seo; comparison-page strategy belongs to suede-competitors.

GEO (Generative Engine Optimization)

Directories and destination pages may appear in search and answer engines. Treat visibility as an observable outcome, not a guaranteed effect of authority scores or markup.

On-page citation tactics (headings, schema, source-dated facts, comparison tables) are owned by suede-seo-audit. Two rules stay this skill's own: earn genuine third-party discussion rather than seeding or fabricating citations, and keep authorized company profiles and live-integration registry entries consistent with verified entity facts.

Measurement

Use authorized, currently callable tools or manual checks to sample relevant queries. Record engine, account context, prompt, locale, date, result, and whether the result is reproducible. Verify any tracking product and its cost before recommending it.

Community & Ongoing Distribution

Most directory submissions are episodic; community participation is ongoing. Measure each as a separate source before combining funnel conclusions.

Cross-posts and community links are still backlinks: publish only where the community's current rules permit it, use a canonical URL where the platform supports one, and verify the rendered link with the same Step 4.8 check applied to directory listings.

Channel selection, cadence, and post formats belong to suede-community-marketing, suede-social, and suede-content-strategy.

KPIs & Tracking

Set baselines and goals from the user's current analytics, eligible audience, capacity, and launch objective. Do not use generic day-based forecasts.

Metric	Baseline	User-approved goal	Source and check date
Listings submitted and live
Verified referring links
Directory referral sessions
Qualified conversions by listing
Review requests and published reviews
Search or answer-engine observations
Cost and team time

What NOT to Do

Don't buy a mass-submission package without diligence and explicit approval. Verify exact destinations, editorial standards, data handling, rights, maximum cost, and refund terms.
Don't submit to low-quality or deceptive directories. Evaluate audience fit, moderation, live traffic evidence, existing listings, outbound-link behavior, and reputation rather than relying on one authority score.
Don't treat directories as your entire GTM. Compare them with content, community, reviews, partnerships, and other measured channels.
Don't churn listings without evidence. Set a review cadence from product changes, platform notices, and observed listing issues.
Don't over-index on launch-day spike. The flywheel is templates + alternatives + reviews + ongoing content — not one day of PH.

Task-Specific Questions

What are you launching? (Category changes tier mix — AI vs traditional SaaS vs no-code vs dev tool.)
When is launch day? (Work backward from verified platform requirements.)
Do you have destination pages built? (Alternatives, use cases, templates — if not, build first.)
Which flagship surface is being considered, and what do its current rules require?
How many eligible users could receive a policy-compliant review request?
Do you have a live tested MCP or agent capability? (If yes, verify compatible registries.)
Existing integrations? (If yes, verify each owner's marketplace eligibility.)
Which owned audiences can be contacted, and has the user authorized outreach?
Current DR and referring domain count? (Baseline for measuring the compounding effect.)

Output Format

When the user asks for a directory plan, return:

Readiness assessment — which Phase 0 items are missing, which block submission
Tier selection — which tiers apply, which to skip, why
Submission order — evidence-backed batches mapped to current requirements
Destination page list — what to build first if missing
Positioning variants — the actual copy per tier (from references/positioning-variations.md)
Flagship listing timeline — mapped from current rules to calendar dates
Policy-compliant review plan — eligible audience, authorization, copy, cadence
Weekly measurement plan — baselines and user-approved goals
Tracker — link to or include the CSV from references/submission-tracker-template.csv

Keep the plan actionable. Every item should be something the user can do today.

Boundaries

Do not claim a directory is dofollow, indexed, high-authority, or producing leads without a current check.
Do not submit listings, create accounts, publish copy, buy placements, or request reviews without explicit authorization.
Do not fabricate traffic, ranking, review, or citation outcomes; label estimates and record the evidence date.
Do not decide positioning or public product claims when the required product context is missing.

Routing

Use suede-launch-packaging for the broader launch sequence.
Use suede-programmatic-seo for destination pages and suede-seo-audit for search or citation checks.
Use suede-competitors for comparison-page strategy and suede-content-strategy for editorial support.
Use suede-free-tools for interactive destination assets, and suede-community-marketing, suede-social, or suede-content-strategy for community and social distribution.
Use suede-public-relations when a flagship launch also warrants earned media.
From those skills, route directory selection, listing positioning, and backlink verification back to suede-directory-submissions.

Files (suede-creator-skills)

agents

openai.yaml 496 B

interface:
  display_name: "Suede Directory Submissions"
  short_description: "Work the directory layer deliberately"
  default_prompt: "Use $suede-directory-submissions on [target]. Research currently eligible startup, SaaS, AI, or MCP listings; verify official requirements, pricing, policies, rendered links, and authority for external action; then recommend a measured submission order without promising traffic, ranking, citations, or conversions."
policy:
  allow_implicit_invocation: true

evals

evals.json 5.4 KB

{
  "skill_name": "suede-directory-submissions",
  "evals": [
    {
      "id": 1,
      "prompt": "We're launching our AI SaaS in 3 weeks. Help me plan all the directories we should submit to.",
      "expected_output": "Should check product context, treat the directory catalog as a research queue, and verify current official eligibility, pricing, policies, form requirements, and asset specifications with source URLs and dates. Should block only candidates missing a current requirement, truthful destination, or submission authority rather than imposing universal page counts. Should select a small evidence-backed mix by audience fit, build calendar dates from verified requirements, set goals from the user's baseline, and request explicit approval before external submissions.",
      "assertions": [
        "Checks product context",
        "Treats candidates as unverified until researched",
        "Records current official sources and check dates",
        "Avoids fixed directory-volume and outcome promises",
        "Maps verified requirements to calendar dates",
        "Requires explicit submission authority"
      ],
      "files": []
    },
    {
      "id": 2,
      "prompt": "Can I just copy-paste the same description into every directory?",
      "expected_output": "Should keep approved product facts consistent but adapt emphasis and length to each directory's current fields, audience, and rules. Should not claim duplicate copy creates an AI or search penalty without current evidence. Should use references/positioning-variations.md as templates, verify every populated feature and outcome, and remove unsupported bracketed claims.",
      "assertions": [
        "Keeps approved facts consistent",
        "Adapts copy to verified fields and audience",
        "Avoids an unsupported AI penalty claim",
        "Does not invent features or outcomes",
        "References positioning-variations.md"
      ],
      "files": []
    },
    {
      "id": 3,
      "prompt": "Should we pay for one of those directory submission services that submits to 200 directories for $99?",
      "expected_output": "Should not approve or reject from price and volume alone. Should request the exact destination list, editorial standards, data handling, rights, refund terms, and maximum total cost; verify live traffic or audience evidence and link behavior; compare a small manual batch; and require explicit approval before purchase. Should warn that raw submission count, authority scores, and promised dofollow links do not prove value.",
      "assertions": [
        "Requests exact destinations and terms",
        "Verifies maximum cost before approval",
        "Evaluates audience and editorial quality",
        "Does not treat dofollow or authority scores as outcomes",
        "Requires explicit purchase approval"
      ],
      "files": []
    },
    {
      "id": 4,
      "prompt": "Walk me through how to launch on Product Hunt next month. We've never done it before.",
      "expected_output": "Should research the platform's current official eligibility, scheduling, form limits, assets, solicitation rules, and moderation using source URLs and dates. Should build a preparation timeline from those verified rules, test the product and listing preview, identify authorized owned channels, prohibit vote manipulation and unsolicited messaging, and avoid remembered claims about ideal weekdays, launch times, algorithms, hunters, or supporter thresholds.",
      "assertions": [
        "Verifies current official platform rules",
        "Builds timeline from verified requirements",
        "Tests listing and destination",
        "Requires authorized communication channels",
        "Prohibits manipulation",
        "Avoids remembered algorithm thresholds"
      ],
      "files": []
    },
    {
      "id": 5,
      "prompt": "We want to list on G2 but we only have 4 customers right now. Worth doing?",
      "expected_output": "Should treat customer count as a constraint rather than an automatic no. Should verify the current official listing, review, incentive, badge, report, and pricing policies with source URLs and dates; avoid asserting remembered thresholds or prices; identify only genuine eligible reviewers; and require explicit approval for recipient list, copy, channel, cadence, and any incentive before outreach.",
      "assertions": [
        "Does not call a small listing worthless",
        "Verifies current official review policies",
        "Avoids stale badge and pricing claims",
        "Uses only genuine eligible reviewers",
        "Requires explicit outreach authorization"
      ],
      "files": []
    },
    {
      "id": 6,
      "prompt": "We submitted to 50 directories last week. Now what?",
      "expected_output": "Should verify each live canonical listing and inspect rendered link attributes and redirects instead of using response headers as proof. Should reconcile the tracker, analytics, qualified conversions, cost, and complaints; update or remove inaccurate listings only with authorization; and choose the next destination or distribution experiment from measured evidence rather than promising rank, citation, or conversion outcomes.",
      "assertions": [
        "Verifies canonical live listings",
        "Inspects rendered links rather than response headers",
        "Reconciles analytics and qualified outcomes",
        "Requires authority for listing changes",
        "Chooses next action from measured evidence"
      ],
      "files": []
    }
  ]
}

references

directory-list.md 5.5 KB

# Directory Research Queue

This is a discovery queue, not a current directory database or endorsement.
Platforms, submission URLs, categories, terms, pricing, moderation, link
attributes, ownership, traffic, and availability change. Never use a candidate
below as a recommendation or submission target until it passes the verification
workflow at the end of this file.

Do not assign an authority score, traffic estimate, `dofollow` label, expected
conversion, ranking effect, citation effect, or cost from memory. Capture each
fact from a current authoritative source with its URL and check date.

## Flagship Launch Candidates

- Product Hunt
- BetaList
- Hacker News Show HN
- DevHunt
- Fazier
- Uneed

Research when the user has a real launch milestone. Verify product eligibility,
account rules, scheduling, required assets, form limits, solicitation policy,
moderation, and publishing authority.

## Startup and Software Directory Candidates

- AlternativeTo
- SaaSHub
- G2
- Capterra
- GetApp
- SourceForge
- F6S
- Startup Stash

Research audience fit, category fit, listing requirements, review rules, exact
cost, data use, and whether the live listing provides a measurable referral path.

## AI Product Directory Candidates

- TAAFT
- Futurepedia
- Toolify
- Future Tools
- AIStage

Use only when the product has a live, substantiated AI capability. Verify current
submission availability, prohibited claims, model/provider fields, pricing,
editorial review, and listing maintenance.

## Agent and MCP Registry Candidates

- Linux Foundation MCP Registry
- Glama
- APITracker

Use only for a live compatible server or agent capability. Verify the current
registry specification, namespace and ownership proof, authentication disclosure,
security metadata, evaluation semantics, and update path. Do not promise a grade,
discovery, or compatibility beyond what was tested.

## No-Code Directory Candidates

- No Code Founders
- NoCodeList
- NoCodeFinder

Verify that the product and audience genuinely fit the directory's current
definition. Do not label a product "no-code" when setup or core use requires code.

## Integration Marketplace Candidates

Research the official marketplace run by each integration owner only after the
integration is live. Examples may include CRM, automation, collaboration, CMS,
commerce, or developer-platform marketplaces.

Verify partner eligibility, app review, security requirements, support
obligations, listing fields, trademark rules, fees, and whether the user is
authorized to accept partner terms.

## Company Profile Candidates

- GitHub organization profile
- LinkedIn company page
- Crunchbase company profile

Use only with authority to create or edit the entity record. Keep names, URLs,
founder facts, descriptions, and product claims consistent with current
first-party evidence. A profile does not guarantee a backlink, indexing, entity
recognition, or discovery.

## Community and Publishing Candidates

- Relevant Reddit communities
- Indie Hackers
- Dev.to
- Hashnode
- Relevant industry forums

Read the current rules of the exact community before participating or linking.
Disclose affiliation, contribute genuine value, and do not automate posting,
vote manipulation, or unsolicited promotion.

## Local and Vertical Directory Candidates

Research only where the business has a real local presence, license, service
area, or industry fit. Candidate categories include:

- Local business profiles
- Legal
- Home and construction
- Hospitality
- Design and creative
- Health and fitness
- Real estate
- Education
- Events
- International B2B catalogs

Verify jurisdiction, business identity, license requirements, address/privacy
implications, category rules, and ownership before creating a listing.

## Editorial Outreach Candidates

Relevant comparison articles, resource pages, newsletters, and trade publications
may be better fits than directories. Treat them as outreach, not guaranteed
placements. Verify editorial contact, disclosure rules, sponsorship cost,
audience fit, and the article's current status. Do not buy undisclosed links.

## Verification Workflow

For every candidate:

1. Open the current official site and submission or partner documentation using a
   callable, authorized research surface. If none is available, give the user a
   manual research checklist and label the candidate unverified.
2. Record:
   - canonical home and submission URLs
   - source URL and retrieval date
   - current product/category eligibility
   - required account, assets, claims, and approvals
   - moderation and expected maintenance process
   - exact free and paid options, currency, taxes, and maximum cost
   - review, incentive, solicitation, privacy, and disclosure policies
   - whether a live listing exists and its canonical URL
3. Inspect the rendered listing link and redirects. Record observed `rel`
   attributes and destination behavior. Absence of `rel` in response headers is
   not proof of a followable link.
4. Check first-party analytics after launch for referral sessions, qualified
   actions, and cost. Do not infer outcomes from an authority metric.
5. Recheck volatile facts before submission and quarterly for maintained
   listings.

## Evidence Record

| Candidate | Category | Official source | Checked at | Eligibility | Cost | Required assets | Policy notes | Live URL | Link observation | Outcome |
|---|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | | |

Only move a candidate from research to submission when its evidence record is
complete and the user has authorized the exact external action.

positioning-variations.md 9.5 KB

# Positioning Variations Library

Directory fields and audiences can call for different emphasis. Keep approved
facts consistent while adapting the copy to current form limits and verified
audience context. Do not claim that duplication creates an AI or search penalty
without current evidence.

Use this library to generate per-tier variants. Swap `[product]`, `[category]`, `[competitors]`, `[use-case]`, and `[audience]` with the real values.

Candidate lists are research cues, not current submission recommendations. Verify
each platform and form before using a template. Delete any bracketed sentence that
cannot be supported by current first-party product evidence; never invent users,
features, integrations, time savings, prices, or outcomes to complete the copy.

---

## Framework: Lead Sentence Varies by Tier

| Tier | Lead sentence pattern | Why |
|---|---|---|
| Startup / launch | "[Product] is the easiest way to [outcome] for [audience]." | Founders scan for outcome clarity. |
| SaaS directory | "[Product] is the [differentiator] alternative to [competitors]." | Catches "[competitor] alternative" search intent. |
| AI directory | "[Product] uses [AI capability] to [outcome]." | TAAFT/Futurepedia audiences explicitly want AI. |
| Agent / MCP | "[Product] is an MCP-native / agent-native [category]." | Niche but high-intent. Ruling-out competitors. |
| No-code | "[Product] lets you build [output] without code." | Audience values speed, not technical depth. |
| Dev tool | "[Product] is a [technical category] with [differentiator]." | Devs want substance upfront. |
| B2B review | "[Product] helps [audience] [measurable business outcome]." | Reviewers want ROI language. |

---

## Template: Startup / Launch Directories

**Target:** Product Hunt, BetaList, Fazier, Uneed, DevHunt, Microlaunch, OpenHunts, LaunchVault, Firsto, PitchWall

**Tagline (under 10 words):**
> The [differentiator] way to [outcome] for [audience].

**Short description (60 chars):**
> [Outcome-focused one-liner with product name]

**Long description (150 words):**
> [Product] is the easiest way to [outcome] for [audience]. Built for teams who [pain point], [product] removes [friction] by [how].
>
> Unlike [competitor category], [product] [key differentiator 1] and [key differentiator 2]. You can [action 1] in under [timeframe], [action 2] without [limitation], and [action 3] that would normally require [cost or technical skill].
>
> We built [product] because [founder origin story in one sentence]. It's now used by [audience examples] to [use case examples].
>
> Try it free at [url]. No credit card, no setup.

**Tags:** [product category], [audience type], [use case 1], [use case 2], [differentiator], [tech]

---

## Template: SaaS / Software Directories

**Target:** AlternativeTo, SaaSHub, G2, Capterra, GetApp, SourceForge, Slashdot, Startup Stash, F6S

**Tagline:**
> The [differentiator] alternative to [top competitors].

**Long description:**
> [Product] is a [differentiator] alternative to [competitor 1], [competitor 2], and [competitor 3] — built for [audience] who need [gap the competitors don't fill].
>
> Where [competitor 1] [limitation 1] and [competitor 2] [limitation 2], [product] [solves]. You get [feature 1], [feature 2], and [feature 3] in a single workspace, at [pricing relative to competitors].
>
> Key features:
> • [Feature 1] — [benefit]
> • [Feature 2] — [benefit]
> • [Feature 3] — [benefit]
> • [Feature 4] — [benefit]
> • [Integration 1], [Integration 2], [Integration 3] integrations
>
> Trusted by [audience examples]. Start free at [url].

**Tags:** [competitor] alternative, [category], [audience], [differentiator], [top 3 features]

---

## Template: AI Directories

**Target:** TAAFT, Futurepedia, Toolify, Future Tools, aitools.inc, AIStage, LogicBalls, SaasAITools

**Tagline:**
> AI-powered [category] for [audience].

**Long description:**
> [Product] is an AI-powered [category] that [core AI capability]. It uses [specific models / techniques] to [outcome] — so [audience] can [job to be done] in a fraction of the time.
>
> What makes it AI-first:
> • [AI feature 1] — [what it does] using [model/approach]
> • [AI feature 2] — [what it does]
> • [AI feature 3] — [what it does]
> • [AI feature 4] — [what it does]
>
> [Product] is built on [tech stack] and supports [models/providers]. Use cases: [use case 1], [use case 2], [use case 3], [use case 4].
>
> Free tier available. No API keys required to start.

**Tags:** AI [category], [AI capability 1], [AI capability 2], AI for [audience], [use case 1], [use case 2], [LLM provider], [differentiator]

---

## Template: Agent / MCP Registries

**Target:** Glama, APITracker, Linux Foundation MCP Registry, AI Agents List, AI Agent Store, AgentHunter

**Tagline:**
> MCP-native [category] for AI agents.

**Long description:**
> [Product] is an MCP-native [category] that lets AI agents [capability]. It exposes [MCP server capabilities] via the Model Context Protocol, so agents in Claude, ChatGPT, Cursor, and any MCP-compatible client can [actions].
>
> MCP capabilities:
> • [Tool 1] — [what the agent can do]
> • [Tool 2] — [what the agent can do]
> • [Tool 3] — [what the agent can do]
> • [Resource 1] — [context surfaced]
> • [Prompt 1] — [pre-built prompt]
>
> Authentication: [auth method]. Transports: stdio, HTTP, SSE. Security: [security posture].
>
> Installation: [one-line install command]. Docs: [docs URL].

**Tags:** MCP, MCP server, AI agent, agent [category], Claude integration, Model Context Protocol, [domain], [auth type]

---

## Template: No-Code Directories

**Target:** NoCodeFinder, No Code MBA Tools Directory, We Are No Code, NoCode.Tech

**Tagline:**
> Build [output] without code.

**Long description:**
> [Product] lets you build [output] without writing code. Drag, drop, or describe what you want and [product] handles the rest — [technical concept 1] and [technical concept 2] are automatic.
>
> What you can build:
> • [Example project 1] — built in [timeframe]
> • [Example project 2] — built in [timeframe]
> • [Example project 3] — built in [timeframe]
>
> No-code friendly features:
> • [Visual feature 1]
> • [Visual feature 2]
> • [AI-assisted feature]
> • [Pre-built templates]
>
> Start free. No credit card. Templates included.

**Tags:** no code, no-code [category], visual [tool], drag and drop, [output type], [audience type]

---

## Template: Dev / Technical Directories

**Target:** DevHunt, Stackshare, GitHub, Dev.to, Hacker News Show HN

**Tagline:**
> [Technical category] with [technical differentiator].

**Long description:**
> [Product] is a [technical category] built on [tech stack]. It solves [technical problem] by [technical approach].
>
> Architecture:
> • [Component 1] — [tech used]
> • [Component 2] — [tech used]
> • [Component 3] — [tech used]
>
> Why it's different: [technical insight or novel approach]. We chose [trade-off] because [reason].
>
> Open source: [yes/no/partial]. Self-hostable: [yes/no]. License: [license].
>
> API: [REST / GraphQL / MCP / gRPC]. SDKs: [languages]. Docs: [url].

**Tags:** [language], [framework], [category], open source, API, [tech stack component], [architecture approach]

---

## Template: B2B Review Platforms

**Target:** G2, Capterra, TrustRadius, GetApp, Gartner Digital Markets, Crozdesk

**Tagline:**
> [Business outcome] for [audience].

**Long description:**
> [Product] helps [audience] [achieve measurable business outcome]. Teams use it to [use case 1], [use case 2], and [use case 3] — reducing [metric] by [percentage] and increasing [metric] by [percentage].
>
> Key benefits:
> • [Business benefit 1] with [how measured]
> • [Business benefit 2] with [how measured]
> • [Business benefit 3] with [how measured]
>
> Integrations: [enterprise integrations — HubSpot, Salesforce, Slack, etc.]
>
> Security: [SOC 2 / GDPR / compliance posture]. Support: [support tier]. Pricing: [pricing range].
>
> Trusted by [customer logos / company size]. Case studies at [url].

**Tags:** [business use case], [vertical], [audience role], [compliance], enterprise [category], [integration 1]

---

## Category Tag Library

Pull 5–8 tags per submission from the relevant sections. Never repeat the exact same tag set across two directories in the same tier.

### Universal
[category], [audience], [differentiator], [use case], AI, no-code, SaaS, [tech stack]

### Industry
B2B, B2C, DTC, ecommerce, fintech, edtech, healthtech, martech, devtools, productivity, creator tools, agency tools

### Job-to-be-done
lead generation, lead qualification, customer onboarding, product recommendation, sales enablement, marketing automation, survey, assessment, calculator, quiz, intake form

### AI-specific
AI agent, LLM, generative AI, conversational AI, RAG, MCP, agent framework, AI form, AI quiz, AI assistant, AI automation

### Technical
open source, self-hosted, API-first, webhook, Zapier, no-code, low-code, embeddable, white-label, multi-tenant, SSO, SAML

---

## Do / Don't Quick Reference

**DO:**
- Vary the opening sentence across tiers
- Use real numbers and specific differentiators
- Match tone to audience (technical for devs, business for G2, excited for PH)
- Include a founder/origin angle in startup directories
- Lead with the AI-first angle in AI directories

**DON'T:**
- Copy-paste the same 150-word description everywhere
- Use vague claims ("blazing fast", "game-changing")
- Mention every feature — pick 3–5 per tier and rotate them
- Lie about competitor features (AI engines cross-reference and de-rank)
- Skip the tag list — it's how moderators route you to the right category

submission-tracker-template.csv 352 B · in bundle

CARD.md 4.4 KB

# Skill Card — Suede Directory Distribution

<!-- Generated by scripts/build-skill-cards.mjs — do not hand-edit. -->
<!-- Regenerate with: npm run build:cards -->

Release record for the `suede-directory-submissions` skill, following the NVIDIA skill-card template (<https://docs.nvidia.com/skills/skill-cards>). It tells a reviewer what the skill does, who owns it, what it needs, what could go wrong, and what evidence backs the release — without requiring them to open the source first.

## Description

Suede-affiliated directory distribution strategy for selecting listings, sequencing submissions, tailoring positioning, and verifying backlinks.

Status: production. Ships in the `suede-skills` plugin (the full pack) at release 0.19.0; loads as a Claude Code / Codex agent skill from this directory's [SKILL.md](./SKILL.md).

## Owner

Jason Colapietro, Suede Labs AI (<https://github.com/JasonColapietro>). Security contact: `info@suedeai.ai` per [SECURITY.md](../../SECURITY.md).

## License / Terms of Use

MIT ([LICENSE](../../LICENSE)). The pack's combined license expression is `MIT AND BSD-3-Clause`; this skill bundles no third-party licensed material of its own.

## Use Case

Target users: developers and creators running the skill inside a Claude Code or Codex CLI session.

Use when a product needs startup, SaaS, AI, MCP, marketplace, or review-directory submissions and a measurable tracker.

Out of scope — broader launch orchestration (use suede-launch-packaging), scalable destination-page production (use suede-programmatic-seo), or citation and search auditing (use suede-seo-audit).

## Deployment Geography

Global. The skill is a prompt-and-script package that runs locally inside the invoking agent session; it pins no region-specific service of its own.

## Requirements / Dependencies

- A Claude Code or Codex CLI session with the `suede-skills` plugin installed (install options: <https://skills.suedeai.ai/>).
- Bundled files loaded relative to this directory: `agents/` (1 file), `references/` (3 files).
- Credentials: none are bundled or required by the skill files. Any tool or API credentials come from the host session; never paste credentials into skill files, prompts, or outputs.

## Known Risks and Mitigations

- Risk: an agent treats a quality gate as autonomous authority. Mitigation: every gate in the pack is advisory — it changes what is reported, never what the user decided; only extreme-risk findings (data loss, credential exposure, legal/rights violations, payment mistakes, irreversible public damage) pause for the user's explicit choice.
- Risk: a skill instruction is used to act outside its mandate. Mitigation: the hard limits in the skill body's "Boundaries" section, quoted below.

From "Boundaries":

- Do not claim a directory is dofollow, indexed, high-authority, or producing leads without a current check.
- Do not submit listings, create accounts, publish copy, buy placements, or request reviews without explicit authorization.
- Do not fabricate traffic, ranking, review, or citation outcomes; label estimates and record the evidence date.
- Do not decide positioning or public product claims when the required product context is missing.

## References

- Skill source: [`skills/suede-directory-submissions/SKILL.md`](./SKILL.md)
- Rendered reference page: <https://skills.suedeai.ai/skills/suede-directory-submissions.html>
- Security policy and reviewed scanner exceptions: [SECURITY.md](../../SECURITY.md) and [`.plugin-scanner.toml`](../../.plugin-scanner.toml) at the repo root

## Skill Output

Structured Markdown returned in the agent's response, shaped by the output contract defined in the skill body: "Output Format". The skill publishes, posts, and sends nothing without the user's explicit authorization; delivery decisions stay with the user.

## Skill Version

0.19.0 — the pack is single-versioned, so every skill releases together; see [VERSION](../../VERSION) and [CITATION.cff](../../CITATION.cff) for the release identifier this card describes.

## Ethical Considerations

- The skill produces recommendations for a human decision-maker. Publishing, sending, payment, and rights decisions stay with the user.
- Its gates require verifiable claims and honest reporting; do not use the skill to fabricate claims, evidence, metrics, or attribution.
- Report suspected misuse or a security concern privately per [SECURITY.md](../../SECURITY.md); do not open a public issue for it.

SKILL.md 17.6 KB

---
name: suede-directory-submissions
description: "Suede-affiliated directory distribution strategy for selecting listings, sequencing submissions, tailoring positioning, and verifying backlinks. Use when a product needs startup, SaaS, AI, MCP, marketplace, or review-directory submissions and a measurable tracker. NOT FOR: broader launch orchestration (use suede-launch-packaging), scalable destination-page production (use suede-programmatic-seo), or citation and search auditing (use suede-seo-audit)."
metadata:
  version: 2.0.0
---

# Suede Directory Distribution

Suede treats directory distribution as a verifiable discovery layer, not a submission-count contest. Build the user's backlink and buyer-discovery foundation by selecting the right directories, sequencing them around real launch moments, adapting truthful positioning, and checking that each listing and backlink actually landed.

**Iron Law — approval is per destination:**

```
No external submission, account creation, paid placement, or review request
happens without explicit approval for that exact destination, copy, assets,
timing, and maximum cost. Approval for research or for another destination
never transfers. Any delta is re-approved before it ships.
```

## Before Starting

**Check for product marketing context first:**
If `.agents/product-marketing.md` exists (or `.claude/product-marketing.md`, or the legacy `product-marketing-context.md` filename, in older setups), read it before asking questions. Use that context and only ask for information not already covered or specific to this task.

---

## Core Philosophy

Directory submissions can add discovery surfaces, referral paths, and backlinks, but
their value varies by product, directory, listing quality, and current platform
rules. Treat each benefit as a hypothesis to verify with listing status, referral
analytics, search data, and qualified outcomes. A directory plan complements
destination pages and other distribution; it does not guarantee authority,
citation, traffic, ranking, or leads.

The full directory catalog lives in `references/directory-list.md`. The positioning variant library lives in `references/positioning-variations.md`. The submission tracker template lives in `references/submission-tracker-template.csv`.

---

## Three Operating Rules

### Rule 1: Foundation before submission
Before recommending a submission, verify the directory's current official
requirements and record the source URL and check date. The linked page should be
publicly reachable, truthful, useful to the directory's audience, and measurable.
Prepare only the assets the current form requires, using real product screenshots
and approved brand files. Add pricing, legal pages, video, schema, or additional
formats when the product, jurisdiction, or verified directory rules call for them;
do not invent universal prerequisites.

### Rule 2: Destination pages before directories
Choose the most relevant verified destination for each audience: a homepage,
use-case page, integration page, comparison page, template, or documentation page.
It must accurately fulfill the listing promise and have a measurable next step.
Do not impose a fixed page count or block a suitable listing merely because an
unrelated content type does not exist.

### Rule 3: Positioning varies by directory type
Adapt the description to the directory's verified fields, audience, and rules.
Reuse approved facts, but change emphasis when that improves relevance; do not
claim that duplicate descriptions trigger a search or AI penalty without current
evidence. See `references/positioning-variations.md` for templates.

| Surface | Lead with | Why |
|---|---|---|
| Startup directories | **Outcome** | Audience is other founders. They care what it does. |
| SaaS directories | **Alternative framing** | People search "[competitor] alternative" — meet them there. |
| AI directories | **AI-first architecture** | TAAFT/Futurepedia audiences explicitly want AI tools. |
| Agent/MCP directories | **Agent/MCP angle** | Use only for a live compatible capability. |
| No-code directories | **Ease + power** | Audience values speed-to-build over depth. |
| Dev directories | **Technical depth** | Dev audiences reward technical substance. |
| B2B review sites | **ROI + use case** | Buyers want outcomes and case studies. |

---

## Workflow

### Step 1: Readiness assessment (Phase 0)

Assess the selected directory against current requirements:

1. Is the product publicly accessible (no password wall)?
2. Is there a pricing page (even "free while in beta")?
3. Are privacy policy + terms live?
4. Are the required approved logo, screenshot, and video assets available?
5. Does the destination page match the proposed listing copy and CTA?
6. Is referral and conversion measurement configured?
7. Does the current directory policy allow this product, claim set, and category?
8. For review sites, are there genuine eligible users and a policy-compliant ask?
9. Who has authority to create the account, accept terms, and submit?

A missing current platform requirement, truthful destination, or submission
authority is a hard block for that directory. At the block: stop work on that
directory, name the blocker in one line ("<directory>: missing <requirement>"),
list the resolution options (obtain the requirement, substitute a truthful
destination, get explicit submission authority, or drop the directory from the
tier), and wait for the user's pick before submitting there. Other gaps are
prioritization inputs, not universal launch blockers.

### Step 2: Choose the tiers

Full catalog in `references/directory-list.md`. Summary:

| Tier | When | Illustrative candidates to verify |
|---|---|---|
| **Flagship launch** | Around a relevant launch | Product Hunt, BetaList, HN Show HN, Fazier, DevHunt |
| **Startup/SaaS** | Launch and rolling | AlternativeTo, SaaSHub, G2, Capterra, F6S |
| **AI directories** | If the product has a substantiated AI capability | TAAFT, Futurepedia, Toolify, Future Tools |
| **Agent/MCP registries** | If a live compatible integration exists | Glama, APITracker, LF MCP Registry |
| **No-code directories** | If the product genuinely serves that audience | NoCodeFinder, No Code MBA |
| **Integration marketplaces** | When the integration ships | The integration owner's official marketplace |
| **Profiles and vertical directories** | When audience and category fit | Relevant company profiles or industry-specific catalogs |

**Triage rule:** Only submit where the product is a genuine fit under the
platform's current eligibility and category rules.

### Step 3: Prepare asset variations

For each tier, prep distinct variants from
`references/positioning-variations.md` only after inspecting the destination's
current form:
- **Tagline** sized to the verified field limit
- **Short description** sized to the verified field limit
- **Long description** sized to the verified field limit
- **Category tags** limited to the verified taxonomy and product fit
- **Logo** assets
- **Screenshots** + demo video URL
- **Founder story** (2–3 sentences)

Keep facts consistent and approved. Adapt length and emphasis to each verified
form without inventing features, customers, outcomes, or platform support.

### Step 4: Batch submit

Set up the tracker spreadsheet (`references/submission-tracker-template.csv`).
Work in evidence-backed approval batches of **3–5 directories**. At the cap,
submit, verify, and report that batch's results before opening the next one.
Every submission is gated by the Iron Law: show the exact public copy, assets,
account, destination, timing, and maximum cost first.

Per submission:
1. Verify the current form, rules, price, and account identity.
2. Prepare the exact field values and assets as a reviewable draft.
3. Obtain explicit approval for that destination (Iron Law).
4. Fill and upload only the approved values.
5. Pause before any changed price, upsell, or materially different rendered
   preview; re-approve the delta.
6. Submit once, then capture confirmation.
7. Log: date, URL, status, moderator notes.
8. Once live, fetch the canonical listing URL, locate the anchor pointing at the
   destination in the rendered HTML, and record its `rel` value, redirect
   behavior, resolved destination, and the check date in the tracker. Absence of
   `rel` in response headers does not prove link attributes — inspect the
   rendered page, and log the method used.

**Reporting rule:** a listing is reported **live** only when the tracker's Live
URL, Rendered Link Attributes, and Destination Verified cells are all filled
with a check date. Anything else is reported as **submitted, unverified**.

---

## Flagship Launch Listing

For any time-sensitive launch surface, research the platform before building the
plan. Use its current official help, submission form, and community rules; record
the URLs and check date. Do not present remembered algorithm behavior, ideal
launch times, asset dimensions, hunter effects, or engagement thresholds as facts.

### Preparation milestones

- Confirm eligibility, account standing, moderation rules, scheduling options,
  required assets, and prohibited promotion.
- Draft truthful positioning, an approved maker story, real product visuals, and
  a working destination CTA in the exact current form limits.
- Preview the listing and test the product, signup, analytics, and support path.
- Build a communication plan from channels the user owns or is authorized to use.
- Assign a responder for genuine questions and feedback.

### Launch and follow-through

- Publish only after the user authorizes the listing, timing, and public copy.
- Follow current solicitation and outreach policies. Do not manipulate voting,
  fabricate engagement, or message people without a legitimate relationship and
  authorization.
- Respond helpfully, log referrals and qualified outcomes, and capture lessons.
- Share a recap only where current community rules permit it.

---

## Reviews Playbook

Review directories can help buyers evaluate products, but eligibility, incentive,
moderation, badge, report, and paid-plan rules change. Before recommending a
campaign:

1. Read the current official review and incentive policy for the chosen platform.
2. Record the source URL, check date, eligibility rules, deadlines, and maximum
   verified cost.
3. Identify real users with firsthand product experience; never manufacture,
   gate, pre-score, or script reviews.
4. Get explicit authorization for the recipient list, wording, channel, cadence,
   and any incentive before outreach.
5. Track requests, completed reviews, moderation status, referral outcomes, and
   complaints. Set targets from the actual eligible pool and user goals.

Do not claim a badge threshold, report cutoff, ownership relationship, incentive
permission, plan price, or expected response rate unless it was verified from a
current authoritative source. A small customer base is a planning constraint, not
automatic proof that a listing is worthless.

---

## Destination Pages Strategy (What the Backlinks Point At)

Match each listing to the most useful truthful page available. A homepage can be
appropriate when it satisfies the audience and promise; a specialized page may be
better when evidence supports it.

| Page type | Build it when |
|---|---|
| Alternatives page (`/alternatives/[competitor]`) | Current customer or search evidence shows comparison intent |
| Use-case / ICP page (`/for/[audience]`, `/use-cases/[use-case]`) | Demand and product evidence justify a dedicated page |
| Template or asset gallery (`/templates/[slug]`) | Templates carry standalone value and activation is measurable |
| Self-authored category roundup | The team can research the category and disclose its methodology |
| Integration page | The integration is live and the page explains setup, capabilities, and limits |

On any comparison or roundup page: verify material competitor claims, state
clearly when each option fits, date the comparison, and correct it when the facts
change. Set output volume from quality capacity and measured demand, not a
borrowed traffic or revenue story, and do not promise ranking or AI citation.

Page production at scale belongs to `suede-programmatic-seo`; comparison-page
strategy belongs to `suede-competitors`.

---

## GEO (Generative Engine Optimization)

Directories and destination pages may appear in search and answer engines. Treat
visibility as an observable outcome, not a guaranteed effect of authority scores
or markup.

On-page citation tactics (headings, schema, source-dated facts, comparison
tables) are owned by `suede-seo-audit`. Two rules stay this skill's own: earn
genuine third-party discussion rather than seeding or fabricating citations, and
keep authorized company profiles and live-integration registry entries
consistent with verified entity facts.

### Measurement

Use authorized, currently callable tools or manual checks to sample relevant
queries. Record engine, account context, prompt, locale, date, result, and whether
the result is reproducible. Verify any tracking product and its cost before
recommending it.

---

## Community & Ongoing Distribution

Most directory submissions are episodic; community participation is ongoing.
Measure each as a separate source before combining funnel conclusions.

Cross-posts and community links are still backlinks: publish only where the
community's current rules permit it, use a canonical URL where the platform
supports one, and verify the rendered link with the same Step 4.8 check applied
to directory listings.

Channel selection, cadence, and post formats belong to
`suede-community-marketing`, `suede-social`, and `suede-content-strategy`.

---

## KPIs & Tracking

Set baselines and goals from the user's current analytics, eligible audience,
capacity, and launch objective. Do not use generic day-based forecasts.

| Metric | Baseline | User-approved goal | Source and check date |
|---|---:|---:|---|
| Listings submitted and live | | | |
| Verified referring links | | | |
| Directory referral sessions | | | |
| Qualified conversions by listing | | | |
| Review requests and published reviews | | | |
| Search or answer-engine observations | | | |
| Cost and team time | | | |

---

## What NOT to Do

1. **Don't buy a mass-submission package without diligence and explicit approval.** Verify exact destinations, editorial standards, data handling, rights, maximum cost, and refund terms.
2. **Don't submit to low-quality or deceptive directories.** Evaluate audience fit, moderation, live traffic evidence, existing listings, outbound-link behavior, and reputation rather than relying on one authority score.
3. **Don't treat directories as your entire GTM.** Compare them with content, community, reviews, partnerships, and other measured channels.
4. **Don't churn listings without evidence.** Set a review cadence from product
   changes, platform notices, and observed listing issues.
5. **Don't over-index on launch-day spike.** The flywheel is templates + alternatives + reviews + ongoing content — not one day of PH.

---

## Task-Specific Questions

1. **What are you launching?** (Category changes tier mix — AI vs traditional SaaS vs no-code vs dev tool.)
2. **When is launch day?** (Work backward from verified platform requirements.)
3. **Do you have destination pages built?** (Alternatives, use cases, templates — if not, build first.)
4. **Which flagship surface is being considered, and what do its current rules require?**
5. **How many eligible users could receive a policy-compliant review request?**
6. **Do you have a live tested MCP or agent capability?** (If yes, verify compatible registries.)
7. **Existing integrations?** (If yes, verify each owner's marketplace eligibility.)
8. **Which owned audiences can be contacted, and has the user authorized outreach?**
9. **Current DR and referring domain count?** (Baseline for measuring the compounding effect.)

---

## Output Format

When the user asks for a directory plan, return:

1. **Readiness assessment** — which Phase 0 items are missing, which block submission
2. **Tier selection** — which tiers apply, which to skip, why
3. **Submission order** — evidence-backed batches mapped to current requirements
4. **Destination page list** — what to build first if missing
5. **Positioning variants** — the actual copy per tier (from `references/positioning-variations.md`)
6. **Flagship listing timeline** — mapped from current rules to calendar dates
7. **Policy-compliant review plan** — eligible audience, authorization, copy, cadence
8. **Weekly measurement plan** — baselines and user-approved goals
9. **Tracker** — link to or include the CSV from `references/submission-tracker-template.csv`

Keep the plan actionable. Every item should be something the user can do today.

---

## Boundaries

- Do not claim a directory is dofollow, indexed, high-authority, or producing leads without a current check.
- Do not submit listings, create accounts, publish copy, buy placements, or request reviews without explicit authorization.
- Do not fabricate traffic, ranking, review, or citation outcomes; label estimates and record the evidence date.
- Do not decide positioning or public product claims when the required product context is missing.

## Routing

- Use `suede-launch-packaging` for the broader launch sequence.
- Use `suede-programmatic-seo` for destination pages and `suede-seo-audit` for search or citation checks.
- Use `suede-competitors` for comparison-page strategy and `suede-content-strategy` for editorial support.
- Use `suede-free-tools` for interactive destination assets, and `suede-community-marketing`, `suede-social`, or `suede-content-strategy` for community and social distribution.
- Use `suede-public-relations` when a flagship launch also warrants earned media.
- From those skills, route directory selection, listing positioning, and backlink verification back to `suede-directory-submissions`.