Project Develop Copilot

Project Develop Copilot

Purpose

project-develop-copilot is the top-level lifecycle router for project development work.

It helps users enter naturally without choosing a child skill first. It decides whether the request should stay lightweight or enter the full project lifecycle, then routes full work into the right stage while preserving scope, lifecycle state, handoff, verification, knowledge sync, artifact sync, dashboard sync, and review.

It does not replace project-query, project-task-dispatch, project-base-init, project-graph-visualize, project-init, project-ingest, project-develop, project-fix, project-finish, or project-review. It owns routing and lifecycle continuity; stage skills own stage execution.

When to Use

Use this skill when the user asks for project development help from natural language, including:

• Finding, explaining, querying, or discussing project .llm-wiki, requirements, bugs, design docs, README files, skills, references, artifacts, or current project status.
• Investigating cross-service or cross-project integration points such as Feign clients, MQTT topics, HTTP/RPC interfaces, shared DB tables, shared config, upstream/downstream services, or external contracts.
• Previewing and distributing a stable design, requirement, discussion, review, test, deployment, or development package across two or more projects without losing the executable source documents.
• Developing a feature, requirement, PRD, design change, implementation plan, or scoped project change.
• Diagnosing or fixing a bug, failed test, runtime error, log symptom, regression, incident, or unexpected behavior.
• Ingesting PRDs, logs, PDFs, URLs, meeting notes, customer feedback, or temporary source material into project context.
• Extracting, distilling, reviewing, or importing historical AI/team chat sessions, transcript files, old conversation summaries, colleague AI discussions, or previous agent handoffs into project .llm-wiki.
• Finishing work, syncing project knowledge, updating progress, preparing handoff, or checking done status.
• Refreshing or updating the static project dashboard/progress page without claiming work is finished.
• Checking, auditing, maintaining, or repairing project .llm-wiki structure, visibility, Flow Records, artifact registry entries, module backlinks, dashboard consistency, logs, links, or safety issues.
• Running LLM Wiki Doctor, scoring .llm-wiki maturity, checking whether project-init produced a useful wiki, diagnosing empty wiki skeletons, or explaining doctor/pre-commit/CI findings.
• Scanning Project Graph candidates through project-graph-candidates-scan.
• Resolving candidates into evidence-backed edge proposals through project-graph-auto-edge.
• Confirming, rejecting, manually registering, or pinning Project Graph edges through project-graph-human-edge.
• Generating, refreshing, rebuilding, previewing, or validating an offline Base Graph / Project Graph interactive HTML through project-graph-visualize.
• Auditing or repairing Project Graph structure through project-maintain.
• Initializing an independent Base Graph repository that coordinates many project-local .llm-wiki directories, including Chinese requests such as 初始化 Base Graph、初始化项目图谱仓库、创建跨项目导航层、注册多项目目录、跨项目总览仓库.
• Reviewing before commit, merge, PR, handoff, release, or broader testing.
• Continuing, resuming, or asking what to do next for previous project work.
• Evaluating whether a project skill flow went wrong, asking for skill-evaluator, conversation self-review, self-review, Dolores, eval gap, failure case, golden case, or lifecycle trace review.

When Not to Use

• Use an ordinary direct answer when the user is not asking about a project, repository, project skill, .llm-wiki, or project lifecycle.
• Use a specialized external skill directly only when the user explicitly wants that skill outside project lifecycle context.
• Do not create lifecycle state for lightweight explanation, file lookup, or design discussion unless the user asks to save or execute the decision.
• Do not route to code implementation when the user says they only want to discuss, inspect, or design.
• Do not claim project work is complete from this router alone.

Owned Gates

The router owns lifecycle coherence across gates:

• Lightweight Boundary
• Context Recovery Gate
• Lifecycle Anchor Gate
• External Bridge Gate
• Session Import Gate
• Finish Sync Gate when the user explicitly asks to refresh dashboard/progress state
• Review & Wiki Integrity Gate when the user reports missing, stale, hard-to-find, inconsistent .llm-wiki state or lifecycle-quality risk
• Cross-Project Dispatch Gate when a stable design spans two or more projects and is ready to split into independently executable task packages

Stage skills own their stage-specific gates, but this router must ensure the next gate is explicit before handing off.

Cross-project evidence is handled as a Context Recovery / External Bridge sub-check, not as a separate lifecycle Gate. Remote wiki/source access must stay read-only and must return through the current lifecycle session.

Cross-Service Project Graph First Rule

When a request mentions cross-service, cross-repository, upstream/downstream, Feign, MQTT, HTTP, WebSocket, API gateway, shared DB, shared configuration, event bus, or two or more registry project ids, inject a Project Graph first step before routing into project-fix, project-develop, or project-query.

