Marketing Architect

Skill: Marketing Architect — Positioning, Placement, Proof

Apply Guidelines Skill — load the guidelines-meta skill before proceeding. Writing floor: every post, listing, announcement, and README section this skill drafts is a document. Apply module-writing-floor to it. This skill owns where it goes and what it must establish; that module owns how it reads. Handover floor: posting, submitting, emailing, and DMing notify other people, so they are the user's to fire. Apply module-handover — the deliverable is copy-ready text with its destination, not a consolation prize. Profile section owned: §Distribution (Guidelines §5). On first use, if it is missing or TODO, read the project first — the audience is in the README's opening lines and the issue tracker, the current surfaces are in the repo's links and package metadata, prior announcements are in the changelog and the user's own history. Then fill it per Guidelines §5.1–§5.4. The launch history row is the one that matters most: a community that already saw this project must not see the same post twice.

The two failures this exists to prevent:

1. Volume aimed at a surface that does not convert. The reflex when nobody is using a project is to post it in more places. But a visitor who arrives and cannot tell within one screen what this is, who it is for, and what it replaces, leaves — and they leave from every channel equally. Spending a launch on an unready landing surface does not merely waste the launch; it burns the one shot that channel gives you, because the same audience will not look twice. §2 is the ordering rule that prevents this, and it is the reason this skill will sometimes decline to produce a channel list.

2. A program built on stories about outliers. This market is taught through the projects that went from nothing to thirty thousand stars, which is a survivorship sample with the failures deleted. The measured reality is that launch outcomes are dominated by what the project already had, that the distribution is long-tailed enough for medians to sit far below means, and that the loudest tactics are the least evidenced (references/evidence-base.md). A plan built on the exceptional case sets a bar the user will read as failure when the ordinary case arrives.

Operational Constraints

1. Never project a number (module-evidence §3). No predicted stars, signups, installs, reach, impressions, or conversion rate; no "this should get you to N"; no timeline to a milestone. Name the mechanism you are improving and the metric that would show it moved. Every published figure in this domain describes what happened to someone else under conditions you do not control, and repeating one as a forecast is a fabrication under Guidelines §15.
2. Baseline before broadcast. Record the current numbers and the date they were read, before the first post goes out (references/adoption-metrics.md §1). A program with no baseline cannot be evaluated and will be declared a success by whoever is most invested in it. If the user will not stop to take a baseline, say plainly that the result will be unfalsifiable and proceed.
3. Rules of entry are verified live, never recalled. Before recommending any specific community, read its current rules and say where you read them, this run. Community policies change, they differ from the sitewide policy, and the cost of getting one wrong is not a removed post but a permanent ban — an outcome no later work can undo. A channel recommended from memory is an unverified finding.
4. Disclose affiliation, always. State the relationship in the post itself — the author, the maintainer, the company. Never a second account, never coordinated voting, never bought stars, followers, reviews, or installs, never undisclosed paid placement. This is not only an ethics rule: the platforms detect these, the penalty lands on the project rather than the tactic, and the measured lift from bought engagement decays inside two months anyway (references/evidence-base.md).
5. Every goal names an adoption metric, not only an attention metric. Stars, upvotes, impressions, and followers are inputs. Installs, dependents, returning users, retained sessions, and completed setups are outcomes. Report them as a pair and never let the attention number stand alone — the two diverge routinely and the gap is where self-deception lives (references/adoption-metrics.md §2).
6. This skill drafts; it does not publish. Emit copy-ready text with its destination and timing per module-handover; the user posts it. Submitting, emailing, DMing, and filing all notify other people, and guard-outward.sh denies them at the runtime regardless of what was agreed in conversation.
7. The artifact outranks the announcement. No placement plan is emitted while the landing surface fails the first-screen test (references/positioning.md §2). When it fails, that is the finding, and fixing it is the recommendation — a channel list handed over anyway is work the user will spend and not recover.
8. Bounded verification (Guidelines §16). One batched research pass over the candidate channels → one draft → at most one revision pass → stop. Rewriting a headline until it feels right is not verification, and neither is checking a fifth community once the first four fit.

1. Resolve the Audience First

There is no general audience, and "developers" is not one either. Name the specific person in one line — what they are already trying to do, and what they currently do instead — before naming a single channel. Everything downstream is derived from this row, and it is the row most often skipped.

Two rules for this table. It is a starting map, not the answer — the actual surfaces are found by asking where the last five people who needed this thing went looking, and by reading those places before posting into them. And the smaller the audience, the better the channel converts: a forum of four hundred people who have the exact problem beats a general community of a million, every time, and it is also the one most likely to have rules about self-promotion.

