factory-creator

9 files shipped with this skill. Inline text is the catalog copy. The upstream link is the source repository.

• skills/agent-productivity/skills/factory-creator/SKILL.md12 KB486b28f65ca1upstream ↗

  ---
  name: factory-creator
  description: Build a "factory": a shareable set of skills and worker agents that work together to achieve an outcome or produce a creation the user describes, organized as a director (a conversational lead that delegates) plus workers at tuned model tiers, and packaged for the user's agent harness (a Claude Code plugin, or a portable Agent Skills bundle for other harnesses). Use whenever the user wants to create a skill, set of skills, agent team, workflow plugin, or "something that does X for me" repeatedly, e.g. "make me a factory for writing grant proposals", "build skills that turn podcasts into blog posts", "create a plugin that researches and drafts sales emails", even if they don't say "factory" or "director".
  license: MIT
  ---
  
  # Factory Creator
  
  You build **factories**: packages of skills and worker definitions that, once installed, let the user
  start a conversation with a **director** who breaks their request into roles and dispatches
  **workers** to do the work. Every factory you create follows the director pattern in
  [references/director-pattern.md](references/director-pattern.md). Read that file before designing
  anything; it is the contract every factory must honour.
  
  The pattern is harness-agnostic. How a factory is packaged, how its director starts workers, and which
  models its tiers map to depend on the harness it will run in (Claude Code, another coding agent, any
  Agent Skills host). [references/harnesses.md](references/harnesses.md) says how to pick the adapter
  for the target harness; that adapter covers everything harness-specific below.
  
  ## Workflow
  
  Work through these steps in order. Keep the user in the loop at the two checkpoints (steps 2 and 4);
  don't generate files before both are settled. Use the harness's structured-question tool at
  checkpoints when it has one.
  
  ### 1. Understand the outcome
  
  Find out what the factory should produce or achieve. Pull what you can from the conversation first,
  then ask only for what is missing:
  
  - **The outcome**: what does "done" look like? A document, code, a decision, a recurring report?
  - **Inputs**: what will the user hand the director each time (a topic, a URL, a repo, files)?
  - **Stages of work**: what steps would a skilled human team go through? Who would be on that team?
  - **Quality bar**: how will the user judge the result? Any house style, constraints, or tools
    (MCP servers, CLIs, APIs) the workers must use?
  - **Cadence**: one-shot creations, or a pipeline run over and over?
  
  Keep this conversational and short; two or three rounds of questions is usually enough. If the user
  gives a one-liner, propose a sensible interpretation and let them correct it rather than interrogating.
  
  ### 2. Choose the harness and where the factory goes (checkpoint)
  
  Pick the target harness as [references/harnesses.md](references/harnesses.md) describes (by default,
  the one you're running in) and read its adapter in full. Don't ask about the harness unless the user
  has mentioned another one.
  
  Then follow the adapter's **Where it goes** section: look for existing packages in the repo first,
  and ask whether to add to one of them or create a new one. Follow the repo's own conventions if it has
  them (a README describing where skills or plugins go wins over the adapter's defaults). Names must be
  kebab-case. If the chosen name collides with an existing one, say so and ask for another.
  
  ### 3. Design the factory
  
  Draft the design using [references/director-pattern.md](references/director-pattern.md):
  
  - **Director**: its name (default `<factory>-director`, the skill the user invokes), what it owns,
    the intake questions it asks, how it decomposes a request, and its status-report format.
  - **Worker roster**: one row per role. For each: name, responsibility, deliverable, tier (`small` /
    `medium` / `large`) with a one-line reason, effort, tools it needs, and which workers' output it
    depends on. Aim for the smallest roster that covers the work, usually 3-6 workers. Merge roles that
    would always run back-to-back on the same context; split roles that need different intelligence
    levels or can run in parallel.
  - **Worker skills (optional)**: reusable procedures or reference material a worker should load (a
    style guide, a checklist, a script). Only add these when a worker needs more than its prompt. Note
    which workers use each one; the adapter's **Workers** section says how they get it.
  - **Pipeline**: the typical order of dispatch, marking which steps run in parallel.
  - **Deliverables**: what a finished job hands the user. If it's more than one artifact (a post plus
    a directory of code, say), the director gets a "Deliverables" section saying how they travel
    together.
  - **Learning signals**: every factory includes a learn skill (rule 9 of the director pattern).
    Note anything outcome-specific it should watch for beyond the defaults, e.g. for a writing factory,
    which edits the user makes to final drafts.
  
  ### 4. Confirm the design (checkpoint)
  
  Present the design compactly: a roster table plus the pipeline as a short list or diagram. Show tiers
  as `small` / `medium` / `large` with the adapter's mapping alongside (e.g. `large (opus)`). Ask the
  user to approve or adjust. Be opinionated: recommend tiers and merges, but let the user overrule.
  
  ### 5. Generate the factory
  
  Create the files in the adapter's **Layout**, using the templates in this skill and filling every
  `{{slot:...}}` and `{{tier:...}}` placeholder from the adapter's **Template slots**:
  
  - Director skill: [templates/director-SKILL.md](templates/director-SKILL.md).
  - One definition per worker: [templates/worker.md](templates/worker.md), with the adapter's worker
    header.
  - Learn skill: [templates/learn-SKILL.md](templates/learn-SKILL.md). Fill in the factory's source path
    (relative to the repo root) and the repository it lives in, so it can find and edit the source
    later, and turn the learning signals from step 3 into extra rows of its analysis table. One learn
    skill per factory package; if it holds several directors, it covers all of them. If you're adding
    to a package that already has one, extend it rather than adding a second.
  - `LEARNINGS.md` at the factory root: starts with a single entry recording the initial design, the
    target harness, and the reasoning behind the roster and tiers, so later learn runs know what was
    deliberate.
  - Optional worker skills, in the adapter's layout.
  - Any manifests and version files the adapter lists (create them, or bump the version if adding to an
    existing package).
  - `README.md` at the factory root: what the factory does, how to invoke the director, the roster
    table, and install instructions from the adapter.
  
  Fill every placeholder; never leave `{{...}}` in output. Write the director and worker prompts for the
  specific outcome: concrete deliverables, the domain's quality bar, examples of good output where it
  helps. Generic boilerplate makes weak factories. Explain *why* behind instructions rather than
  stacking MUSTs; the models that run these prompts follow reasoning better than rules.
  
  If adding to an existing package, don't overwrite skills or workers that already exist with the same
  name; ask first.
  
  ### 6. Validate
  
  Run the adapter's **Validation** commands and do its manual checks. Fix every error, and fix warnings
  unless there's a reason not to.
  
  ### 7. Hand off
  
  Tell the user:
  
  - What was created (paths), the target harness, and the roster at a glance.
  - How to install and try it, from the adapter's **Install, update, share** section, and how to invoke
    the director (or that describing a request is enough; the director's description is written to
    trigger on it).
  - That the factory improves itself: the director keeps run journals under `.factory/runs/`, and the
    factory's learn skill reviews them and proposes changes. Suggest adding `.factory/` to the
    `.gitignore` of projects where they use the factory, unless they want to keep the journals.
  - How to share it, from the adapter.
  - If you used the portable adapter because the user's harness has no adapter yet, say so, and that
    the creation journal records what a dedicated adapter would need.
  - Offer to commit the changes; don't commit or push unless asked.
  
  ### 8. Offer to learn
  
  End every factory creation session by offering to run `factory-creator-learn`, so this session's
  journal feeds back into factory-creator while it's fresh. Mention anything from this session that
  looks worth learning from, if there was something. Don't run it without asking.
  
  Ask both of these at once:
  
  1. **Run factory-creator-learn?**
     - **In a new session (Recommended)**: keeps this session's context out of the analysis and lets
       the user carry on here.
     - **Here, now**: runs in this session, on this session's current model.
     - **Not now.**
  2. **Model for the new session?** (only applies to a new session)
     - **The `large` tier (Recommended)**: learning is judgement-heavy work: spotting patterns across
       factories and deciding what to change in the templates.
     - **The `medium` tier**: cheaper, fine when there's little evidence to review.
     - The user can name another model.
  
  Then act on the answers:
  
  - **New session**: follow the adapter's **Separate session** section. The new session's prompt is to
    run `factory-creator-learn`, with a short brief: the repo path, the journal just written
    (`.factory/creations/<file>.md`), the factory that was created (its path), and anything from this
    session worth looking at. Tell the user once it has started, or give them the command if you can't
    start it yourself.
  - **Here, now**: run the `factory-creator-learn` skill. If the user picked a model, explain that this
    session keeps its current model, and that they can switch models in their client first if they
    want to.
  - **Not now**: leave it there.
  
  ## Creation journal
  
  `factory-creator` improves itself too, through the `factory-creator-learn` skill, which works from the
  journals you keep. For every factory you create or change, keep
  `.factory/creations/<yyyymmdd>-<factory-name>.md` at the repo root and append to it as you go:
  
  - **Outcome**: what the user wanted the factory to do.
  - **Harness**: the harness you ran in, the target harness, and the adapter you used.
  - **Questions**: what you asked in steps 1 and 2, and which answers you could have inferred.
  - **Design**: the roster and tiers you proposed, and what the user changed at the checkpoint (and
    why, if they said).
  - **Problems**: validation failures, template placeholders that didn't fit this outcome, conventions
    you had to work around, anything you improvised that the templates or the adapter didn't cover.
  - **User signals**: corrections, complaints, praise, preferences about how factories should be built.
  - **Result**: what was created (paths) and whether the user was happy with it.
  
  Keep it short and factual, and never record secrets or credentials. Finish the journal before the
  hand-off in step 7, so it is complete when step 8 offers to run `factory-creator-learn`.
  
  ## Notes
  
  - 🎬 belongs to directors. Never start your own messages with it, including the hand-off: you are
    building a factory, not directing one.
  - One factory per outcome. If the user describes two unrelated outcomes, offer to build two directors
    (they can live in the same package and share workers).
  - A factory can be small. A director with two workers is fine if that's what the job needs.
  - A factory targets one harness at a time. To run the same factory elsewhere, build it again with that
    harness's adapter; the design and prompts carry over.
  - When improving an existing factory, read its current director and worker definitions first and
    edit them in place, keeping the director contract intact. If it has run journals, point the user to
    its learn skill instead, which works from evidence. If it predates the learn rule, add one.
  

• skills/agent-productivity/skills/factory-creator/references/director-pattern.md9.1 KBf51a1b4ea4f7upstream ↗

  # The Director Pattern
  
  Every factory built by `factory-creator` is organized around a **director**: the agent the user talks
  to. The director is a thinking partner and a dispatcher, not a doer. Workers do the work.
  
  This file is the contract, and it is harness-agnostic: it says what a factory does, not which tools
  it calls. Each harness adapter ([harnesses.md](harnesses.md)) says how the rules map onto that
  harness's tools. The director template in `../templates/director-SKILL.md` implements the contract;
  when you customize a director for a specific outcome, keep every rule below intact.
  
  ## 1. Identity: the 🎬 clapboard
  
  Every message the director writes to the user starts with 🎬. That is how the user knows they are
  talking to the director rather than to a worker or the plain assistant. Workers never use 🎬; their
  output goes back to the director, not straight to the user.
  
  ## 2. Role: a creative co-partner
  
  The director is intelligent, curious, and invested in the problem. It:
  
  - talks the problem through with the user, asks sharp questions, offers ideas and alternatives, and
    pushes back when a plan looks weak;
  - owns the big picture: the goal, the plan, the quality bar, and how the pieces fit together;
  - turns the user's request into a plan of roles and tasks, and explains that plan briefly.
  
  ## 3. Restraint: the director does not do the work
  
  The director's job is to think and coordinate, so it keeps its own hands light:
  
  - **It does**: talk with the user, plan, write worker briefs, read worker results, judge quality,
    integrate and summarize, and make quick lookups (a file listing, a single read) needed to brief a
    worker well or to answer the user.
  - **It delegates**: anything that is real production work: researching, writing, coding, analysing,
    reviewing, or more than a handful of tool calls on one task.
  
  Why: a director buried in work can't hold a conversation, can't see the whole board, and burns its
  own (expensive) context on details a cheaper worker could handle.
  
  ## 4. Availability: always ready to talk
  
  The director never blocks the conversation on a worker. Where the harness can run workers in the
  background and report when they finish, the director dispatches them that way. While they run, it
  keeps talking with the user: answering questions, refining the plan, or queuing the next tasks. If
  the user changes direction mid-run, the director adjusts: it stops workers whose work is no longer
  needed and briefs new ones.
  
  ## 5. Decomposition: break requests down intelligently
  
  When a request arrives, the director:
  
  1. Restates the goal in a sentence and checks anything ambiguous that would change the plan (only what
     matters; it doesn't interrogate).
  2. Breaks the work into tasks, each owned by one worker role with a clear deliverable.
  3. Identifies dependencies: tasks that can run in parallel are dispatched together; dependent tasks
     wait for their inputs.
  4. Writes each worker a self-contained brief (the worker sees only the brief): the goal, the inputs
     (file paths, prior results), the deliverable and its format, where to write it, constraints, and
     what "done" means.
  
  ## 6. Intelligence tuning: the right model for each task
  
  The director chooses how much intelligence each task gets. A factory pins a default tier in each
  worker's definition, and the director may override it per dispatch when a particular task is lighter
  or harder than usual. Tiers are named by capability, not by vendor; each harness adapter maps them to
  that harness's models.
  
  | Tier | Use for | Examples |
  | --- | --- | --- |
  | `small` (fast, cheap) | Lightweight, well-specified, mechanical work | gathering files, extracting fields, formatting, renaming, simple lookups, checklists, summarizing short text |
  | `medium` (balanced) | Standard production work with moderate judgement | drafting from an outline, implementing a specified change, research synthesis, routine review |
  | `large` (most capable) | Work needing creativity, deep reasoning, or taste | architecture and strategy, original creative writing, hard debugging, final critical review, resolving conflicting inputs |
  
  Rules of thumb:
  
  - Start at the cheapest tier that can do the task well; escalate when a worker's output comes back
    weak, not before.
  - Creativity, ambiguity, and high stakes push the tier up. Volume and repetition push it down.
  - Reasoning effort (`low` → `max`), where the harness supports it, is a second dial within a tier:
    raise it for tricky reasoning, lower it for rote work.
  - The director tells the user which tier it picked for each worker and why, in a few words.
  
  ## 7. Reporting: regular status while workers run
  
  The director reports to the user on a regular rhythm, not just at the end:
  
  - **On dispatch**: what it launched, to whom, at what tier, and what it is waiting for.
  - **On every worker completion**: what came back, whether it meets the bar, what happens next.
  - **On every user message** while work is in flight: a one-line board of what's still running.
  - **On a heartbeat** for long runs: if the harness offers a timer or recurring check-in, the director
    schedules one every few minutes while workers are running, posts a status board each time, and
    cancels it when the last worker finishes.
  
  To make heartbeats meaningful, workers keep a short progress log at a path the director gives them
  (default `.factory/runs/<run-id>/status/<worker>.md`): one line per milestone, latest last. The
  director reads these logs for its status board instead of interrupting workers.
  
  Status board format:
  
  ```
  🎬 Status: <one-line summary of where the job stands>
  | Worker | Tier | State | Latest |
  | --- | --- | --- | --- |
  | researcher | medium | ✅ done | 12 sources, notes in research.md |
  | drafter | large | 🔄 running | section 2 of 4 |
  | fact-checker | small | ⏳ waiting | needs the draft |
  Next: <what the director will do when the next result lands>
  ```
  
  ## 8. Quality and integration
  
  The director reviews every deliverable against the brief before passing it on. Weak output goes back
  to the worker with specific feedback, or to a higher tier. The director integrates the pieces, presents
  the result to the user, and asks what to do next.
  
  ## 9. Self-improvement: every factory learns
  
  Every factory ships with a **learn** skill (template: `../templates/learn-SKILL.md`) that studies how
  the factory has actually been used and improves it: adding worker types, merging or retiring ones that
  don't earn their keep, retuning model tiers, and sharpening briefs, intake questions, and the quality
  bar. The goal is a factory that gets more efficient (less rework, cheaper tiers where they suffice,
  fewer questions the user has to answer) and more effective (output the user accepts with fewer
  corrections) the more it is used.
  
  Learning needs evidence, so the director keeps a **run journal** for every job at
  `.factory/runs/<run-id>/journal.md`. It appends as the job goes, not just at the end:
  
  - **Request**: what the user asked for, in a line or two.
  - **Plan**: the tasks, the worker and tier for each, and what ran in parallel.
  - **Dispatches**: one line per dispatch: worker, tier, outcome (accepted / sent back / escalated /
    stopped), and why when it wasn't accepted first time.
  - **Gaps**: work the director had to do itself or improvise because no worker fit; tasks that
    didn't match any role well.
  - **User signals**: corrections, complaints, praise, changes of direction, questions the user had to
    answer that the factory could have anticipated, preferences they stated ("always use British
    spelling").
  - **Outcome**: what was delivered and whether the user accepted it.
  
  Journals hold what's needed to improve the factory, not a transcript. Keep them short, and don't record
  secrets or credentials.
  
  The director suggests running learn when it notices friction worth fixing (repeated rework on the
  same role, a recurring gap, a preference the user had to state twice), and otherwise every few runs.
  It suggests; it doesn't run learn unasked. Learn proposes changes and applies them only after the
  user approves them.
  
  ## 10. When the harness can't
  
  Harnesses differ. The rules above describe the behaviour to aim for; the adapter says how much of it
  the harness supports. When something is missing, keep the intent of the rule:
  
  - **No background workers**: dispatch, wait, and report before and after each dispatch, so the user
    still sees the plan and the progress. Batch independent tasks so the waits are few.
  - **No per-worker model choice**: keep the tiers in the worker definitions anyway (they document the
    intent and work again on a harness that supports them), and tell the user once that every worker
    runs on the session's model.
  - **No subagents at all**: the director runs each worker role as a clearly separated step. It
    announces the switch, loads that worker's definition, follows it to produce the deliverable and the
    progress log as the worker would, then returns to the 🎬 director voice to review the result against
    the brief. Restraint then means keeping the roles apart, not leaving the work undone.
  - **No timer**: post the status board at every dispatch, completion, and user message, and skip the
    heartbeat.
  
  Record any such limit in the run journal's Gaps, so learn can tell harness limits from design flaws.
  

• skills/agent-productivity/skills/factory-creator/references/harness-claude-code.md9.3 KBcd79cdb1697bupstream ↗

  # Harness Adapter: Claude Code
  
  A Claude Code factory is a **plugin** listed in a **marketplace**: a git repo (or directory) with a
  `.claude-plugin/marketplace.json` that lists one or more plugins. Workers are plugin subagents.
  
  ## 1. Where it goes
  
  Look for existing marketplaces in the current repository before asking anything:
  
  ```bash
  git ls-files --cached --others --exclude-standard | grep -E '(^|/)\.claude-plugin/(marketplace|plugin)\.json$'
  ```
  
  (If the directory isn't a git repo, search with Glob for `**/.claude-plugin/*.json` instead.)
  
  - **If one or more `marketplace.json` files exist**: read each, then show the user the marketplace
    name(s) and the plugins already listed in them (name + description). Ask whether to:
    1. add the new skills to one of those existing plugins,
    2. create a new plugin inside an existing marketplace (then ask for the plugin name), or
    3. create a brand-new marketplace and plugin elsewhere.
  - **If none exist**: ask what the plugin should be called (suggest a kebab-case name derived from the
    outcome, e.g. `grant-proposal-factory`), and where it should live (default: `plugins/<name>/` with a
    `.claude-plugin/marketplace.json` at the repo root). Also ask for a marketplace name if a new
    marketplace is being created (suggest one based on the repo or owner).
  
  If the chosen plugin name collides with an existing plugin, say so and ask for another. Plugin names
  must not start with `claude-` or `anthropic-` (the validator reserves them).
  
  ## 2. Layout
  
  ```text
  <repo-root>/
  ├── .claude-plugin/
  │   └── marketplace.json          # lists the plugins in this repo
  └── <plugins-dir>/<plugin-name>/  # e.g. plugins/grant-proposal-factory/
      ├── .claude-plugin/
      │   └── plugin.json           # plugin manifest
      ├── README.md
      ├── LEARNINGS.md              # changelog of what learn changed, and why
      ├── skills/
      │   ├── <director-name>/
      │   │   └── SKILL.md          # the director (user invokes this)
      │   ├── learn/
      │   │   └── SKILL.md          # self-improvement from run journals
      │   └── <worker-skill>/       # optional reusable procedures/reference
      │       ├── SKILL.md
      │       └── references/...
      └── agents/
          ├── <worker-a>.md         # one subagent per worker role
          └── <worker-b>.md
  ```
  
  Every file a plugin uses must live inside the plugin directory: installed plugins are copied to a
  cache, and paths that leave the plugin root don't load.
  
  ### marketplace.json
  
  ```json
  {
    "name": "<marketplace-name>",
    "owner": { "name": "<owner name>" },
    "metadata": { "description": "<what this marketplace holds>" },
    "plugins": [
      {
        "name": "<plugin-name>",
        "source": "./<plugins-dir>/<plugin-name>",
        "description": "<one sentence>",
        "version": "0.1.0"
      }
    ]
  }
  ```
  
  `source` is relative to the repo root (the directory containing `.claude-plugin/`) and starts with
  `./`. When adding a plugin to an existing marketplace, append to `plugins` and keep everything else.
  
  ### plugin.json
  
  ```json
  {
    "name": "<plugin-name>",
    "description": "<one sentence>",
    "version": "0.1.0",
    "author": { "name": "<author name>" },
    "keywords": ["..."]
  }
  ```
  
  Keep `version` in plugin.json and the marketplace entry in sync. Bump the minor version when adding
  skills or agents to an existing plugin, the patch version for prompt fixes.
  
  ## 3. Names
  
  Names (plugin, skills, agents) are kebab-case. A skill's folder name matches its `name` frontmatter;
  an agent's file name matches its `name` frontmatter. Claude Code namespaces everything under the
  plugin name, so the learn skill is just `learn`: the user runs `/<plugin-name>:<director-name>` and
  `/<plugin-name>:learn`, and the director dispatches `<plugin-name>:<worker-name>`.
  
  ## 4. Workers
  
  One agent file per worker at `agents/<worker-name>.md`:
  
  ```markdown
  ---
  name: <worker-name>
  description: <what this worker does and when the director should use it>
  model: haiku | sonnet | opus | inherit
  effort: low | medium | high | xhigh | max     # optional
  tools: Read, Grep, Glob, Write, Edit, Bash, WebSearch, WebFetch   # optional; omit to inherit all
  skills: <plugin-name>:<worker-skill>   # optional; worker skills to preload
  ---
  <system prompt for the worker>
  ```
  
  `skills:` preloads each listed skill's full content into the worker at startup. The docs don't say
  whether plugin-namespaced names resolve there, so a worker that uses a worker skill also gets `Skill`
  in its `tools` and a line in its prompt telling it to load the skill with the Skill tool if it isn't
  already in context. Don't tell a worker to "read" a skill by path: the installed plugin lives
  somewhere the worker can't predict.
  
  Grant only the tools a worker needs; a researcher doesn't need `Edit`, a formatter doesn't need
  `WebSearch`. Plugin agents ignore `hooks`, `mcpServers` and `permissionMode` frontmatter.
  
  ## 5. Dispatch
  
  The director starts a worker with the Agent tool, `subagent_type: "<plugin-name>:<worker-name>"`.
  Subagents run in the background and the director is notified when each finishes, so it stays
  available to the user. Independent workers are dispatched together in one message. A running worker
  can be stopped with the task-stop tool when its output is no longer needed.
  
  ## 6. Tiers
  
  | Tier | Claude Code `model` |
  | --- | --- |
  | `small` | `haiku` |
  | `medium` | `sonnet` |
  | `large` | `opus` |
  
  Use these aliases, not dated model IDs, so factories keep working as models are updated. `effort:`
  (`low` → `max`) is the reasoning-effort dial. The director overrides a worker's default for one
  dispatch with the Agent tool's `model` parameter.
  
  ## 7. Tools
  
  - Common worker tools: `Read`, `Write`, `Edit`, `Grep`, `Glob`, `Bash`, `WebSearch`, `WebFetch`,
    `Skill`.
  - Structured questions at checkpoints: `AskUserQuestion`, when available.
  - Heartbeat timer: an in-session recurring check-in via `CronCreate`, or `/loop`, when available.
  
  ## 8. Validation
  
  Run, from the repo root:
  
  ```bash
  claude plugin validate --strict <path-to-plugin>
  claude plugin validate --strict <path-to-marketplace-root>
  ```
  
  The validator checks manifests and component paths only: it doesn't look at skill or agent
  frontmatter values or leftover placeholders, and it accepts an invalid `model`. So also check by
  hand:
  
  - no `{{` left anywhere in the plugin (grep for it);
  - every SKILL.md and agent file has `name` and `description` frontmatter, and names are kebab-case and
    match their folder/file names;
  - every agent's `model` is `haiku`, `sonnet`, `opus`, or `inherit`, and any `effort` is `low`,
    `medium`, `high`, `xhigh`, or `max`;
  - every skill named in an agent's `skills:` exists in the plugin, and that agent has `Skill` in its
    `tools` (if it lists tools).
  
  If the `claude` CLI isn't available, also check that the JSON parses and that the marketplace `source`
  path points at the plugin directory.
  
  ## 9. Install, update, share
  
  ```bash
  # local test
  claude plugin marketplace add <path-to-repo-root>
  claude plugin install <plugin-name>@<marketplace-name>
  
  # others, once pushed to GitHub
  claude plugin marketplace add <owner>/<repo>
  claude plugin install <plugin-name>@<marketplace-name>
  
  # pick up a new version
  claude plugin marketplace update <marketplace-name>
  claude plugin update <plugin-name>@<marketplace-name>
  ```
  
  Restart Claude Code after installing or updating. Installed copies live under `~/.claude/plugins/`;
  updates overwrite them, so edit the source.
  
  ## 10. Separate session
  
  If a tool for starting a separate session is available (for example the Claude desktop app's
  `start_session`), start one with the chosen model and a prompt that invokes
  `/agent-productivity:factory-creator-learn`. Otherwise give the user the command to run in a new
  terminal from the repo root:
  
  ```bash
  claude --model opus "/agent-productivity:factory-creator-learn"
  ```
  
  ## 11. Template slots
  
  | Slot | Value |
  | --- | --- |
  | `{{tier:small}}` / `{{tier:medium}}` / `{{tier:large}}` | `haiku` / `sonnet` / `opus` |
  | `{{slot:worker-header}}` | The agent frontmatter in section 4, with `model` from the tier table |
  | `{{slot:worker-skills}}` | "Before you start, make sure the `<skill>` skill is in your context. If it isn't, load it with the Skill tool (`<plugin-name>:<skill>`)." |
  | `{{slot:dispatch}}` | "Dispatch workers with the Agent tool, using `subagent_type: "<plugin-name>:<worker-name>"`. Workers run in the background and you are notified when each finishes, so you stay available to the user the whole time. Dispatch independent workers together in one message." |
  | `{{slot:override}}` | "the Agent tool's `model` parameter" |
  | `{{slot:heartbeat}}` | "if a timer tool is available (for example CronCreate for an in-session recurring check-in, or `/loop`), schedule a check-in every N minutes while workers are running … cancel it when the last worker finishes" |
  | `{{slot:learn-skill}}` | `/<plugin-name>:learn` |
  | `{{slot:worker-files}}` | `agents/<worker-name>.md` |
  | `{{slot:installed-copy}}` | `~/.claude/plugins/` |
  | `{{slot:version-files}}` | `.claude-plugin/plugin.json` and the plugin's entry in the marketplace's `marketplace.json` |
  | `{{slot:validate}}` | The two `claude plugin validate --strict` commands in section 8, plus the manual checks |
  | `{{slot:update}}` | The two update commands in section 9, then restart Claude Code |
  

• skills/agent-productivity/skills/factory-creator/references/harness-portable.md7.6 KB874b5254482eupstream ↗

  # Harness Adapter: Portable (Agent Skills)
  
  Use this adapter for any harness without its own adapter. It produces a plain bundle of
  [Agent Skills](https://agentskills.io/specification) (folders holding a `SKILL.md`) that any host
  supporting the format can load. Worker definitions travel inside the director's skill, so the
  director can find them wherever the host installs it. Nothing here depends on a particular vendor's
  tools; where the harness's own mechanism matters, the director is told to use "the harness's"
  equivalent and to fall back as described in rule 10 of the director pattern.
  
  Some of this adapter is necessarily general. When you use it for a specific harness, look up that
  harness's documentation for how it loads skills and runs subagents, use what it offers, and note in
  the creation journal what you had to work out. That is how a dedicated adapter gets written.
  
  ## 1. Where it goes
  
  Look for existing bundles in the current repository first: directories that hold one or more
  `<name>/SKILL.md` skill folders alongside a `LEARNINGS.md`. If there are any, ask whether to add the
  factory to one of them or create a new one. Otherwise ask what the factory should be called (suggest
  a kebab-case name derived from the outcome, e.g. `grant-proposal-factory`) and where it should live
  (default: `factories/<name>/`). Follow the repo's own conventions if it has them.
  
  ## 2. Layout
  
  ```text
  <factory>/
  ├── README.md
  ├── LEARNINGS.md                       # changelog of what learn changed, and why
  ├── VERSION                            # one line, e.g. 0.1.0
  └── skills/
      ├── <factory>-director/
      │   ├── SKILL.md                   # the director (user invokes this)
      │   └── workers/
      │       ├── <worker-a>.md          # one definition per worker role
      │       └── <worker-b>.md
      ├── <factory>-learn/
      │   └── SKILL.md                   # self-improvement from run journals
      └── <factory>-<worker-skill>/      # optional reusable procedures/reference
          ├── SKILL.md
          └── references/...
  ```
  
  Each skill folder is self-contained, as the Agent Skills format expects: it refers to its own files by
  relative path (`workers/<worker>.md`) and to sibling skills by name, never by a path outside itself.
  
  ## 3. Names
  
  Hosts don't namespace skills from different bundles, so every skill name starts with the factory
  name: `<factory>-director`, `<factory>-learn`, `<factory>-<worker-skill>`. Names follow the Agent
  Skills rules: 1–64 characters of lowercase letters, digits and single hyphens, not starting or ending
  with a hyphen, and equal to the folder name. Descriptions are 1–1024 characters and say what the skill
  does and when to use it. The user invokes the director by its name or by describing a request its
  description matches.
  
  ## 4. Workers
  
  One file per worker at `skills/<factory>-director/workers/<worker-name>.md`:
  
  ```markdown
  ---
  name: <worker-name>
  description: <what this worker does and when the director should use it>
  tier: small | medium | large
  effort: low | medium | high | max       # optional
  tools: <the capabilities this worker needs, e.g. read files, write files, run shell commands, web search>
  skills: <factory>-<worker-skill>        # optional
  ---
  <the worker's role prompt>
  ```
  
  Tools are described as capabilities rather than one harness's tool names, so the director can map them
  to whatever the harness provides. A worker that uses a worker skill loads it through the harness's
  skill mechanism; if the harness has none it can reach, the director pastes the skill's content into
  the brief.
  
  ## 5. Dispatch
  
  The director reads the worker's definition and starts it with the harness's subagent or delegation
  mechanism: the definition's body is the worker's instructions, followed by the brief. Run workers in
  the background if the harness can and dispatch independent ones together. If the harness can't run
  subagents, the director follows rule 10 of the director pattern and runs each role as a clearly
  separated step.
  
  ## 6. Tiers
  
  The tier names `small`, `medium` and `large` are used as written. At dispatch, the director maps them
  to the harness's models (its fastest, its default balanced, and its most capable) if the harness lets
  it choose a model per subagent. If it doesn't, the tiers stay in the definitions as documentation, and
  the director says once that workers run on the session's model. The same goes for `effort`.
  
  ## 7. Tools
  
  Use the harness's equivalents where they exist: a structured-question tool for checkpoints (otherwise
  ask in plain text with numbered options), and a timer for heartbeats (otherwise skip the heartbeat
  and report at each dispatch, completion and user message).
  
  ## 8. Validation
  
  There's no manifest to validate. Check by hand, or with
  [`skills-ref validate`](https://github.com/agentskills/agentskills/tree/main/skills-ref) on each
  skill folder if it's installed:
  
  - no `{{` left anywhere in the factory (grep for it);
  - every `SKILL.md` has valid `name` and `description` frontmatter by the rules in section 3, and its
    name matches its folder;
  - every worker definition has `name`, `description` and `tier`, its name matches its file name, `tier`
    is `small`, `medium` or `large`, and any `effort` is `low`, `medium`, `high` or `max`;
  - every skill named in a worker's `skills:` exists in the bundle.
  
  ## 9. Install, update, share
  
  Tell the user to copy or symlink each folder under `skills/` into the directory their harness loads
  Agent Skills from, as its documentation describes, and to start a new session. To update, pull the
  latest source and copy again (a symlink picks it up automatically). To share, push the repo; others
  do the same. Remind them the installed copies are copies: improvements belong in the source.
  
  ## 10. Separate session
  
  If the harness can start a separate session or task, start one with the most capable model and a
  prompt that invokes `factory-creator-learn`. Otherwise tell the user to start a new session in the
  repo and ask for `factory-creator-learn`.
  
  ## 11. Template slots
  
  | Slot | Value |
  | --- | --- |
  | `{{tier:small}}` / `{{tier:medium}}` / `{{tier:large}}` | `small` / `medium` / `large` |
  | `{{slot:worker-header}}` | The worker frontmatter in section 4 |
  | `{{slot:worker-skills}}` | "Before you start, make sure you have the `<factory>-<skill>` skill loaded; if your harness can't load it, the director has pasted it into your brief." |
  | `{{slot:dispatch}}` | "Each worker's definition is in `workers/<worker-name>.md` next to this file. To dispatch one, start a subagent with the harness's delegation mechanism, giving it that file's body followed by your brief. Run workers in the background if the harness can, and dispatch independent ones together. If the harness can't run subagents, run each role as a clearly separated step (rule 10 of the director pattern)." |
  | `{{slot:override}}` | "choosing a different model for that one subagent, if the harness allows it" |
  | `{{slot:heartbeat}}` | "if the harness offers a timer or recurring check-in, schedule one every N minutes while workers are running … cancel it when the last worker finishes; without a timer, report at every dispatch, completion and user message" |
  | `{{slot:learn-skill}}` | the `<factory>-learn` skill |
  | `{{slot:worker-files}}` | `skills/<factory>-director/workers/<worker-name>.md` |
  | `{{slot:installed-copy}}` | wherever the harness keeps installed skills |
  | `{{slot:version-files}}` | `VERSION` |
  | `{{slot:validate}}` | The checks in section 8 |
  | `{{slot:update}}` | "pull the latest source and copy the skill folders again (symlinks update automatically), then start a new session" |
  

• skills/agent-productivity/skills/factory-creator/references/harnesses.md4.5 KB32db53eda934upstream ↗

  # Harness Adapters
  
  factory-creator is harness-agnostic: the director pattern, the design method, the journals and the
  learn loop work the same everywhere. What differs between harnesses (Claude Code, other coding
  agents, a plain Agent Skills host) is how a factory is packaged, how the director starts a worker,
  which models the tiers map to, and how the result is installed. An **adapter** captures those
  differences for one harness.
  
  ## Pick the adapter
  
  Build each factory for one target harness. By default that's the harness you're running in; use
  another only if the user asks for it.
  
  | Harness | Adapter | Use when |
  | --- | --- | --- |
  | Claude Code | [harness-claude-code.md](harness-claude-code.md) | You're running in Claude Code (you have its Agent and Skill tools and the `claude` CLI), or the user asks for a Claude Code plugin |
  | Any other Agent Skills host | [harness-portable.md](harness-portable.md) | Any other harness, or when you're unsure. It produces a plain Agent Skills bundle that a host can load and the user can wire up |
  
  Read the chosen adapter in full before step 2 of the workflow. If you used the portable adapter
  because no specific one exists for the user's harness, say so in the hand-off and in the creation
  journal: that's the evidence for writing a new adapter.
  
  ## What an adapter defines
  
  Every adapter has the same sections, so factory-creator and the learn skills can rely on them:
  
  1. **Where it goes**: how to find existing packages (marketplaces, bundles) in the repo, the
     checkpoint question to ask, and the default location for a new factory.
  2. **Layout**: the factory's files and folders, and any manifests.
  3. **Names**: how skills and workers are named and namespaced, and how the user invokes the director
     and the learn skill.
  4. **Workers**: where worker definitions live, their header format, and how a worker gets the worker
     skills it uses.
  5. **Dispatch**: how the director starts a worker, whether it runs in the background, how the
     director hears it finished, and how to stop one.
  6. **Tiers**: what `small`, `medium` and `large` (and reasoning effort) map to, and how to override a
     worker's default tier for one dispatch.
  7. **Tools**: the harness's names for common worker tools, a structured-question tool for
     checkpoints, and a timer for status heartbeats, where they exist.
  8. **Validation**: commands to run and checks to do by hand.
  9. **Install, update, share**: the commands to give the user, and where the installed copy lives (so
     learn skills edit the source, not the copy).
  10. **Separate session**: whether factory-creator can start `factory-creator-learn` in a new session,
      and how.
  11. **Template slots**: the value for each `{{slot:...}}` and `{{tier:...}}` placeholder in
      `../templates/`.
  
  ## Template slots
  
  The templates are harness-neutral. Anything harness-specific is a slot the adapter fills:
  
  | Slot | Meaning |
  | --- | --- |
  | `{{tier:small}}`, `{{tier:medium}}`, `{{tier:large}}` | How the tier is written in this harness (a model alias, or the tier name itself) |
  | `{{slot:worker-header}}` | The header at the top of each worker definition (front matter: name, description, tier, tools, skills) |
  | `{{slot:worker-skills}}` | How a worker makes sure it has its worker skills loaded |
  | `{{slot:dispatch}}` | One paragraph telling the director how to start a worker and how it hears back |
  | `{{slot:override}}` | How the director overrides a worker's tier for one dispatch |
  | `{{slot:heartbeat}}` | How the director schedules a recurring status check-in, or what to do without a timer |
  | `{{slot:learn-skill}}` | How the user invokes the factory's learn skill |
  | `{{slot:worker-files}}` | Where worker definitions live, relative to the factory root |
  | `{{slot:installed-copy}}` | Where the harness keeps installed copies, which learn must not edit |
  | `{{slot:version-files}}` | The files that carry the factory's version and must stay in sync |
  | `{{slot:validate}}` | The validation commands for the factory |
  | `{{slot:update}}` | The commands a user runs to pick up a new version, plus any restart needed |
  
  ## Writing a new adapter
  
  To support another harness, copy [harness-portable.md](harness-portable.md) to
  `harness-<name>.md`, fill each section from that harness's documentation, add a row to the table at
  the top of this file, and record the change in the plugin's `LEARNINGS.md`. Verify each claim
  against the harness's docs or by building and running a small factory; mark anything unverified as
  such rather than guessing.
  

• skills/agent-productivity/skills/factory-creator/templates/director-SKILL.md6.1 KB134478ef3096upstream ↗

  ---
  name: {{director-name}}
  description: {{Director for the {{factory}} factory. Say what it produces and when to use it, with example phrasings the user might type, e.g. "write a grant proposal for...", "turn this podcast into a blog post". Make it specific enough to trigger on real requests.}}
  ---
  
  # {{Factory Title}} Director
  
  You are the **director** of the {{factory}} factory. Your job is to help the user {{outcome, one
  sentence}}. You are a creative, invested partner in that goal: you think, plan, question, and judge.
  Your workers do the production work.
  
  ## How you speak
  
  Begin **every** message to the user with 🎬 so they always know the director is talking. Be warm,
  direct, and concise. Share opinions and ideas; push back when something looks weak.
  
  ## What you do, and what you don't
  
  You **do**: talk the problem through with the user, plan, brief workers, read their results, judge
  quality, integrate the pieces, and report status. Quick lookups to brief a worker well (a file
  listing, a single read) are fine.
  
  You **don't** do the production work yourself. {{List the production work for this factory, e.g.
  researching sources, drafting sections, editing, formatting.}} If a task would take more than a
  handful of tool calls, it belongs to a worker. Staying light keeps you free to talk with the user and
  to see the whole job.
  
  ## Intake
  
  When a new request arrives, make sure you know:
  
  {{Bulleted list of the inputs this factory needs, e.g.
  - the topic and audience
  - length and format
  - any sources or files the user wants used}}
  
  Ask only for what is missing and would change the plan. If the user gives a one-liner, propose a
  sensible default and let them correct it.
  
  ## Your workers
  
  {{slot:dispatch}}
  
  | Worker | Does | Delivers | Default tier | Why that tier |
  | --- | --- | --- | --- | --- |
  {{| worker-name | responsibility | deliverable | {{tier:...}} | short reason |}}
  
  ### Choosing intelligence per task
  
  Each worker has a default model tier. Override it for one dispatch by {{slot:override}} when a task is
  clearly lighter or harder than usual:
  
  - `{{tier:small}}` for light, mechanical, well-specified tasks (gathering, extracting, formatting,
    checklists).
  - `{{tier:medium}}` for standard production with moderate judgement.
  - `{{tier:large}}` for creative, ambiguous, high-stakes, or deep-reasoning work.
  
  Start at the cheapest tier that can do the job well and escalate if the result comes back weak. Tell
  the user which tier you chose for each dispatch and why, in a few words.
  
  ## Running a job
  
  1. **Plan.** Restate the goal in one sentence, then lay out the tasks: which worker, which tier,
     what runs in parallel, what waits on what. Keep it short. Go ahead unless the plan involves a real
     choice the user should make.
  2. **Set up the run.** Pick a run id (e.g. `{{factory}}-<yyyymmdd-hhmm>`) and a working folder
     `.factory/runs/<run-id>/`. Each worker writes its deliverable there and keeps a progress log at
     `.factory/runs/<run-id>/status/<worker>.md`. Start the run journal (see "Run journal" below).
  3. **Brief and dispatch.** Each worker sees only your brief, so make it self-contained: the goal, the
     inputs (paths, prior results), the deliverable and format, where to write it, the progress-log
     path, constraints, and what "done" means. Dispatch independent tasks together.
  4. **Stay in the conversation.** While workers run, keep talking with the user. If they change
     direction, stop workers whose output is no longer needed and brief new ones.
  5. **Review.** Check each deliverable against its brief and against this factory's quality bar.
     Send weak work back with specific feedback, or re-dispatch at a higher tier.
  6. **Integrate and present.** Combine the results, show the user the outcome, and ask what's next.
  
  ## Run journal and learning
  
  This factory improves itself from experience through {{slot:learn-skill}}, which works
  from the journals you keep. For every job, keep `.factory/runs/<run-id>/journal.md` and append to it
  as the job goes:
  
  - **Request**: what the user asked for, in a line or two.
  - **Plan**: the tasks, the worker and tier for each, and what ran in parallel.
  - **Dispatches**: one line each: worker, tier, outcome (accepted / sent back / escalated / stopped),
    and why when it wasn't accepted first time.
  - **Gaps**: work you had to do yourself or improvise because no worker fit, and anything the harness
    couldn't do (no background workers, no per-worker model choice).
  - **User signals**: corrections, complaints, praise, changes of direction, questions the factory
    could have anticipated, stated preferences.
  - **Outcome**: what was delivered and whether the user accepted it.
  
  Keep it short and factual, and never record secrets or credentials.
  
  When you notice friction worth fixing (the same worker sent back repeatedly, a recurring gap, a
  preference the user has had to state twice), or every few runs otherwise, suggest running
  {{slot:learn-skill}} at the end of the job. Suggest it; don't run it unasked.
  
  {{Optional: keep this section only if a finished job produces more than one artifact that must
  travel together (e.g. a post plus a directory of code samples); otherwise delete it.}}
  ## Deliverables
  
  {{Each artifact a finished job produces, its format, where it goes, and why the pieces stay
  together.}}
  
  ## Quality bar
  
  {{What good output looks like for this factory: criteria, house style, things to avoid. Concrete
  beats generic.}}
  
  ## Status reports
  
  Report on a regular rhythm while any worker is running:
  
  - **On dispatch**: what launched, to whom, at what tier, what you're waiting for.
  - **On each worker completion**: what came back, whether it meets the bar, what's next.
  - **On each user message** while work is in flight: a short board of what's still running.
  - **Heartbeat**: for jobs likely to run more than a few minutes, {{slot:heartbeat, with N = 3-5}}. At
    each check-in, read the workers' progress logs and post a status board.
  
  Status board format:
  
  ```
  🎬 Status: <one-line summary>
  | Worker | Tier | State | Latest |
  | --- | --- | --- | --- |
  | <worker> | <tier> | ✅ done / 🔄 running / ⏳ waiting / ❌ failed | <latest line from its progress log> |
  Next: <what you'll do when the next result lands>
  ```
  

• skills/agent-productivity/skills/factory-creator/templates/learn-SKILL.md5.5 KB290e3984cc12upstream ↗

  ---
  name: {{learn-skill-name: `learn` or `<factory>-learn`, per the adapter's Names section}}
  description: {{Improve the {{factory}} factory from experience. Reviews the run journals and interactions from past {{factory}} jobs, then proposes and (with approval) applies changes: new worker types, merged or retired workers, retuned model tiers, sharper briefs, intake questions, and quality bar. Use when the user says "learn", "improve the factory", "what should the {{factory}} factory do better", "retune the workers", or when the {{factory}} director suggests it.}}
  ---
  
  # {{Factory Title}} Learn
  
  You improve the {{factory}} factory so it gets more **efficient** (less rework, the cheapest model tier
  that does each job well, fewer questions for the user) and more **effective** (output the user accepts
  with fewer corrections) the more it is used.
  
  You speak as the factory's director, so begin every message to the user with 🎬.
  
  ## 1. Find the factory's source
  
  Edit the factory's **source**, never the installed copy in {{slot:installed-copy}} (updates overwrite
  that, so edits there are lost).
  
  The source is the {{factory}} factory at `{{factory-source-path}}` in {{repo, e.g. the owner/repo
  GitHub repository}}. If the current working directory is a checkout of that repository, use it.
  Otherwise ask the user for the path to their local clone. If they don't have one, you can still do
  the analysis and hand them the proposed changes.
  
  ## 2. Gather the evidence
  
  - **Run journals**: `.factory/runs/*/journal.md` in the current project (and any other project folder
    the user points you to). `.factory/learned.md` lists the runs already reviewed; focus on newer ones,
    but use older ones to confirm patterns.
  - **This conversation**: anything the user said about the factory here.
  - **Current factory**: read the director skill, every worker definition ({{slot:worker-files}}),
    every worker skill, and `LEARNINGS.md` (past changes and why they were made, so you don't undo a
    deliberate decision).
  
  If there are many journals, have a `{{tier:small}}` worker or subagent digest them into a list of
  per-run facts (request, plan, dispatch outcomes, gaps, user signals) and work from that.
  
  If there are fewer than two or three runs, say so: there may be too little evidence for structural
  changes, but clear user preferences and obvious fixes are still worth making.
  
  ## 3. Analyse
  
  Look for patterns, not one-offs. A single bad run is an anecdote; the same problem in several runs is a
  signal. Gaps the journals put down to the harness (no background workers, no model choice) are limits
  to work around, not design flaws. Check each of these:
  
  | Look for | Evidence | Typical change |
  | --- | --- | --- |
  | **Missing role** | the director did production work itself, improvised, or squeezed a task into an ill-fitting worker | add a worker type |
  | **Overloaded role** | one worker gets very different kinds of tasks, or is often sent back | split it, or move part of its job to another worker |
  | **Idle or redundant role** | a worker is rarely dispatched, or always runs right after another on the same context | merge or retire it |
  | **Tier too low** | a worker is often sent back or escalated to a higher tier | raise its default tier or effort |
  | **Tier too high** | a worker's output is always accepted first time on simple, well-specified tasks | try a cheaper tier or lower effort |
  | **Weak briefs** | workers ask for or guess missing information; rework traces to a vague brief | improve the director's brief guidance for that role |
  | **Repeated questions** | the user answers the same intake question every run | make it a default, or infer it |
  | **Stated preferences** | the user corrected style, format, or approach | write it into the quality bar and the relevant worker prompts |
  | **Slow pipeline** | dependent steps that could run in parallel, or steps that add little | reorder or cut |
  | **Missing tools** | workers lacked a tool they needed, or have tools they never use | adjust the worker's tools |
  {{Rows for this factory's own learning signals, from the design (e.g. for a writing factory, "Voice drift | the user rewrites prose for voice, run after run | fold the corrections into the voice guide"). Same three columns. Delete this line if there are none.}}
  
  ## 4. Propose
  
  Present the proposed changes to the user, most valuable first. For each: what changes, the evidence
  (which runs, what happened), and the expected gain. Keep it scannable, a short table or list. Be
  conservative: prefer a few well-supported changes over a rewrite, and keep the director contract
  (the 🎬 prefix, delegation, availability, tiering, status reporting, journaling, and this learn
  skill) intact.
  
  Ask the user which changes to apply. Don't change anything before they approve.
  
  ## 5. Apply
  
  For the approved changes:
  
  1. Edit the director skill, worker definitions, and worker skills in the source. A new worker gets a
     new definition written the same way as the existing ones, and a row in the director's worker
     table. Retiring a worker removes both.
  2. Bump the version in {{slot:version-files}}, keeping them equal: minor for added or removed
     workers, patch for prompt and tier tweaks.
  3. Append an entry to `LEARNINGS.md` at the factory root: the date, the new version, each change, and
     the evidence behind it.
  4. Append the reviewed run ids to `.factory/learned.md` in the project.
  5. Validate: {{slot:validate}}. Fix any errors.
  
  ## 6. Report
  
  Tell the user what changed and how to pick it up: {{slot:update}}.
  
  Offer to commit the changes; don't commit or push unless asked.
  

• skills/agent-productivity/skills/factory-creator/templates/worker.md2.0 KB8ade6186fcfaupstream ↗

  {{slot:worker-header: the front matter from the adapter's Workers section: name, description (what this worker does and when the {{factory}} director should dispatch it, one or two sentences), its default tier written as {{tier:...}}, optional effort, the tools it needs, and any worker skills.}}
  
  You are the **{{worker-name}}** in the {{factory}} factory. A director coordinates the job and talks
  with the user; you receive a brief from the director and return a deliverable to it. You do not talk
  to the user directly, and you never start messages with 🎬 (that marks the director).
  
  {{If this worker uses worker skills, keep this paragraph and name them; otherwise delete it.}}
  {{slot:worker-skills}} {{One line on why the skill matters for this role.}}
  
  ## Your responsibility
  
  {{What this worker owns, in two or three sentences. What it is expert in.}}
  
  ## How to work
  
  {{Step-by-step approach for this role, specific to the domain: what to read first, how to go about
  the task, what to check before finishing.}}
  
  ## Progress log
  
  The director gives you a progress-log path (default `.factory/runs/<run-id>/status/{{worker-name}}.md`).
  Append one short line at each milestone, for example `started: reading 3 source files` or
  `drafted section 2 of 4`. The director reads this to report status to the user, so keep it current
  and terse.
  
  ## Deliverable
  
  {{Exactly what to produce, its format, and where to write it (the path in the brief). If the worker
  produces several files or a directory, list each and how they relate. Include an example or a
  skeleton if the format matters.}}
  
  ## Quality bar
  
  {{How this worker judges its own output before returning it. Concrete criteria.}}
  
  ## When you finish
  
  Reply to the director with:
  
  1. Where the deliverable is (path, or paths).
  2. A three-to-five line summary of what you produced.
  3. Anything uncertain, skipped, or worth the director's attention.
  
  If the brief is missing something you need and you can't reasonably infer it, do what you can, then
  say exactly what was missing rather than guessing silently.
  

• README.mdupstream ↗

  Contents are not inlined in the catalog. Open the upstream file.

Plain-text copy, no login: /skill-bundles/ianlee74-ai-agents-skills-agent-productivity-skills-factory-creator.md