The injected step is:

1. Read .llm-wiki/cross-refs/index.md.
2. Read .llm-wiki/project-graph/edges.md.
3. Read .llm-wiki/project-graph/candidates.md when confirmed edges do not cover the relation.
4. Use the graph only to narrow source-reading scope.
5. If graph evidence is missing, stale, draft, or indirect, verify from source before making implementation decisions.

This is a router navigation rule, not a validator guarantee. Do not claim Project Graph was the primary workflow unless the actual trace shows it was used before source exploration.

Cross-Project Task Dispatch Trigger

When a stable design spans two or more projects, proactively offer task distribution instead of waiting for the user to name a child skill. Preserve the original task kind: a discussion or design stays a discussion/design task unless the user chooses development.

Present exactly two clear choices:

• A — Dispatch mode (default): preview and send complete project-specific task packages. Delivery to the target Codex session means dispatch is complete; do not require receipts or manage downstream results.
• B — Development mode: preview and send complete project-specific task packages, then track each child until project-local development, project-local tests, and a local Git commit are complete. Do not push, create worktrees, switch branches, or require cross-project integration tests by default.

If the user asks to distribute tasks without requesting receipts, select Dispatch mode. Resolve each destination by corroborating Base Graph, Project Graph, and Codex Projects. If no matching Codex Project exists, fall back to creating the child task from the current session while setting its working directory to the Base Graph project root.

Always preview the complete split and task packages before creation. Ask for one batch confirmation covering all child tasks; never require one confirmation per project. Route the approved package to project-task-dispatch.

LLM Wiki Discovery Rule

Treat a discovered .llm-wiki/ directory as proof that the project has an LLM Wiki. Do not use .llm-wiki/index.md as the existence sentinel.

When .llm-wiki/index.md is missing, report only that the root index is missing or optional, then continue with available wiki targets such as .llm-wiki/README.md, .llm-wiki/log.md, .llm-wiki/modules/index.md, .llm-wiki/requirements/, .llm-wiki/bugs/, .llm-wiki/sources/, .llm-wiki/working-context/, .llm-wiki/artifacts/index.md, and Project Graph files. Fall back to source only after checking the relevant available wiki entries or when the wiki evidence is insufficient or stale.

Initialization Gate

Run this gate after resolving the business-project root and intended route, but before creating or resuming lifecycle state or invoking a wiki-backed child skill.

