launch
Skill8 starsChanged 5 months agoMITView on GitHub
Use this skill when planning a product launch, feature announcement, or release strategy. Trigger phrases include: "plan our product launch," "write a launch plan," "Product Hunt launch strategy," "launch checklist," "pre-launch preparation," "waitlist strategy," "launch email sequence," "beta launch vs public launch," "PR for our launch," "launch day execution," "post-launch follow-through."
We split this skill into the rules it gives an agent
28 rules. 0 are common, 28 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 58 edited versions we read keep these.
28
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Write in a way that sounds like a knowledgeable human wrote it.
- Distinctive: line 13
Use short sentences. One idea per sentence.
- Distinctive: line 14
Use active voice. Never passive constructions.
- Distinctive: line 16
Use bullet points only when they genuinely improve readability.
- Distinctive: line 19
No hashtags, emojis, or asterisks.
- Distinctive: line 20
No introductory or closing filler phrases such as "in conclusion," "in summary," or "in a world where."
- Distinctive: line 21
No warnings, notes, or disclaimers.
- Distinctive: line 22
No AI cliches: no "game-changer," "unlock," "leverage," "dive into," "delve," "cutting-edge," "transformative," "revolutionize."
- Distinctive: line 23
No excessive adjectives or adverbs.
- Distinctive: line 24
No broad generalizations. Every claim tied to specific context.
- Distinctive: line 25
Use specific examples, data, and scenarios.
- Distinctive: line 44
Not all launches serve the same purpose.
- Distinctive: line 86
Write down specific, measurable goals before you do anything else.
- Distinctive: line 88
Not this: "Have a successful launch." This: "Generate 500 trial signups in the first 72 hours.
- Distinctive: line 102
Write a one-paragraph launch narrative before you write any launch copy.
- Distinctive: line 108
Create all launch assets at least two weeks before launch:
- Distinctive: line 148
If possible, a brief demo or screenshot showing what the product looks like.
- Distinctive: line 150
Do not include pricing, a long FAQ, or detailed feature documentation on the waitlist page.
- Distinctive: line 154
When you are ready to invite waitlist members, segment them if your list is large.
- Distinctive: line 168
Create or optimize your Product Hunt account.
- Distinctive: line 205
Do not buy upvotes. Product Hunt penalizes this and it damages your credibility in the community.
- Distinctive: line 224
Test the trial or signup flow end-to-end.
- Distinctive: line 276
No lengthy feature lists. No padding.
- Distinctive: line 336
Create a dedicated feedback channel (Slack channel or Discord server) for beta users.
- Distinctive: line 353
Write and publish a "what we learned from our launch" post on your blog.
- Distinctive: line 357
Run your first post-launch customer interview.
- Distinctive: line 359
Start your post-launch nurture sequence for anyone who signed up but has not activated.
- Distinctive: line 376
Use these numbers to inform your next launch.
“Common” is measured: kept by at least 6 in 10 of the 58 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Product Launch Strategy Skill
Mandatory Content Standards
- Match the output length to the task. For full audits, strategies, plans, or multi-part deliverables, write 1,500 to 10,000 words. For quick tasks, single assets, snippets, or narrow revisions, keep the output concise and provide only the useful variations, rationale, and next steps.
- Write in a way that sounds like a knowledgeable human wrote it. No robotic or templated phrasing.
- Use short sentences. One idea per sentence. One focus per paragraph.
- Use active voice. Never passive constructions.
- Address the reader directly using "you" and "your."
- Use bullet points only when they genuinely improve readability.
- Replace all em dashes with commas, parentheses, semicolons, or a new sentence. No hidden Unicode characters.
- End every sentence with a period.
- No hashtags, emojis, or asterisks.
- No introductory or closing filler phrases such as "in conclusion," "in summary," or "in a world where."
- No warnings, notes, or disclaimers. Stick to requested output.
- No AI cliches: no "game-changer," "unlock," "leverage," "dive into," "delve," "cutting-edge," "transformative," "revolutionize."
- No excessive adjectives or adverbs. Let specifics do the work.
- No broad generalizations. Every claim tied to specific context.
- Use specific examples, data, and scenarios.
- Pose at least one thought-provoking question per skill.
- Mobile-friendly: short paragraphs, clear headers, scannable.
- Practical and actionable. Every section connects to a next step.
What This Skill Does
This skill covers the full lifecycle of a product launch, from early planning through post-launch analysis. It applies to full product launches, significant feature releases, and beta programs. It covers the strategic planning, the tactical execution, and the follow-through that most launch plans skip.
A launch is not a single event. It is a concentrated period of attention that, if managed well, creates a durable lift in visibility, signups, and brand awareness. If managed poorly, it wastes months of anticipation in a day.
The question worth answering before anything else: are you launching to validate, to grow, or to signal? The answer changes nearly every decision you make.
Part 1: Types of Launches and When to Use Each
Not all launches serve the same purpose. Clarity on your launch type shapes your goals, channels, and success metrics.
Beta Launch
A beta launch brings a product to a small, controlled group of users before public availability. The goals are product validation, early feedback, and building a group of advocates before the public launch.
A beta launch is the right choice when:
- Core functionality works but the product is not fully polished.
- You need real usage data to make product decisions.
- You want to build a group of early users who will amplify the public launch.
Beta launches should be exclusive but not opaque. Tell beta users what you are testing. Ask for specific feedback. Set expectations about when the product will be available publicly.
Public Launch
A public launch opens the product to anyone. The goals are signups, revenue, and press coverage. You have one shot at the "new product" story. Do not waste it on an unfinished product.
A public launch is the right choice when:
- Core use cases work reliably.
- You have an onboarding experience that can handle new users.
- You have a plan for turning launch-day signups into activated users.
Feature Launch
A feature launch announces a significant new capability within an existing product. The goals are customer retention, expansion revenue (upsell), and media coverage within your category.
Feature launches are underutilized. Most teams ship features with a changelog entry and nothing else. A well-executed feature launch for a significant capability can drive meaningful press, social engagement, and upgrade activity.
Soft Launch
A soft launch makes the product available without a coordinated promotional push. You do not announce. You do not pursue press. You let people find it organically while you continue refining.
Soft launches are appropriate when you want real usage data before committing to a positioning strategy. They are not a substitute for a real launch. They are a precursor.
Part 2: Pre-Launch Preparation
Pre-launch is where most of the work happens. A launch day that goes smoothly is the product of four to eight weeks of preparation.
Set Your Launch Goals
Write down specific, measurable goals before you do anything else.
Not this: "Have a successful launch." This: "Generate 500 trial signups in the first 72 hours. Finish in the top 3 on Product Hunt. Get coverage in at least two publications in our category."
Your goals determine your tactics. If your primary goal is Product Hunt performance, your prep looks different than if your primary goal is PR coverage.
Define Your Launch Narrative
Your launch narrative is the story you want the world to tell about your product. It answers:
- Who is this for?
- What problem does it solve that was not solved well before?
- Why does this exist now? (What made it possible or necessary?)
- What is the most surprising or specific thing about it?
Write a one-paragraph launch narrative before you write any launch copy. Every piece of launch content (press release, Product Hunt post, launch email, social posts) should tell the same story, differently.
A narrative built around a specific pain point converts better than a narrative built around features. "Teams of 3 to 10 spending 10+ hours per week on manual reporting now have an automated alternative" is a narrative. "We built a reporting tool" is not.
Build Your Asset Library
Create all launch assets at least two weeks before launch:
- Product Hunt listing (tagline, description, gallery images, maker comment).
- Press release (for press outreach only, not for publishing publicly).
- Launch email (for your existing list).
- Social posts (LinkedIn, Twitter, and any other active channels).
- Blog post or announcement post (for your website).
- Demo video (60 to 90 seconds, showing the product working).
- High-resolution product screenshots (labeled with context).
- Founder headshot and bio (for press requests).
- FAQ document (for your team to answer press and community questions consistently).
Having all of these ready in advance means launch day is execution, not creation.
Part 3: Waitlist and Early Access Strategy
A waitlist builds anticipation and creates a pool of ready-to-activate users before you launch publicly.
When to Build a Waitlist
A waitlist makes sense when:
- Your product is not yet publicly available but you want to validate demand.
- You plan a controlled rollout and need to manage capacity.
- You want to create social proof (showing a high number on the waitlist signals desirability).
A waitlist does not make sense when:
- Your product is already available to everyone.
- You cannot deliver meaningful value to early waitlist members.
Waitlist Page Design
A waitlist landing page has one job: get the email address of someone who is interested.
Include:
- A specific headline describing what the product does and for whom.
- A brief description (three to five sentences) of the core problem and solution.
- Two to three benefits in specific language.
- An email capture form.
- If possible, a brief demo or screenshot showing what the product looks like.
Do not include pricing, a long FAQ, or detailed feature documentation on the waitlist page. Those belong on the main product site after launch. The waitlist page should be a focused, short page.
Activating the Waitlist
When you are ready to invite waitlist members, segment them if your list is large. Invite the first 10 to 20% manually, with a personalized note. These early invitees are your first advocates. Treat them like beta users.
Invite in waves. This creates anticipation among people still waiting and reduces the risk of overwhelming your onboarding and support capacity in a single day.
Send a waitlist survey before you start inviting. Ask what they want to accomplish with the product. Use those responses to personalize onboarding and to feed into your launch messaging.
Part 4: Product Hunt Launch Playbook
Product Hunt is the most concentrated launch channel available to software products. A top-5 finish on launch day can drive 1,000 to 5,000 trial signups. A poorly prepared launch can barely register.
30 Days Before Launch
Create or optimize your Product Hunt account. Follow products, comment on launches, and engage with the community. A maker profile with activity converts followers better than a brand new account with no history.
Identify a hunter. A hunter is the person who posts your product on Product Hunt. A hunter with a large, engaged following increases the visibility of your launch because followers receive notifications. Research hunters with followings in your category. Reach out with a personal note explaining what you built and why you think it would interest their followers.
Alternatively, post it yourself if you have an account with established followers.
Decide on your launch date. Tuesday, Wednesday, and Thursday are the highest-traffic days. Avoid Mondays (lower engagement) and weekends (significantly lower traffic). Schedule your launch to go live at 12:01 AM Pacific Time to get the full 24-hour window.
7 to 14 Days Before Launch
Prepare your Product Hunt listing in full:
Tagline (60 characters max): The most important piece of text on your listing. It appears everywhere your listing appears. Write five to ten options and test them with people outside your company. Choose the most specific and surprising one.
Description (260 characters): Expand on the tagline. Include who the product is for and what problem it solves.
Gallery images: 3 to 5 images minimum. Include labeled screenshots, a product demo GIF (if relevant), and a cover image that reads well as a thumbnail. Every image should have a title overlay explaining what the viewer is looking at.
Demo video: A Loom or YouTube video embedded in the listing. 60 to 90 seconds. Show the product working, not a slide deck.
First comment from maker: Written in advance. This appears at the top of the comments section when your listing goes live. Write about:
- Why you built this.
- Who it is for.
- What you are most excited about.
- A specific question inviting community feedback.
Launch Day Execution
At 12:01 AM Pacific Time, your listing goes live. Within the first two hours:
- Share to your existing email list (if you have one). Keep the email short: "We launched on Product Hunt today. If you find the product valuable, a comment or upvote would mean a lot." Include the direct link.
- Post to LinkedIn, Twitter, and any other active channels. Show the listing, not just the product URL.
- Post in relevant Slack communities and Discord servers. Do not spam. One or two communities that know your product is appropriate.
- Notify your team, investors, and advisors. Give them the link and make it easy to support: "If you've used the product and want to share your experience, here's the link."
During launch day, respond to every comment within two to four hours. A listing with active maker engagement ranks better in Product Hunt's algorithm and looks more credible to voters.
Do not buy upvotes. Product Hunt penalizes this and it damages your credibility in the community.
Post-Launch on Product Hunt
Within 24 hours after your launch, post a "maker update" comment thanking the community and sharing one specific thing you learned from the feedback.
Send a follow-up email to everyone who commented with a note of appreciation and, where relevant, an answer to any question they raised.
Export every comment and note every specific piece of product feedback. Feed this into your roadmap.
Part 5: Launch Day Execution Checklist
A launch day without a checklist is a launch day you will regret.
The Night Before Launch
- Confirm all landing pages load correctly and forms submit.
- Test the trial or signup flow end-to-end.
- Confirm your email sequence triggers correctly for new signups.
- Confirm your analytics tracking is working.
- Set up real-time monitoring: a Slack channel with signup notifications if possible.
- Confirm your team knows their roles for launch day.
Launch Day (First Two Hours)
- Product Hunt listing goes live at midnight Pacific.
- Send the launch email to your list.
- Post on all social channels.
- Share with communities.
- Notify your personal networks.
- Begin monitoring and responding to comments.
Launch Day (Ongoing)
- Respond to all Product Hunt comments, social comments, and mentions.
- Monitor for press coverage. Set up Google Alerts for your product name if you have not already.
- Track signups in real time.
- Address any critical bugs or onboarding issues immediately.
- Escalate any support issues that could affect multiple users.
Launch Day (End of Day)
- Share a brief update on social channels: "Here's what day one looked like."
- Send a thank-you message to anyone who actively supported the launch.
- Note any immediate feedback themes to address in your post-launch communications.
Part 6: The Launch Email Sequence
Your existing list is your highest-converting launch audience. They already know you. Email them before, during, and after the launch.
Pre-Launch Email (3 to 7 Days Before)
Tell your list that something is coming. Be specific about when.
"We're launching on Product Hunt this Thursday at midnight Pacific. [Product name] is [one sentence description]. We'll have more to share on Thursday, but wanted to give you an early heads-up."
This primes your audience to look for the launch email and increases open rates when the launch email arrives.
Launch Day Email
Your most important marketing email for the launch. Keep it short.
- One clear headline announcing the launch.
- One to two sentences on what the product does.
- One sentence explaining what you would appreciate (a visit to Product Hunt, a trial signup, a share).
- Direct links to the Product Hunt listing and the product.
No lengthy feature lists. No padding. Short respects the reader's time and converts better.
Post-Launch Follow-Up Email (2 to 3 Days After)
Share the results. Tell your list what happened.
- How many upvotes, signups, or press mentions you received.
- One or two pieces of feedback you received and how you plan to address them.
- A reminder of what the product does for anyone who missed launch day.
This email builds community and demonstrates transparency. It is one of the highest-engagement emails you will send.
Part 7: PR Outreach for Launches
Press coverage for launches requires preparation, targeting, and a compelling story. Generic press releases sent to general tech journalists rarely result in coverage.
Targeting the Right Journalists and Publications
Identify journalists who have recently covered:
- Products in your exact category.
- Launches from companies at your stage.
- Stories about the problem your product solves.
A reporter who covered "the rise of AI writing tools" six months ago is a better target than a general tech reporter who covers anything.
Build a list of 20 to 40 targets. Include their name, publication, their most relevant recent article, and how your story connects to what they cover.
The Pitch
A press pitch is not a press release. It is a short, direct email that:
- References a specific piece of content they published (demonstrating you read their work).
- Connects that piece to your launch story.
- Offers one concrete, specific angle: a data point, a customer stat, or a trend angle.
- Offers an exclusive or a demo.
The email should be under 200 words. No attachments on the first contact. Offer to send more if they are interested.
Timing
Send embargoed pitches two to four business days before launch. An embargo means you ask the journalist to hold publication until your launch date. In exchange, you offer an exclusive or early access. Most tech journalists respect embargoes and appreciate the advance notice.
Send non-embargoed pitches on launch day, in the morning. These compete with everything else happening that day, but the launch activity (Product Hunt ranking, social engagement) gives journalists a concrete hook.
Part 8: Beta Launch vs. Public Launch
The choice between a beta launch and a public launch is often treated as a sequencing question. It is better treated as a positioning question.
A beta launch signals: "We are still learning. We want collaborators." A public launch signals: "We are ready. We want customers."
Both can be correct at the right time. The mistake is doing a public launch posture with beta product readiness, or doing a quiet beta when you have a product good enough to support a public launch moment.
Running a Successful Beta
Recruit 30 to 100 beta users from your network, your waitlist, or communities where your ICP hangs out. Be specific about what you are testing.
Create a dedicated feedback channel (Slack channel or Discord server) for beta users. Check it daily. Respond to every piece of feedback.
Set a beta timeline. "We will be in beta for eight weeks, then we are launching publicly in [month]." This gives beta users a sense of commitment and creates urgency for the public launch.
Offer beta users something for their participation: early pricing, lifetime access to a feature tier, or simply public acknowledgment in the launch.
Part 9: Post-Launch Follow-Through
Most launch energy disappears within 72 hours. The teams that extract the most value from a launch are the ones that plan the 30 days after launch with the same care as launch day.
Post-Launch Week 1
- Review all feedback from Product Hunt comments, social mentions, and support tickets.
- Identify the top three product friction points surfaced during launch.
- Send a personal thank-you to your top 10 launch supporters.
- Write and publish a "what we learned from our launch" post on your blog. This drives secondary traffic from people who find launches interesting.
Post-Launch Weeks 2 to 4
- Run your first post-launch customer interview. Ask launch-day signups what brought them in, what they expected, and what they found.
- Activate any press coverage by sharing it across your channels.
- Start your post-launch nurture sequence for anyone who signed up but has not activated.
- Track cohort-specific activation and retention for launch-day signups. This tells you whether your launch attracted the right users.
Measuring Launch Success
Assess these metrics 30 days after launch:
- Total signups from the launch period (define the window: 72 hours, 7 days).
- Activation rate for launch signups vs. baseline.
- Trial-to-paid conversion rate for launch signups vs. baseline.
- Press mentions (number, publication quality, reach).
- Backlinks generated from the launch.
- Product Hunt rank and total upvotes.
- Social impressions and engagement.
A launch that drives 1,000 signups with a 5% activation rate is worse than a launch that drives 300 signups with a 40% activation rate. Track both volume and quality.
Use these numbers to inform your next launch. Every launch teaches you something about which channels perform for your specific audience.
Other versions64 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 64
- microsoft/vscode★ 194ksame name
- coreyhaines31/marketingskills★ 58ksame name
- Yeachan-Heo/oh-my-claude-sisyphus★ 40ksame name
- Yeachan-Heo/oh-my-claudecode★ 40ksame name
- posit-dev/positron★ 4.3ksame name
- Nexus-JPF/note-companion★ 874same name
- whitecircle/halo★ 839same name
- menkesu/awesome-pm-skills★ 441same name
- NeuralInverse/neuralinverse★ 245same name
- Cesarjoquin/Marketing-Skills★ 190same name
54 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use add-policy, tool-rename-deprecation and 4 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
OpenCortexIDESkilladd-policy
Use when adding, modifying, or reviewing VS Code configuration policies. Covers the full policy lifecycle from registration to export to platform-specific artifacts. Run on ANY change that adds a `policy:` field to a configuration property.
Also in 4 projects that use this
gitpod-ioSkilltool-rename-deprecation
Ensure renamed built-in tool references preserve backward compatibility. Use when renaming a toolReferenceName, tool set referenceName, or any tool identifier. Run on ANY change to tool registration code. Covers legacyToolReferenceFullNames for tools and legacyFullNames for tool sets.
Also in 4 projects that use this
riggyzSkillattribution
Attribution rules for issues, pull requests, work items, reviews, and comments created or edited by the agent in GitHub, Linear, Azure DevOps, or similar collaboration systems. Use when creating, commenting on, reviewing, or modifying external tracker content.
Also in 6 projects that use this
CesarjoquinSkilloffers
When the user wants to design, construct, or improve an offer — the thing they actually sell — including value framing, bonus stacking, guarantee design, scarcity/urgency, naming, and payment structure. Also use when the user mentions 'offer,' 'offer design,' 'build an offer,' 'grand slam offer,' 'irresistible offer,' 'value stack,' 'bonus stack,' 'guarantee,' 'risk reversal,' 'money-back guarantee,' 'scarcity,' 'urgency,' 'high-ticket offer,' 'productize a service,' 'naming an offer,' 'payment plan,' 'down-sell,' 'upsell offer,' or 'why isn't my offer converting.' Best for services, agencies, courses, coaching, info products, high-ticket B2B, and direct-response. If you run pure self-serve SaaS, read pricing first — tiers and packaging do more work there. For price level itself (tiers, freemium, value metric), see pricing. For the page that presents the offer, see copywriting. For the launch moment, see launch. For sales collateral, see sales-enablement.
Also in 9 projects that use this
coreyhaines31Skillconversion-tracking
Set up, audit, verify, or fix website conversion tracking. Use when the conversion is a form submission, booked meeting, chat, phone call, signup, or purchase; when conversions must reach Google Ads, Meta, GA4, LinkedIn, TikTok, or Microsoft Ads; when the work involves GTM tags and dataLayer events, pixels, the Conversions API (CAPI), Enhanced Conversions, server-side tagging, or gclid and fbclid capture; or when the user reports conversion problems like "conversions stopped", "double counting", "spend but no conversions", "GA4 and Google Ads don't match", or an Unverified or Inactive status. Covers lead gen and ecommerce. Always fire on confirmed success, never the submit click; verify a test conversion arrives; diagnose before changing anything; offer free and native paths alongside paid ones and disclose partner tools. For tracking plans and UTMs, see analytics. For attribution models, see attribution. For campaigns and bidding, see ads. For CRM lead-stage design, see revops.
Also in 3 projects that use this
coreyhaines31Skillmarketing-loops
When the user wants to set up a recurring, self-running marketing workflow — a repeatable loop an AI agent runs on a cadence (weekly, daily, on a trigger) rather than a one-off task. Also use when the user mentions 'marketing loop,' 'recurring marketing workflow,' 'automate my marketing,' 'marketing on autopilot,' 'weekly marketing review,' 'ad fatigue check,' 'weekly ads check,' 'content refresh loop,' 'churn watch,' 'ranking drop alert,' 'run my SEO,' 'SEO operator,' 'daily SEO agent,' 'run my outbound,' 'AI SDR,' 'reply triage,' 'always-on marketing,' 'marketing automation workflow,' or 'run this every week.' Use this to pick, adapt, and schedule an ongoing marketing loop that orchestrates the other marketing skills. For one-off marketing ideas, see marketing-ideas. For the experimentation loop specifically, see ab-testing.
Also in 6 projects that use this
In this repository76 other files it gives its agents.
- AGENTS.mdAGENTS.md
- a11y-auditSkill
- ab-testingSkill
- ad-creativeSkill
- adsSkill
- ai-image-creatorSkill
- ai-seoSkill
- analyticsSkill
- asoSkill
- brand-guidelinesSkill
- brand-reviewSkill
- brand-storytellingSkill
- business-strategySkill
- campaign-brief-generatorSkill
- churn-preventionSkill
- cold-emailSkill
- co-marketingSkill
- community-marketingSkill
- competitive-teardownSkill
- competitor-profilingSkill
- competitorsSkill
- content-humanizerSkill
- content-repurposingSkill
- content-strategySkill
- copy-editingSkill
- copywritingSkill
- croSkill
- customer-researchSkill
- customer-serviceSkill
- customer-story-builderSkill
- directory-submissionsSkill
- ecommerce-contentSkill
- ecommerce-product-opportunity-researcherSkill
- education-contentSkill
- email-marketingSkill
- emailsSkill
- env-secrets-managerSkill
- free-toolsSkill
- imageSkill
- instagram-carouselSkill
- landing-page-croSkill
- lead-magnetsSkill
- linkedin-strategySkill
- local-seoSkill
- marketing-ideasSkill
- marketing-osSkill
- marketing-psychologySkill
- market-researchSkill
- onboardingSkill
- paid-ads-opsSkill
- paywallsSkill
- podcast-pipelineSkill
- popupsSkill
- pr-communicationsSkill
- pricingSkill
- product-marketingSkill
- programmatic-seoSkill
- prospectingSkill
- prospect-researchSkill
- referralsSkill
- The first 60 shown.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

