一键导入
simple-dev
Simple development - clarify requirements, draft a plan, checkout a branch, modify files, commit, push, and open a PR
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Simple development - clarify requirements, draft a plan, checkout a branch, modify files, commit, push, and open a PR
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Commit remaining changes, push the branch, open a pull request, and run Codex review
Full development cycle — plan a feature, implement it, and open a PR
Process unhandled PR review comments on the current branch's open PR — answer questions, modify code, or push back
Like /develop, but skips test-writer invocation and post-impl verification (for repos without a test suite — see ADR-014 §12)
Run deep-learning experiments as disciplined hypothesis tests — frame the question, set up a self-contained per-experiment folder, launch training/eval runs (confirming before heavy GPU jobs), track metrics, analyze results against a baseline, and write a human-readable report with tables and plots. Use this whenever the user is doing experimental ML work: launching or preparing a training/finetuning/sampling/eval run, an ablation, or a hyperparameter sweep; saying things like "let's try X and see if it helps," "does this change improve FID/accuracy/loss," "compare these two runs/checkpoints," "track this experiment," "analyze the results," or "write up what we found." Trigger even when the user doesn't say the word "experiment" but is clearly testing whether a change moves a metric, or wants results organized, compared, or reported reproducibly.
Post-merge cleanup — update main, prune the remote, and print one paste-ready block of follow-up commands
| name | simple-dev |
| description | Simple development - clarify requirements, draft a plan, checkout a branch, modify files, commit, push, and open a PR |
| allowed-tools | Agent, Bash, Read, Write, Glob, TaskCreate, TaskUpdate |
| argument-hint | [--no-test] <feature description> |
You are facilitating a simple development task autonomously.
The feature to develop: $ARGUMENTS
Flag check. --no-test is recognized only when it is the first whitespace-delimited token in $ARGUMENTS (e.g., /simple-dev --no-test fix foo). A literal --no-test later in the description is part of the description, not a flag. When the leading-token flag is present, set the no-test mode; spec authoring still happens but the test-writer flow is skipped (see ADR-014 §12).
ToDo List.
Do NOT skip any steps. Follow the checklist below.
Before starting, mirror each top-level checklist item into the task list via TaskCreate. As you work, call TaskUpdate to set each task to in_progress when you begin it and completed when it's done.
main and pull.$ARGUMENTS references a GitHub issue (bare #NNN, NNN, or a github.com/.../issues/NNN URL), fetch the issue's title, body, and comments before asking the user anythingbot/, shell under .claude/hooks/ / .githooks/, runtime scripts under scripts/). Prose-only = markdown / non-runtime config / test-files-only. Default on ambiguity: write the spec.--no-test) Write spec doc — create docs/specs/NNN-<slug>.md using docs/specs/000-template.md. Numbering per docs/specs/README.md. Commit: docs: add spec NNN-<slug>.--no-test) Extract API manifest — uv run python scripts/extract_api.py <target-paths>. Capture stdout. Shell hooks skip this (no Python AST).--no-test) Generate failing tests via test-writer subagent — invoke the Agent tool with subagent_type: test-writer. Use the same prompt template as /develop Phase 2.A step 4 (spec content, language, manifest, target test paths, no-impl-read constraint, paraphrased planner notes). Verify the agent reports all new tests fail. On halt → stop, surface report, wait for user direction. Commit: test: add failing tests from spec NNN-<slug>.--no-test) Write spec doc only — same as above but skip the manifest + test-writer + failing-tests bullets. Spec authoring is NOT skipped under --no-test (per ADR-014 §12).docs: spec → test: failing tests → <feat|fix>: impl, three separate commits. Under --no-test, only docs: spec → <feat|fix>: impl.--no-test, this still runs — only writing new tests is skipped; running existing tests is not.<feat|fix>: <description>.origin main to ensure the local ref is up to date.# ADR-NNN: / # Spec-NNN: header).docs: renumber ADR(s) to avoid collision with main and/or docs: renumber spec(s) to avoid collision with main./run-codex-review review --base main --background/run-codex-review result/resolve-review Bucket Routing — checks branch planning-doc header AND spec file presence on branch or main), classify each Codex finding per the Bucket Routing section of /resolve-review. Apply Sanitization rules before forwarding reviewer text to the test-writer subagent. Ambiguous findings halt /simple-dev and surface to the user. For Behavior-change-bucket findings, follow the three-commit sequence per /resolve-review's Step 4d Behavior-change pattern; the (round 1) suffix attaches to the impl commit only.fix: address codex code review round 1 (single-commit buckets only — Test-only and Internal-impl. Behavior-change uses the three-commit sequence with (round 1) only on the impl commit).
If the review found no issues, proceed.The test-writer reads only the spec and the AST manifest. Any planner notes or reviewer comments forwarded into its prompt MUST be paraphrased first:
bot/, .claude/hooks/, .githooks/, scripts/; line numbers; identifier names that do not appear in the spec.docs: spec edit, then re-run sanitization.No regex sanitizer is mandated — paraphrasing is done by the orchestrator inline. Verbatim reviewer text is never forwarded.