Farm stand
Skill Manzanita-Research/magpie/plugins/farm-stand/skills/farm-stand
π¦ββ¬ Opinionated agentic project management built on Linear. For solo devs and small teams with too many repos.
npx -y skills add Manzanita-Research/magpie --skill farm-standAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 4 stars4 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 author says it does
Copied from the file, not written here
Generate a "building in public" update from recent Linear activity and freeform notes. Use when the user wants to share what they've shipped, write a dev update, post about recent work, or draft a "here's what we built" post. Triggers on "farm-stand", "what did I ship", "write an update", "building in public", "what have I been working on", "status update", "what's new", "what did we release", or any variation of wanting to summarize recent work for an audience.
SKILL.md
6.0 KB, as published. Nobody here has run it
Farm Stand
Here's what we brought to market today.
This skill generates casual, human "building in public" updates from your recent work. It pulls what you've shipped from Linear, asks for the yapping (the good stuff β the color commentary, the vibes, the context machines can't know), and formats it into something you'd actually want to post.
Not a changelog. Not a sprint report. A farm stand β here's what we grew, come take a look.
How it works
Step 1: Figure out the time window
Check for a previous farm-stand post to determine what "recent" means:
# Look for the most recent farm-stand post in the magpie repo
ls -1t ~/code/manzanita-research/magpie/farm-stand/*.md 2>/dev/null | head -1
If a previous post exists, read it to find the date. The window is "since that last post." If no previous posts exist, ask the user: "How far back should I look? Today? This week?"
Default to "since yesterday" if there's no prior post and no guidance.
Step 2: Pull recent activity from Linear via subagent
Delegate the Linear data-fetching to a background subagent. This is multiple calls that don't need to be in the main context.
- Use the Agent tool with
subagent_type="general-purpose"andrun_in_background=true - Include in the prompt:
- The full text of
plugins/linear/LINCTL_REFERENCE.md(read it first) - The time window from Step 1
- Instructions to run:
linctl team list --json(to get team key)linctl issue list --team <KEY> --state "Harvested" --newer-than week --jsonlinctl issue list --team <KEY> --state "Ripening" --newer-than week --jsonlinctl project list --team <KEY> --newer-than week --json
- Ask it to return results grouped by product label
- The full text of
Filter results to the time window from Step 1. Group by product label β each product label roughly maps to a project/repo.
Issues in "Ripening" (in review / nearly done) are worth a "coming soon" mention if the user wants.
Step 3: Ask for the yapping
Present what you found from Linear, then ask:
Here's what I found since your last update:
- caspar: 3 issues harvested (list them briefly)
- magpie: 2 issues harvested
- village-radio: 1 issue harvested
What else should go in this update? Things Linear doesn't know β vibes, context, what inspired this work, what you're excited about, shoutouts, stuff that's not tracked. The human parts.
Let the user freeform. This is where the good stuff lives β "it's been a busy morning lol" and "inspired by Kyle Wild's linctl" and "time for breakfast." Don't summarize this away. Preserve their voice.
Step 4: Draft the update
Format the update with these principles:
- Lead with energy, not a list. If the user gave you a vibe ("it's been a busy morning"), start there.
- Group by project, not by issue. Nobody outside your team cares about ticket numbers. They care about what the thing is.
- One line per project, maybe two. What it is + why it matters. Not a feature list.
- Preserve the user's voice. If they said something well in the yapping, use their words. Don't corporate-wash it.
- End naturally. "everything is wip/alpha" or "back to it" or "time for breakfast" β not "stay tuned for more updates!"
- Use emoji sparingly and only if the user's style includes them. Match their energy.
- No Manzanita brand-banned words. Never "leverage," "ecosystem," "game-changing," etc.
- Keep it short. A farm stand has a few crates, not an entire grocery store. 5-10 lines is the sweet spot.
Draft format (adapt to what feels natural):
## farm stand β [date]
[opening energy / vibe line if the user gave one]
[emoji] **project-name** β one-line description of what it is + what shipped.
[repeat for each project with recent activity]
[any freeform context, shoutouts, or color commentary from the user]
[natural closing]
Step 5: Review and save
Show the draft to the user. Let them edit. Then:
# Create the farm-stand directory in magpie if it doesn't exist
mkdir -p ~/code/manzanita-research/magpie/farm-stand
# Save the post
cat > ~/code/manzanita-research/magpie/farm-stand/YYYY-MM-DD.md << 'EOF'
[the final post]
EOF
# Copy to clipboard (macOS)
cat ~/code/manzanita-research/magpie/farm-stand/YYYY-MM-DD.md | pbcopy
Tell the user: "Saved and copied to clipboard. Paste it wherever it needs to go."
If the user posts multiple times in one day, append a counter: 2026-03-01-2.md.
What this is NOT
- Not a changelog. Changelogs are for machines and release notes. This is for humans.
- Not a standup. Nobody's checking up on you. You're sharing because you want to.
- Not comprehensive. You shipped 47 commits today? Cool, pick the 3-5 things that matter to someone who doesn't live in your codebase.
- Not polished marketing copy. It should sound like you, talking to people you like, about things you made.
Tips
- If the user has a lot to share, help them pick the highlights. A farm stand has a few things displayed beautifully, not everything from the entire farm.
- If nothing was harvested in Linear, that's fine β maybe they were planting. "Mostly planting this week" is a valid update.
- If they mention other people's work that inspired them (like Kyle Wild's linctl), keep those shoutouts in. Building in public means building in community.
- The user might want different formats for different platforms (LinkedIn vs. blog vs. Discord). Ask if it's not obvious, but default to a clean markdown that works anywhere.
Gives 0 of the 12 instructions most ship operate skills give
Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-06
- document a rollback plan before deploymentin 40 of 779, across 21 files
- create an annotated git tagin 21 of 779, across 20 files
- Run the test suitein 20 of 779
- update the changelogin 20 of 779, across 18 files
- verify deployment health after launchin 19 of 779, across 10 files
- clean up feature flags after full rolloutin 18 of 779, across 10 files
- verify the working tree is cleanin 18 of 779
- test both feature flag statesin 17 of 779, across 9 files
- Make database migrations backward-compatiblein 16 of 779, across 8 files
- set up error monitoring before launchin 15 of 779, across 7 files
- monitor metrics at each rollout stagein 14 of 779, across 5 files
- create a github releasein 14 of 779
Said here and by no other author read
- find the previous post to determine the time window
- fetch recent activity from Linear via a background subagent
- group Linear results by product label
- ask the user for additional context and vibes
- preserve the user's voice in the draft
- lead with energy instead of a list
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.