Forem: Francesco Sardone

Model Sizing for Coding Agents: Bigger Is Not Always Better

Francesco Sardone — Mon, 18 May 2026 07:00:00 +0000

AI coding agents need capable models, and that part is obvious by now. What is less obvious is that model capability is only half the problem. The other half is model fit.

A model that works beautifully for one coding task can be wasteful for another. A frontier reasoning model may be the right choice for architecture, migration planning, or debugging a subtle production issue. The same model may be unnecessary for formatting code, generating a small helper function, renaming symbols, summarizing diffs, or applying a known pattern.

So the real question is not only:

"Are you using the best model?"

It is also:

"Are you using the right model for this task?"

That is the part I think we should talk about more.

Overview
The Hidden Problem: Model Fit
Why One Model Is Not Enough
Task Classes: What Kind of Coding Work Is This
Model Profiles: How Much Intelligence Should the Task Get
Why the Best Model Depends on the Harness
Routing, Escalation, and Cascades
Why This Matters in Real Repositories
Conclusion

Overview

A lot of discussion around AI coding still treats model choice as a leaderboard problem. The assumption is simple: if one model is strongest overall, then using it everywhere should produce the best results. That is true sometimes, but it is also incomplete.

In practice, coding work is not one task. It is a mix of small edits, local reasoning, repository navigation, test interpretation, dependency awareness, code generation, code review, refactoring, migration planning, debugging, and long-horizon agentic work. These are not all equally difficult, and they do not all benefit from the same model size.

That means model selection is not just a capability decision. It is a systems design decision.

The largest or newest model may be the safest default for hard tasks, but it is not automatically the best default for every task. Larger models usually cost more. They can be slower. They may produce longer outputs than needed. They may burn tokens on reasoning that the task does not require. OpenAI’s own latency guidance makes this point directly: model size is one of the main factors influencing inference speed, and smaller models are usually faster and cheaper; used correctly, they can even outperform larger models for some workloads. (OpenAI Developers)

So the useful framing changes. It becomes less about "which model is best?" and more about this:

What is the smallest model that can reliably complete this coding task at the required quality level?

The Hidden Problem: Model Fit

When an AI coding workflow gets expensive or slow, we often blame token volume. Sometimes that is fair. Context bloat is real. Large repository prompts are expensive. Tool loops can multiply cost quickly.

But sometimes the issue is more basic: the wrong model is doing the wrong job.

A frontier model may be excellent at difficult multi-step coding work, but that does not mean it should handle every operation in the pipeline. Many coding-agent workflows contain tasks that are more operational than intellectual: classify the request, summarize a file, identify relevant paths, generate a test command, rewrite a small function, apply a style rule, or explain a diff. These tasks still require accuracy, but they often do not require the maximum available reasoning budget.

This is where model sizing becomes important.

A model can be "too small" for a task, causing bad patches, shallow reasoning, or missed edge cases. But a model can also be "too large" for a task, creating unnecessary cost and latency without materially improving the outcome. The second failure mode is quieter, because the answer may still be good. It just may be inefficient.

In other words, the problem is not always model capability. Sometimes it is mis-sized capability, and that distinction matters because once you move from "use the best model" to "size the model to the task," the design space gets much more interesting.

Why One Model Is Not Enough

There is a quiet assumption in many coding-agent setups that one model should carry the whole workflow. Pick the strongest model you can afford, wire it into the agent, and let it handle everything.

That sounds clean, but real coding workflows do not behave that way.

A small bug fix is not the same as a cross-package refactor. A failing unit test is not the same as a flaky integration test. A code review comment is not the same as a schema migration. A repository-wide modernization is not the same as adding one missing null check.

The model market also no longer behaves like a single ladder where every better model is simply "more of the same." Providers now expose families of models with different cost, latency, context, and reasoning tradeoffs. OpenAI, for example, explicitly presents frontier models for complex reasoning and coding while also pointing to smaller models for lower-latency, lower-cost workloads. (OpenAI Developers) Anthropic’s pricing page similarly shows large price differences across Claude model tiers, with higher-end models costing materially more per token than smaller ones. (Claude Platform) Google’s Gemini pricing also separates Pro and Flash-style options with different cost profiles. (Google AI for Developers)

So a single fixed model quickly starts to look less like a simplification and more like an accidental constraint.

The better framing is that a coding agent should not have one model, but a model portfolio. Once you accept that, at least two dimensions become worth choosing deliberately: task difficulty, meaning how much reasoning the work needs, and execution role, meaning where in the workflow the model is being used.

Those two decisions matter much more than they usually get credit for.

Task Classes: What Kind of Coding Work Is This

The first question is task class. Not all coding tasks deserve the same model budget, and the easiest way to waste money is to treat them as if they do.

Mechanical Tasks

Mechanical tasks are low-ambiguity operations. They include formatting, renaming, applying simple conventions, translating obvious patterns, generating boilerplate, extracting structured data from code, summarizing a small diff, or making a localized edit with clear instructions.

These tasks can often be handled by smaller or faster models, especially when the repository context is clean and the expected output is easy to validate.

The important point is not that these tasks are trivial. The important point is that they are bounded. The model does not need to discover a new architecture. It needs to execute a known operation correctly.

Local Reasoning Tasks

Local reasoning tasks require understanding a function, file, module, or narrow dependency chain. Examples include fixing a failing unit test, adding a small feature inside an existing pattern, explaining a bug, or modifying behavior in one bounded area of the codebase.

These tasks often benefit from a mid-sized model. The model needs enough reasoning to understand cause and effect, but it may not need the most expensive frontier model if the context is well-scoped and tests are available.

Repository Reasoning Tasks

Repository reasoning tasks require understanding conventions, cross-file relationships, hidden assumptions, or interactions between systems. Examples include changing a public API, updating a persistence layer, modifying authentication behavior, or refactoring a shared package.

This is where stronger models become more valuable. The difficulty is not just writing code. The difficulty is preserving behavior across a larger surface area.

Long-Horizon Agentic Tasks

Long-horizon tasks require planning, tool use, repeated verification, and recovery from mistakes. Examples include migrating a framework version, resolving a complex GitHub issue, implementing a feature across multiple packages, or debugging failures after several failed attempts.

This is the class where the strongest models are most defensible. Benchmarks such as SWE-bench Verified focus on real software issues and evaluate whether generated patches pass associated tests, which makes them more relevant to this kind of work than simple code-generation benchmarks. SWE-bench Verified is a human-filtered subset of 500 tasks, and the SWE-bench site also distinguishes between different harnesses and agent setups, which is important because the model is only one part of the result. (SWE-bench)

The important point is not that one class is better. The important point is that they have different model requirements.

A mechanical task optimizes for speed and cost. A long-horizon task optimizes for reliability and recovery. Those are not the same objective.

Model Profiles: How Much Intelligence Should the Task Get

The second question is model profile. Once you understand the task class, you can decide how much model you actually need.

Small and Fast

Small models are useful when the task is bounded, the expected output is short, and failure can be cheaply detected. They are good candidates for classification, extraction, simple transformations, file summaries, quick explanations, and narrow edits.

This profile is especially valuable inside coding agents because many agent steps are not the final patch. They are supporting operations: deciding what to inspect, summarizing what changed, checking whether a file is relevant, or generating a small intermediate artifact.

Using a frontier model for every supporting operation can make the whole agent feel expensive before it has even started solving the real problem.

Mid-Sized and Balanced

Mid-sized models are often the best default for day-to-day coding. They can usually handle common implementation tasks, local debugging, test-driven edits, and straightforward refactors while keeping cost and latency under control.

