← All build notes

November 11, 2026 · 4 min read

Find a skill, read its rules, then use it

A short walkthrough: ask for an AIWG skill in plain words, read what discovery found, check the rule the skill is bound to, install it if needed, and then...

AIWG ships hundreds of skills. Since 2026.11.1, your assistant gets the closest matches as each request arrives. This walkthrough adds one habit before you let your assistant act on a match: read what it found and the rules that come with it. The skill describes how to do the job, and its rules set what the result has to meet.

Each step starts with what you can ask your assistant, followed by the command it runs, which you can also run yourself. We ran the commands in steps 1 to 5 with AIWG 2026.11.3 in a fresh project, after aiwg use sdlc, deployed for one assistant. Output is cut where marked with ... and otherwise as printed. The prompts are suggestions; we did not record an assistant's answers to them.

1. Ask in plain words

Find the AIWG skill for reviewing my architecture. Show me what it does and which rules it follows before you use it.

aiwg discover "review my architecture"
Discovery results for "review my architecture" (5 matches, 710ms):
...
1. Twelve-Factor Design
   type: skill  score: 1.00
   ...
   name: twelve-factor-design
   capability: Generate or review application architecture against Twelve-Factor and modern 12+ Factor design criteria.
   trigger: "review architecture against 12+ factor"
   ranking: lexical 1.0000 -> final 1.0000; trigger covers 100% of query tokens; scope packaged
   templates: remediation-backlog (aiwg show template remediation-backlog)
   rules: 1 high · activation: 1 bound · 1 required checks
   ...
   - twelve-factor-evidence: Tie every factor finding to reproducible evidence or mark it missing; use explicit statuses, attach remediation to gaps, and separate observations from recommendations. ...

2. gatechk-review-architecture
   type: flow  score: 1.00
   ...

Two results share the top score, so the score alone does not settle it. The capability line and the trigger: line do. The first skill reviews an application against Twelve-Factor criteria, and its trigger covers every word of the request. The second is a flow that validates architecture readiness, checking that views are documented, decisions justified and risks retired, and reports READY, GAPS or BLOCKED as part of a gate check. For a design review of your app, the first is the one to open.

2. Read the card

Show me the card for twelve-factor-design.

aiwg show skill twelve-factor-design
# skill: twelve-factor-design
...
Owner: addon:twelve-factor | installed: false
rules: 1 high · activation: 1 bound · 1 required checks
... Deploy it with `aiwg use twelve-factor`.

## Templates
- remediation-backlog (template): Twelve-Factor Remediation Backlog — `aiwg show template remediation-backlog`
...
## Bound rules
...
- **twelve-factor-evidence** [bound / high]: Tie every factor finding to reproducible evidence or mark it missing; ...

## Outline
- Twelve-Factor Design (2571 bytes, 53 lines)
- Triggers (241 bytes, 7 lines)
- Behavior (1081 bytes, 10 lines)
- Output (265 bytes, 11 lines)
- Examples (437 bytes, 16 lines)
- References (255 bytes, 5 lines)

Before anything runs, the card shows that this skill belongs to the twelve-factor addon, which this project does not have yet, and that it is bound to one rule. It lists a remediation-backlog template. The skill's instructions are not on the card; the outline names the sections you can open.

3. Read the rule

Show me the full twelve-factor-evidence rule.

aiwg show rule twelve-factor-evidence --body
# Twelve-Factor Evidence Rule
...
Every Twelve-Factor or 12+ Factor finding must be tied to concrete evidence or explicitly marked as missing evidence.

## Requirements

- Each factor finding has exactly one status: `pass`, `partial`, `fail`, or `not_applicable`.
- A `pass` finding cites enough evidence to reproduce the judgment.
- A `partial` or `fail` finding includes at least one risk or remediation task.
- Missing evidence is recorded as `missing`; do not infer compliance from intent, naming, or undocumented conventions.
...

These four lines are what a finding from this skill has to look like before you count it as done. A review that says "config looks fine" without pointing at a file does not meet them, and neither does one that passes a factor because a folder has the right name.

4. Open the instructions

What steps does twelve-factor-design follow?

aiwg show skill twelve-factor-design --section Behavior
## Behavior

1. Identify the application boundary: service name, runtime, deployment model, backing services, operators, users, and platform targets.
...
5. For each factor, produce a status of `pass`, `partial`, `fail`, or `not_applicable`, with rationale and missing evidence.
...
7. Generate remediation tasks for gaps that block implementation, readiness review, or continuous audit.

--section takes any heading from the outline; the Output section, for example, lists the review's sections, ending with remediation backlog candidates and open questions for humans. aiwg show skill twelve-factor-design --body prints the whole skill. The drill-in lines on the card add --backend and --resource-source flags; the shorter commands shown here worked without them.

5. Install it if needed

Install the addon that provides twelve-factor-design.

The card said installed: false, so the addon goes in first:

aiwg use twelve-factor
  Deploying twelve-factor addon...
...
  OK twelve-factor addon deployed
AIWG ready with advisories
...

If you deploy AIWG for more than one assistant, --provider picks which one gets the addon. In our run, the advisory said verified signed-release source evidence was unavailable from the cache, and suggested aiwg auth login; the addon still deployed. Afterwards aiwg show skill twelve-factor-design reports installed: true. Restart your assistant so it loads the new skill.

6. Use it, then check the result against the rule

Use twelve-factor-design to review this project. Follow twelve-factor-evidence: give every factor one status, cite the file or config behind each pass, and mark anything you could not check as missing. Put the gaps in the remediation backlog.

When the review comes back, hold it against the rule from step 3:

  • Every factor has exactly one status.
  • Every pass names something you can open and confirm.
  • Every partial or fail has a risk or a remediation task.
  • Anything that could not be checked says missing, rather than passing on intent.

Suppose the config factor comes back as pass with no file named. Send it back with the rule's own words: a pass cites enough evidence to reproduce the judgment. That is a narrower request than "be more thorough", and the assistant can meet it or mark the factor missing.

When the top match is wrong

Discovery ranks by the words you use, and the ranking: line shows how much of your request a result's trigger covers. A high score with low trigger coverage can be a weaker fit than it looks. If none of the top three capability lines describes your task, do not let the assistant go ahead on the closest one. Rephrase and look again, or limit the results to one kind with aiwg discover "<need>" --type skill. If you already know a component's name, aiwg show skill <name> opens it directly.

Agents work the same way. Discovery lists them with their own aiwg show agent line, and in our run aiwg show agent twelve-factor-reviewer showed the same bound rule as the skill.