DEV Community: Francisco Hernandez

Learning to Fit the Room: A Skill I Built to Practice Concision

Francisco Hernandez — Mon, 12 Oct 2026 01:31:31 +0000

How working on my own communication led me to build Concision, a portable skill for AI agents.

I’ve received the same kind of feedback more than once at work: I can go too far into detail when I explain something.

I care deeply about the work. When I’ve spent time figuring something out, I want to share the whole story: the problem, what we tried, what we learned, and why we made certain decisions. Sometimes that’s exactly what a conversation needs. Sometimes it’s more than the person asked for.

I work closely with engineers, product, and management. The same piece of work can turn into three very different conversations. An engineer might want to understand the trade-offs. Someone from product might be thinking about the people using the feature. Management may need to know where we stand and whether a decision is needed. Knowing the work well doesn’t automatically mean I’m explaining it in the way each person needs.

Spanish is my first language, and much of my professional communication happens in English. That adds another layer, but the challenge isn’t simply finding the right words. It’s choosing which details matter in the moment.

I wanted to get better at that throughout my day. That’s where Concision started.

A way to practice

“Be more concise” is advice I understand. Applying it consistently is harder.

It’s easy to ask an AI assistant to shorten a message. But shorter isn’t always clearer. A Teams update might need a quick conclusion and a next step. A technical document needs enough detail for someone else to follow the work. A spoken explanation needs to sound like something I’d actually say, not a paragraph lifted from a report.

I wanted a skill that helped me ask: Who am I speaking to? What do they need to understand? What can I leave out without changing the meaning?

Those are choices I want to get better at making myself. Using the same principles with an AI assistant gives me a way to practice them consistently.

Finding a structure for the idea

As I explored this, I came across Harsha Perera’s article, The Art of Being Concise. It describes four connected elements: the real question, the audience, curiosity, and knowing where you stand.

That gave me a framework for something I’d been trying to improve personally. Being knowledgeable or passionate about a subject doesn’t automatically mean I’m communicating it in the way someone else needs.

I used Perera’s ideas as inspiration for Concision, a portable SKILL.md for AI agents. It can help edit a message, explain a topic, offer feedback when I ask for it, or work through a draft with me. Underneath those different uses is the same principle: understand the purpose and the person first, then decide how much to say.

The value for me is consistency. I want that principle to carry through a meeting, a Teams update, a piece of documentation, or whatever I’m working on next.

One story, three conversations

To show what I mean without sharing actual work information, I made up a small performance pilot. A support application has a slow ticket search, and engineering is testing a cache. In one controlled staging comparison, p95 search latency drops from 820 to 510 milliseconds, while the error rate stays at 0.2%. Here, p95 is the response-time threshold within which roughly 95% of searches finish.

Security and QA reviews are still pending. Nothing has been approved for production.

Here’s how I’d shape that same information for three conversations using Concision’s principles.

To engineering, in Teams:

Quick update on the search cache: in our staging test, p95 latency dropped from 820 ms to 510 ms with the cache enabled. Errors stayed at 0.2%.

It’s a good sign, but Security still needs to check tenant isolation and access to cached results, and QA has permission changes and stale results to cover. Nothing’s approved for production. Engineering will send the design to Security on Tuesday.

To product, in a conversation:

We’ve been looking at ways to make ticket search faster for support staff. In one staging test, p95 response time went from 820 to 510 milliseconds, and errors stayed at 0.2%. We haven’t seen what that means for real users yet, though. We still need the security and QA checks before we can decide whether a limited rollout test makes sense.

To management, in an email:

Hi,

We saw a promising result from the search-cache pilot in staging: p95 latency went from 820 ms to 510 ms in one controlled test, with errors holding at 0.2%. Security and QA reviews are still open, and we need more representative performance testing before making a rollout recommendation.

We’re not asking for production approval yet. Engineering will send the design to Security on October 13, and we’ll come back with a recommendation after the remaining checks.

These are illustrative drafts from fictional information. The numbers and limitations haven’t changed. What changes is the conversation: engineering needs the open checks and handoff; product needs to connect the technical result to the user problem without assuming an impact we haven’t measured; management needs to know whether a decision is required.

That’s what I want Concision to help me do: notice why one detail belongs in a message and another doesn’t. Over time, I want to make those calls more naturally myself.

I want AI to support that practice while I remain responsible for what I say.

Why I’m sharing it

I want to use Concision in my everyday work. And I know I’m not the only person moving between engineering, product, and management, trying to tell the same story in a way that makes sense to everyone involved.

Concision is now available on GitHub under the MIT license, with installation instructions and examples other people can try or adapt. You can install it through the Skills CLI:

npx skills add franciscoh017/concision

The README covers installation for different agents and manual setup. The skill itself has no required APIs, connectors, or external skills.