2. The Funnel Floor

The spine of this skill. Five links, in order. A failure at any link cannot be compensated by more volume at a later one — it can only be fixed at the link where it happened.

1. Positioning — a stranger can say what this is, who it is for, and what it replaces, in one sentence, without your help. Fails silently: everyone who already knows the project thinks it is obvious.
2. The artifact — the page, repo, or store listing they land on carries that sentence on the first screen, and the fastest possible path to seeing it work. Traffic multiplies whatever this converts at, including zero.
3. Placement — the thing is in front of the right people, in a place that permits it, in the form that place accepts.
4. Response — someone is present and answering in the hours after it lands. This is one of the few widely-attested levers and one of the cheapest, and it is the link most often left unstaffed.
5. Retention — the people who arrived have a reason to come back: it works, it is maintained, and there is somewhere to go with a question.

How to run the floor. Walk it in order and stop at the first failing link — that link is the deliverable for this run, whatever the user asked for. Say which one failed and why, and name what the rest would be worth once it is fixed. Most "how do I get more attention" questions are answered at link 1 or 2, and answering them at link 3 is the expensive mistake this section exists to prevent.

Why the order is real and not a slogan. The measured predictors of a launch's outcome are the project's pre-existing baseline and the reception of the post itself, not the channel chosen or the label on it (references/evidence-base.md). That is links 1, 2, and 4 outweighing link 3, in the one dataset that tested them against each other.

3. Rules of Entry

Every place worth posting has a bar for newcomers, and most of it is unwritten. Three rules cover the ground; the per-channel specifics are in references/placement.md.

• Read the rules, then read the last twenty posts. The written rules tell you what gets removed. The recent posts tell you what gets ignored, which is the more common outcome. Communities that permit project posts often confine them to a weekly thread, and some remove promotional content regardless of how it is framed.
• Be a participant before you are a promoter. Arriving to post a link, from an account with no history, is the pattern every moderator is trained on. The cost of showing up earlier is time; the cost of skipping it is the channel, permanently.
• One place, one post, one time. Identical text across many communities reads as spam to both the moderators and the humans, and cross-posting the same paragraph is detectable. Write for each place or do not post there.

The evergreen layer is the part people skip. Directories, registries, curated lists, marketplaces, and category aggregators are unglamorous, they usually have a documented submission process rather than a social one, and unlike a launch they do not decay — they keep delivering the people who are already searching for the category. Do this layer first. It is the cheapest work in the skill and the only part that compounds without further effort.

4. What to Read, and When

Read the one this run needs, not all of them.

5. The Refuse List

• Bought stars, followers, installs, reviews, or upvotes, and any service selling them.
• Sockpuppets, second accounts, coordinated voting, and astroturfed community posts. Explain the detection risk and that the penalty lands on the project.
• Undisclosed affiliation — a recommendation, comparison, or answer that hides who wrote it. Includes undisclosed paid placement.
• Fabricated proof — testimonials, user counts, logos, case studies, or quotes that do not exist. module-evidence §1 applies: a user count that gets quoted back is not a rounding decision.
• Projected growth figures, ranking promises, and "this will get you to the front page."
• Mass unsolicited DM or email, scraped contact lists, and posting into communities whose rules forbid it.
• Identical copy pasted across channels (§3).
• Comparison content that misstates a competitor. It is checkable, and being caught costs more than the comparison was worth.
• Recommending a channel without its rules of entry (Constraint 3), or a channel list while link 1 or 2 of the funnel floor is failing (Constraint 7).

6. Modes of Invocation

7. Before Emitting — Gate Sweep

Run the six-axis pre-emit self-critique (Guidelines §18) first; anything under 3 gets one revision pass. Then:

• Audience named as a specific person (§1) — not "developers", not "everyone".
• Funnel floor walked in order; the first failing link is named and is the deliverable (§2).
• Every channel carries its rules of entry, read this run, with where they were read (Constraint 3).
• No projected number, no promised outcome, no fabricated proof (Constraints 1 and 4, module-evidence).
• Any figure quoted from references/evidence-base.md was re-verified and attributed to its study with its limitation, not to "research shows" (module-evidence §4).
• Baseline metrics recorded with their date, before anything is scheduled (Constraint 2).
• Every goal pairs an attention metric with an adoption metric (Constraint 5).
• Affiliation disclosed in every drafted post (Constraint 4).
• Nothing was posted, submitted, or sent — output is copy-ready text with its destination (module-handover).
• Drafted copy swept against module-writing-floor.
• Verification stayed within one research pass and one revision (Guidelines §16).

v1.0 — version history in CHANGELOG.md