菜单
Capture the technology choices for the project — languages, frameworks, data stores, auth, and key libraries. Stack-neutral; presents options with tradeoffs. Use when the project-builder agent is gathering technology information.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Development workflow using an agent team (Analyst, Challenger, Developer, QA) to implement features, bug fixes, or refactors in a target project folder. Requires a PROJECT_BRIEF.md in the target folder; if missing, invokes project-builder first to generate one. Use BEFORE entering plan mode whenever the user asks for a code change in an external project. MUST be invoked whenever the user asks — even generically — to implement, build, add, fix, refactor, or "use the agents" / "use the team" on a target project, not only for fully detailed requests. If in doubt whether a request warrants this skill, prompt the user rather than silently proceeding solo.
Check whether the current Claude session was launched with --dangerously-skip-permissions. Run `ps aux`, find the claude process, and report yes/no via the command's exit code.
Generate a proper GitHub release description for a target project from the ACTUAL changes since the previous release tag — never by copying the prior release's notes. Produces a bullet-pointed "New features" section (each feature bullet up to 200 words) and a "Bugfixes" section (each bugfix bullet at most 50 words), with every bullet linking to the use case(s) it came from, then writes it to the release. Use whenever a release is cut for a target project (any release tag — a single `vX.Y.Z`, or per-component tags like `<component>-vX.Y.Z`), or standalone to (re)write the notes of an existing release.
Safely wait for and monitor any external-consequence outcome — CI runs, deploys, queue drains, container/service health, files appearing on disk — using the general "pre-flight the polled command, cap the loop, check exit code every iteration" pattern that prevents silent infinite stalls. Documents the reusable `wait_until` wrapper plus a concrete GitHub Actions instantiation (push / tag / PR-triggered runs, terminal-state field vocabularies, log-failed extraction) with every foot-gun that silently breaks polls. Use whenever a Claude run needs to wait for an asynchronous outcome before its next step.
Make a target project's own skills usable in the current session. Reads <TARGET_DIR>/.claude/skills/, symlinks each skill into ~/.claude/skills/ (so Claude Code hot-reloads them on the next turn), and records them in acquired-project-skills.json so the SessionEnd hook can remove them on exit. Invoke this at the START of working in any TARGET_DIR that ships its own .claude/skills/ — including from the project-builder, develop, revise-brief, and define-use-case entry points — or run it standalone to pull in one project's skills. Skips (never clobbers) any name already present in ~/.claude/skills/ or any name that matches a workspace skill.
Capture a single use case for a target project. Collects a free-form description from the user, produces a formalized version (summary, acceptance criteria, pitfalls), runs a clarifying-question loop, and saves the result as an incrementally-numbered Markdown file in the target project's `use-cases/` folder. After saving, offers to define another use case or continue to implementation via the `develop` skill. Use when the user wants to document what the project should do, before or instead of jumping into implementation.
| name | define-technologies |
| description | Capture the technology choices for the project — languages, frameworks, data stores, auth, and key libraries. Stack-neutral; presents options with tradeoffs. Use when the project-builder agent is gathering technology information. |
Settle the core stack before architecture and deployment so later choices line up. Stay stack-neutral: present options with tradeoffs, let the user decide.
Use AskUserQuestion for multi-choice items (storage type, auth approach).
When the user is undecided, sketch 2–3 coherent options with tradeoffs rather than recommending one. These are examples of the kinds of options to offer, not a prescription:
For each option the user expresses interest in, add a one-line tradeoff touching on ecosystem, performance profile, hiring pool, and operational complexity. Do not push a favorite.
constraints (list)runtimes (list)languages (list, each mapped to a runtime)frameworks (list, each mapped to a runtime)data_stores (list of {engine, purpose})auth_strategy (string)external_services (list)ai_ml_dependency (string or "none")Write to PROJECT_BRIEF.md under a ## Technologies heading. Replace any prior ## Technologies section when re-run.
Update these YAML frontmatter fields (see CLAUDE.md for the full schema). Leave every other field untouched:
stack.languages — list of language namesstack.frameworks — list of framework namesstack.runtimes — list of runtime targets (browser, server, mobile, desktop, edge, embedded)stack.versions — map of pinned versions (e.g., {java: "21", gradle: "8.9", spring_boot: "3.3.2"}). When a profile mandates "latest" for a tool, the agent must look up the current version via WebFetch and record it here.stack.data_stores — list of stores with purpose (e.g., "postgres (primary)")build.tool — primary build tool (gradle, maven, npm, pnpm, cargo, uv, etc.)build.commands — map of common invocations (test, lint, format). Use the exact string the dev-team QA and developer should run (e.g., ./gradlew test).