跳到正文
cccskills
免费在 GitHub 公开

start-job

Top-level orchestrator for Flutter feature implementation. Runs the full uninterrupted pipeline: tasks → implement-tasks-sequence → build-verify → pr-review uncommitted. Use after a PRD and tech spec are complete. Trigger phrases: "start job", "start the job", "run the full pipeline", "do it all", "implement the feature end-to-end".

中文简介正在准备中。当前显示原文说明。

查看安装方法

包含的文件(1)

  • SKILL.md4.8 KB

SKILL.md(原文)

安装前可以查看交给 AI 代理的指令内容。

Flutter Template Start Job

Single entry point that runs the post-spec Flutter implementation pipeline. It is designed to be invoked once, with no user input between phases, so the feature goes from "spec approved" to "verified, uncommitted implementation" in one shot.

Use this only after the PRD and tech spec are finished. If another agent or developer is still editing the tech spec, do not start implementation yet.

Prerequisites

  • PRD exists at .claude/tasks/[feature-name]/prd.md
  • Tech Spec exists at .claude/tasks/[feature-name]/techspec.md
  • The tech spec is complete and no other agent is actively editing it.
  • The current working tree does not contain unresolved conflicts in .claude/tasks/[feature-name]/.

If the PRD or techspec is missing, stop and ask the user to run /prd and/or /techspec first. If the tech spec appears to be in progress, stop and ask the user to confirm it is ready.

Pipeline

Run each phase in order. Do NOT ask for user approval between phases. Do NOT commit anything at any point. If a phase fails hard (cannot proceed), stop and surface to the user.

Critical orchestration rule: when a sub-skill returns control, do not treat its output as the end of your turn. You are still inside this /start-job orchestrator. Immediately invoke the next phase's skill in the same response. Do not stop, do not summarize, do not pause for user input between phases. The only valid stops are: (a) hard failure, (b) the Final Report after Phase 4.

Phase 1 — Task Breakdown

Invoke the tasks skill. It generates tasks.md and individual task files under .claude/tasks/[feature-name]/. No approval prompt.

After tasks returns: do not stop, do not wait for input, do not summarize. Immediately invoke implement-tasks-sequence (Phase 2) in the same response.

Phase 2 — Implementation

Invoke the implement-tasks-sequence skill. It executes all generated tasks in dependency order, parallelizing when safe. No per-task builds, tests, or commits — agents only write code changes.

After implement-tasks-sequence returns: immediately invoke build-verify (Phase 3).

Phase 3 — Build & Test Verification

Invoke the build-verify skill. It runs the Flutter verification suite for this repo: dependency sync, code generation when needed, analyzer, tests, iOS and Android native builds when in scope, and formatting. Fix any failures it surfaces with root-cause changes until everything is green.

After build-verify returns: immediately invoke pr-review uncommitted (Phase 4).

Phase 4 — Standards Review

Invoke the pr-review uncommitted skill. It reviews the actual diff against Flutter template standards after the build/test/analyze gate has passed. Fix any IMPORTANT findings it surfaces outside the review skill, rerun build-verify, and then rerun pr-review uncommitted until no IMPORTANT findings remain, unless the fix needs user judgment.

After pr-review returns cleanly or only leaves accepted follow-up NITs: produce the Final Report. This is the only place the pipeline stops on success.

Final Report

Output a single consolidated summary:

  • Feature name and task count
  • Implementation result (which tasks completed, any that were blocked)
  • build-verify result (✓/✗ per step, with the auto-scope decision repeated)
  • pr-review result (IMPORTANT/NIT counts and any auto-fixed NITs)
  • Reminder: nothing has been committed. The user reviews the diff and commits, or invokes create-pr, on their own terms.

Rules

  • Never commit. The entire pipeline leaves the working tree dirty for the user to review.
  • No intermediate approvals. Uninterrupted execution is the whole point.
  • Do not edit specs. start-job reads PRD and tech spec inputs. It should not rewrite them unless the user explicitly asks.
  • Stop on hard failure. If a phase cannot proceed (missing spec, repeated build failures, an agent reports it cannot implement a task), stop and surface — don't continue on a broken base.
  • Do not re-run phases already completed. If /start-job is invoked on a feature that already has tasks.md, confirm whether to re-generate tasks or pick up from implementation.
  • Implementation standards are reviewed after verification (via /pr-review). Build/test/lint failures are resolved first; standards findings are handled as the final pre-PR review pass.

评价

还没有评价。欢迎分享你的使用感受。

评论

无需登录即可发表。欢迎分享使用感受、提问,或说明在哪些环境下无法运行。

还没有评论。来写第一条吧。

提交后会立即公开。请勿填写邮箱、电话等个人信息。URL 最多 2 个。

0 / 1000 字

此表单受 reCAPTCHA 保护,适用 Google 的隐私权政策和服务条款。

同一仓库的技能

Build/test/lint verification pass for this Flutter app — runs codegen, analyze, test, then iOS + Android native builds in parallel, then `dart format`. Does NOT commit anything; leaves the working tree dirty so the user can review and commit on demand. Used at the end of the prd → techspec → tasks → implement-tasks-sequence flow before `pr-review`, and can also be invoked manually when the user says "verify build", "run full verification", or "check everything".

中文简介正在准备中。当前显示原文说明。

strvcom/flutter-template242026年6月18日 更新

create-pr

免费

Create or update a GitHub PR for this Flutter repository using gh CLI. Verifies the work with build-verify and pr-review, generates an inline PR description, commits pending changes when approved, pushes, and opens or updates the PR. Supports stacked PRs by asking for the base branch when detection is ambiguous. Use when the user says "create PR", "open PR", "push PR", or wants to submit their work for review.

中文简介正在准备中。当前显示原文说明。

strvcom/flutter-template242026年6月18日 更新

Build a full feature in this Flutter repository that includes backend or storage data flow: read API schema, create DTOs, map DTOs to entities, add Riverpod use cases, connect feature state, and render UI data. Use when a task goes beyond a screen and needs real data integration.

中文简介正在准备中。当前显示原文说明。

strvcom/flutter-template242026年6月18日 更新

Create a new Flutter screen in this repository using the existing feature structure, AutoRoute setup, Riverpod state pattern, and code generation workflow. Use when adding a new page, route, stateful screen, or feature folder in this template.

中文简介正在准备中。当前显示原文说明。

strvcom/flutter-template242026年6月18日 更新

implement

免费

Implement a single Flutter task following this repository's Riverpod, Freezed, AutoRoute, DTO/entity, codegen, and verification conventions. Reads the task definition, PRD, and tech spec, then executes the implementation. When invoked standalone, verifies the change; when invoked by implement-tasks-sequence, writes code only and leaves verification to start-job/build-verify. Use when the user says "implement task X", "work on task X", or wants to execute a specific task from the task list.

中文简介正在准备中。当前显示原文说明。

strvcom/flutter-template242026年6月18日 更新

Orchestrates implementation of all tasks for a feature using an agent team. Respects task dependencies, runs tasks in correct order, parallelizes independent tasks. Does NOT build, run tests, or commit at any point — verification is delegated to the caller (typically `/start-job`, which runs `build-verify` and `pr-review uncommitted` afterwards). Use when the user says "implement all tasks", "run the task sequence", "implement the feature", or wants to execute multiple tasks from a task list end-to-end.

中文简介正在准备中。当前显示原文说明。

strvcom/flutter-template242026年6月18日 更新

查看 strvcom 的全部技能

报告此技能的问题