Skip to content
Go back

Claude Code Setup Changelog #2: What's Been Working This Week

Published:

More notes on what’s been working in my Claude Code setup. This week is less about individual tools and more about how a few skills chain together.


1. The feedback-to-feature pipeline

Four skills: /feedback-intake, /slack-to-code, /brainstorming, /using-superpowers.

Someone drops feedback in Slack. A feature request, a bug report, a screenshot of something that doesn’t look right. Instead of context-switching into Jira or writing a design doc, I run these four skills in sequence and go from raw feedback to a shipped feature in one sitting.

/feedback-intake takes a raw Slack message or screenshot and structures it into a formal request doc. Who asked, what they asked for, data sources, UI references. Output lands in docs/feedback/ as markdown.

Real example: a user wrote “would be great to get a dropdown that would allow me to jump between team members to see what they are missing and act as a safety net.” Running /feedback-intake on that message produced a structured doc with requester, priority, data requirements, and relevant existing components. Took about 30 seconds.

/slack-to-code picks up that structured file and runs it through a 5-phase pipeline: input processing, codebase exploration, design/root cause, sub-agent verification (schema checks, edge cases), and execution planning. It classifies the request as simple/medium/complex and adjusts.

A P1 feature request to flag something in the UI started as one Slack message: “Cases where I see users created should be flagged to my team.” slack-to-code explored the Snowflake tables, verified the data sources, designed the approach, and produced a plan with bite-sized tasks.

/brainstorming refines the design. When I needed to redesign a sidebar, brainstorming walked through the design space with structured Socratic questioning until I had a clear spec.

/using-superpowers orchestrates implementation with guardrails: check for relevant skills, write tests first, plan before coding, review after. When AEs reported login/signup UX issues, I handed it the raw feedback. It found existing PRs, root-caused a redirect routing issue, and guided the fix through TDD.

Context doesn’t get lost between when someone reports something and when I ship something. A Slack message at 10 AM can be a merged PR by 11 AM. No ticket required. The structured feedback docs also mean I can pick up any request weeks later and have everything I need.


2. api2cli: turning any API into a CLI (and then a skill)

Every API I integrate with has the same problem: Claude can make HTTP requests, but it doesn’t know the endpoints, the auth patterns, the pagination, or the weird production quirks that only surface after you’ve hit them a few times. I was writing the same boilerplate wrappers over and over. Different API, same scaffolding.

api2cli by Alex Hillman solves this. Point it at any API and it generates a dual-mode CLI: human-readable tables in the terminal, structured JSON when piped to an agent. Then it packages the whole thing as a Claude Code skill so future sessions know how to use it without rediscovering anything.

I’ve built CLIs for two APIs I use constantly:

Dokploy (infrastructure/deployment) — commands for projects, applications, postgres databases, domains, schedules, and backups. The dual-mode output is where it gets interesting. When I run dokploy project list I get a table. When Claude runs it programmatically, it gets JSON with next_actions like “run dokploy project get <id> to view details.” Claude chains commands on its own without me mapping out every step.

npx tsx ~/.claude/scripts/dokploy.ts project list
npx tsx ~/.claude/scripts/dokploy.ts postgres create --name "my-db" --databaseName my_app
npx tsx ~/.claude/scripts/dokploy.ts application deploy <id>

SalesLoft (sales engagement) — here the value is less about the CLI shape and more about capturing production quirks: the owner_id bug when enrolling contacts, HTML line breaks in email bodies, PUT instead of PATCH for certain updates. Those are baked into the skill now. Every future session gets them without me remembering to mention it.

Link: api2cli on GitHub (378+ stars)


3. Sharing my Claude Code setup with colleagues via plugins

I onboard 2-4 colleagues per week onto Claude Code. Each time, they need the same things: Snowflake access, Select Star for our data catalog, SalesLoft and Dokploy skills, our PandaDoc design system, Google OAuth patterns. For a while I was sending zip files and walking people through manual setup over Slack. It didn’t scale past the third person.

Claude Code has a plugin marketplace system. A plugin is a GitHub repo with a specific directory structure that bundles skills, MCP server configs, and a setup wizard (and more). You add a marketplace, install the plugin, and run the wizard. Three commands:

/plugin marketplace add aaronnam/pandadoc-claude-kit
/plugin install pandadoc-claude-kit
/aaron-pandadoc-claude-code-kit

The last command is an interactive setup wizard that detects what’s already configured, skips it, and walks through the rest: Snowflake credentials (with a link to the data engineering ticket queue), Select Star API token, Slack MCP via Anthropic’s official OAuth plugin. Takes about 5 minutes plus whatever wait time on credential requests.

The plugin distributes 8 skills and 2 MCP servers. No secrets in the repo. Credentials use environment variable placeholders in .mcp.json, and the wizard tells people to add their own tokens to ~/.zshrc. This means I can push the repo to GitHub without worrying about leaked keys.

I built a /share-claude-kit skill that handles the whole flow: accept a screenshot or name, verify the GitHub account exists, add as collaborator to the right repo, generate the onboarding Slack message with the correct repo URL, and copy it to clipboard. What used to be a 5-minute manual process is now one command.

Bonus: the plugin system also handles updates. When I add a new skill or fix something, I commit, push to both remotes, and colleagues get the update on their next /plugin update. No re-sharing zip files.


If any of this is useful or you’ve found similar workflows, I’d like to hear about it.


Share this post on:

Next Post
Claude Code Setup Changelog: What's Been Working for Me Lately