This profile matters because most coding work is not at the extreme frontier. It is not always a research-level debugging problem. It is often a known engineering task inside a known codebase.

That is where balanced models can be very effective: enough capability to reason, not so much cost that every iteration becomes expensive.

Frontier and Expensive

Frontier models should be reserved for tasks where failure is expensive, ambiguity is high, or reasoning depth matters. They are useful for architecture, difficult debugging, security-sensitive review, large refactors, migrations, and agentic loops where a bad early decision can waste many later steps.

The key is not to avoid frontier models. The key is to spend them deliberately.

A strong model is most valuable when it is applied to the part of the workflow where intelligence is actually scarce. If it is used everywhere, it becomes less like a precision instrument and more like a very expensive default setting.

Why the Best Model Depends on the Harness

This is probably the most important point in the whole article. The right model depends not only on the task, but also on the harness, because different coding-agent environments do not consume model intelligence the same way.

Some harnesses front-load a lot of context. Some use retrieval. Some rely heavily on shell feedback. Some run tests aggressively. Some ask the model to plan and execute. Some split work across sub-agents. Some keep a human tightly in the loop. Others run closer to batch mode.

That changes model requirements.

A smaller model with excellent context, strong tools, tight tests, and clear instructions may outperform a larger model operating with poor context and weak feedback. This is also why benchmarks should be read carefully. SWE-bench, for example, is not only a model benchmark; results depend on the agent scaffold, tools, retries, and evaluation setup. The SWE-bench leaderboard explicitly separates benchmark variants and notes the harness used for some comparisons. (SWE-bench)

The same applies in production. A model that is too weak for open-ended coding may be perfectly reliable when used as a sub-agent for search, summarization, or patch verification. A frontier model that performs well in an interactive IDE may be too expensive for a high-volume automated review pipeline. A model that is excellent for code generation may not be the best choice for cheap classification or test-log summarization.

So when people ask what the ideal coding model is, I think the honest answer is this:

There is no ideal model independent of the consumption model.

There is only the best fit for the task, the repository, the harness, the validation loop, the latency target, and the cost budget.

That is why model choice should be a routing decision, not a static preference.

Routing, Escalation, and Cascades

A practical way to think about model optimization is fairly simple.

Use a small model when the task is bounded, reversible, cheap to validate, or part of the agent’s internal workflow.

Use a mid-sized model when the task requires local reasoning, but the scope is still clear and tests or review can catch most mistakes.

Use a frontier model when the task is ambiguous, cross-cutting, high-risk, long-horizon, or expensive to get wrong.

But the more interesting pattern is not manual selection. It is routing.

Model routing means choosing the model dynamically based on the task. Model escalation means starting cheaper and moving upward only when needed. Model cascades mean trying one model first, validating the result, and escalating if confidence or correctness is insufficient.

This is not just a theoretical idea. The research direction is well established. FrugalGPT proposed prompt adaptation, LLM approximation, and LLM cascades as ways to reduce inference cost, and reported that cascades could match the performance of the best individual LLM with up to 98% cost reduction in their experiments. (arXiv) RouteLLM similarly frames model choice as a cost-performance routing problem, dynamically selecting between stronger and weaker models at inference time. (OpenReview) More recent routing work continues in the same direction: select models based on task requirements, cost, latency, and expected quality rather than treating one model as universally optimal. (arXiv)

For coding agents, this suggests a useful architecture:

Do not ask one model to do every job. Build a workflow that knows when to spend intelligence.

That can look like this:

A small model classifies the task;
A small or mid-sized model retrieves and summarizes relevant files;
A mid-sized model attempts the patch;
Tests, linters, or static analysis validate the result;
A frontier model is invoked only when the task is hard, the patch fails, or the risk is high.

That is a very different cost profile from sending every step directly to the most expensive model.

It is also a better engineering posture. The goal is not to be cheap for its own sake. The goal is to reserve expensive reasoning for the moments where it changes the outcome.

Why This Matters in Real Repositories

This matters because coding-agent cost is not only a token problem. It is a workflow problem.

An agent that uses a frontier model to summarize every file may not need better summarization. It may need cheaper summarization. An agent that sends every lint fix to the largest model may not need more intelligence. It may need a mechanical edit path. An agent that uses the same model for task classification, repository search, code generation, test repair, and architectural reasoning may not need one better model. It may need a model-sizing strategy.

The economics become especially important once agents move from demos to real usage. Coding agents are iterative. They inspect files, call tools, run tests, read failures, revise patches, and sometimes repeat the loop many times. That means small inefficiencies compound quickly.

Prompt caching helps, and it should be part of the conversation. OpenAI states that prompt caching can reduce latency by up to 80% and input token costs by up to 90% for repeated prompt prefixes. (OpenAI Developers) But caching does not replace model sizing. Caching makes repeated context cheaper. Model sizing asks whether the expensive model needed to see that context in the first place.

The real optimization is layered:

better context, better routing, better validation, better caching, and better escalation.

That is why model selection deserves more engineering attention. Not just which model scores highest, but which model should do which part of the workflow, under which conditions, with which fallback path.

If we care about coding-agent performance, we should care about model capability. But we should also care about cost per successful task, latency per iteration, failure recovery, validation quality, and how often expensive reasoning is invoked unnecessarily.

That is not procurement detail. It is part of the runtime architecture of the agent.

Conclusion

A good AI coding workflow is not only about using a powerful model. It is about fit: fit to the task, fit to the repository, fit to the harness, and fit to the way the work is validated.

That is why I do not think coding agents should default to one model everywhere. Some tasks need the strongest available model. Some need a balanced model. Some need a small, fast model with good instructions and tight validation. Some need a cascade where the system starts cheap and escalates only when the task proves difficult.

The important shift is this:

Stop thinking of model choice as a leaderboard decision. Start thinking of it as a sizing problem.

Once you do that, cost and performance stop looking like opposing forces. They become part of the same engineering problem.

So if you are building coding-agent workflows, that naturally leads to a more useful question:

Are you using the best model, or are you using the right model at the right moment?

Your AGENTS.md Should Not Look the Same Everywhere

Francesco Sardone — Fri, 08 May 2026 17:45:13 +0000

AI coding agents need context, and that part is obvious by now. What is less obvious is that context quality is only half the problem. The other half is context shape.

An instruction file that works well in one repository, one harness, or one workflow can be the wrong format for another. A dense single file may be perfect for one setup and awkward for another. A concise operational doc may be ideal in one environment and too shallow in another. A multifile structure may dramatically improve retrieval in one workflow while feeling unnecessary in a smaller repo.

So the real question is not only:

“Do you have an AGENTS.md?”

It is also:

“Is it in the right format for the way your agent actually consumes it?”

That is the part I think we should talk about more.

Overview
The Hidden Problem: Context Shape
Why One AGENTS.md Format Is Not Enough
Profiles: How Much Context Should an Agent Get
Layouts: How Should Context Be Packaged
Why the Best Format Depends on the Harness
Single vs Split vs Multifile
Why This Matters in Real Repositories
Conclusion

Overview

A lot of discussion around coding agents still treats repository guidance as a content problem. The assumption is simple: if the instructions are correct, the agent should behave better. That is true, but it is also incomplete.

In practice, even good repository guidance can underperform when it is delivered in the wrong shape. A document can be accurate and still be too dense. It can be detailed and still be hard to navigate. It can be comprehensive and still be poorly suited to the way a given harness retrieves or loads information.

That means AGENTS.md is not just documentation. It is a delivery format for operational context, and as soon as you see it that way, the important design question changes. It becomes less about “write one good markdown file” and more about this:

What format gives this agent the best chance of using repository knowledge correctly?

The Hidden Problem: Context Shape