It’s a work in progress, and I plan to keep improving it as I use it. I’ve been using its principles while shaping this article, too.

I still get excited about the work, and I still want to share what I’ve learned. I’m learning to give people the details they need, when they need them.

To me, concision isn’t saying less. It’s knowing what matters and saying enough for it to land.

Understanding CSS Selectors

Francisco Hernandez — Sun, 13 Mar 2022 01:55:43 +0000

Recently, I was chatting and mentoring a colleague, a Frontend programmer who consults me frequently whenever he is working with user interfaces, where some CSS is required. As long as I've known him this has always been a frequent query throughout our career, and during our last few interactions, I decided to pay a little more attention to the reasons why he wasn't getting the rules he wanted to apply to elements on the page to work for him.

After several questions and answers, I realized that, despite being a very competent Frontend programmer, handling multiple JavaScript Frameworks such as Vue.js and React.js, and being able to use CSS libraries such as Bootstrap, Bulma and TailwindCSS, he seemed to possess a certain lack of knowledge of the basics of CSS, even though he claimed to know about it.

As I contemplated this, and began to include comments with lessons and information that my colleague could understand and see as new learning, his inquiries decreased and his comments of victory in being able to do it on his own began to become more frequent.

So, I have decided to make this brief guide for all those who, for one reason or another, feel identified with my colleague's situation, or simply want to learn and/or refresh their CSS knowledge.

What are CSS selectors?

If you've ever worked with Javascript or CSS, chances are you've come across one of these in the past.

A CSS selector is the initial part of a CSS rule. It is a pattern of elements or other terms that lets the browser know which HTML elements should be selected to apply the CSS properties found in the rule applied to them.
MDN Web Docs - CSS Selectors

Anatomy of a CSS Declaration by MDN Web Docs

That's right, as the image above describes, selectors are the first part of a CSS rule, and will always precede the opening braces of a CSS rule.

Types of selectors

There are different groups of CSS selectors, and knowing which type of CSS selector you need in each situation will help you to always select the HTML elements you require in the right way.

Universal Selector

The CSS universal selector "*" matches elements of any type. It selects everything in the document (or inside the parent element if it is being chained together with another element and a descendant combinator).

* {}

Type, class, and ID selectors

This group includes selectors that select an HTML element such as a <p>:

p {}

Also, it includes selectors that select a class:

.card {}

Or an ID:

#login-modal {}

Attribute selectors

They provide various ways to select elements based on the presence of a certain attribute or an attribute with a certain value.

a[target] {}
a[target="_blank"] {}

Pseudo-classes and pseudo-elements

This group of selectors includes pseudo-classes, which apply styles to certain states of an element:

a:hover {}
a:visited {}
a:disabled {}

For the set of supported pseudo-classes, see the full specification on MDN Web Docs.

And pseudo-elements, which select a specific part of an element, rather than the element itself.

For example, if we wanted to select the first line of a p element, we could use the ::first-line pseudo-element, which would always select the first line within a text element:

p::first-line {}

Or if we wanted to apply a rule to the marker or number of an item <li> in a list, we could use the ::marker pseudo-element to accomplish this task:

li::marker {}

For the set of supported pseudo-elements, see the full specification on MDN Web Docs

Combinators

Finally, there are the combinators which, as the name suggests, are used to combine other selectors in order to precisely select elements in the document.

Descendant Combinator

This is represented as a space “ “, and combines two selectors, where those elements match where the second selector matches an element that has an ancestor (parent, parent's parent, parent's parent's parent, etc.) that matches with the first selector.
It is similar to the Child Combinator, but has the peculiarity that it does not require a strictly parent-child relationship for the declared rule to be applied.

selector1 selector2 {}

Child Combinator

Presented as a greater than symbol “>” that is placed between two selectors. Matches only those elements where the second selector matches an element that is a direct child of the element that matches the first selector.

selector1 > selector2 {}

Adjacent Sibling Combinator

Presented as a plus sign “+” that is placed between two selectors. It matches only those elements matched by the second selector that are the next sibling element of the first selector.

selector1 + selector2 {}

General Sibling Combinator

The general sibling combinator “~” separates two selectors and matches all iterations of the second element, that are following the first element (though not necessarily immediately), and are children of the same parent element.

selector1 ~ selector2 {}

Conclusion

Analyzing my colleage's situation, and evaluating the occasions where other colleagues have resorted to my CSS skills to meet some requirement in the past, I can say that many programmers actually claim to know CSS, but very few really master concepts beyond of the type, class, id, and descendant selectors.

After learning, practicing, and putting this selector to good use, writing CSS rulesets will be a piece of cake!

Finally, I leave this CSS selectors cheat sheet that links to the MDN Docs reference of each CSS selector.