create-knowledge

Imported from atlasfoo/jaiba-framework (skills/create-knowledge/SKILL.md). Install upstream with npx skills add atlasfoo/jaiba-framework --skill create-knowledge. Copyright stays with the author.

create-knowledge

A JAIBA meta-skill. It takes a skill that already holds knowledge — best practices, domain rules, an external-tracker integration — and makes that knowledge participate in the conduct workflow chain (its propose, spec, and tasks phases), automatically, at the right moment, without the developer having to paste the rules into every prompt.

The output is the same skill, minimally rewritten so it behaves as a plugin: it co-triggers with a workflow and folds itself in. You change three things and nothing else: the description (so it triggers at the right workflow moment), an injected ## JAIBA Integration section (the contract that says how it folds in), and the tags. The knowledge itself — the body's rules, the references/, the assets/, the folder layout — is left exactly as you found it.

Why this works without touching the workflows

There is no runtime step where a workflow "calls its plugins". JAIBA relies on something simpler: the agent running conduct:spec is the same agent that has the knowledge skill sitting in its available skills. Skill selection is driven by the description. So if a knowledge skill's description is engineered to fire on that workflow, in that domain context, it co-triggers and the agent weaves it in.

The vanilla workflows were built expecting this. The sockets already exist — you are conforming a skill to them, not inventing them:

• Input socket — the requirement that enters conduct:spec (define step) can arrive via a knowledge skill: the PRD template carries source: ticket / source-ref: frontmatter for exactly that provenance, and the workflow drafts from whatever requirement input it is handed.
• Output socket — conduct/references/spec-mode.md lists "knowledge skills" among the sources the Technical approach cites, and plan-template.md carries a literal slot: - <Knowledge skill name> (if applicable).

Because the connection is description + the existing sockets, installing an adapted skill modifies no framework artifact — no AGENTS.md, no constitution, no reference index. Dropping the skill in is enough.

The known tradeoff (be honest about it): an output-modifier only fires if its description is pushy enough to co-trigger during conduct:spec. There is no poll that guarantees it. The mitigation is description quality and an explicit hook line — not a workflow edit. Say this to the developer when you adapt an output-modifier.

The two modifier types

Every knowledge plugin is one or both of these. Decide which before writing — it determines the hook and the behavior.

Read the matching reference before you write the contract:

• references/input-modifier.md — the input-enrichment pattern, its boundaries, and the Linear walkthrough.
• references/output-modifier.md — the output-augmentation pattern, its boundaries, and the ASP.NET / OpenAPI walkthrough.

The transform

Work on the skill the developer points you at. Touch only its SKILL.md.

1. Locate and validate the target. It must have a SKILL.md with YAML frontmatter. Refuse three things, with a one-line reason:

   • a JAIBA workflow skill (conduct, ask, fast) — those are the sockets, not plugins;
   • a JAIBA meta skill (jaiba-configure, jaiba-init, jaiba-doctor, including this one);
   • anything without a SKILL.md.

2. Read the target's SKILL.md in full, and skim its references/ only enough to understand the domain. Do not modify references or assets — you are reading them to classify, not to edit.

3. Classify and locate the hook. Decide: input, output, or both? Which workflow mode(s) does it plug into? What is the concrete trigger signal — the cue in a prompt or plan that means "this plugin applies now"? If any of these is ambiguous, ask the developer (one closed question each — see AGENTS.md §3 and the workflows' "Asking the Human"). Do not guess a tracker's ID format or a domain's boundary.

4. Engineer the description. Keep what the skill knows (so it still reads as itself), and add the JAIBA triggering clause that ties it to the workflow mode + trigger signal, pushy enough to co-trigger. The description is the whole triggering mechanism — if it doesn't name the workflow and the signal, the plugin is inert. See "Description shape" below.

5. Inject or update the ## JAIBA Integration section. Use assets/jaiba-integration-template.md verbatim, filled in. This is the contract the agent reads at workflow time. Idempotent: if the section already exists (the skill was adapted before), update it in place — never append a second copy.

6. Set the tags. Add jaiba and jaiba-knowledge, plus jaiba-input and/or jaiba-output to match the type. Preserve the skill's existing tags.

7. Leave everything else alone. Knowledge body, references/, assets/, scripts/, structure — untouched. If the skill carried no description or frontmatter at all, add the minimum frontmatter needed and say so.

8. Report. Show the description before/after and the injected ## JAIBA Integration block. State plainly: which workflow it now hooks, which signal fires it, and that no framework artifact was modified — installing it is just dropping the folder in.

Description shape

A good adapted description has two halves: what the skill knows, and when JAIBA should consult it. Keep the first; add the second.

Example — input modifier (a Linear skill):

Input (before): Knows how to read Linear issues via the Linear MCP and summarize their requirements.

Output (after): Knows how to read Linear issues via the Linear MCP and summarize their requirements. JAIBA knowledge plugin (input): whenever the 'conduct' workflow runs its spec phase (especially the define step, and 'propose' when the requirement starts there) and the prompt contains a Linear issue reference (e.g. LIN-1234, or a linear.app/issue URL), trigger and fetch that issue, then hand its description to the spec as the requirement input — so the developer never has to paste the ticket. See this skill's 'JAIBA Integration' section.

Example — output modifier (an ASP.NET skill):

Input (before): Organization's ASP.NET Core best practices: clean architecture layering, xUnit testing conventions, and per-endpoint Markdown docs.

Output (after): Organization's ASP.NET Core best practices: clean architecture layering, xUnit testing conventions, and per-endpoint Markdown docs. JAIBA knowledge plugin (output): whenever 'conduct:spec' (or 'conduct:tasks') is producing a PRD, plan, or task graph for ASP.NET Core work — new controllers, endpoints, or services — trigger and contribute its mandated tasks and artifacts (e.g. a Markdown doc task per endpoint, the layering and xUnit rules) into the workflow's output, and cite this skill under the plan's 'Sources consulted'. See this skill's 'JAIBA Integration' section.

Notice both name the workflow mode and the trigger signal explicitly, and stay pushy ("whenever… trigger and…"). That is what makes co-triggering reliable.

Boundaries

• Adapt, don't rewrite. The developer's skill is theirs. You are adding a triggering clause and a contract, not re-authoring their knowledge or "improving" their rules.
• One skill, one job. Don't merge two knowledge skills, and don't split one. Adapt the skill as it is.
• Never edit a workflow. If you feel the only way to make a plugin work is to change conduct, stop and say so — that is a framework change, out of scope here, and it would break the "installs with zero framework edits" guarantee.
• No invented integrations. If the skill claims an MCP or API that isn't there, surface the gap (AGENTS.md §5.3); don't paper over it in the contract.

Common failure modes

• A description that names the domain but not the workflow. Then it triggers on chit-chat about the domain, not at spec/plan time. Always bind it to the exact conduct phase (spec, tasks, or propose).
• Editing the knowledge. Out of scope. If the rules are wrong, that's a conversation, not a silent rewrite.
• Double-injecting the contract on a re-run. Update in place.
• Over-promising an output-modifier. It co-triggers; it isn't guaranteed by a runtime poll. Say so, and make the description carry its weight.
• Adapting a workflow skill. Workflows are the sockets. Refuse.