When an agent fails to follow repo conventions, we often blame the model. Sometimes that is fair, but sometimes the problem is much more boring than that. The instructions exist, the rules are written down, the commands are there, and the conventions are documented. The problem is that the information is packaged in a way that is awkward for the actual workflow.

That can happen in several ways. The document may be too long for the way the harness front-loads context. The operational rules may be buried under explanatory material. The file may be too concise and lack useful examples or nuance. The document may be logically organized for humans, but not for retrieval. Or the agent may be forced to repeatedly scan one large file when section-level access would work better.

In other words, the issue is not always missing context. Sometimes it is mis-shaped context, and that distinction matters because once you move from “missing information” to “information packaging,” the design space gets much more interesting.

Why One `AGENTS.md` Format Is Not Enough

There is a quiet assumption in a lot of agent workflows that AGENTS.md should always look roughly the same: one file, one structure, one level of detail, one universal best practice. That sounds neat, but real repositories do not behave that way.

A small service with a narrow stack does not need the same instruction surface as a polyglot monorepo. A repo with highly stable conventions does not need the same explanatory depth as one with lots of exceptions. A harness that pulls one root document into context does not behave the same way as one that can navigate multiple files more selectively.

So a single fixed format quickly starts to look less like a standard and more like an accidental constraint. The better framing is that AGENTS.md is not one artifact, but a family of possible context surfaces. Once you accept that, at least two dimensions become worth choosing deliberately: density, meaning how much detail to include, and layout, meaning how to package that detail.

Those two decisions matter much more than they usually get credit for.

Profiles: How Much Context Should an Agent Get

The first question is density: how much context should the agent actually receive? This is easy to underestimate because more detail often feels safer, but more detail is not always better. Too little context causes guessing, while too much context can create drag, bury key rules, or dilute what matters most.

That is why there is real value in separating at least two broad profiles.

Concise

A concise profile should focus on operational rules. It should answer things like where code goes, how tests are run, what formatting or linting tools are canonical, which naming conventions matter most, and what the agent must not do.

This format is useful when speed and clarity matter more than depth. It is often the better choice when the repository is relatively legible, when the harness already has decent retrieval behavior, or when you want the file to act as a sharp execution guide rather than a full repository reference.

Comprehensive

A comprehensive profile should keep the same core rules, but add richer explanation, examples, representative patterns, exceptions, and more supporting detail. This format is useful when the repository has a lot of nuance, when conventions are not obvious from source alone, or when the agent is likely to benefit from more supporting structure.

The important point is not that one is better. The important point is that they solve different problems. A concise file optimizes for directness, while a comprehensive file optimizes for coverage, and those are not the same objective.

Layouts: How Should Context Be Packaged

The second question is layout. Even if you know how much detail you want, you still have to decide how that detail should be delivered. This is where things get more interesting, because layout changes how context is navigated, retrieved, and reused.

Single File

The simplest option is one complete document. That has obvious benefits: it is easy to find, easy to version, easy to explain, and works well with simple workflows. A single-file layout is often the right baseline, but it is not automatically the best final form.

Split Layout

A split layout separates the document into two levels: a concise operational primary file and a deeper companion reference. This is useful because it preserves a clean entrypoint without losing richness. The primary file stays sharp, while the companion file holds the expanded explanation.

That structure mirrors how many people actually want agent instructions to behave: one file for immediate execution, another for deeper context when needed.

Multifile Layout

A multifile layout goes one step further. Instead of one document with many sections, it creates a root entrypoint plus separate files for areas like testing, formatting, naming, imports, git workflow, tooling, or red lines.

This is not just a documentation choice. It is a retrieval choice.

In some workflows, section-level access is much better than forcing the agent to traverse a single long markdown file repeatedly. That becomes especially true when the repository is large, when different categories of convention are independently important, when the harness benefits from targeted reads, or when different tasks repeatedly touch different instruction subsets.

Again, none of these layouts is universally best. They are different answers to different consumption patterns.

Why the Best Format Depends on the Harness

This is probably the most important point in the whole article. The right format depends not only on the repository, but also on the harness, because different agent environments do not consume instructions the same way.

Some front-load a single root document. Some can navigate multiple files more intelligently. Some behave better with compact operational instructions, while others benefit from richer references they can consult selectively. Some workflows are highly interactive, while others are deterministic and closer to batch processing.

So when people ask what the ideal AGENTS.md looks like, I think the honest answer is this:

There is no ideal AGENTS.md independent of the consumption model.

There is only the best fit for the repository, the task, the harness, the retrieval style, and the context budget. That is why format should be a design choice, not an afterthought.

Single vs Split vs Multifile

A practical way to think about it is fairly simple.

Use a single file when you want the lowest-friction default. This works well for straightforward repositories, smaller projects, or harnesses that just want one obvious source of truth.

Use a split layout when you want a clean operational layer plus deeper reference material. This is a strong middle ground because it keeps the entrypoint lean while still preserving richer explanation nearby.

Use a multifile layout when you want the instructions to be navigable as a structured knowledge surface, not only as one long document. This becomes more compelling as repositories grow, conventions become more layered, or workflows benefit from targeted section retrieval.

The important thing is not to over-theorize it. Just ask:

How will this agent actually read and use the guidance?

That question usually points to the right format much faster than abstract style preferences do.

Why This Matters in Real Repositories

This matters because agent failures are often more structural than they look. An agent that uses the wrong test command may not need better reasoning; it may need better command discoverability. An agent that violates naming conventions may not need stronger coding ability; it may need the naming rules surfaced more directly. An agent that keeps missing repo-specific constraints may not need more context in the abstract; it may need context that is easier to retrieve at the right moment.

That is why I think context design deserves more engineering attention. Not just the content, but the delivery mechanism.

If we care about repository alignment, we should care about what is included, what is omitted, how it is grouped, how it is accessed, how much context is presented up front, and how much is left available as deeper reference. That is not documentation polish. It is part of the runtime interface between the repository and the agent.

Conclusion

A good AGENTS.md is not only about accuracy. It is about fit: fit to the repository, fit to the task, fit to the harness, and fit to the way context is actually consumed.

That is why I do not think AGENTS.md should look the same everywhere. Some projects need one concise operational file. Some need a lean primary doc plus deeper companion material. Some need a structured multifile layout that behaves more like a retrieval surface than a static note.

The important shift is this:

Stop thinking of AGENTS.md as a fixed document template. Start thinking of it as a context interface.

Once you do that, density and layout stop looking cosmetic. They become part of the engineering problem.

So if you are working on agent workflows, that naturally leads to a more useful question:

Is your AGENTS.md written well, or is it also shaped well?

If the content shared in this post resonates, I've built Agentskill which already supports this approach with different profiles and layouts for shaping AGENTS.md, to fit both the repository and the harness that will consume it.

Consider leaving a star on GitHub.

Turning Repository Knowledge Into Usable Agent Context

Francesco Sardone — Sun, 03 May 2026 11:08:59 +0000

AI coding agents are getting better at writing code, but they still struggle with one thing that every real-world repository has: context.

Not syntax. Not boilerplate. Context.

That means understanding how a repo is structured, which commands are the right ones, how tests are run, what naming conventions are actually used, what tooling is configured, and what rules are implicit but never properly documented.

That is the gap Agentskill is built to solve.

Overview
Why Agentskill Was Needed
What Agentskill Actually Does
Static CLI, But Also LLM Enrichment
Multi-Language Support
Use it as a Skill
Why a Good AGENTS.md Matters
Where Agentskill Makes the Difference
Conclusion

Overview

Agentskill is a tool that analyzes a repository and turns what it finds into something coding agents can actually use.

