Which Coding Skill Should You Use Next?

Choose the skill for your current task, not for the most ambitious name. Use $talking-us when the product rules are unclear, $write-design-doc when confirmed requirements need an implementation design, and $develop-closed-loop when that design is ready for authorized implementation. Use $test-case for explicit test work, $bug-fixing for an observed failure, and $code-review-multiagent for a read-only review of a concrete diff.

These six Boloop workflows are instruction packages for Codex-style agents. They do not provide a model, browser, test environment, credentials, or permission to act. You can enter at the phase you actually need; running all six is not a requirement.

“I know the goal, but the rules are not settled”

Start with talking-us. Its job is product-requirements discussion: inspect current behavior, distinguish facts from proposals, clarify roles and failure recovery, and maintain requirements and acceptance criteria. The name does not describe a translation or general chat tool.

Bring the goal, actual project, available samples, and the unresolved decisions you own. Expect a requirements document with readiness and open questions. It does not implement code or produce the technical design. Move on when the relevant requirements are confirmed, rather than treating silence as approval.

“The requirements are confirmed; how should we build it?”

Choose write-design-doc. Bring the authoritative requirements, acceptance criteria, repository, and existing contracts. Expect an implementable design covering applicable development, database, API, interaction, recovery, and verification details.

It edits design documents only. Proposed fields are not deployed schema, and an outline is not implementation readiness. Complete-product handoff references material from develop-closed-loop; new-page design conditionally needs the external frontend-design-lab workflow. Resolve missing decisions or dependencies before claiming the corresponding design is ready.

“The design is ready; implement and verify the feature”

Use develop-closed-loop. Bring confirmed requirements, applicable designs, allowed code/test scope, and the required execution environment and data. It coordinates implementation, tests, repair, regression, review, and requirement-level evidence.

Expect actual changes plus a scope-to-evidence record, not a blanket “done.” Implementation, local verification, deployment, and live-path acceptance are separate states. The standalone package is not the full suite: install the companion skills for phases needed. New or substantial UI interaction work conditionally requires external, unbundled frontend-design-lab. The workflow does not authorize deployment or extra features.

“I need cases, a red-test handoff, or acceptance validation”

Choose test-case and name the mode:

• design: create cases and coverage from confirmed rules, without side-effecting acceptance execution
• tdd_handoff: prepare the authorized red-test handoff
• validation: execute authorized checks of existing behavior without adding or changing tests or product code
• closed_loop: coordinate the authorized test-and-repair loop

Bring expected results, REQ/AC references where available, roles, version, data, and permitted side effects. A mode name grants no permission. Expect traceable cases and actual PASS, FAIL, BLOCKED, NOT RUN, or justified N/A results. Missing rules remain questions; mocks, empty test collection, and unexplained skips are not a full-product pass.

“Something already fails; find and verify the repair”

Use bug-fixing. Bring the original entry point, input, expected and actual outcomes, version, logs, and allowed scope. It traces the real failure path, checks related impact, and verifies a minimal repair when repair is authorized.

For diagnosis-only work, say so. The output should connect cause, change, and before/after evidence, plus gaps and rollback. If reproduction is unavailable, the cause may remain provisional; a verified repair still needs a defect-sensitive regression signal. Do not use this workflow to silently decide a new feature's behavior.

“There is a patch; give it an independent review”

Choose code-review-multiagent. Supply the exact baseline and target, current diff, requirements, and existing evidence. It is read-only: it traces callers and checks implementation, requirements, and applicable risk boundaries.

Deep Solo review is the default despite the name. Independent agents are conditional on complexity and host capability. Expect actionable, evidence-backed findings or a scoped no-demonstrable-defects conclusion, with runtime gaps separate. No diff means no candidate implementation review. It does not auto-fix or establish browser usability or deployment from static evidence.

A synthetic example: add export, then investigate a failure

This is an invented planning example, not an executed project or a measured outcome.

An export request with undecided ownership and formats starts in talking-us. Once those rules are confirmed, write-design-doc can specify contracts and recovery. develop-closed-loop can then carry the authorized implementation through tests and review, using the companion workflows it needs. test-case can also be used independently to design coverage before code exists.

If an existing export already fails, enter bug-fixing directly with the original failure evidence. If you only need a read-only assessment of its patch, enter code-review-multiagent directly. The handoff is driven by missing evidence or work, not a mandatory six-stage ceremony.

Before the first invocation

