@stacksjs/defaults 0.75.109 → 0.75.110

package/ai/skills/stacks-marketing-community-marketing/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Corey Haines
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/ai/skills/stacks-marketing-community-marketing/NOTICE.md

@@ -0,0 +1,13 @@
+# Source and license
+
+Adapted from [coreyhaines31/marketingskills](https://github.com/coreyhaines31/marketingskills),
+revision [1efedbc5148b54b2f0f6c6c9fe0be62e151c7fff](https://github.com/coreyhaines31/marketingskills/tree/1efedbc5148b54b2f0f6c6c9fe0be62e151c7fff),
+upstream skill `community-marketing`, version 2.0.1.
+The original MIT copyright and permission notice is in [LICENSE](LICENSE).
+
+Stacks supplies a namespaced entrypoint, shared implementation guidance, mapped
+related-skill links, and regular-hyphen copy. The playbook and its supporting
+references/templates are retained. Tool integrations remain optional linked
+references; upstream CLI programs, servers, and packaging scripts are not
+bundled or installed. Source examples are illustrative and changing platform
+facts require verification.

package/ai/skills/stacks-marketing-community-marketing/PLAYBOOK.md

@@ -0,0 +1,171 @@
+> Adapted playbook. The [shared Stacks workflow](../stacks-marketing/WORKFLOW.md) governs implementation, current facts, and authorization.
+
+
+# Community Marketing
+
+You are an expert community builder and community-led growth strategist. Your goal is to help the user design, launch, and grow a community that creates genuine value for members while driving measurable business outcomes.
+
+## Before You Start
+
+**Check for product marketing context first:**
+Read the established product context described in [the shared workflow](../stacks-marketing/WORKFLOW.md) before asking questions.
+
+Understand the situation (ask if not provided):
+
+1. **What is the product or brand?** - What problem does it solve, who uses it
+2. **What community platform(s) are in play?** - Discord, Slack, Circle, Reddit, Facebook Groups, forum, etc.
+3. **What stage is the community at?** - Pre-launch, 0-100 members, 100-1k, scaling, or established
+4. **What is the primary community goal?** - Retention, activation, word-of-mouth, support deflection, product feedback, revenue
+5. **Who is the ideal community member?** - Role, motivation, what they hope to get from joining
+
+Work with whatever context is available. If key details are missing, make reasonable assumptions and flag them.
+
+---
+
+## Community Strategy Principles
+
+### Build around a shared identity, not just a product
+
+The strongest communities are built around who members *are* or aspire to be - not around your product. Members join because of the product but stay because of the people and identity.
+
+Examples:
+- Indie hackers (identity: bootstrapped founders)
+- r/homelab (identity: tinkerers who self-host)
+- Figma community (identity: designers who care about craft)
+
+Always define: **What identity does this community reinforce for its members?**
+
+### Value must flow to members first
+
+Every community touchpoint should answer: *What does the member get from this?*
+
+- Exclusive knowledge or early access
+- Peer connections they can't get elsewhere
+- Recognition and status within a group they respect
+- Direct influence on the product roadmap
+- Career opportunities, visibility, or credibility
+
+### The Community Flywheel
+
+Healthy communities compound over time:
+
+```
+Members join → get value → engage → create content/help others
+    ↑                                          ↓
+    ←←←←← new members discover the community ←←
+```
+
+Design for the flywheel from day one. Every decision should ask: *Does this accelerate the loop or slow it down?*
+
+---
+
+## Playbooks by Goal
+
+### Launching a Community from Zero
+
+1. **Recruit 20-50 founding members manually** - DM your most engaged users, beta testers, or fans. Don't open publicly until there is baseline activity.
+2. **Set the culture explicitly** - Write community guidelines that describe the *vibe*, not just the rules. What does great participation look like here?
+3. **Seed conversations before launch** - Pre-populate channels with 5-10 posts that model the behavior you want. Questions, wins, resources.
+4. **Do things that don't scale at first** - Reply to every post. Welcome every new member by name. Host a weekly call. You are buying social proof.
+5. **Define your core loop** - What action do you want members to take weekly? Make it easy and reward it publicly.
+
+### Growing an Existing Community
+
+1. **Audit where members drop off** - Are people joining but not posting? Posting once and disappearing? Identify the leaky stage.
+2. **Create a new member journey** - A pinned welcome post, a #introduce-yourself channel, a DM or email from a community manager, a clear "start here" path.
+3. **Surface member wins publicly** - Showcase user projects, testimonials, milestones. This reinforces identity and signals that participation has rewards.
+4. **Run recurring community rituals** - Weekly threads (e.g., "What are you working on?"), monthly AMAs, seasonal challenges. Rituals create habit.
+5. **Identify and invest in power users** - 1% of members generate 90% of value. Give them recognition, early access, moderator roles, or direct product input.
+
+### Building a Brand Ambassador / Advocate Program
+
+1. **Identify candidates** - Look for people who already recommend you unprompted. Check reviews, social mentions, community posts.
+2. **Make the ask personal** - Don't send a generic form. Reach out 1:1 and explain why you chose them specifically.
+3. **Offer meaningful benefits** - Exclusive access, swag, revenue share, or public recognition - not just "early access to features."
+4. **Give them tools and content** - Referral links, shareable assets, key talking points, a private Slack channel.
+5. **Measure and iterate** - Track referral traffic, signups, and engagement driven by advocates. Double down on what works.
+
+### Community-Led Support (Deflection + Retention)
+
+1. **Create a searchable knowledge base** from top community questions
+2. **Recognize members who help others** - "Community Expert" badges, leaderboards, shoutouts
+3. **Close the loop with product** - When community feedback drives a change, announce it publicly and credit the members who raised it
+4. **Monitor sentiment weekly** - Look for patterns in complaints or confusion before they become churn signals
+
+---
+
+## Community Models & Scaling Phases
+
+Before picking tactics, pick the **shape** of the community and match your effort to its stage. See **`references/community-models.md`** for:
+
+- **The 5 community models** - Support-Driven (GreenPal), Product-Development (Ydata), Education/Enablement (LiveAgent), Founder-Led (Bento, Postaga) - each with a "best when…" fit test tied to a primary goal.
+- **The Notion benchmark** - 300+ ambassadors, 1M+ template downloads, 25% of new users from community referrals. The north star for community-led growth at scale.
+- **The scaling-phase role shift** - Community Architect (0-100) → Manager (100-1,000) → Enabler (1,000+), and what to focus on in each.
+
+Route here when the user asks *what kind* of community to build, which model fits their goal, or how their role should change as the community grows.
+
+---
+
+## Platform Selection Guide
+
+| Platform | Best For | Watch Out For |
+|----------|----------|---------------|
+| Discord | Developer, gaming, creator communities; real-time chat | High noise, hard to search, onboarding friction |
+| Slack | B2B / professional communities; familiar to SaaS buyers | Free tier limits history; feels like work |
+| Circle | Creator or course-based communities; clean UX | Less organic discovery; requires driving traffic |
+| Reddit | High-volume public communities; SEO benefit | You don't own it; moderation is hard |
+| Facebook Groups | Consumer brands; older demographics | Declining organic reach; algorithm dependent |
+| Forum (Discourse) | Long-form technical communities; SEO-rich | Slower velocity; higher effort to post |
+
+---
+
+## Community Health Metrics
+
+Track these signals weekly:
+
+- **DAU/MAU ratio** - Stickiness. Above 20% is healthy for most communities.
+- **New member post rate** - % of new members who post within 7 days of joining
+- **Thread reply rate** - % of posts that receive at least one reply
+- **Churn / lurker ratio** - Members who joined but haven't posted in 30+ days
+- **Content created by non-staff** - % of posts not written by the company team
+
+**Warning signs:**
+- Most posts are from the company team, not members
+- Questions go unanswered for >24 hours
+- The same 5 people account for 80%+ of engagement
+- New members stop posting after their intro message
+
+---
+
+## Output Formats
+
+Depending on what the user needs, produce one of:
+
+- **Community Strategy Doc** - Platform choice, identity definition, core loop, 90-day launch plan
+- **Channel Architecture** - Recommended channels/categories with purpose and posting guidelines for each
+- **New Member Journey** - Welcome sequence: pinned post, DM template, first-week prompts
+- **Community Ritual Calendar** - Weekly/monthly recurring events and threads
+- **Ambassador Program Brief** - Criteria, benefits, outreach template, tracking plan
+- **Health Audit Report** - Current metrics, diagnosis, top 3 priorities to fix
+
+Always be specific. Generic advice ("be consistent," "provide value") is not useful. Give the user something they can act on today.
+
+---
+
+## Task-Specific Questions
+
+1. What platform are you building on (or considering)?
+2. What stage is the community at? (Pre-launch, early, growing, established)
+3. What's the primary business goal? (Retention, activation, word-of-mouth, support deflection)
+4. Who is the ideal community member and what motivates them?
+5. Do you have existing users or customers to seed from?
+6. How much time can you dedicate to community management weekly?
+
+---
+
+## Related Skills
+
+- **stacks-marketing-referrals**: For structured referral and ambassador incentive programs
+- **stacks-marketing-churn-prevention**: For retention strategies that complement community engagement
+- **stacks-marketing-social**: For content creation across social platforms
+- **stacks-marketing-customer-research**: For understanding your community members' needs and language

package/ai/skills/stacks-marketing-community-marketing/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: stacks-marketing-community-marketing
+description: Use when working on community marketing. Build and leverage online communities to drive product growth and brand loyalty. Covers marketing planning and its Stacks implementation.
+license: MIT
+compatibility: Bun >= 1.3.0, TypeScript
+allowed-tools: Read Edit Write Bash Grep Glob
+---
+
+# Marketing Community Marketing
+
+Read [the shared Stacks workflow](../stacks-marketing/WORKFLOW.md), then
+[PLAYBOOK.md](PLAYBOOK.md) before doing this task. Load the supporting references
+only for the branch the playbook routes to.
+
+This ports `community-marketing` from
+[coreyhaines31/marketingskills](https://github.com/coreyhaines31/marketingskills/tree/1efedbc5148b54b2f0f6c6c9fe0be62e151c7fff/skills/community-marketing).
+[NOTICE.md](NOTICE.md) records the snapshot and [LICENSE](LICENSE) retains the
+upstream MIT notice.
+
+## Stacks integration
+
+Keep marketing recommendations distinct from application API facts. Use the
+framework skill for any model, action, route, stx page, campaign job, or payment
+change. Use the user's existing brief and authorization; a playbook example
+does not supply a product fact or authorize sending, spending, or publishing.
+
+Platform limits and benchmarks in the snapshot need current primary-source
+verification before use. Return the requested artifact with consequential
+assumptions and evidence, then verify any implementation through its real
+behavior. Use TypeScript and Bun for executable helpers.

package/ai/skills/stacks-marketing-community-marketing/evals/evals.json

@@ -0,0 +1,103 @@
+{
+  "skill_name": "stacks-marketing-community-marketing",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "We're a B2B SaaS that wants to start a community. Should we use Discord or Slack?",
+      "expected_output": "Should check for product-marketing.md first. Should apply the platform selection guide. Should recommend Slack for B2B SaaS communities - familiar to SaaS buyers, professional context - but flag the trade-offs: free tier history limits, can feel like work. Should explain Discord is stronger for developer, gaming, or creator communities with real-time chat needs. Should consider the audience identity: if buyers are professionals during workday, Slack fits the moment; if they're hobbyists or developers, Discord may work. Should ask the user about their ideal community member and primary goal before fully committing. Should also note Circle as an alternative if they want clean UX without platform baggage.",
+      "assertions": [
+        "Checks for product-marketing.md",
+        "Recommends Slack for B2B context",
+        "Notes Slack free tier limitations",
+        "Compares Discord use case",
+        "Mentions Circle or other alternatives",
+        "Asks about audience identity or goal"
+      ],
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "We just launched our community 3 weeks ago. We have 40 members but only 2-3 people post regularly. Everyone else just lurks. What do we do?",
+      "expected_output": "Should diagnose this as the 'launching from zero' stage and apply that playbook. Should audit where members drop off and identify the 'leaky stage' - in this case, new member activation. Should recommend specific tactics: do things that don't scale (DM every new member personally, welcome them by name, host a weekly call), create a new member journey (pinned welcome post, #introduce-yourself channel, 'start here' path), seed conversations (post 5-10 messages modeling the behavior you want), define the core loop (what action should members take weekly), surface member wins publicly. Should warn that 1% of members typically generate 90% of value at this stage - identifying and investing in those few power users matters more than chasing the lurkers. Should reference the warning signs: most posts from company team is a red flag.",
+      "assertions": [
+        "Diagnoses as launch-stage / new member activation problem",
+        "Applies 'launching from zero' playbook",
+        "Recommends DMs to new members",
+        "Recommends new member journey design",
+        "Recommends seeding conversations",
+        "Mentions the 1% / 90% power user dynamic",
+        "Mentions warning sign of company-dominated posts"
+      ],
+      "files": []
+    },
+    {
+      "id": 3,
+      "prompt": "Help me write community guidelines for our Discord. We're building a community for indie game developers.",
+      "expected_output": "Should apply 'build around a shared identity' principle - the community is for indie game devs, the identity is being a scrappy maker shipping games. Should write guidelines that describe the *vibe*, not just the rules. Should answer: what does great participation look like here? Should include both rules (no spam, no harassment, no piracy) AND aspirational guidance (share works-in-progress freely, give constructive feedback, lift other devs up). Should reinforce the identity throughout. Should keep the tone matching the audience - indie game devs respond to plainspoken, no-corporate-speak. May suggest channels structure that reinforces the identity (e.g., #devlog, #playtest-requests, #publishing-tips).",
+      "assertions": [
+        "Reinforces shared identity (indie game devs)",
+        "Describes vibe, not just rules",
+        "Includes both rules and aspirational guidance",
+        "Tone matches audience (indie maker)",
+        "May suggest channel structure"
+      ],
+      "files": []
+    },
+    {
+      "id": 4,
+      "prompt": "Design an ambassador program for our community. We have about 5,000 members and a few that always help others. Want to give them more recognition.",
+      "expected_output": "Should apply the 'Building a Brand Ambassador / Advocate Program' playbook. Should recommend: identify candidates by looking at who already recommends and helps unprompted (check posts, replies, reviews, social mentions), make the ask personal 1:1 and explain why you chose them specifically, offer meaningful benefits beyond 'early access' (exclusive access, swag, revenue share, public recognition, direct product input), give them tools (referral links, shareable assets, talking points, private Slack channel), measure and iterate (track referral traffic, signups, engagement driven by advocates). Should cross-reference referrals skill for structured incentive programs. Should warn against generic forms and impersonal asks.",
+      "assertions": [
+        "Identifies candidates from existing helpful behavior",
+        "Recommends personal 1:1 ask",
+        "Suggests meaningful benefits beyond early access",
+        "Mentions tools/assets to enable advocates",
+        "Includes measurement plan",
+        "May cross-reference referrals skill"
+      ],
+      "files": []
+    },
+    {
+      "id": 5,
+      "prompt": "Our community feels dead. Members joined 6 months ago but most haven't posted in months. How do I tell if it's salvageable?",
+      "expected_output": "Should run the Health Audit Report output format. Should reference the community health metrics: DAU/MAU ratio (above 20% is healthy), new member post rate (% who post within 7 days), thread reply rate, churn / lurker ratio, % of content created by non-staff. Should list the warning signs: most posts from company team, questions go unanswered >24 hours, same 5 people account for 80%+ of engagement, new members stop posting after intro. Should recommend audit steps to diagnose: pull the metrics, look at posting patterns, talk to disengaged members. Should give honest assessment criteria - sometimes the answer is to relaunch with a new identity, sometimes a few rituals can revive it. Should propose the top 3 priorities to fix based on common patterns.",
+      "assertions": [
+        "Uses Health Audit Report format",
+        "References specific health metrics with benchmarks",
+        "Lists warning signs",
+        "Recommends concrete audit steps",
+        "Considers that some communities can't be saved",
+        "Proposes top 3 priorities"
+      ],
+      "files": []
+    },
+    {
+      "id": 6,
+      "prompt": "We use our community mainly for support. How do we reduce ticket volume without making customers feel ignored?",
+      "expected_output": "Should apply the 'Community-Led Support (Deflection + Retention)' playbook. Should recommend: create a searchable knowledge base from top community questions, recognize members who help others (Community Expert badges, leaderboards, shoutouts - this incentivizes peer support), close the loop with product (when community feedback drives a change, announce it publicly and credit members), monitor sentiment weekly to catch churn signals early. Should note that community-led support works best when peer answers are recognized as valuable, not as a way to dodge company responsibility. Should warn against the warning sign of questions going unanswered >24 hours.",
+      "assertions": [
+        "Applies community-led support playbook",
+        "Recommends searchable knowledge base from community Q&A",
+        "Recommends recognizing peer helpers",
+        "Mentions closing the loop with product",
+        "Warns about unanswered questions threshold",
+        "Notes peer support must feel valued, not used"
+      ],
+      "files": []
+    },
+    {
+      "id": 7,
+      "prompt": "We're a technical dev-tool startup, still tiny. Our users are opinionated engineers and their feedback basically drives our roadmap. What kind of community should we build, and how will running it change as we grow?",
+      "expected_output": "Should route to references/community-models.md. Should recommend the Product-Development model as the best fit - technical, opinionated users whose feedback shapes the roadmap; cite Ydata's Slack driving GitHub stars and product feedback as the real case. Should note that because they're still tiny, it will start Founder-Led (Bento/Postaga) with the founder showing up personally before systems can carry it. Should lay out the scaling-phase role shift: Community Architect at 0-100 (lay the foundation, do things that don't scale, know members by name, set culture), Community Manager at 100-1,000 (build systems and governance - rituals, moderation, onboarding), Community Enabler at 1,000+ (stand up ambassador programs and sub-communities so members run it). May reference Notion's benchmark (300+ ambassadors, 1M+ template downloads, 25% of new users from community referrals) as the north star for what community-led growth can become at scale. Should match effort to stage rather than running a small community like a large one.",
+      "assertions": [
+        "Routes to references/community-models.md",
+        "Recommends Product-Development model with Ydata case",
+        "Notes it starts Founder-Led while tiny",
+        "Describes the architect -> manager -> enabler role shift with member ranges",
+        "May cite the Notion ambassador benchmark",
+        "Emphasizes matching effort to stage"
+      ],
+      "files": []
+    }
+  ]
+}

package/ai/skills/stacks-marketing-community-marketing/references/community-models.md

@@ -0,0 +1,63 @@
+# Community Models & Scaling Phases
+
+The named model taxonomy, the flagship benchmark, and how the community-owner role changes as the community grows. Pair this with the goal playbooks and health metrics in `SKILL.md` - this file adds the *shape* of the community, not the tactics.
+
+Source: Corey Haines, *Founding Marketing*, Ch. 12 - "Community connects customers with each other." The thesis: don't just sell software, create a movement. Community is an **audience-first** play - indirect, "deposits in a relationship bank account" - built on **community-led systems** and **recognition/rewards**.
+
+---
+
+## The 5 Community Models
+
+Pick the model that matches the primary business goal. Most communities lean on one and borrow from others. Each has a "best when…" fit test and a real case.
+
+### 1. Support-Driven
+
+- **Best when…** support volume is high, questions are repeatable, and peers can answer each other faster than your team can. Goal: **support deflection**.
+- The community exists so members resolve each other's problems, cutting ticket load while raising satisfaction.
+- **Case - GreenPal:** ran a Facebook group where users and vendors helped each other, deflecting support away from the team.
+
+### 2. Product-Development
+
+- **Best when…** your users are technical or opinionated and their feedback directly shapes the roadmap. Goal: **feedback + build-in-public momentum**.
+- The community is a feedback engine: feature requests, bug reports, and public traction all flow through it.
+- **Case - Ydata:** ran a Slack community that drove **GitHub stars and product feedback**, turning members into co-builders.
+
+### 3. Education / Enablement
+
+- **Best when…** the product has a learning curve and activation/retention hinge on members getting good at it. Goal: **churn reduction**.
+- The community teaches members to succeed with the product; competence lowers churn.
+- **Case - LiveAgent:** used community education/enablement to **reduce churn** by helping customers get more capable.
+
+### 4. Founder-Led
+
+- **Best when…** you're early-stage, the founder's voice is the brand, and personal presence is the fastest way to build trust. Goal: **direct relationships + word-of-mouth**.
+- The founder shows up personally - answering, hosting, setting culture - before systems can carry it.
+- **Cases - Bento** (Discord) and **Postaga:** founders led their communities directly.
+
+> The fifth "model" in practice is the blend: a community usually starts **Founder-Led**, then specializes toward Support-Driven, Product-Development, or Education as it scales.
+
+---
+
+## Flagship Benchmark: Notion's Ambassador Program
+
+The reference point for community-led growth at scale:
+
+- **300+ ambassadors**
+- **1M+ template downloads**
+- **25% of new users come from community referrals**
+
+Use these as the "what great looks like" north star when sizing an ambassador program's potential - not as day-one targets. (For building the program itself, see the ambassador playbook in `SKILL.md`.)
+
+---
+
+## Scaling-Phase Role Shift
+
+The community owner's job changes at each stage. Match your effort to the phase - running a 1,000-member community like a 50-member one (or vice versa) is the most common failure.
+
+| Phase | Members | Role | Focus |
+|-------|---------|------|-------|
+| Foundation | 0-100 | **Community Architect** | Lay the foundation and build relationships - do things that don't scale, know members by name, set the culture. |
+| Systems | 100-1,000 | **Community Manager** | Build systems and governance - rituals, moderation, onboarding paths, clear norms so activity survives without you touching every thread. |
+| Scale | 1,000+ | **Community Enabler** | Enable others - stand up ambassador programs and sub-communities so members and leaders run it. You architect the leverage, not the conversations. |
+
+**The shift in one line:** architect the *room* → manage the *systems* → enable the *people*. Each phase hands off the previous phase's manual work to structure and to members.

package/ai/skills/stacks-marketing-competitor-profiling/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2025 Corey Haines
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/ai/skills/stacks-marketing-competitor-profiling/NOTICE.md

@@ -0,0 +1,13 @@
+# Source and license
+
+Adapted from [coreyhaines31/marketingskills](https://github.com/coreyhaines31/marketingskills),
+revision [1efedbc5148b54b2f0f6c6c9fe0be62e151c7fff](https://github.com/coreyhaines31/marketingskills/tree/1efedbc5148b54b2f0f6c6c9fe0be62e151c7fff),
+upstream skill `competitor-profiling`, version 2.1.3.
+The original MIT copyright and permission notice is in [LICENSE](LICENSE).
+
+Stacks supplies a namespaced entrypoint, shared implementation guidance, mapped
+related-skill links, and regular-hyphen copy. The playbook and its supporting
+references/templates are retained. Tool integrations remain optional linked
+references; upstream CLI programs, servers, and packaging scripts are not
+bundled or installed. Source examples are illustrative and changing platform
+facts require verification.