At its core, it helps generate a data-backed AGENTS.md instead of the usual vague, statistically guessed document that many LLM-driven workflows produce.

That distinction matters a lot.

A typical AI-generated repo guide often sounds correct, but it is frequently inferred from a partial read of the codebase. Agentskill takes a different approach: first it inspects the repository deterministically, then it uses that evidence to generate instructions grounded in actual project data.

So instead of producing something like:

“This repo seems to use pytest and black.”

it can produce something much closer to:

“This repository uses these test commands, these formatting conventions, these tool configs, and these language-specific patterns because they were detected from the repo itself.”

That makes the output much more useful both for humans and for coding agents.

Why Agentskill Was Needed

Modern coding agents are powerful, but they are still very sensitive to missing context.

Even a strong model can fail for surprisingly boring reasons:

It runs the wrong test command
It assumes the wrong formatter
It places files in the wrong directory
It follows naming conventions that do not match the repo
It invents project rules that do not really exist

In other words, the problem is often not code generation. The problem is repo alignment.

That is exactly where Agentskill comes in.

It exists because repository knowledge is usually fragmented across source code, config files, directory layout, git history, tests, and tribal knowledge in the team’s head. Agentskill extracts those signals and packages them into a format agents can consume.

What Agentskill Actually Does

The simplest way to describe Agentskill is this:

it compiles repository reality into agent-usable instructions.

It can inspect:

Repository structure
Formatting patterns
Config files
Git conventions
Dependency and import relationships
Symbol and naming patterns
Test layout and execution clues

Then it uses that information to generate or update AGENTS.md.

So the workflow is not:

LLM Guesses Repo Conventions

It is:

Repo Analysis → Structured Evidence → Generated Agent Instructions

To put it visually, a simple way to look at it is:

Repository
   ↓
Agentskill analyzes structure, config, tests, style, git, symbols
   ↓
Structured evidence
   ↓
Generate or update AGENTS.md
   ↓
Better instructions for coding agents

That is the whole magic, and also why it feels more robust than “ask a model to summarize the repo.”

Static CLI, But Also LLM Enrichment

One of the things I like most about Agentskill is that it works at two levels.

1. Static CLI Tool

You can use it as a pure CLI utility to inspect repositories and generate structured outputs.

That already makes it useful in CI, audits, or local repo analysis.

2. LLM Enrichment Layer

But Agentskill does not stop at static analysis.

It also supports an enrichment workflow that helps produce a much better AGENTS.md than a purely statistical generation would.

This is where the project becomes especially interesting.

Instead of relying only on model intuition, it combines:

Repository facts
Reference repos
Interactive clarification for missing high-value information
Prompt contracts designed to avoid invention

So the final output is not just “AI-written.”
It is AI-shaped, but data-backed.

That is a very important difference.

Because the real problem with many generated instruction files is not formatting. It is hallucinated certainty.

Agentskill addresses that by grounding the generation process in what the repository actually shows.

Multi-Language Support

Another strong point is that Agentskill is not built for one ecosystem only.

It supports a broad set of languages and works well in polyglot repos too.

That matters because real repositories are rarely pure anymore. A backend in Python, some TypeScript in the frontend, a shell layer for automation, and maybe a Go or Rust service on the side is a pretty normal setup.

Agentskill is designed for that reality.

It supports a wide range of languages including:

Python
TypeScript
JavaScript
Go
Rust
Java
Kotlin
C#
C
C++
Ruby
PHP
Swift
Objective-C
Bash

That is one of the reasons the project feels practical rather than academic. It is built for the messiness of modern repositories, not for a toy single-language demo.

Use it as a Skill

This is one of the easiest parts to appreciate, and it deserves its own section.

Agentskill is not only something you run manually from the terminal. You can also use it as a skill, so your agent can leverage it directly through conversation.

That means the integration model becomes much simpler:

you do not need to explain the whole repository every time.

You can just talk to your agent naturally, and let the skill provide the missing repo intelligence.

That is a much better UX.

Instead of saying:

“Please inspect the repository, find the formatting conventions, infer the correct test commands, understand the project structure, and then generate instructions.”

you can say something much closer to:

“Generate an AGENTS.md for this repo.”
“Update the repo instructions after these changes.”
“Analyze this codebase and tell me what conventions matter.”
“Use the repo’s real config and create agent instructions.”

That is where Agentskill becomes very approachable: it turns a fairly advanced repository-analysis workflow into something you can trigger with plain language.

Example Prompts

Here are the kinds of prompts that make sense in a skill-driven workflow:

Analyze this repository and generate a data-backed AGENTS.md.

Update the existing AGENTS.md without losing the manual notes we already added.

Inspect the repo and tell me the canonical test, lint, and format commands.

Generate instructions for this polyglot repo and separate the conventions by language.

Use this repo as a reference and apply the same conventions to the new service.

Scan the repository and tell me which rules are strongly evidenced versus tentative.

Why This Matters

This approach is powerful because it shifts the burden away from the user.

You are no longer hand-authoring everything.
You are no longer trusting a model to freestyle repo conventions.
And you are no longer repeating the same context in every session.

You can simply chat with your agent, while Agentskill supplies the structure and evidence behind the scenes.

That makes it feel less like a generator and more like an actual capability layer for agentic coding.

Why a Good `AGENTS.md` Matters

This is the part that is getting more important every month.

A good AGENTS.md is not just documentation anymore. It is operational context for coding agents.

When that file is good, agents have a much better chance of producing code that is:

Aligned with repo conventions
Runnable with the correct commands
Consistent with project structure
Closer to review-ready on the first attempt

Research on repository-level code assistance strongly suggests that better repository context improves results. More broadly, studies on developer productivity and documentation friction reinforce the same point: when the right context is easier to access, outcomes improve.

To be careful here: there is not a public benchmark that isolates “Agentskill-generated AGENTS.md vs no AGENTS.md” as a standardized published result.

So it would be misleading to present a fake exact number as if it were officially benchmarked.

Still, a reasonable summary is this:

Good repository context measurably improves code-generation outcomes
Better documentation and explicit conventions reduce friction
Therefore a strong AGENTS.md should improve agent performance in meaningful ways

A conservative estimate for a solid, data-backed AGENTS.md is something like:

+10% to +18% better first-pass compliance with repo conventions
20% to 40% fewer wrong-command or wrong-tool mistakes
8% to 18% fewer retries before a patch becomes reviewable
15% to 35% fewer cross-language or boundary mistakes in polyglot repos

These are best treated as practical estimates, not official benchmark claims.

Still, directionally, they match what most teams already feel in practice: a well-instructed agent is a much better collaborator than a blind one.

Where Agentskill Makes the Difference

For me, the key value of Agentskill is not that it generates text.

Plenty of tools can generate text.

Its value is that it separates two things that should be separated:

What can be measured from the repo
What can be synthesized into instructions

That design makes the result much more trustworthy.

So instead of a generic repo summary, you get something closer to a contract between the repository and the agent.

That is why Agentskill feels useful in at least three scenarios:

Existing Repositories

You already have conventions, but they are implicit. Agentskill extracts them and makes them usable.

New Repositories

You want to bootstrap agent instructions from day one without writing everything manually.

Multi-Repo or Reference-Based Setups

You want to transfer conventions from one stronger repo to another, while still adapting to the target codebase instead of blindly copying rules.

That last part is especially valuable. A lot of teams do not need more AI output. They need better convention transfer.

Agentskill is very good at that framing.

Conclusion

What makes Agentskill interesting is not just that it generates AGENTS.md.

It is that it treats agent context as something that should be engineered, not improvised.

That means:

Using static analysis where static analysis is the right tool
Using LLMs where synthesis is useful
Grounding the final output in repository evidence
Making the whole thing simple enough to invoke from the CLI or just through chat with your agent

And honestly, that is probably the right pattern for this whole space.

The future is not “let the model guess the repo.”
The future is “give the model better repo memory.”

Agentskill is a practical step in that direction.

If you are working with coding agents across real repositories, especially polyglot ones, this is the kind of tooling that can make the difference between “interesting demo” and “usable workflow.”

If this sounds interesting, check out Agentskill, try it on one of your repositories, and see what happens when agent instructions are built from real repository evidence instead of educated guesses.

And if you like the project, leave a star on GitHub, follow the work, and consider sponsoring it to support future development.

Open source tooling like this gets better faster when people use it, share it, and back it.

Understanding GitHub Pull Requests

Francesco Sardone — Mon, 16 Oct 2023 06:00:00 +0000

Introduction
Requirements
Overview
Pull Requests
Navigating Request
Conclusion
Share Support

Introduction

Hey there! I'm Francesco known as Airscript on the web.
Today we're gonna continue our focus on GitHub Repositories taking a look to Pull Requests tab.
Without any further ado, I think we can start.

Requirements

You don't need any particular requirement to consult pull requests section on GitHub.
If you need a place to follow along this post, my chosen repository for today's blog post is Beelzebub.

Overview

I will start this post with a simple question: have you ever wondered how you can actually contribute to a software project?
Probably now in your mind you have something like: "Writing code, of course!"
That is totally right, but how? How do you represent and share that block of code that you wrote?
That is done by making a pull request!

Pull Requests

So, let's deep dive on what is a pull request first.
As we have seen in the overview section, a pull request, for short PR, is actually a request for making a change inside a software.
Those changes are detected as additions and removals and usually they look like this:

In green we see additions and in red removals.

Unlike issues, pull requests can have more than two states.
A pull request can be seen as open, closed and merged. In some cases also as draft.
Let's see what they mean:

An open pull request means that a contributor just has expressed the willingness to contribute to a project, making some changes;
A closed pull request means that the pull request has come to an end, without being merged inside the repository;
A merged pull request means that our contribution has seen light and now it is part of the software project itself;
A draft pull request means that it is not ready to be reviewed and merged.

As a last note, pull requests like issues can be labeled and added to milestones.
So, everything we told about those two entities in this previous blog post is totally right also for pull requests!

Navigating Requests

Now that we are experts of what a pull request actually means, let's see where we can find them and how we can filter them out.
While over our selected GitHub repository, let's just take a look on the top left portion of our screen:

As indicated inside the image above, we can simply select Pull Requests and jump inside this wonderful world:

I've filtered out for closed ones since there were no open requests at the time of this blog post.

This is where all the pull requests lie.
And just like issues themselves, we can use fast filters for searching whatever we are looking for in a rapid fashion as well as just searching for keywords inside the search bar!

Bonus

Now that you know what is a pull request and where you can find it, if you're looking for making your own first pull request just make sure to drop off my blog post on how to make your first pull request!

Conclusion

In today's blog post we have seen what is a pull request, how many states it can have and where we can find and filter them out in GitHub.
At this point with the knowledge acquired with this series, you are already able to create your own project, open issues and resolve them via pull request.
Be proud of yourself!

Share Support

If you have liked this post, just leave a reaction and a comment in the section below.
To not lose any new post, just remember that you can follow me here on dev.to and also other platforms that you can find on airscript.it.
Thank you kindly!

Patreon Meets GitHub Sponsors

Francesco Sardone — Mon, 09 Oct 2023 06:00:00 +0000

Introduction
Requirements
Overview
Connecting Patreon
Bonus
Conclusion
Share Support

Introduction

Hey there! I'm Francesco known as Airscript on the web.
Today we're gonna see how to connect Patreon to our GitHub Sponsors profile.
This possibility to interconnect these two services has been launched a few days ago from the publishment of this post, so I thought it would be awesome to see how it can be done.

Requirements

In order to proceed with this post, you'll need two things:

A personal GitHub Sponsors profile;
A personal Patreon profile;

Overview

This event, happened between GitHub Sponsors and Patreon, marks a new milestone in open source empowerment.
One thing that we suffer inside our ecosystem is the possibility to give something back to those marvelous contributors, who gift everyday their time for our own pledge.

Having Patreon it's not only an additional service to give credit, but this credit can be shown up over our GitHub profile too!

Now without investing more words on the matter, let's see how we can connect everything.

Connecting Patreon

Let's start heading to our GitHub profile.

Here we can simply click onto Sponsors Dashboard and reach this section after that:

You can find this at the left of the page.
Just click onto Settings to reach our final stop for connecting Patreon:

Simply click Connect with Patreon and allow Patreon to connect with your GitHub Profile:

If everything goes as expected, you'll be redirected to your GitHub Sponsors with this marvelous message appearing before your eyes:

And that's all, we did it!
Now we can see who sponsors us on Patreon also onto GitHub Sponsors!

Bonus

If you want to allow people to sponsor you through Patreon via GitHub Sponsors, there is a small step to do.
Just go again inside your Settings section and tick this functionality:

After selecting this, inside your sponsor page, you'll see a new tab leading to Patreon and its tiers:

Conclusion

In today's post we have seen how to connect Patreon with GitHub Sponsors.
Don't forget to donate even a single dollar to your most ispirational open contributors out there.
Tell them that they are meaningful for you!

Share Support

No More Problems With GitHub Issues

Francesco Sardone — Mon, 02 Oct 2023 06:00:00 +0000

Introduction
Requirements
Overview
Issues
Labels
Milestones
Conclusion
Share Support

Introduction

Hey there! I'm Francesco known as Airscript on the web.
Today we're gonna continue our focus on GitHub Repositories taking a look to Issues tab.
Without any further ado, I think we can start.

Requirements

You don't need any particular requirement to consult issues section on GitHub.
If you need a place to follow along this post, my chosen repository for today's blog post is Awesome.

Overview

Let's say you have encountered problems with a particular software that you're using and that software is also available on GitHub. How do you check an open issue or report one?
That's what we'll be learning today!

It can be daunting at first, looking at this image, to know what's going on. Fear not, there are three main things to learn here: issues, labels and milestones.

Issues

Starting from the roots, an issue as the name implies, is a problem.
During the years this term just evolved in something more, even though not matching its meaning.
Today's issues are simply activities. Activities that can span from features, discussions, ideas, bugs and so on.
One important thing to keep in mind for issues is that they can have, talking simply, two states: open and close state.

Inside of GitHub you can create, search or simply interact with issues.

Creating An Issue

So starting from here, what do I have to do to start creating a new issue?
It's simple. Just use the green button on the right and fill the information needed in the opening page:

Remember that this is not an in-depth article on issues lifecycle , but an overview on issues tab in GitHub.

Searching An Issue

In order to fulfill the search of an issue, we have a pretty long search bar in this section.
And, the cool thing about this bar, is that it just responds to its search language.

In this image, we are filtering for opened issues.

Interacting With An Issue

The last thing that we can do, regarding issues in this section, it to click on them and actually interacting with them.
As you see, there is a list in the first image representing, of course, the listed issues for the repository.
When clicking on one of them, you are entering the deep context of it, looking at title, descriptions, comments and so on.
You can also leave a comment of yours if you want to!

Labels

Now that we have seen what issues are and what we can do with them, specifically to this section, let's talk about labels.

Labels serve different purposes but the main one is to categorize issues.
GitHub on every new repository just creates some default ones such as: enhancement, documentation, bug and so on.

