Software Factory
Modules

Skills

Save reusable instructions your project agent loads on demand, so your team's guidance becomes durable shared knowledge.

A skill is a reusable instruction document: a named, saved set of instructions the project agent loads on demand instead of you re-typing the same guidance every time. Each skill has a title, a description, and a body of instructions, and it is scoped to a module. The agent reads a skill's instructions only when the skill is pulled into the conversation, either because you invoked it or because the agent matched it to the task from its description.

Skills turn one-off prompting into durable, shared team knowledge that lives in the project. When you find yourself repeating the same guidance to the agent, save it once as a skill and the whole team reuses it.

Modules

Every skill is scoped to a category that controls where it surfaces. A skill in General Skills is available across the whole project. A module category surfaces when you work with that module's agent, so a skill in Blueprints Skills appears while you work in Blueprints.

Skill CategorySurfaces when you work in
General SkillsAnywhere in the project
Knowledge Base SkillsKnowledge Base
Requirements SkillsRequirements
Blueprints SkillsBlueprints
Work Orders SkillsWork Orders
Feedback SkillsFeedback

When you create a skill, you choose one of these categories in the Skill Category field. Pick General Skills to make the skill available across the whole project.

The description and the body

A skill is created from a short dialog and then filled out in the editor. The Create Skill dialog collects just two things:

  • Skill Category: the category, and so the module, the skill is scoped to.
  • Title: the skill's name.

Once the skill is created, it opens in the editor. A fixed Description label sits above a short front-matter line where you write the description, and the body below it holds the full instructions the agent follows.

The description does two jobs. It is what the agent uses to decide whether a skill fits the task at hand, and it is the subtitle shown beneath the skill in the picker and the "/" menu. Write it as a trigger, not a summary.

Write descriptions as a trigger

Start with "Use when..." so the agent can match the skill to a task. For example: "Use when drafting or editing release notes for 8090 Software Factory releases." Keep the description short. The body can be as long as the guidance needs.

The body is where the real content goes. It is the instruction set the agent follows once the skill is loaded.

Creating a skill

Open Create Skill

Go to the Skills module. Each category section header has a + control; open it and choose Create Skill.

Pick a Skill Category

Choose the category the skill belongs to. Pick General Skills to make it available across the whole project.

Give it a Title

Enter a clear title for the skill.

Write the description and body

In the editor, write the description as a trigger, starting with "Use when...", then put the full guidance the agent should follow in the body. Your changes save automatically.

You can also create and edit skills over the API and MCP, so teams can script skill authoring or manage skills from an external tool.

Invoking a skill

There are several ways a skill gets loaded into a conversation.

  • Skill chips. The agent panel shows your skills as chips above the composer. Click a chip to apply that skill. When there are more skills than fit, a More control opens the rest in a popover.
  • "/" chips. Type "/" in the composer to open an inline picker and attach a skill to a single message as a chip.
  • @skill/ in automations. In an automation prompt, reference a skill with an @skill/ mention followed by its identifier. The automation loads that skill every time it runs. For example, a feedback triage automation can have the prompt "Use @skill/triage_feedback for the newly received feedback item."
  • Automatic matching. The agent loads a skill on its own when the task matches the skill's description, without you naming it.

Some skills, such as parent skills and writing-rules skills, are applied automatically and do not appear as "/" chips.

Built-in writing-rules skills

Every project ships with built-in writing-rules skills that encode how the project writes each document type: Blueprints Writing Rules, Requirements Writing Rules, and Work Orders Writing Rules. They are the project's shared writing standard, and the agent loads the matching one automatically whenever it writes or edits that document type. Loading is required, not optional. The agent reads the current writing-rules skill before it writes, so your conventions are applied on every write and a freshly edited standard takes effect on the next one.

These skills are editable but not deletable. You can open one and change its instructions to match your team's house style, but you cannot remove it, because the agent depends on it existing whenever it writes that document type. Out of the box they carry real content. The Blueprints rules, for example, define the decision-first ADR structure the project uses.

Edits to a built-in skill are versioned like any other document, and the current version is what the agent applies on the next write.

Nested skills and per-user overrides

Skills can nest. A parent skill groups child skills that only apply in its context, and the parent tells the agent which child to use. Two patterns are common.

Template families. A parent skill can hold one child template per variant. A theme-writing skill, for example, can parent a bug template, a feature-request template, and an enhancement template, with the parent picking which child applies to the theme at hand.

Per-user overrides. A parent skill can redirect the agent to a personal style for a specific teammate. The parent instructs the agent that when the current user is that teammate, it should ignore the default project writing-rules skills and follow that person's own child skills instead, such as their personal blueprint style and work-order style. The override is keyed on who is driving the agent, so the same project produces house-standard documents for most people and a personalized format for the teammate who set up the override.

One standard, room for exceptions

Per-user overrides let a project keep a single shared standard while letting individuals opt into their own format, without forking the project rules.

Versions and comments

Every custom and writing-rules skill is versioned automatically, exactly like blueprints and requirements. Each edit creates a new version. You can open the version history, read any past version, and see who changed it, including when the change came from the agent versus a person. Because skills are versioned, you can see exactly how a shared standard evolved, and the agent always applies the current version.

You can also leave comment threads on a skill, so a team can discuss or flag wording in a shared standard the same way it comments on any other document.

Built-in preset skills that have no backing document have no version history and cannot be opened to a past version. Only document-backed skills, meaning custom skills and writing-rules skills, carry history.

Not the same as the coding-agent plugin

"Skill" also appears in the flow that connects an external coding agent to 8090 Software Factory, where you install the 8090 Software Factory plugin into a tool like Cursor or Claude Code. That installable plugin skill is a different thing: it teaches an outside coding tool how to talk to 8090 Software Factory over MCP.

Two kinds of skill

The Skills documented here are instruction documents that live inside a project and steer the project agent. If you want to connect an external coding tool to 8090 Software Factory, see the 8090 Software Factory plugin instead.

Want the agent to draw on more of your team's material? Learn about the Knowledge Base.

On this page