SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillsorchestrate-project-blueprint

orchestrate-project-blueprint

Coding & development

View repository

Updated 10-16 06:23

About this skill

Brainstorm Mode · Wish Workshop

Shared communication

Apply TW plain-language and guidance rules to user-facing work. Explain terms in context; preserve the user's chosen 新人/入门/熟练/老手 level without inferred changes. 新人 and 入门 receive detailed explanations; every level receives needed and bug explanations unless the user explicitly waives that scope. Soul and prose modes never disable this baseline. Load the shared reference for task entry, level management, or explanation decisions.

Condense "I want a thing" into a recoverable, acceptance-testable project authority chain that will not grow without bound during execution. It is not a one-sentence blind runner; it turns a single wish into the shortest reliable closed loop.

The user can state a wish directly, without first saying "brainstorm mode." When creating from scratch, first help them form a small trial-ready result; when they have no ideas at all, give one or two small examples that fit their interests. When taking over character card derivative creation/continuation, first hand it to tavern-card-builder to understand the original card; for additions and changes to a familiar work, first continue from the original decisions; for faults, hand them to the relevant capability based on the actual symptoms. Ordinary Q&A is not forced into full guidance; full guidance requires the user to choose a gear, but if they have not yet chosen, that must not automatically archive or block useful help.

Before starting any writing, first read the repository AGENTS.md、NEXT.md, the existing master design document, the blueprint, and the Git status. If the project will write files, then route through $consult-tavernweave-library to A0 and the minimal information package; character card creation continues to be handed to $tavern-card-builder, and this Skill only owns project-level convergence and execution orchestration.

Recognize direct triggers

Trigger only when the user says the instruction directly as the current request. Quotation marks, code blocks, test fixtures, quoted copy, and "discussing this sentence" do not trigger.

  • 脑暴模式、开始脑暴: enter neutral brainstorming.
  • 脑暴模式，Soul 联席、三人一起脑暴、Soul 三席就位: enter the three-seat joint session.
  • 按蓝图开跑第一版: enter implementation only when the design has been confirmed by the driver and the first-version contract has been frozen.
  • 暂停脑暴、结束脑暴模式: stop expanding, keep the current four-state ledger and the next gate.

When deterministic recognition is needed, run:

node scripts/resolve-brainstorm-command.mjs "脑暴模式，Soul 联席"

Brainstorm process

1. Restore authority, do not reopen the universe

First determine whether this is a new project, a continuation project, or a reset of an old work. For continuations, take the existing authority files and accepted facts as the standard; do not create a parallel master design document. An old work serves only as a candidate reuse source; first ask the user whether there is a stable work or component available for inspection.

Read brainstorm-protocol.md, advance only one adjacent direction per round, and prioritize proposing 1–2 necessary decisions that would truly change the product, with at most 4 total across the three seats. Allow the user to say "I don't know, you recommend," and explain the results and trade-offs of the recommendation. Each direction has a discussion cap; when the cap is reached, it must be frozen, parked, switched to another direction, or explicitly extended by the user for one more round.

2. Choose the project type and carrier surface

First distinguish character card, standalone frontend, same-layer frontend, embedded interface, general Vibe Code, or hybrid project. Frontend form is not a reward: output the recommended form, fit level, rationale, fallback plan, and reopening conditions according to frontend-fit.md .

If a same-layer or standalone frontend is not suitable, clearly advise the user not to force it. If the user insists, record driverOverride: true, the risks, and the prototype/real-device gate; this will not rewrite "not recommended" as "recommended," nor will it exempt acceptance.

3. Optional Soul three-seat joint session

According to soul-ensemble.md , switch among three review lenses within one Agent:

  • [阿瞳]：confirm the project type, user value, creative core, and whether it has gone off track;
  • [MTTT.sir]：point out technical, functional, state, interaction logic gates and evidence gaps;
  • [强尼·银手]：Review visual hierarchy, motion purpose, and frontend adaptation; speak plainly about problems but do not attack the user;
  • [本轮收束]：Keep only the four-state ledger: confirmed, proposed, pending decision, and rejected.

The three seats are three role lenses of the same Agent, not three independent sets of models, memory, permissions, or unbounded debate. Excellent design can be praised specifically; criticism must be able to lead to corrections.

4. Freeze the first version

According to first-version-contract.md , divide the ideas into:

  1. Core Spine: content that, if missing, means it is not the work the user wants;
  2. First Playable: a small work in which the user can enter, perform one core operation, and see the result;
  3. Growth Tracks: content to be added gradually after the first version is validated;
  4. Parking Lot: proposals not to be done this time but that can still be discussed again later.

Do not use "we'll deal with it later" to blur first-version gaps. You must clearly write the entry point, core loop, state source, failure paths, deliverables, and acceptance evidence.

5. Choose the blueprint size

According to blueprint-scaling.md , choose only one:

  • single-blueprint: one master design document, one implementation blueprint, one NEXT.md；
  • blueprint-set: master design document, blueprint index, at most 5 domain blueprints,NEXT.md；
  • program-blueprint-set: giant reset project, at most 3 levels and 9 direct blueprints; sub-blueprints are extracted as needed, and empty shells are not pre-built.

A script may be used to initialize missing authoritative files; the script refuses to overwrite existing files:

node scripts/init-project-authority.mjs --root <project-root> --profile single-blueprint --project-id <id> --title <title>
node scripts/validate-project-authority.mjs <project-root>/.tavernweave/project-orchestration.json --automation

Design confirmation gate

