Ris Adams

If your AI workflow still makes you repeat the same instructions in every single chat, that's a tax you don't need to pay. I built Ink and Agency to fix that friction point. It’s a practical skills pack designed to integrate right into Claude—and can be adapted for other agents, giving reusable prompts for writing, planning, triage, architecture design, and just general day-to-day work.

I wanted better outputs with less effort and more consistency across tasks. So I turned repeatable playbooks into discrete skills, each with clear boundaries and predictable behavior.

Why I Built It​

Most agent failures don't happen because the model is bad. They happen because the prompt quality falls apart.

You ask for something broad, get a broad response. Then you spend time correcting it—steering it back on track. That’s fine if you do it once in a while. But when that becomes your daily job, it grinds you down.

Ink and Agency packages task-specific behavior into reusable units. Now, you can route work by intent instead of rewriting the entire process every time.

What's In The Pack​

The repository is structured like a catalog: one folder per skill with a SKILL.md entry point. It gives you practical coverage across areas that teams actually deal with:

• Writing: Drafting, shaping, humanizing, and structuring long-form content.
• Analysis: Codebase explanation, issue triage, and message breakdown.
• Planning: Sprint planning, review reporting, standup prep, and daily briefings.
• Collaboration: Structured critique modes or multi-persona consultation (a "council").
• Workspace: Operations for Obsidian notes, markdown files, canvases, and general vault work.

Quick Start for Claude Users:

git clone git@github.com:risadams/skills.git "$HOME/.claude/skills"

After that, the skills are ready—no extra launcher needed.

The Real Value in Day-to-Day Work​

A good skills pack isn't just a bag of clever prompts. It’s a reliability layer. Here is what changes after you start using one:

• Better handoffs: Tasks are framed consistently, so the output quality doesn't feel random.
• Less context thrash: You stop re-explaining your process in every single chat thread.
• Faster execution: Known task types map directly to known skill patterns.
• Easier team adoption: Every skill has a stable surface area and clear purpose—it’s predictable.

If you work in DevOps, delivery, or product engineering, this pattern hits home quickly. You're already used to turning repeated work into scripts, templates, and automation. Skills are just that move for prompt-driven work.

A Few Quick Examples of Use​

You don't have to write long instructions; you can just ask for the outcome:

• Use break-it-down on this email to explain what it is really saying.
• Run codebase-explain for this module.
• Triage PROJ-1234.
• Run a clarity-council on this design tradeoff.

That's the whole point. You ask for outcomes, not rituals.

I did not grow up in Pittsburgh.

I came here as an adult, with college debt, a meager job offer, and more than a little uncertainty. By the time I was learning to code in earnest and building a career, I was watching former industrial spaces turn into trails, riverfront paths, labs, and small tech offices. People pushing strollers where shift whistles used to run the clock is not my childhood memory. It is what I learned to notice after I moved here.

The most productive three hours of my week look suspicious from the outside. No meetings, no Slack, headphones in, do not disturb. From the inside, it's the only time I'm actually working.

I don't mean "actually working" as a knock on everything else. I mean it's the only time my brain is in the state where hard problems get solved, where the architecture makes sense, where I stop fighting friction and start making progress. Getting there, for an ADHD brain, is not as simple as closing your email client.

I was in an architecture review a few years back. Fifteen people on the call, half of them senior engineers. Someone proposed a caching strategy that I knew would fall apart under concurrent writes. I'd hit that exact failure mode six months earlier on a different project. I had the scars and the postmortem to prove it.

I didn't say anything.

I sat there, muted, composing and deleting the same sentence in the chat three times. Someone else eventually raised the issue twenty minutes later, after the team had already committed to the direction. The rework cost us a sprint. And I spent that whole sprint thinking: Why didn't I just say something?

If you've been that person, sitting on the right answer, the useful question, the experience that could save your team time, this one's for you.

If you've watched Resident Alien, you know the core premise: Harry, an alien, crashes on Earth and spends the series pretending to be a human so he can complete his mission (and eventually repair his spaceship). He's brilliant at it. He studies human behavior obsessively. He nails the performance. He says and does all the right things.

And he's absolutely miserable.

The alien's constant act of "being human" — perfectly mimicking behavior while feeling fundamentally separate from it — is actually a masterclass in imposter syndrome. And what's wild is how closely it mirrors something I see constantly in development teams: brilliant people who excel at their jobs while feeling like complete frauds.

The difference? The alien's situation is literal. He's actually not human. But the developers I know? They are good at what they do. Yet they're convinced they're faking it, waiting to be exposed, performing competence while feeling like imposters.

