Skip to content

ccf-pipeline-orchestrator

Plan or coordinate CCF research stages, goals, gates, artifacts, and ccfa.yaml state. Use for 任务拆解, 流程规划, project status, end-to-end coordination, and explicitly requested autonomous research, autoresearch, or 自主科研迭代. Coordinate scientific hypotheses, experiments, feedback, and strategy changes within the task budget. Specialist skills own research outputs; scaffolder owns folder/template creation.

1,861
installs
0 up / 0 down, score 0.00
votes
3,214
repo stars
Updated
less than a month ago
In the catalog since
1 Oct 2026
From
mikubaka88/ccfa-skills
Get it through your agent npx skills add mikubaka88/ccfa-skills@ccf-pipeline-orchestrator

Skill instructions

Rendered from the published SKILL.md, 55 lines.

CCF Pipeline Orchestrator

Family File Contract

Before file work, reuse canonical paths and one task/artifact working directory; default to project-root ccfa-workfiles/<purpose>/<artifact-id>/. Update in place, preserve inputs, and use UTF-8 with Chinese-text checks. Apply artifact-contracts.md for naming, ownership, and task-created cleanup; handoffs inherit these paths.

Collaboration Contract

Before specialist execution, read and apply ccf-humanization first, then ccf-common. At every handoff, reuse their applicable active rules or refresh missing/changed ones. Both preflights are required even without prose; detailed editing, experiment, and maintenance modes run only when relevant.

Integrate necessary specialist contributions under one owner; reuse valid prerequisites and verify affected results. Follow the cooperation routes without duplicate reports.

Core Rule

Operate as the project coordinator and workflow planner. Clarify the goal, map the current stage, update or read ccfa.yaml, define gates, and name the next owner skill. Specialist skills own downstream outputs. For a plan-only request, return the plan. For explicitly requested end-to-end execution, coordinate the authorized owners through completion rather than stopping after naming the next skill. Follow ../ccf-common/references/task-modes.md: if the user asks for a short plan, checklist, YAML update, table, or narrative roadmap, use that visible shape instead of forcing a fixed report.

Ensure Humanization and Common are active before planning and every contributing skill. Reuse their applicable rules at handoffs. Apply Humanization's detailed prose modes within authorized writing stages; raw planning and rendering still receive its baseline without a manuscript-edit workflow.

Follow ../ccf-common/references/handoff-modes.md and ../ccf-common/references/artifact-contracts.md. Later user corrections normally steer the active project: preserve valid completed work, update affected requirements, and continue. Do not invent completed stages or automatic background jobs.

For an explicit autonomous-research request, load autonomous-research.md and coordinate the complete authorized loop: scientific objective, candidate mechanism, discriminating experiment, observed feedback, and a supported keep/discard/branch decision. Use actual host tools for execution; a plan or script exit alone is not experimental evidence. The loop may change task-owned research code and search strategies within scope. It does not run for ordinary planning, idea review, or writing, and does not require a new preference switch. Skill-maintenance candidate limits do not cap an explicitly requested research campaign.

Workflow

  1. Identify target venue when relevant, current stage, available artifacts, constraints, deadline pressure, and the user's immediate goal. Distinguish a requested plan, a bounded specialist task, and autonomous research. For the latter, establish its per-run execution contract and remaining budget through references/autonomous-research.md; missing execution inputs block only the dependent run, not hypothesis development or preparation.
  2. Read ccfa.yaml when available; if absent, continue with supplied artifacts. Do not require setup or create project state merely to route work; disclose its absence only when it limits requested tracking.
  3. For unclear projects, use references/workflow-planning/intake-protocol.md, approach-options.md, and design-brief-template.md.
  4. Assign integrating owners using ../ccf-common/references/routing.md. Work backward from the requested outcome to missing prerequisites and material checks, including upstream work not named by the user. Group tightly connected decisions under one owner; skill ownership identifies required expertise, not a separate agent for every stage. Delegate complete questions through the shared handoff rules. Distinguish contributions from next-artifact ownership; carry both active preflights and relevant Humanization modes throughout. Preserve explicit scope limits.
  5. Define each applicable gate through its required evidence, output, pass condition, blocker, and responsible skill. Mark prerequisites satisfied, missing, conflicting, or outside scope; reuse valid ones and resolve missing/conflicting ones before advancing dependent conclusions. Tool completion alone does not pass a gate.
  6. Use ../ccf-common/references/handoff-modes.md and, for long tasks or recovery, ../ccf-common/references/continuity.md: carry the current goal, justified route, evidence/version, canonical paths, work status, and exact next action. Reconcile actual artifacts after lost context before resuming or replaying side effects. Apply explicit user changes and evidence-backed corrections within scope. Update existing ccfa.yaml stage/gate fields only when state maintenance is authorized; preserve unrelated fields and schema. A planning-only request proposes changes without writing.
  7. Integrate specialist results, resolve conflicts against source evidence, and check affected downstream conclusions. Advance gates from actual evidence; preserve valid completed work and continue independent stages around a blocker. Reopen only changed dependencies or unresolved findings. Finish when requested outputs and applicable prerequisites/checks are complete, or identify the precise dependent result that remains incomplete.

Adaptive Output Contract

Put the requested artifact first: roadmap, next-step decision, task list, handoff packet, or ccfa.yaml patch instructions. Use the full structure below only for standard planning, ambiguous multi-stage projects, or when the user asks for a complete coordination report.

For autonomous research, deliver the best supported result or precise unresolved outcome, the mechanisms tried and decision-changing observations, retained artifact/evidence paths, observed resource use, and the stopping reason. Distinguish a completed bounded campaign from a demonstrated scientific claim; a campaign may establish a negative result or leave the goal unresolved. Use the existing task record rather than a report per candidate.

Project goal:
Current stage:
Known artifacts:
Missing artifacts:
Gate decision:
Next owner skill:
Handoff packet:
ccfa.yaml update:
Risks / blockers:

References

  • references/autonomous-research.md: explicitly requested scientific iteration, execution contracts, strategy updates, evidence-based selection, and recovery.
  • references/workflow-planning/: project intake, approach comparison, and design briefs when ordinary planning needs them.