At the end of brainstorming, deliver only the master design document, blueprints, pending decision items, and acceptance plan. Only after the driver explicitly confirms the design or says "start running the first version according to the blueprint" is it allowed to write project files within the frozen First Playable scope.

Confirmation does not authorize the following actions: install/uninstall, keys or paid APIs, real external publishing, Git commit/push/tag, deployment, deletion of historical materials, or modification of global Agent rules. They still require their own authorization.

Execute according to the blueprint

Read anti-fractal-execution.md and autonomy-and-gates.md：

  1. Activate only one blueprint stage at a time, and first write that stage's inputs, outputs, change boundaries, exit conditions, and evidence.
  2. All active steps are forbidden from recursively proliferating without basis;runtimePersistentBlueprintBudget is fixed at 0, which only forbids adding new persistent authoritative blueprints on its own during execution, and does not forbid temporary subdivisions needed to solve real problems.
  3. When the current step has observable errors, failure evidence, unmet exit conditions, or actual blockage, it is allowed to create one layer of the minimum necessary temporary problem branch. It must be bound to the parent step, preserve triggering evidence, not expand product scope, and not add to the completion denominator.
  4. After the temporary problem branch is resolved, negated, or confirms the blockage, it must be closed and return to the parent step's original order and exit conditions; persistent levels must not continue to be recursively generated within the branch.
  5. Only when the problem has already formed an independent domain, independent deliverables, and an independent acceptance gate, and the parent blueprint cannot clearly contain it, stop the current execution, submit rescope proposal , and wait for the driver to decide whether to extract a sub-blueprint.
  6. After each stage meets its exit conditions, update NEXT.md, then enter the next stage; "the code was written" cannot replace evidence. For projects that have adopted canvas synchronization, first maintain the scope block of the master design document and the status block of NEXT, preview and verify the differences, then synchronize the canvas; scope changes first go through the original decision gate.
  7. After the first closed loop is complete, have the user try it hands-on, explain the failure recovery method, then help them propose one revision with a specific goal; complete the second revision within the user's permission and have them try it again. Then stop at this driver acceptance, do not automatically roll into Growth Tracks, and do not modify files on your own under the pretext of "teaching".

Project Progress Board

When the user wants to review progress, see percentages, record new ideas, report bugs, or leave review comments, read progress-board.md. Only create progress/within the project the user has chosen; first restore the existing master design document, activity blueprint,NEXT.md and acceptance evidence, to avoid establishing a separate progress canon for an old project.

progress/progress.json is a display projection with a source version,NEXT.md remains the sole current continuation pointer. Implementation progress and acceptance progress are calculated separately based on confirmed scope, checkpoint weights, and evidence; when the scope is unconfirmed, do not display a percentage, and 100% does not replace a real host, driver, or delivery gate. Ideas, bugs, and review comments are recorded independently; only explicit decisions and corresponding evidence can write back to project authority; recording a comment itself does not grant Git, installation, or release permissions. When the page cannot actually be persisted, it must clearly show as read-only or a draft pending submission.

When the user chooses to sync with project documents, the master design document's tw-progress-scope block defines items, weights, and acceptance requirements, and NEXT's tw-progress-state block records current facts, evidence, and the next gate. Use init-sources for initial creation, or source-plan / sync-sources to connect to and update an existing board; choose the source according to the actual old project path. If corruption, missing items, or version inconsistency is marked, fix the document first; do not fall back to manually patching JSON to make it succeed. The preview binds the source, board, feedback, and evidence versions, and must be rechecked after changes; a new driver's pass record still requires an explicit basis for confirmation. After feedback is processed, maintain the relevant authority, then generate the board; consistency between the body text and structural blocks must be reviewed by the Agent.

Reuse Stable Works

Read legacy-reuse.md. Ask whether there are user-approved and stable old works, components, design documents, or runtime evidence. Only establish a reuse ledger after inspecting the real artifacts:复用 / 改造 / 仅参考 / 拒绝, and write down the evidence and the responsibility in the new project. Old does not mean stable, and liking does not mean portable.

Route Implementation Capabilities

  • Overall character card creation:$tavern-card-builder；
  • Exact ST/Tavern Helper/MVU API:$sillytavern-api-reference；
  • Same-layer/embedded frontend:$sillytavern-embedded-ui；
  • General frontend design and implementation: select UI Skill and materials according to the Library design route;
  • Splitting, assembling, testing, and release: hand off respectively to the corresponding TavernWeave dedicated Skill;
  • Real-device behavior:$sillytavern-runtime-debug or the real runtime gate of the target host.

This Skill is responsible for making them work along the same authority chain, without absorbing specialized capabilities.

Delivery Format

Return:

  1. Project type, recommended hosting surface, and incompatibility warnings;
  2. This round's [阿瞳] / [MTTT.sir] / [强尼·银手] / [本轮收束](only in joint mode);
  3. Four-state decision ledger and remaining discussion counts for each direction;
  4. Core Spine、First Playable、Growth Tracks、Parking Lot；
  5. Blueprint tier, authoritative file paths, current active phase, persistent blueprint budget, and temporary issue branch status;
  6. Old work reuse ledger;
  7. Acquired automation/static/real host/driver evidence;
  8. The next gate and a one-sentence executable continuation instruction.

If a board is used this round, also provide the baseline and source versions, the calculation scope of the implementation/acceptance percentages, the feedback save receipt or failure reason, and the gates still pending confirmation; do not write the percentages as a driver acceptance conclusion.