Don't forget to put a label on your issue if you want to get recognized for what it really is!

Milestones

At last only milestones remain.

Milestones are something that you don't want to sleep on.
They can be a container for issues, regarding a specific goal.
Let's do an example on this. Let's say that you file an issue for a project that you use and want to know when that issue will be solved.
Milestones tell you exactly that, even though not everyone uses them in the right way.
If your issue is listed inside a milestone that will be marked as the next version of the software, then you're good to go!

Here, following, an image representing a list of milestones.

Had to take this one onto another repository since Awesome is not using milestones currently.

Conclusion

In today's post we have seen Issues section inside a GitHub Repository.
We have talked about how to create, search and interact with issues as well as the meaning behind labels and milestones.
As you can see, things are starting to get a little bit complicated but don't worry: we still have time to talk in depth about issues, labeling, milestones and so on in later specific posts.

Share Support

Navigating Code In GitHub Repositories

Francesco Sardone — Mon, 25 Sep 2023 06:00:00 +0000

Introduction
Requirements
Header
Files
About
Releases
README
Conclusion
Share Support

Introduction

Hey there! I'm Francesco known as Airscript on the web.
Today we're gonna continue our focus on GitHub Repositories taking a look to Code tab.
Without any further ado, I think we can start.

Requirements

You don't need any particular requirement to consult code section on GitHub.

Header

Since we're going to do a deep dive on this topic, let's start from the top.
For the purpose of this blog post, I'll be using Awesome Steam Deck as reference.

Open the link and start with me from the left, just below the code tab:

In the case of this repository we have three main aspects:

Title: the actual name of repository;
Template: the base template from where it was generated;
Visibility: in this case as public, means it can be seen by everyone.

Going right, instead, we start to see something specific to GitHub itself:

Just looking at them in order, from left to right:

Sponsor: on GitHub repositories or users can be funded through GitHub Sponsors and this button serves that purpose;
Pin/Unpin: if you want to showreel you work, you can pin it on your profile page to make it stand thanks to this button;
Watch/Unwatch: when you're interested by a project, you can watch it and get all the updates from it such as releases and more;
Fork: the concept of fork is literally to make a copy of a repository on your profile or organization;
Star/Starred: a star is something that usually makes GitHub users happy and you can refer to it as a bookmark telling that you like it.

Files

After the header we can move out together inside the hot part of a repository: files.
Inside files we can check the actual code, documentation and more.
The whole project, basically.

Starting from the top, we see a selector for both branches and tags, but what are they?
Simply put, branches can be seen like different versions of a project that can be identical or flow in a different pathway just like a tree branch.
Tags have a similar concept but they're literally a photo of a branch on a specific period in time. Yes, just the selfie you made yourself years ago.
Other than this, on the right you see utilities for searching files, creating new ones and also different possibilities to code on your own.

Leaving behind the top part, we can go directly to the files tree.
This tree shows two main things:

Who made the last changes to the repository's code;
The files that compose up the repository.

Before moving onto the right portion of this page, I have to make a small focus onto the changes.
When you make a change to repository's code, that change is being called a commit.

About

Moving forward and for forward I mean to the right, we can see the About section.
Treat this as a recap section with all the useful information and metrics about a repository:

Aside all the information that we have already seen in the previous sections, a mention of honor goes to the software license, the various policies and the README of which we'll be talking in a few words.

Releases

The last section that we'll be covering from the right part is the one for Releases.
One thing that I've seen during my travels in the web, is that both technical and non-technical people will, from time to time, reach this section.

The reason is simple: it contains the actual software and usually you can download it from there.

README

The last part that we'll see in this post, is the famous README.

This section is one of the most useful inside a repository.
It tells you what does the project, how you can use it or how you can even contribute to it.
Look always for this section because it makes things clear about what you're looking to!

Conclusion

And we reached the end also for this blog post.
We have seen from top to bottom how a repository is organized, how to read and interpret all the fancy words it has in it and so on.

As a side note, a GitHub Repository is fulfilled of things that may be or not be there, so I made sure to treat only visible sections.
My wish is that you would go out there and discover them out by yourself. Now you have the knowledge to look up at repositories, after all!

Share Support

Creating A New GitHub Repository

Francesco Sardone — Mon, 18 Sep 2023 06:00:00 +0000

Introduction
Requirements
Creating A Repository
Repository Tabs
Conclusion
Share Support

Introduction

Hey there! I'm Francesco known as Airscript on the web.
Today I want to share with you how you can create a new GitHub Repository and navigate into it.
This post will serve us well for the next weeks while we'll be going deeper into the concepts behind repositories.

Requirements

In order to create a GitHub Repository you'll need a GitHub Account.

Creating A Repository

Now that you've checked all the requirements, just head to github.com and look at the top right portion of the screen.
There you'll see a button with a plus sign that makes wonders:

After clicking on New Repository, something like this one will appear in front of you:

First of all you'll be asked for a template repository.
A template repository is an already setup repository that will just work as a blueprint.
After that you'll have to choose the owner, a repository name and description.
Fill it out with whatever you want or use the funny suggestions that GitHub does for you!

Now let's go deeper onto the next steps and see what they mean:

You'll be asking yourself: "What is a README or even a license?"
Good question! A README is a simple text file where you can describe your repository starting from what does it address, to how you can use it and also how to contribute to it.

The license, on the other side, is also a file that contains a contract for protecting your rights regarding the software you're creating.
If you choose to not have one, the software you're making will not be freely usable like usually an open source software can.
If you want to make your own ideas on this matter, jump by choosealicense.com or wait for my series on the matter.

Of course I'm not forgetting about .gitignore.
This is a simple file that takes track of which files are not welcomed inside your repository.
If you have a personal file that you don't want to commit publicly then you just add its name inside of it and the magic is done.

After you've setup everything just click onto Create repository and the mission will be completed!

Repository Tabs

Now that you have created your repository, you'll see something like this:

Yes, I know. There's a lot of stuff right in front of us but fear not! I'm here.
As a first stepping stone let's see the various tabs inside of it and what they mean:

Right know we are into the Code section.
In this section you can actually see the code of your software and other useful information such as topics, websites and more.

Right after that, there's Issues tab where all issues are stored.
An issue can be a lot of things but explained simply, it's a tool to track down things about your repository.
e.g. Your software has an error while doing something? Fine, that's an issue to be opened.

Next to the issues tab there is a Pull Requests tab that also stores them.
This one is practically the heart of open source if you ask me.
Basically, if I want to contribute to a software, I make my own magic with code and then send it back to the original repository as a pull request.

Actions tab is a cool one. A little bit more advanced but nothing impossible to understand.
Let's think about something you do everyday, like brushing your teeths.
The key question here is: "Can you automate it?" and if the answer is yes, then you can represent it with the use of a reusable action!
Inside this tab you'll find all the actions and all the reports for every action that has been runned in the past.

Following this, there's Projects tab.
It speaks by itself but, you can see projects like big boards where you can track down things to do over your software.
This is a cool collaboration and management tool that GitHub gives for managing issues as well!

The Wiki tab is a good stop point for learning about the software itself.
Just imagine: you're a newcomer and don't know how things work. Where should you go to read about it? That's that place.

Now things start getting intresting with the Security tab.
This tab is essential if you want to keep track of vulnerabilities, updates, code improvements and so on. All automated for you with the ease of a simple click.

If you're a social person, we have also a tab for that side of you: Insights.
Here you have a lot of interesting information spacing between how many changes you did to the project to from where that contributor came inside your repository in the first place.

As last but not as least important we have the Settings tab.
This tab is the control panel for everything that just rotates around your repository.
e.g. Repository name, who can access it and more.

