agentsclimarketplace
Sign in

Growth engineering brief

Skill duandigi/duandigi-growth-marketing-skill/skills/growth-engineering-brief

Use this skill when translating a growth hypothesis into an implementation-ready brief for a landing page, free tool, calculator, onboarding change, tracking event, CRM automation, referral mechanism, integration, or WordPress change.From its SKILL.md

Install
npx -y skills add duandigi/duandigi-growth-marketing-skill --skill growth-engineering-brief

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 file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

2.8 KB, 445 tokens by cl100k_base, as published. Nobody here has run it

Growth Engineering Brief

Purpose

Bridge growth strategy and safe technical execution with measurable acceptance criteria.

Inputs

  • Approved hypothesis and experiment design
  • Current system and constraints
  • Tracking requirements
  • Security, privacy, accessibility, rollback, and approval rules

If critical input is unavailable, label it unknown and create a research or instrumentation task. Do not invent values.

Workflow

  1. Define the user problem, target behavior, and experiment mechanism.
  2. Describe scope, non-scope, user flow, states, content, data, and integrations.
  3. Specify analytics events, properties, identity rules, consent, and QA queries.
  4. Define acceptance criteria for function, tracking, accessibility, performance, and SEO where relevant.
  5. List failure modes, security concerns, data retention, and platform-policy constraints.
  6. Design feature flags, backups, rollback, and approval checkpoints.
  7. Return an implementation brief; do not execute production changes unless separately authorized.

Required output

Return a concise, decision-oriented response containing:

  • Problem and hypothesis
  • Functional scope
  • User flow
  • Data and tracking
  • Acceptance criteria
  • Risks
  • Launch and rollback plan

Label important statements as confirmed, inferred, assumed, or unknown when the distinction affects the decision.

Guardrails

Do not:

  • Writing code before requirements and tracking are clear

  • Storing secrets in the brief

  • Shipping without rollback

  • Claim guaranteed growth or present an estimate as observed fact.

  • Recommend spam, fake reviews, impersonation, deceptive urgency, dark patterns, policy evasion, or unauthorized production changes.

  • Hide material uncertainty, tracking limitations, or possible harm.

When an action can spend money, publish content, contact people, change production systems, delete data, or alter access, produce a plan and request explicit authorization rather than executing automatically.

Completion check

Before finishing, verify that the output:

  • answers a specific growth decision;
  • uses the supplied business context;
  • separates evidence from assumptions;
  • defines a measurable next step;
  • includes risks, constraints, and missing data;
  • is no longer than necessary for the decision.

What ships with it: 1 file

1.3 KB alongside SKILL.md

evals/

Gives 0 of the 12 instructions most plan spec skills give in 445 tokens

Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07

  • Ask one question at a timein 51 of 1099
  • Break plans into vertical slicesin 29 of 1099, across 11 files
  • Publish issues in dependency orderin 27 of 1099, across 9 files
  • Iterate until user approves the breakdownin 25 of 1099, across 7 files
  • Explore the repository to understand the codebase statein 24 of 1099, across 7 files
  • Use domain glossary vocabularyin 23 of 1099, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1099, across 5 files
  • Prefer AFK slices over HITLin 22 of 1099, across 7 files
  • Write a specification before writing any codein 22 of 1099, across 14 files
  • Write failing tests before implementation codein 22 of 1099, across 20 files
  • Ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
  • Respect existing architecture decision recordsin 20 of 1099, across 5 files

Said here and by no other author read

  • label unavailable critical inputs as unknown
  • do not invent missing input values
  • define the user problem and experiment mechanism
  • describe the functional scope and user flow
  • specify analytics events and tracking properties
  • design feature flags and a rollback plan

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,834. 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.