Resident Alien shows us why this matters and what healthy teams do differently.

Spoilers ahead.

After writing about what Ted Lasso taught me about being a Scrum Master, someone asked if I had any other TV shows that shaped my thinking on teams. I hesitated before answering "Yellowjackets," because unlike Ted's relentlessly optimistic football club, Yellowjackets is about a high school soccer team that crashes in the Canadian wilderness and descends into Lord of the Flies-style chaos. But here's the thing: I've seen more development teams operating like the Yellowjackets survivors than I'd like to admit. And the show's unflinching look at what happens when teams break down under pressure offers lessons that Ted Lasso's feel-good narrative can't.

So yes, we're going from biscuits and believe signs to cannibalism and cult behavior. Welcome to the darker side of team dynamics.

Massive spoilers ahead for Yellowjackets seasons one and two.

It's no secret that I am not a sports person. I don't follow football, baseball, basketball, or any of the major leagues. My idea of athleticism is walking briskly to the coffee shop without getting winded. So when I first heard about Ted Lasso, I was skeptical. But, I gave it a shot. And when Ted Lasso first walked into that Richmond AFC locker room with his signature mustache and relentless optimism, I had no idea I was watching a masterclass in servant leadership. Sure, he knew nothing about football (nor did I), but he knew everything about people.

I've just finished rewatching the series for the third time, and each viewing reveals another parallel between coaching a struggling team and facilitating a development team. Turns out, "Believe" isn't just a cute sign above a doorway — it's a whole leadership philosophy.

Beware: spoilers ahead for Ted Lasso seasons one through three.

Scrum gets mislabeled as project management. Then we ask it to do budget tracking, dependency orchestration, and scope control. No wonder it feels clumsy. Scrum is not your project management framework. Scrum is your communication framework for complex work. It sets the cadence, topics, and decision rules so a team can learn fast and adapt even faster. If you treat it that way, delivery gets less brittle and leadership gets better signal with less theater.

You know that moment in sprint planning when everyone reveals their story point estimates simultaneously, and the numbers range from 2 to 13? That's not a planning failure—that's collaborative dice rolling at its finest. Just like a D&D party assessing whether they can take on a dragon, your development team is essentially asking "What are the odds we can pull this off?" The answer, as any seasoned dungeon crawler knows, depends on your party composition, available equipment, and whether anyone remembered to bring healing potions.

Ever walked into a retrospective and immediately spotted the person frantically scribbling diagrams in the corner while someone else dominates the conversation? Or noticed how one team member always finds the potential pitfalls while another sees nothing but opportunity? Welcome to the beautiful chaos of agile team dynamics. Understanding these personality types isn't just helpful—it's essential for any Scrum Master who wants to facilitate effectively and unlock their team's full potential.

Ever notice how a well-run Scrum team feels suspiciously like a D&D campaign? The Scrum Master guides the narrative, developers bring specialized skills to overcome challenges, and everyone rolls dice (story points) to see how badly they've underestimated the complexity of "simple" tasks. After years of facilitating sprints and rolling d20s, I've realized these frameworks aren't just similar—they're practically the same game with different terminology.

You know the signs: minimal participation in standup, delayed deliverables, and that thousand-yard stare during retrospectives. A disengaged team member can derail sprint momentum faster than a production bug on Friday afternoon. But before you escalate to management or start documenting performance issues, remember that disengagement is often a symptom, not the disease.

You're about to deploy to production and your PM asks for "just a clean copy of the code without all that Git history stuff." Or maybe you need to package a specific release for a client who shouldn't see your development branches. Enter git archive — the Git command that's criminally underused despite solving these exact problems elegantly.

There I was, facilitating a retrospective for a team of brilliant engineers, when someone asked a technical question that made my stomach drop. I nodded thoughtfully, buying time, while my inner voice screamed: "You have no idea what they're talking about, do you?" Welcome to the Scrum Master's paradox — leading teams through complex technical challenges while secretly wondering if you belong in the room at all.

You know that uncomfortable moment in standup when someone says "everything's fine" while their face screams otherwise? That's transparency without courage—and it's killing your sprint predictability. The Scrum value of Courage isn't just a feel-good principle; it's the psychological foundation that makes real transparency possible.

Welcome to Surprise Driven Development (SDD) — the revolutionary methodology where uncertainty isn't a bug, it's a feature. Why plan when you can panic? Why document when you can discover? Join me as we explore the chaotic art of building software where every deployment is Christmas morning and every bug is a delightful present from your past self.