Features
PartialTaskcenter Skills
Reusable procedures for agents
Overview
Skills are durable runtime instructions for repeatable workflows, tool use, design quality, and recovery paths.
Info popup
Entry routes
/app through the composer skill picker and /app/settings?tab=skills for browse and search; governance lives at /admin#skills.
Status
Partial.
Data source
/api/skills/catalog, the runtime skill search/read tools, and the governed Skill Registry.
Required permission
skills:read for discovery, skills:write for future customer mutation, and the existing Admin permissions for governance.
Empty state
no catalog records produces a specific skill empty state while the composer remains usable.
Failure state
the Settings pane offers retry and unavailable skill details stay confined to discovery instead of blocking chat. Personal/team publication, import, sharing, and a public marketplace are not customer-live and must not be implied. Connectors remain authenticated external capabilities under Connections; runtime plugins are a separate internal package inventory.
Steering queue
Entry route
/app.
Status
Live as durable active-run steering with a saved-message fallback.
Data source
the Agent transcript, runtime events, and D1-backed agent_run_steering_messages. A message submitted while a run is active is labeled ‘Queued for the agent — it will read this at its next step’ and changes to ‘Read by the agent at its next step’ only after the durable consumed event arrives. Native turns consume at model-step boundaries; coded website work also consumes after long install, build, and verification commands and re-runs affected gates. Commands are not interrupted mid-command.
Required permissions
the authenticated chat control route and existing thread/project execution authorization.
Empty state
no saved-message panel is shown without fallback messages.
Failure state
if the active run has settled or steering is unavailable, the composer saves the message for a later turn and says that it did so.
What Northstar Is
Northstar is the project-aware orchestration layer inside TaskCenter, not a generic chatbot. It works from project state, retrieved memory layers, planning context, proposals, and recent chat history. It should turn ambiguous requests into concrete next moves, proposals, or escalation paths. It should avoid pretending work shipped, merged, or tested unless the evidence is present.
Memory Layers
TaskCenter should not rely on one long chat. The backend keeps durable project memory that agents can reload. Foundation stores the brief, repo posture, and project intent. Workflow explains how planning, proposal review, and applied state should move. Active Context keeps in-flight tasks, open proposals, and recent user intent.
How Northstar Should Choose Tools
Northstar needs a clear internal tool model so it knows when to inspect, route, plan, or escalate. Screen Read: Understand the current page, active project, visible work state, and thread context before answering. Project Retrieve: Pull grounded project state from memory layers, tasks, proposals, planning contexts, app memory, and recent messages. Evidence Inspect: Check docs, code context, connector state, runtime tool readiness, and execution evidence before claiming something is true.
Stuck Recovery
Northstar should have a rescue path for both user confusion and assistant uncertainty. If the user is blocked, say what screen they are on, what is visible, and what the next action should be. If Northstar lacks evidence, say what is missing and which view, integration, or setting would unblock it. If a task is too broad for a single reply, escalate into a structured run or proposal flow.