jakedahn

I’m excited to play with their memory stuff. I’m curious if they will add any hooks for allowing skills to store things intentionally.

The system skill idea is a little different in that you can store and query structured data out of your own SQLite db.

I’ve been playing with Claude Skills and stumbled on a simple pattern for tiny, durable personal data systems:

* CLI: a small, self-contained executable

* SKILL.md: the operator's manual (what to run, how to parse output, how to think about the system)

* SQLite: a local DB for persistent state

It’s nothing mind-blowing, but the ergonomics of this combo feel great.

If you define a process/flow, Claude can "turn the crank" by running the CLI, accumulating context, and animating the system to life over time.

They’re also easy to share: you can distribute System Skills via Claude Code’s `/plugin marketplace add <repo>`.

More details in the blog post and the toy Pomodoro System Skill reference implementation here:

Blog: https://www.shruggingface.com/blog/the-system-skill-pattern Repo: https://github.com/jakedahn/pomodoro

--

Curious whether any of this resonates. Also excited to hear any interesting System Skill ideas worth exploring!

I'm the author of t2x and shrugginface.com, I'm surprised to see this landed on HN a month after I first shared it.

I originally planned to make it real during the holiday break but got distracted by other projects. This is the inspiration bump I needed, so I'll get back to shipping over the coming weeks

The idea behind t2x was to make a stripped-down cli with a "functionality first" mindset and remove the actual selection of specific models from the user's flow.

However, subcommand like `t2x ask` are used to route you to a different model with different behavior. The ask subcommand currently makes requests to perplexity, where you can ask questions and get near realtime grounding from the world.

The original intention behind t2x was to be "functionality first", and make an opinionated call on which LLMs get used for specific functionality. However I think the way to go will be sane defaults and then allow user-specified models from something like openrouter.

It's using Phoenix LiveView, and the whole game state lives inside a GenServer

Realtime state is written to ETS and periodically (every 5s) flushed to disk.

It's running on fly.io

---

code lives on github here: https://github.com/jakedahn/clickthebutton/blob/main/lib/cli...

and https://github.com/jakedahn/clickthebutton/blob/main/lib/cli...

I have a 1.5yo that’s obsessed with pointing out planes in the sky.

Now we can go plane watching together!

I haven't had a chance to try it yet, but I am :excitedllama:

I started this blog a few months ago to explore the emerging world of generative AI. Hoping to write much more soon!

I built it as a next.js app with mdx support, and the microblog posts are rendered from a custom notion CMS setup.

But this is totally true, I found that maybe 30% of the images I generated did not look like my dog at all. However the rest do a good job at capturing his eyes and facial expressions that he actually makes. I thought that the chosen image I worked from captured the look of his eyes super well.

But yeah, nobody but me would really appreciate that.

I did the actual work back on March 11th, so I was likely on an older build; but I was seeing issues where inpainting was just replacing my selection/mask with a white background. I had the inpainting model loaded, but couldn't figure it out.

I'm planning to continue playing with Draw Things locally, and exploring the inpainting stuff. For such an iterative process I feel like a local client would make for the best experience.

Here's the colab notebook, in case anyone is interested: https://github.com/TheLastBen/fast-stable-diffusion

I've trained a few smaller models using their Dreambooth notebook, but I think for 4000 training steps, an A100 will usually take 30-40min. I believe replicate also uses A100s for their dreambooth training jobs.