Which coding skill should I use next?

Select a skill based on your current task, not on which name sounds the strongest. Use $talking-us when product rules are unclear; use $write-design-doc when requirements are confirmed and technical design is needed; use $develop-closed-loop when design is ready and approved for implementation. Use $test-case for clear test work, $bug-fixing for existing bugs, and $code-review-multiagent for read-only reviews of specific code differences.

These six Boloop workflows are instruction sets for Codex-type agents and do not provide models, browsers, test environments, credentials, or operational permissions. You can go directly to the stage you truly need, without running all six processes.

“Goal is set, but rules not yet defined”

Start with talking-us. It handles product requirements discussions: checking the status quo, distinguishing facts from proposals, clarifying roles and failure recovery, and maintaining requirements and acceptance criteria. Its name does not indicate translation or general chat tools.

Prepare the goal, actual project, available samples, and issues that need your decision. The output should be a requirements document with ready status and open questions, not implementation code or technical design. Relevant requirements must be confirmed and handed off before being considered approved; silence does not equal approval.

“Requirements confirmed, how to implement specifically?”

Select write-design-doc. Provide authoritative requirements, acceptance criteria, repository, and existing contracts. The expected output is an implementable design covering applicable development, database, API, interaction, recovery, and validation details.

It only edits design documents. The proposed fields are not the deployed structure, and the outline is not equivalent to implementability. The full product handoff will reference relevant materials from develop-closed-loop; new page designs will require external frontend-design-lab under certain conditions. When decisions or dependencies are missing, do not claim that the corresponding design is ready.

“Design ready, implement and validate functionality please”

Use develop-closed-loop. Provide confirmed requirements, applicable design, allowed code and test scope, required execution environment, and data. It coordinates implementation, testing, repair, regression, review, and requirement-level evidence.

The expected output is actual changes and records of scope to evidence, not a general “completed.” Implemented, locally validated, deployed, and online path acceptance are different states. Independent packages are not complete suites and should be accompanied by the required Skills for the respective stages. When creating or significantly modifying UI interactions, external frontend-design-lab may be required under certain conditions and is not included. This workflow does not authorize deployment or addition of functionality.

“Need use cases, red test handoff, or acceptance validation”

Select test-case and specify the mode:

• design：Design use cases and coverage according to confirmed rules, do not execute acceptance with side effects
• tdd_handoff：Prepare an authorized red test handoff
• validation：Perform authorized checks on existing behavior, do not add or modify test and product code
• closed_loop：Coordinate authorized test and repair cycles

Provide expected results, existing REQ/AC references, roles, versions, data, and allowed side effects. The mode name itself does not grant permission. The expected output is traceable use cases and actual PASS, FAIL, BLOCKED, NOT RUN, or justified N/A. Missing rules are kept as open issues; Mock, zero test collection, and unexplained skips do not equal entire acceptance passing.

“Existing bug, need to locate and validate fix”

Use bug-fixing. Provide original entry, input, expected and actual results, version, logs, and allowed scope. It locates issues along the real failure path, checks related impacts, and validates minimal fixes when authorized.

Just state clearly what diagnosis is needed. The output should correspond causes, changes, and before/after evidence, while listing gaps and rollbacks. If the issue cannot be reproduced, the root cause may still be tentative; validation of the fix still requires regression signals sensitive to the defect. Do not use it to quietly decide business rules for new features.

“Existing patch, please review independently”

Select code-review-multiagent. Provide accurate baseline and target, current differences, requirements, and existing evidence. It is a read-only process that tracks the caller, checks implementation, requirements, and applicable risk boundaries.

Despite the name including multiagent, it defaults to an in-depth solo review. Independent agents depend on complexity and host capabilities. The expected output is evidence-based, actionable issues, or a limited scope of “no verifiable defects found,” with runtime gaps listed separately. There can be no review of a candidate implementation without differences. It does not automatically fix, nor can it prove browser usability or deployment success based on static evidence.

Composite example: Add export, then troubleshoot bug

This is a fictional planning example, not an executed project, and there is no data on its effects.

If the ownership and format of the export request are not yet determined, start with talking-us. Once rules are confirmed, write-design-doc defines contracts and recovery; then develop-closed-loop can coordinate authorized implementation, testing, and review, using supporting processes as needed. Code can also be independently designed for coverage using test-case before any code is written.

If the existing export has already failed, bring the original failure evidence directly into bug-fixing. If only a read-only evaluation of a patch is needed, go directly to code-review-multiagent. Handoffs are determined by missing evidence or work, not by a mandatory six-step ceremony that must be completed.

Before the first call

1. Read the instructions and dependencies of the selected package. When installing a collection, retain the relative structure of the six Skill folders and the shared folder at the same level, and place them in the supported local Skills directory; a separate ZIP retains the internal shared resources. Back up same-name installations before overwriting to avoid duplication.
2. Confirm that the host provides the tools required for the task. Real UI acceptance requires a real browser or target application; the instruction package cannot supplement access capabilities.
3. Clearly state the goal, authoritative source, allowed changes, environment, data, and prohibited side effects. Use the accurate $skill-name and install any required supporting processes separately.
4. Request output results, evidence, unresolved issues, and next steps, and do not accept only a ready tag without requirements or validation basis.

When necessary processes or environments are missing, point out the specific dependencies and continue working independently; do not pretend that a missing stage has already been executed. Lack of business rules means returning to requirement clarification; lack of operational evidence means retaining validation gaps.

Copy a focused start request

The following is an example prompt, not actually executed:

“Use $talking-us to clarify the export requirements for this project. First, check existing roles and export behavior, maintain confirmed requirements, acceptance criteria, and unresolved issues. Do not implement, modify data, or decide unconfirmed business rules for me.”

Replace with your goal and scope. When moving to subsequent stages, select the accurate Skill and provide the preconditions from above. The request template is below.

The above introduction corresponds to the instructions in the package and does not represent tested cross-model reliability. Next step: select the sentence that best matches your current blockage, open the corresponding Skill page, and prepare for input.

Download Markdown template