Product collection · 25 skills
25 skills for APIs, SDKs, CLIs, open-source projects and other products used by engineers.
Work from the engineering task to a runnable example, real-project value and team ownership. These versions account for supported stacks, local or hosted execution, packages and SDKs, maintainers, integration effort and platform approval.
Each version has its own skill name, product-specific decision criteria and examples. Shared methods do not create a runtime dependency on the other repository.
Clone jonbishop1/devtool-marketing-skills and copy the desired .agents/skills/<name>/ folders to the location documented by your Agent Skills-compatible host. Preserve the references and assets.
For Claude Code: /plugin marketplace add jonbishop1/devtool-marketing-skills then /plugin install devtool-marketing-skills@jon-bishop-devtool.
The skills use the open Agent Skills format and MIT license. File-format and plugin-manifest checks have passed; compatibility and output quality still depend on your host, tools and evidence.
Examples are fictional unless explicitly described as measured evidence. A sample result does not establish production readiness. Plans and drafts do not authorize external actions.
Assess whether an agent can discover, understand and complete a defined task, with evidence for each stage.
Assess a defined engineering task through available docs/API/SDK/CLI/MCP/skills paths. Separate discoverability, documented setup, authorized execution, result verification, and recovery; no particular interface file is sufficient or mandatory.
Prepare useful technical contributions for relevant communities, maintainers and product ecosystems.
Choose stack-specific communities, maintainers, or package ecosystems where the task is relevant. Offer a reproducible answer and disclose affiliation. Respect project governance and maintain the example rather than turning issue trackers into promotion channels.
Build a small, verifiable path to a useful technical result, including prerequisites, recovery and cleanup.
Use one supported engineering task with sanitized input, exact prerequisites, expected output, deterministic success assertion, recovery, and cleanup. Disclose credentials or hosted costs before commands and distinguish verified execution from plausible instructions.
Turn a repository README into a clear path from the engineering task to a working example and real-project adoption.
Expose task, local/hosted boundary, supported runtime, minimal verified command, expected output, license, maintenance, and support. Make the route from a sample to own-project adoption clear without inventing traction badges.
Work out who needs your product, how they describe the problem, and where you can reach them.
Compare segments by stack, recurring engineering task, deployment policy, integration authority, and dependency ownership. Separate tutorial learners from teams with a production problem; include maintainers and internal-build alternatives.
Compare the alternatives buyers consider, including their current manual process, and find a useful position for your product.
Compare the tool with scripts, framework features, existing platform tooling, and open-source packages on the exact engineering task. Inspect installability, maintenance, licensing, integration effort, and reversibility before claiming a reason to switch.
Turn a clear brief and real expertise into a useful article, guide, comparison or other content asset.
For tutorials state supported runtime, installation, sanitized input, expected result, failure recovery, and integration boundary. Test only in the authorized environment, label untested commands, and show a process diagram when it explains execution.
Decide which customer questions your content should answer and where that content belongs.
Build around supported stacks, debugging and integration tasks, migration decisions, and production tradeoffs. Choose a canonical docs path and a distinct editorial purpose; avoid duplicating reference documentation to fill a calendar.
Turn your product facts and customer language into clearer website, email, ad or sales copy.
Anchor copy in the engineering task, supported environment, input/output, and evidence of reduced effort or risk. Distinguish local/open-source use from paid hosted behavior; select a runnable example or docs CTA when that fits readiness.
Use customer evidence to understand buying decisions, switching concerns and friction in your marketing or product experience.
Investigate whether hesitation concerns owning another dependency, exposing payloads, debugging integration failure, or persuading a platform owner. Offer a reversible local proof and a clear maintenance boundary; do not attribute every stall to developer skepticism.
Connect marketing activity to signup, activation, retention and customer quality using clear definitions and usable data.
Choose person/project/workspace/account identities deliberately. Separate downloads, automated API activity, sample success, own-project useful tasks, repeat project use, and paid team adoption. Cohort by eligibility and complete observation windows.
Plan or diagnose paid search around buyer intent, campaign structure and meaningful conversion tracking.
Classify learner, job, support, free-package, commercial-tool, and production-task queries before excluding or bidding. Define qualified own-project evaluation and recurring use; do not optimize a campaign solely for low-cost signups.
Plan a page around the visitor’s questions, the evidence they need and the action you want them to take.
Organize the page around task, supported stack, input/output, runnable path, integration limits, proof, and adoption requirements. Provide an evaluator route and a platform/buyer route where they need different evidence.
Create a reusable product, audience and adoption brief. Other skills can reuse it, but a full intake is optional.
Record language/runtime, local or hosted execution, package or repository access, current debugging/integration workflow, and who maintains a new dependency. Define first useful task success and repeated project use separately.
Choose marketing priorities that fit your product, audience, budget and capacity.
Sequence task-specific discovery, a runnable example, own-project success, and team adoption. If setup fails, prioritize evaluation reliability before additional distribution. Measure qualified projects and recurring useful tasks instead of stars or package downloads.
Plan or review Facebook and Instagram campaigns with attention to creative, audience, tracking and downstream quality.
Judge whether a verified task demonstration can reach relevant engineers in an interruption channel. Broad interests do not establish a developer role or deployment authority. Connect engagement to useful task evaluation, with a capped hypothesis test.
Help new users reach a useful first result through clearer signup, setup, in-product guidance and supporting messages.
Map installation, environment compatibility, credentials if needed, sample task, own-project task, repeat use, and team integration. Provide recovery and a maintenance owner; distinguish automation/retries from independent successful use.
Prepare the launch of a product or feature, from audience and channel choices through follow-up.
Verify package/repository access, license, supported runtime, install commands, a reproducible demo, limitations, and maintainer support before choosing launch scope. Measure task success and repeated project adoption alongside attention.
Diagnose technical, on-page and content problems, then prioritize fixes using evidence from your own site.
Inspect docs versioning, repository/package links, supported framework examples, rendered task instructions, canonical paths, and useful transitions into a runnable evaluation. Diagnose the observed rendering issue before proposing a stack rewrite.
Find relevant search topics, understand search intent and choose opportunities your site can realistically pursue.
Separate programming education, package support, jobs, debugging, integration, and tool-selection intent. Favor tasks the product can actually complete and check whether official framework docs already answer the query better.
Turn useful event conversations into consent-aware, qualified next steps and bounded evaluations.
Use a reproducible engineering demo with a safe offline fallback. Qualify stack, recurring task, and team-integration ownership. Capture only permitted notes and an agreed next step; badge scans are not qualified pipeline or blanket outreach consent.
Explain and distribute a verified joint workflow, with clear compatibility, data flow and support ownership.
Verify the SDK/CLI/plugin/CI/API workflow, versions, permissions, expected result, artifact storage, secrets handling, maintenance, and support ownership. Distinguish a custom example from an officially supported partner integration.
Choose a value metric and package boundaries that fit real technical workloads and predictable customer costs.
Compare value alignment for individuals, teams, service accounts, and heavy CI automation. Assess whether per-seat or per-request billing discourages integration or creates surprise usage. Separate open-source license terms from managed-service pricing.
Substantiate technical claims with an appropriate test, reproducible evidence and honest limitations.
Define the actual task and baseline before making productivity or speed claims. A faster local demonstration does not prove team productivity. Record versions, equivalent setup, correctness, failures, repeated runs, and reproducibility.
Help a technical champion turn demonstrated value and unresolved risks into an informed internal decision.
Turn an individual successful task into an honest team-evaluation memo: dependency and maintenance owner, integration effort, deployment and security review, commercial fit, reversibility, and an owned next test. Do not call a local demo production adoption.