• wiki_required_for: full-lifecycle-or-wiki-backed
• on_missing_wiki: route project-init
• excluded_mode: lightweight-answer-or-mechanical-artifact
• missing_wiki_bootstrap_mode: automatic-minimal
• explicit_no_write_missing_wiki: confirm-before-init
• Preserve the original request as pending_intent and the selected route as pending_primary_stage.
• If <project_root>/.llm-wiki/ is absent, stop the pending stage and hand off to project-init with bootstrap_mode: automatic-minimal. Do not create a partial wiki, Change Brief, Bug Brief, routing record, plan, or code change first.
• Automatic minimal bootstrap may write only under <project_root>/.llm-wiki/**; it must defer project-root integrations such as .gitignore, .pre-commit-config.yaml, and .github/workflows/llm-wiki-doctor.yml.
• Keep the bootstrap routing handoff in memory until project-init creates the standard wiki; then persist the routing record in the appropriate lifecycle session.
• Resume the pending stage only when the project-init return handoff identifies a supported next_gate. Initialization Level 1 or 2 alone must not be treated as feature-ready.
• Explicit project-init and project-base-init requests are gate destinations, not inputs to this gate.
• Default read-only behavior of a child stage, including Doctor diagnosis, is not an explicit no-write constraint. Only when the user explicitly says read-only, no writes, do not modify, or equivalent, report the missing wiki and ask before project-init writes; offer a source-only lightweight-answer alternative without losing the pending intent.
• A source-only answer stays lightweight-answer. A clearly source/diff-only review may use the narrow quick-diff-review exception, but it must not claim lifecycle or wiki integrity.

Required First Check

Before doing project work:

1. Decide whether the request is lightweight-answer or full-lifecycle.
2. If lightweight-answer applies, answer from available evidence without creating lifecycle state.
3. If mechanical-artifact applies, route directly to the deterministic child skill without Change Brief, Flow Record, planning, finish sync, or other lifecycle state.
4. If full lifecycle or any wiki-backed route applies, resolve or ask for the project root when it is not obvious.
5. Select the intended primary stage without invoking it.
6. Run the Initialization Gate for business-project full-lifecycle or wiki-backed work.
7. If the gate routes to project-init, wait for its return handoff and keep pending_intent plus pending_primary_stage intact.
8. For full-lifecycle routes, create or resume a Lifecycle Session: Change Brief, Bug Brief, or working-context.
9. Save or update a short routing record for full-lifecycle routes.
10. Invoke one primary stage skill, then select optional external bridge skills only after project scope is known.

Core Process

1. Read references/north-star.md when goals, scope, or lifecycle ownership are unclear.
2. Read references/lifecycle-router.md for routing decisions and routing record format.
3. Classify the user request:
   • lightweight-answer
   • project wiki query / discussion context
   • cross-project lookup / evidence gathering
   • cross-project task dispatch
   • init / ingest
   • historical session extraction / Session Digest import
   • requirement or feature development
   • bug or incident fixing
   • finish or progress sync
   • dashboard refresh
   • review
   • resume
   • evaluator / self-review / Dolores / lifecycle-quality review
4. Recover project context only as much as the route requires.
5. For full lifecycle work, establish the lifecycle session and next gate.
6. Hand off to the primary stage skill with concise scoped context.
7. After the stage returns, make sure the lifecycle still has a next action: verify, sync, review, update dashboard, evaluate flow quality, or stop with a clear limitation.

Mode / Entry Selection

If confidence is low, ask one minimal routing question. Do not start a long intake form.

Routing Tie-breakers

When multiple routes seem plausible, choose the least state-changing route that still satisfies the user:

lightweight-answer < read-only-query < mechanical-artifact < wiki-doctor < dashboard-refresh < wiki-maintenance < cross-project-dispatch < full-lifecycle

Use this quick decision order:

1. No project evidence needed and no write requested -> lightweight-answer.
2. Project evidence needed, but read-only -> read-only-query / project-query.
   • If the evidence crosses another project through Project Graph pins/edges/candidates, use cross-project-lookup and keep remote scope read-only.
3. Only visible dashboard/progress projection requested -> dashboard-refresh / project-query.
4. LLM Wiki Doctor, wiki maturity score, empty wiki skeleton, or doctor/pre-commit/CI finding explanation requested -> wiki-doctor / llm-wiki-doctor.
5. Project Graph candidate scan requested (graph-scan, candidates scan, 自动扫描候选关系, 扫一下 candidates) -> wiki-maintenance / project-graph-candidates-scan.
6. Project Graph auto proposal requested (auto-edge, 自动登记, 生成 edge proposal, 通过 base-graph 找项目类方法但先确认) -> wiki-maintenance / project-graph-auto-edge.
7. Project Graph human confirmation/manual edge requested (human-edge, 手动登记, 确认 proposal, 接受 proposal, 拒绝 proposal) -> wiki-maintenance / project-graph-human-edge.
8. Wiki visibility, broken links, stale indexes, dashboard/card drift, artifact registry drift, Project Graph audit/repair, safety, or consistency requested -> wiki-maintenance / project-maintain.
9. Base Graph repository initialization, adoption, or refresh requested, including Chinese prompts like 初始化项目图谱仓库 or 跨项目导航层 -> full lifecycle / project-base-init.
10. Stable confirmed work spans two or more projects and needs previewed task creation -> cross-project-dispatch / project-task-dispatch.
11. Requirement, bug, source ingest, implementation, finish, verification, handoff, or review readiness requested -> full lifecycle.
12. Process/routing/gate/conversation-flow evaluation requested -> lifecycle-quality.

Natural lifecycle-quality intent is enough. The user does not need to say Dolores or skill-evaluator; phrases like "did this flow go wrong", "review whether the lifecycle drifted", or "评估这次流程是否跑偏" should route to lifecycle-quality. Ordinary review code, continue, finish, bug, and next step stay on normal delivery routes unless the user asks to evaluate the process itself.

No Child Skill Mode

no skills, no child skill, and no lifecycle requests are aliases for lightweight-answer with primary_stage: none.

Use this mode when the user wants a quick answer, a tiny lookup, a lightweight explanation, or a design discussion that should not be saved or executed yet.

In this mode:

• Do not call a child project skill.
• Do not call an external bridge skill.
• Do not create or modify .llm-wiki files.
• Do not create Change Brief, Bug Brief, Flow Record, handoff, artifact registry rows, dashboard updates, or code changes.
• Cite evidence when useful, then answer directly.

Upgrade out of this mode only when the user explicitly asks to save, ingest, plan, execute, fix, review, finish, refresh dashboard, or otherwise update project lifecycle state.

Lifecycle Quality Trigger Phrases

Use lifecycle-quality mode when the user explicitly uses language such as:

• skill-evaluator, evaluator, evaluate this skill, eval gap, failure case, golden case
• self-review, conversation self-review, Dolores, lifecycle trace, routing trace, gate trace
• "这个 skill 为什么跑偏？", "这个流程是不是跑偏了", "先不要直接改，评估一下"
• "review the conversation trace", "did this lifecycle go wrong", "find the smallest patch"

Do not trigger lifecycle-quality for ordinary delivery requests such as "继续", "修 bug", "review 代码", "完成了吗", or "总结一下" unless the user also asks to evaluate the process or review the conversation lifecycle.

Inputs

Possible inputs include:

• user request
• repository path or project root
• PRD/design/log/source paths
• .llm-wiki pages
• Change Brief, Bug Brief, or working-context
• git diff or changed files
• external skill output
• dashboard file or artifact registry

Outputs

For lightweight-answer:

• concise answer
• evidence references when useful
• no lifecycle state changes unless requested

For read-only query:

• answer from .llm-wiki and linked evidence
• Project Context Pack
• related requirements/bugs/sources/artifacts
• possible next routes
• no lifecycle state changes unless requested

For dashboard-refresh:

• recover project dashboard evidence from .llm-wiki
• update only .llm-wiki/dashboard/progress.html and related dashboard artifact metadata/log when needed
• do not mark work done unless finish/verification evidence already exists

For session-context-import:

• brief Session Digest candidate list first
• user selection of items to keep
• Session Digest Markdown draft before .llm-wiki writes
• confirmation question before writing .llm-wiki/session-digests/
• no requirement, bug, Flow Record, dashboard, scope, or project-truth update by default
• optional Lifecycle Promotion candidates only when the user asks to promote selected digest items
• imported digest path after approval

For cross-project-dispatch:

• verified destination mapping from Base Graph, Project Graph, and Codex Projects
• complete shared baseline plus one executable project task specification and handoff per destination
• preview before task creation
• one batch confirmation
• Dispatch mode by default; Development mode only when the user explicitly requests receipt tracking

For full lifecycle:

• routing decision
• lifecycle session path or recovery summary
• active source/scope summary
• selected primary stage
• optional secondary bridges
• next gate

Context Handoff

When handing off to a child stage skill or external bridge, use a short structured handoff:

## Context Handoff

- project_root:
- lifecycle_session:
- user_intent:
- pending_intent:
- pending_primary_stage:
- active_sources:
- active_scope:
- read_only_scope:
- candidate_scope:
- excluded_scope:
- current_gate:
- requested_stage_or_bridge:
- bootstrap_mode:
- constraints:

Do not include long reasoning. Include only enough context for the next skill to act safely.

Return Handoff

When a child stage or external bridge returns, fold the result back into lifecycle state:

## Return Handoff

- stage_or_bridge_used:
- result_summary:
- changed_assumptions:
- recommended_scope_changes:
- artifacts:
- verification_notes:
- lifecycle_updates_needed:
- next_gate:

If the returned result suggests new scope, new sources, changed acceptance criteria, or missing verification, route to the correct gate before proceeding.

Boundaries

• Lightweight-answer and read-only query must not create Change Brief, Bug Brief, dashboard updates, or code changes by default.
• mechanical-artifact routes such as project-graph-visualize may write only their declared artifact output and must not create lifecycle documents, plans, finish-sync records, or commits unless the user explicitly asks.
• Full lifecycle work must not call external implementation/debugging/planning skills before project scope is established.
• Cross-project dispatch must not replace executable source documents with summary-only handoffs, create worktrees, switch branches, or push commits by default.
• External skills are bridges, not lifecycle owners.
• Completion claims must go through verification, knowledge sync, artifact sync, dashboard sync when enabled, and review as appropriate.
• Evaluator and Dolores are non-blocking by default unless the user explicitly asks to enter improvement mode or review finds high-risk process failure.
• .llm-wiki stores indexes, summaries, relationships, status, and gaps; it is not a raw document warehouse.

Common Mistakes

• Forcing lightweight design discussion into full lifecycle.
• Letting users choose child skills manually when natural routing is possible.
• Asking for one confirmation per child task instead of one batch confirmation after preview.
• Jumping into systematic-debugging, planning, TDD, or execution before scoped project context exists.
• Creating duplicate Change Briefs or Bug Briefs instead of resuming existing sessions.
• Treating dashboard state as a source of truth instead of evidence-backed summary.
• Answering "why can I not see this wiki document" as a plain query when the underlying issue is missing artifact, module, dashboard, or log visibility.
• Declaring project work done from the router without finish/review gates.
• Running evaluator or Dolores on every normal task and making the workflow feel heavy.