1. Read the chosen package instructions and dependencies. For the collection, preserve the six skill folders and sibling shared folder in the supported local skills directory. For an individual ZIP, keep its internal shared resources intact. Back up same-named installations and avoid duplicates.
2. Confirm that the host supplies the tools the task requires. Real UI acceptance needs a real browser or target application. Package instructions cannot create missing access.
3. State the goal, authoritative sources, allowed changes, environment, data, and forbidden side effects. Invoke the exact $skill-name; install required companion workflows separately.
4. Ask for the artifact, evidence, unresolved decisions, and next action. Do not accept a readiness label without its underlying requirements or verification.

If a required workflow or environment is missing, report that specific dependency and continue only independent work. Do not pretend the absent phase ran. If business rules are missing, return to requirements clarification; if runtime evidence is missing, retain the verification gap.

Where do these skills load? Codex vs Claude Code

These six Boloop packages are instruction workflows for Codex-style agents. They are not a hosted model, a browser, or a permission grant. If you keep the same SKILL.md folders on disk, Codex and Claude Code can both discover Agent Skills–format skills — but the folder path and the way you call a skill by name differ.

Codex (OpenAI docs)

Codex loads repo skills from .agents/skills (scanned from the current working directory up to the repository root) and personal skills from $HOME/.agents/skills. A skill directory needs a SKILL.md with name and description. In the CLI or IDE you can open /skills or type $ to mention a skill; Codex can also pick a skill when the task matches its description. Source: Build skills (OpenAI, read 2026-11-06).

Claude Code (Anthropic docs)

Claude Code skills follow the same open Agent Skills idea. Project skills live at .claude/skills/<name>/SKILL.md; personal skills at ~/.claude/skills/<name>/SKILL.md. You invoke one with /skill-name, or Claude can load it when the request matches the description. The skill body is loaded when the skill is used, not for every turn. Source: Extend Claude with skills (Claude Code docs, read 2026-11-06).

What this means for Boloop’s six skills

• On Codex-style hosts, the article’s $talking-us style names match explicit $ / skill-picker invocation.
• On Claude Code, the same folder name is typically typed as /talking-us (or the frontmatter name), after the files sit under .claude/skills/.
• Sharing one set of files usually means keeping a single skill tree and linking or copying it into the host’s expected directory — identical markdown does not guarantee identical runtime behaviour (tools, hooks, and frontmatter extensions differ).
• Boloop has not claimed a measured pass rate for these six packages inside Claude Code. Treat host differences as configuration facts from the vendors’ docs, not as a Boloop product test.

Common mismatches (pick again)

Match the current blocker, not the most impressive skill name.

• Rules, roles, or failure recovery are still open → start with $talking-us, not $develop-closed-loop.
• Requirements are confirmed but the implementable design is missing → $write-design-doc, not implementation.
• Design exists and the allowed scope is clear → $develop-closed-loop (with companion skills installed for the phases you need).
• You need cases or a red-test handoff before coding → $test-case.
• Something already fails and you need a verified repair → $bug-fixing.
• There is already a patch and you need an independent review → $code-review-multiagent.

If two skills seem to fit, prefer the earlier phase. Skipping clarification does not create authority for implementation.

FAQ

Do I need to run all six skills every time?

No. Enter at the phase you actually need. The six packages are a map, not a mandatory pipeline.

Does installing a skill give the agent credentials or deploy rights?

No. Skills are instruction packages. Credentials, browsers, test environments, and permission to change production stay under your control.

Can I use these on Claude Code the same way as on Codex?

You can place Agent Skills–format SKILL.md folders where Claude Code looks (.claude/skills/…) and invoke them with /name, per Claude Code’s docs. Codex uses .agents/skills and $name / /skills. Behaviour still depends on each host’s tools and settings; this page does not assert that Boloop validated every package on Claude Code.

After implementation, what should I use to accept the change?

Use a separate acceptance pass: map requirements to checks, prove tests can fail, and verify the user-visible path. See [AI-Generated Code Review & Acceptance Checklist](/en/articles/ai-generated-code-acceptance-checklist) and [verify AI-generated bug fixes](/en/articles/verify-ai-generated-bug-fix).

Copy a focused starting request

Illustrative prompt, not an executed case:

“Use $talking-us to clarify this project's export request. Inspect existing roles and export behavior first. Maintain confirmed requirements, acceptance criteria, and unresolved decisions. Do not implement, change data, or choose unresolved business rules for me.”

Replace the goal and scope with your own. For a later phase, choose its exact skill and provide the prerequisites above. A companion request template is available below.

These descriptions reflect the package instructions, not measured reliability across models. Next: select the sentence above that matches your current blocker, open that skill's page, and prepare its inputs.

Download the Markdown template