Skip to content

Implement portable orchestration core (skills, agents, instructions) #220

@nnoce14

Description

@nnoce14

Summary

Implement the portable, reusable pieces that execute the orchestration model.

Why

The spec is the control plane; the core must deliver thin, profile-driven agents and skills that remain portable across Cellix-based repos.

The core must work for:

  • mixed framework+app repos
  • framework-only repos
  • application-only repos

without baking current CellixJS folder names or namespaces into the behavior model.

Scope

New core skills

Create the following new skills in .agents/skills/:

  • cellix-task-intake
  • cellix-session-state
  • cellix-feature-delivery
  • cellix-phase-review
  • cellix-framework-surface-review

These should follow the repo’s managed-skill conventions and remain modular.

cellix-feature-delivery should be the standard application-development TDD and bounded delivery workflow.
It should not absorb framework-contract responsibilities that belong to cellix-tdd.

Existing framework-oriented skill

Integrate existing cellix-tdd as a framework-oriented extension point.

This task must not recreate cellix-tdd.
It must treat it as a profile/lane-specific skill that becomes available only when reusable framework work is supported and selected.

cellix-tdd remains focused on framework contract development and public framework surface expectations rather than general application delivery.

Core custom agents

Create the following thin custom agents in .github/agents/:

  • senior-orchestrator.agent.md
  • discovery-planner.agent.md
  • implementation-engineer.agent.md
  • qa-reviewer.agent.md
  • framework-surface-reviewer.agent.md

These agents must remain thin and role-focused:

  • the orchestrator owns classification, bounded planning, delegation, gating, and escalation
  • the planner owns repo-truth gathering
  • the implementation engineer owns bounded execution
  • the QA reviewer owns review/gate responsibilities
  • the framework-surface reviewer focuses on reusable framework public-surface scrutiny

Framework-surface reviewer behavior must only become relevant where the repo profile and selected lane permit it.

State-machine-aware agent design

Agent definitions must assume enforced orchestration phases rather than relying only on prompt convention.

They must be designed to cooperate with:

  • phase-based orchestration
  • phase-specific role validity
  • hook-enforced transitions
  • denial/retry/replan flows

For application-delivery lanes, the Planner → Implementor → Reviewer pattern is a valid baseline.
Cellix may extend that baseline with framework-surface review where required.

Instruction layers

Implement the layered instruction model:

  • expand .github/copilot-instructions.md for durable repo-wide law
  • add .github/instructions/*.instructions.md for path/class-scoped guidance
  • add AGENTS.md for high-level operating norms if useful to the final design

These layers must support the orchestration spec rather than compete with it.

Consumer experience requirement

The portable core must assume that downstream repos should only need:

  • a small orchestration.spec.yaml
  • standard file layout
  • optional overrides when deviating from defaults

Do not design the core in a way that forces consumer repos to enumerate all lanes, skills, hooks, and agents manually.

Acceptance criteria

  • 5 new skills created
  • existing cellix-tdd integrated as a framework-oriented extension point
  • 5 thin custom agents created
  • agents are designed for enforced phase/state orchestration
  • repo-wide instruction layer refined
  • path/class-scoped instruction layer added
  • AGENTS.md added if needed by the chosen design
  • portable core works for mixed, framework-only, and application-only repo profiles
  • skills and agents reference the orchestration model for behavior
  • no hardcoded dependency on current CellixJS namespaces exists in the core workflow logic

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status

    No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions