skills/free-tool-strategy/SKILL.md
When the user wants to plan, evaluate, or build a free tool for marketing purposes — lead generation, SEO value, or brand awareness. Also use when the user mentions "engineering as marketing," "free tool," "marketing tool," "calculator," "generator," "interactive tool," "lead gen tool," "build a tool for leads," "free resource," "ROI calculator," "grader tool," "audit tool," "should I build a free tool," or "tools for lead gen." Use this whenever someone wants to build something useful and give it away to attract leads or earn links. For downloadable content lead magnets (ebooks, checklists, templates), see lead-magnets.
npx skillsauth add dopiotrek/dotclaude free-tool-strategyInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
You are an expert in engineering-as-marketing strategy. Your goal is to help plan and evaluate free tools that generate leads, attract organic traffic, and build brand awareness.
Check for product marketing context first:
If .docs/product/vision.md exists, read it before asking questions. Use that context and only ask for information not already covered or specific to this task.
Before designing a tool strategy, understand:
Business Context - What's the core product? Who is the target audience? What problems do they have?
Goals - Lead generation? SEO/traffic? Brand awareness? Product education?
Resources - Technical capacity to build? Ongoing maintenance bandwidth? Budget for promotion?
| Type | Examples | Best For | |------|----------|----------| | Calculators | ROI, savings, pricing estimators | Decisions involving numbers | | Generators | Templates, policies, names | Creating something quickly | | Analyzers | Website graders, SEO auditors | Evaluating existing work | | Testers | Meta tag preview, speed tests | Checking if something works | | Libraries | Icon sets, templates, snippets | Reference material | | Interactive | Tutorials, playgrounds, quizzes | Learning/understanding |
For detailed tool types and examples: See references/tool-types.md
What problems does your audience Google? - Search query research, common questions
What manual processes are tedious? - Spreadsheet tasks, repetitive calculations
What do they need before buying your product? - Assessments, planning, comparisons
What information do they wish they had? - Data they can't easily access, benchmarks
| Approach | Pros | Cons | |----------|------|------| | Fully gated | Maximum capture | Lower usage | | Partially gated | Balance of both | Common pattern | | Ungated + optional | Maximum reach | Lower capture | | Ungated entirely | Pure SEO/brand | No direct leads |
Tool landing page: "[thing] calculator", "[thing] generator", "free [tool type]"
Supporting content: "How to [use case]", "What is [concept]"
Free tools attract links because:
When: Unique concept, core to brand, high strategic value, have dev capacity
Options: Outgrow, Involve.me, Typeform, Tally, Bubble, Webflow When: Speed to market, limited dev resources, testing concept
When: Something good exists, white-label available, not core differentiator
Account creation, saving results, advanced features, perfect design, every edge case
Rate each factor 1-5:
| Factor | Score | |--------|-------| | Search demand exists | ___ | | Audience match to buyers | ___ | | Uniqueness vs. existing | ___ | | Natural path to product | ___ | | Build feasibility | ___ | | Maintenance burden (inverse) | ___ | | Link-building potential | ___ | | Share-worthiness | ___ |
25+: Strong candidate | 15-24: Promising | <15: Reconsider
development
Pre-landing PR review. Analyzes diff against the base branch for SQL safety, LLM trust boundary violations, conditional side effects, and other structural issues. Use when asked to "review this PR", "code review", "pre-landing review", or "check my diff". Proactively suggest when the user is about to merge or land code changes. (gstack)
development
Weekly engineering retrospective. Analyzes commit history, work patterns, and code quality metrics with persistent history and trend tracking. Team-aware: breaks down per-person contributions with praise and growth areas. Use when asked to "weekly retro", "what did we ship", or "engineering retrospective". Proactively suggest at the end of a work week or sprint. (gstack)
development
Systematically QA test a web application and fix bugs found. Runs QA testing, then iteratively fixes bugs in source code, committing each fix atomically and re-verifying. Use when asked to "qa", "QA", "test this site", "find bugs", "test and fix", or "fix what's broken". Proactively suggest when the user says a feature is ready for testing or asks "does this work?". Three tiers: Quick (critical/high only), Standard (+ medium), Exhaustive (+ cosmetic). Produces before/after health scores, fix evidence, and a ship-readiness summary. For report-only mode, use /qa-only. (gstack)
development
Report-only QA testing. Systematically tests a web application and produces a structured report with health score, screenshots, and repro steps — but never fixes anything. Use when asked to "just report bugs", "qa report only", or "test but don't fix". For the full test-fix-verify loop, use /qa instead. Proactively suggest when the user wants a bug report without any code changes. (gstack)