Conclusion

And I think we're good to go for now!
In the next posts we'll be seeing every tab in detail and also add some tabs that are hidden right after you create a project.
So, basically we have seen how to create a new repository and learned more about code licenses, README files and repository tabs.
As you can see behind a simple action, there is a lot more. But this is a good thing: means that you have a lot of space for self improvement!

Share Support

Adding Tools To Your GitHub Repositories

Francesco Sardone — Sun, 10 Sep 2023 15:57:05 +0000

Introduction
Requirements
Accessing The Marketplace
A Brief Overview
Integrating An App
Integrating An Action
Conclusion
Share Support

Introduction

Hey there! I'm Francesco known as Airscript on the web.
Today I want to share with you what is GitHub Marketplace and how you can use it for adding mainly tools to your repositories!

Requirements

In order to use GitHub Marketplace you'll need a personal GitHub account and preferably a repository where you can experiment all of this.

Accessing The Marketplace

In order to access the marketplace, go to your GitHub Dashboard while logged in, and select the hamburger menu in top left corner:

A sidebar will appear.
Just at the bottom of it, you'll see a marketplace entry:

Clicking it, you will reach GitHub Marketplace, where our adventure will take place.

A Brief Overview

Inside the marketplace we can practically select two different types of things: apps and actions.

They can be seen as almost the same thing: they just automate something and report back to you.
One of the key differences is that apps can act on their behalf.

Other than this, you can filter apps and actions by categories or their price.
No worries on that, most of the apps are regularly free for open source projects.

Integrating An App

After our brief introduction, I think it's time to start integrating stuff.
I've already selected one app, but feel free to experiment with your own needs and taste on that.
We'll try to integrate an image bot inside my blog repository:

Now just scroll down, select Open Source and click onto install:

The platform will ask you for a payment method but don't worry, the bot is free of cost, it's just a requirement.
Follow the steps and eventually you'll see something like this:

I've just selected one repository, but you can install over them all or wherever you want to.
Now that everything is setup, just click onto install again.
You'll be prompted for a password and then a screen like this will show up for giving the actual permissions:

Just remember: you're giving permissions on acting on your behalf to the apps that you're integrating.
Be sure of what you're installing or it can lead to serious security flaws.

Here we can click the authorization button and...

Now it's just a matter of time for receiving a pull request from our bot that is optimizing repo's images in a lossless fashion!

Integrating An Action

The other type of cool things that we can take from the marketplace are the actions.
Actions are simple workflows that automate something.
Instead of reinventing the wheel writing your own commands for running automated tests, for example, you can just check if there is an action already prepared for this reason and install it right away on your fabulous project.

Now, into the action. Same thing as before, let's go to the marketplace and select an action filtering by type.
For this post, I've selected a simple Action called First Interaction.
It simply greets a user on the first issue or pull request:

Click onto use latest version and copy the lines of code that it just gives you.
Go onto your repository on GitHub and create a .yml file inside a .github folder like this:

After that, just write on top of the explorer this string: .github/workflows/interaction.yml.
This is needed in order to create or point up to a folder.
The explorer I'm talking about it's something like this one:

And then, you can paste what we have actually copied.

Now, this is not enough because we're not telling the action the actual messages we want to display or, for example, on what kind of issues or pull requests it has to print them out.
Documentation comes in our help and every action has a usage section on their installation page:

So we'll just use the one from the example but a little bit more customization since it's missing all the environment's directives:

name: interaction

on:
  issues:
    types: [opened]

  pull_request:
    branches: [main]
    types: [opened]

jobs:
  interaction-checker:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v3

      - uses: actions/first-interaction@main

        with:
          repo-token: ${{ secrets.GITHUB_TOKEN }}

          issue-message: |
            Hey there! Thank you kindly for filing an issue.
            I'll reply back to you as soon as I can.

          pr-message: |
            Hey there! Thank you kindly for your contribution!
            I'll review back as soon as I can.

What I'm telling here is simply that I want to run this action only on opened issues and pull requests that are being made towards main branch.
The next thing I configured is the actual job that indicates the machine it'll be running on and the custom messages for both issues and pull requests.
Simple, isn't it?

Now we can simply commit everything and wait for someone to contribute to our project to see the magic!
In my case I've just asked @ilmanzo to open a test issue for me:

And this clears up the process on integrating also an action!

Conclusion

Today we have seen what is GitHub Marketplace and how to use it to integrate Apps and Actions as tools onto our repositories.
It may be challenging at first but don't give up!
Struggle is a sign of growth if you move toward it.

Share Support

If you have liked this post, just come and tell me!
Are you too shy for doing this? No problem. Just visit airscript.it and share your support following me on your preferred social platform.
If you want to make me even happier, just follow, share or star me and my projects on GitHub.

Discovering With GitHub Explore

Francesco Sardone — Sat, 02 Sep 2023 20:33:26 +0000

Introduction
Requirements
How To Access It
Explore
Topics
Trending
Collections
Events
GitHub Sponsors
Conclusion
Share Support

Introduction

Hey there! I'm Francesco known as Airscript on the web.
Today I want to share with you what is GitHub Explore and how you can use it for discovering magic things on it!

Requirements

In order to use GitHub Explore you don't need anything else except your browser.
I just recommend you make a personal GitHub account to take out the best out of it in terms of feeds.

How To Access It

In order to access Explore, we have different ways.
I'll just divide them by ease of access spacing from simple URL to the actual button inside the UI.

If you don't have an account on GitHub, the easiest way to reach it, it's by just simply going to https://github.com/explore:

The other way you can do it, it's via authenticated access.
While logged in, go to GitHub and on the bottom right portion you'll find something like this section:

Just click over Explore more and voilà, you're inside it.

Of course, there are other ways to go inside of it, but here we're listing only a few ways to do that.

Explore

Now that we know how to enter it, let's just look at Explore!
As we have seen in the other images in the previous section, we have a lot of things to check out.
In this section we'll be looking at Explore tab.
This specific part is useful for having a quick overview over everything we'll be seeing in other tabs.

At left we can see our starred topics, at the center the heart of Explore, i.e. repositories and on the right trending stuff.
Just by looking at this and scrolling you'll be finding, eventually, cool stuff to look over and try out!

An example of feed from Explore.

Topics

Let's imagine that you like a certain topic and you want to build a feed over it.
Instead of just cherry-picking best projects, GitHub Explore gives you the possibility to star a topic.
In this way you can have everything related to a topic straight up in your feeds without any effort!

Collections

Maybe you're just wondering that a topic cannot cover completely a specific theme or that a trending repository is only one about a big pool of things that concerns, for example, learning to code.
No worries on that! We got collections.

Collections, as the name suggests, are simply specific collections about a specific theme.
One example that comes to my mind is repositories made in your country and so on.

Events

This section is relevant to open source related events and here, if you like the subject, you can find something really amazing.
For example, in this period of time when I'm writing, GitHub itself is organizing GitHub Universe!

GitHub Sponsors

The last section is dedicated to GitHub Sponsors.
If you don't know what it is, it's simply the sponsor program made by GitHub in order to give value to developers contributing to open source.
We'll be making a deep focus on this matter, don't you worry.
Here you can practically check who's behind the libraries you use in your projects and eventually you can donate to them...and I highly suggest you do it.

Conclusion

So, we are at the end of this post from GitHub series.
We have checked how to access GitHub Explore, what are basically Explore, Topics, Trending, Collections, Events and GitHub Sponsors and what you can do with them!
If you integrate this tool in your dailies, I can assure you will find something that will change your life for the better.

Share Support

Making Your First Pull Request

