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
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:
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-intakecellix-session-statecellix-feature-deliverycellix-phase-reviewcellix-framework-surface-reviewThese should follow the repo’s managed-skill conventions and remain modular.
cellix-feature-deliveryshould 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-tddas 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-tddremains 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.mddiscovery-planner.agent.mdimplementation-engineer.agent.mdqa-reviewer.agent.mdframework-surface-reviewer.agent.mdThese agents must remain thin and role-focused:
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:
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:
.github/copilot-instructions.mdfor durable repo-wide law.github/instructions/*.instructions.mdfor path/class-scoped guidanceAGENTS.mdfor high-level operating norms if useful to the final designThese 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:
orchestration.spec.yamlDo not design the core in a way that forces consumer repos to enumerate all lanes, skills, hooks, and agents manually.
Acceptance criteria
cellix-tddintegrated as a framework-oriented extension pointAGENTS.mdadded if needed by the chosen design