Make Factory's entry explicit with a coordinator/planning skill for owner-side AI agents #91

Problem

An owner-side personal/planning agent coordinating several applications sent OpenPaperDesign and Claude Bridge work to the AgentOps conversation in the Factory repository as though it were Factory's general entry point. That lead could understand and handle the request, but this bypassed the intended project entry and blurred responsibility.

The owner clarified that capability is not the same as the intended entry. They asked for a reusable Factory coordinator/planning skill that their everyday AI agent can consult whenever it interacts with Factory: how, why and when to use it.

The current README already says each application has its own pinned AgentOps and that Factory's AgentOps develops Factory itself. This is a failure to discover and apply an existing rule, not evidence that every AgentOps instance needs to lose cross-project capabilities. The coordinating caller did not have a Factory skill in its enabled native skill catalogue; distinguish this local adoption/use gap from a missing method rule.

Intended outcome

Provide one small, discoverable entry for an owner-side AI agent using Factory. Consider a Factory entry/coordinator skill, or a thin entry skill referencing the existing canonical methods. Settle its name and placement through normal AgentOps triage; avoid another competing orchestration role or duplicate policy.

It should help the caller:

• Understand Factory's purpose and distinguish the owner's personal/planning agent, each project's AgentOps, Foundation and ADLC. The caller coordinates the owner's goals; each project lead retains its own mandate, workers and acceptance.
• Resolve the actual target project/repository and reuse its existing AgentOps. Factory-method development belongs with Factory's AgentOps. Application work belongs with that application's AgentOps. A genuinely cross-project request is separated into explicit scoped handoffs to the relevant existing leads, with shared dependencies coordinated by the caller.
• Choose the right route for an idea/research request, an accepted task/backlog, a setup or readiness gap, an operational follow-up and a return for human review. Use Foundation when an affected capability needs preparation; do not rerun setup for every task.
• Read the relevant current request, decisions, holds and project/adoption record before effects; recover these after compaction or restart. Resolve the real recipient and native workspace rather than treating a familiar thread title as authority.
• Carry the outcome, current candidate/evidence, decision authority, constraints and next action in a concise handoff. Preserve the owner’s existing admission and delivery delegation. Green review or CI does not grant merge/release permission.
• Distinguish queued, consumed/acknowledged, actually started, blocked and delivered. Reconcile current native state before a retry, correction or new assignment. Continue independently authorized work without duplicate leads or competing writers.
• Surface a genuinely missing owner decision clearly and retain responsibility for following up. The entry skill must not silently acquire host administration, another project's mandate or approval rights.

Easy host and role setup

The intended user journey is: “Help me make this machine a Factory host and explain its role.” The owner's ordinary AI agent should guide and carry out authorized setup without requiring the owner to know Factory's internal skills, manually find thread identities or reconstruct old chat instructions.

Reconcile the actual failure across the Factory method, installation/discovery and the caller's local instructions before selecting a repair. Evaluate a thin Factory plugin bundling the entry skill with the existing Foundation, AgentOps and ADLC skills as one adoption option. Compare it with the existing supported skill installation route for each chosen harness; a Codex-specific plugin is not proof that T3 or another harness can discover it. Keep canonical sources, versioning, reviewed updates and rollback coherent rather than maintaining duplicate skill copies.

Reuse #83 for the actual host setup and coordinator relationship: resolve the host's intended purpose, execution account/harness, clients, existing project leads, permissions, recovery holder, startup/maintenance and appropriate power/display behavior. Explain who plans and coordinates, who owns a project, who executes and who can accept delivery. Apply authorized setup and distinguish configured, running, reachable, resumed and demonstrated useful work. Keep sensitive host identities and paths in the installation record. Surface only genuinely missing owner choices; do routine supported setup autonomously under the existing mandate.

Acceptance

• The normal Factory entry is explicit and easy to discover from the README and native skill installation/adoption route. A caller need not reconstruct it from old chats.
• One canonical skill/entry references the existing AgentOps, Foundation and ADLC sources without copying their policies. It explains when to load each and is useful outside this checkout.
• Existing setup/adoption guidance explains how an owner's ordinary AI agent discovers, loads and reuses this entry on subsequent interactions and after resume. Requested installation, applied installation, discovery and actual use remain separate claims.
• Representative caller behavior demonstrates the correct recipient for Factory development, an existing application's issue and a request spanning two applications; it also handles a missing/stale recipient without silently routing everything to Factory's repository lead or creating duplicate leads.
• The same representative evidence covers an idea versus accepted implementation, a relevant Foundation gap and a human review/delivery decision, preserving concrete delegation and holds.
• The selected packaging and local adoption repair are justified from the observed discovery/use gap. If a plugin is chosen, it exposes the canonical entry and existing methods through supported discovery, with coherent version/update/recovery guidance; unsupported harnesses have an explicit supported skill route.
• A representative ordinary-agent host-setup/resume journey uses Foundation: complete host startup, maintenance and planning-agent setup #83's method, explains and records the selected roles, performs eligible authorized setup, reports real readiness and preserves existing project ownership. This need not repeat unchanged host qualification or interrupt active jobs.
• Independent review checks the exact method candidate and the observed behavior. Metadata checks or a written route alone do not establish that callers use it.

Boundaries and related work

Use the existing Factory AgentOps' normal triage and queue. This issue does not reprioritize or halt already authorized application work, authorize merge/release, or require a new coordinator service, daemon, router, scheduler, dashboard, task database or privileged fourth agent tier.

• Foundation: complete host startup, maintenance and planning-agent setup #83 owns host startup/maintenance and the host coordinator's installation relationship with Foundation. Reuse that record; this issue owns the owner's recurring interaction and entry skill.
• Prove Agent Ops across idea research, assignments and accepted backlog #3 owns the broader project AgentOps proof and existing per-project entry.
• Gør det tydeligt, hvornår en PR kræver menneskelig godkendelse #88 owns the human PR review/approval handoff; reference it rather than introducing another approval system.

Sources: README entry and responsibilities, project AgentOps setup, canonical AgentOps skill.

The duplicate check found related #83 and #3, but no existing issue owning this owner-facing entry skill. Public evidence is intentionally limited to the observed routing failure and desired behavior; private chat, account and machine identities stay in the installation record.