Francesco Sardone — Sun, 27 Aug 2023 16:02:43 +0000

Introduction
Requirements
Searching For A Project
Forking
Making Your Changes
The Pull Request
Conclusion
Share Support

Introduction

Hey there! I'm Francesco known as Airscript on the web.
Today I want to share with you how you can contribute to an open source project making your first pull request to it!

Requirements

In order to make it, we'll use solely GitHub, since going into depth with tools and programming languages can be hard at first.
So the only requirement needed is an account on GitHub.

Searching For A Project

After you've got your GitHub account, we just need to search for a project to contribute to.
We have different options here: known projects, using the search bar, using the explore section and so on. It's really up to you.
If you're interested on how to do project scouting, let me know and I'll make a blog post specific to it.
For this blog post, I have chosen option A and so I'll be doing the pull request to a known project of a close connection.

Forking

The first action to do when contributing to open source projects, is to make a fork of the repository.
This comes true when you don't have direct push access to those repositories.
The fork process is easy to do as clicking a simple button on GitHub:

After clicking that button, GitHub will ask us where we want to place the repository and how we want to name it:

Let's keep everything as default and click the fork button.
Ta-da! Our first fork has been done.
Now the repository will be copied over the profile you have chosen.

Making Your Changes

Now that you did the fork, you got a copy of that project over your profile or the one that you've chosen to.
Because of this, we can just do our changes safely without worrying about being blocked for lack of permissions.
As I told you, this blog post just covers the basics of how you can do your first pull request taking out all the tech jargon you can from the process.
So even for our changes, we'll use GitHub's editor:

The edit option is placed on top right corner, just right when you select the file to be edited.
Clicking it, you'll just go inside the editor where you can make the changes.
After you have done that, we have to commit:

Clicking on commit changes will open a modal where we can choose a bunch of things:

Things like a commit title and description or the branch where we want to commit.
For the purpose of this post we want to choose main branch, like I did in this photo.
This help us cutting of the process of doing feature branching on our forked repository before doing the actual Pull Request to the project owner.
After clicking the green button, we are ready for opening our first Pull Request!

The Pull Request

Let's head back to our forked repository page and click onto the contribute button:

Here we can click onto the green button for opening the actual Pull Request and GitHub will just launch us towards a page like this one:

And after you've applied a title and a description to what you are changing, just click again the green button and ta-da! You made it!

Conclusion

In this blog post we actually have seen how to make our first pull request to our chosen open source project.
Bear in mind that we have actually looked only at the process and that in reality this can take up extra effort.
For example, the need to read how to contribute specifically to a project or, keeping behind the lifecycle of a pull request starting from change requests to failing pipelines.
I hope you have found this useful and if you want something deeper regarding this kind of topic, just reach me out!

Share Support

Multi Repository Documentation

Francesco Sardone — Sun, 20 Aug 2023 14:53:02 +0000

Introduction
Requirements
Setup
Wrapping Up
Conclusion
Share Support

Introduction

Hey there! I'm Francesco known as Airscript on the web.
Today I want to share with you how to use Antora, a tool for managing multi repository documentations.
In this blog post we'll see what's required to run an Antora project and how actually you can spin up one too!

Requirements

Before even starting the next section, be sure to have installed on your machine the following requirements:

Since we'll be using Antora 3, the suggested versions for Node.js runtime are spacing between 16 and 18 LTS.
Be sure to type node -v inside your terminal of choice to check which version you have.

Setup

After you got all the requirements, we can start making our multi repository documentation.
In this article I'll be covering a multi repository where we have split up the actual documentation and the UI used to present it.

UI

Let's start from the UI. In order to use it, we can just clone the base template offered by Antora:

$ git clone https://gitlab.com/antora/antora-ui-default.git documentation-ui

In this default UI, you'll find a folder structure comprehensible of various sections such as one for previewing your UI changes and so on.

After looking at the UI, we can practically move onto the actual repository for the documentation.
For this post we'll be using two demo documentations made by Antora, written in AsciiDoc.
You can simply modify those to your needs after all.

$ git clone https://gitlab.com/antora/demo/demo-component-a.git documentation-1
$ git clone https://gitlab.com/antora/demo/demo-component-b.git documentation-2

Now we have two documentations to add to our previously built UI.

Wrapping Up

Now that you have a fully scaffolded multi repository documentation, we have to wrap things up together.
Just for ease of use, we'll be making a dedicated repository that will contain the actual documentation holding both UI and contents.
In this repository we only need a playbook that will link everything up.
This playbook we'll be needed by antora CLI.
Let's start creating a documentation-playbook.yml file with contents like this one in it:

site:
  title: Antora Documentation
  url: <documentation-url>
  start_page: documentation::index.adoc

content:
  sources:
    - url: <documentation-1-url>
    - url: <documentation-2-url>

ui: 
  bundle:
    url: <documentation-ui-bundle-url>
    snapshot: true

  output_dir: assets

output:
  clean: true
  dir: ./docs

And to generate the actual final result, we only have to install antora CLI and run a simple command:

$ npm install -g antora
$ antora documentation-playbook.yml

# If you don't want to install globally antora, this is an alternative with npx.
$ npx antora documentation-playbook.yml

This command will generate our bundle inside docs folder and basically that's it.
You only have to deploy it wherever you want to.

Conclusion

After almost 5 repositories we managed to compose up a multi repository documentation: starting from UI, content and actual bundle repository.
This tool is suggested to who wants to build products with multiple versions or a hub of documentations encapsulated in their own repository.
In case you want something lighter and easier, just take a lighter tool like Docusaurus.

Forem: Francesco Sardone

Model Sizing for Coding Agents: Bigger Is Not Always Better

Table of Contents

Overview

The Hidden Problem: Model Fit

Why One Model Is Not Enough

Task Classes: What Kind of Coding Work Is This

Mechanical Tasks

Local Reasoning Tasks

Repository Reasoning Tasks

Long-Horizon Agentic Tasks

Model Profiles: How Much Intelligence Should the Task Get

Small and Fast

Mid-Sized and Balanced

Frontier and Expensive

Why the Best Model Depends on the Harness

Routing, Escalation, and Cascades

Why This Matters in Real Repositories

Conclusion

Your AGENTS.md Should Not Look the Same Everywhere

Table of Contents

Overview

The Hidden Problem: Context Shape

Why One AGENTS.md Format Is Not Enough

Profiles: How Much Context Should an Agent Get

Concise

Comprehensive

Layouts: How Should Context Be Packaged

Single File

Split Layout

Multifile Layout

Why the Best Format Depends on the Harness

Single vs Split vs Multifile

Why This Matters in Real Repositories

Conclusion

Turning Repository Knowledge Into Usable Agent Context

Table of Contents

Overview

Why Agentskill Was Needed

What Agentskill Actually Does

Static CLI, But Also LLM Enrichment

1. Static CLI Tool

2. LLM Enrichment Layer

Multi-Language Support

Use it as a Skill

Example Prompts

Why This Matters

Why a Good AGENTS.md Matters

Where Agentskill Makes the Difference

Existing Repositories

New Repositories

Multi-Repo or Reference-Based Setups

Conclusion

Understanding GitHub Pull Requests

Contents

Introduction

Requirements

Overview

Pull Requests

Navigating Requests

Bonus

Conclusion

Share Support

Patreon Meets GitHub Sponsors

Contents

Introduction

Requirements

Overview

Connecting Patreon

Bonus

Conclusion

Share Support

No More Problems With GitHub Issues

Contents

Introduction

Requirements

Overview

Issues

Creating An Issue

Searching An Issue

Why One `AGENTS.md` Format Is Not Enough

Why a Good `AGENTS.md` Matters