SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillscs-roadmap-impl-goal

cs-roadmap-impl-goal

General & other

View repository

Updated 10-15 20:30

About this skill

cs-roadmap-impl-goal

Must-read before starting

Before making any judgment or taking any action, first execute CodeStable preflight: read .codestable/attention.md; if missing, first cs-onboard; do not substitute by reading an external AI entry point (see .codestable/reference/execution-conventions.md）。

Goal

Turn a large requirement into a reviewable, recoverable, auto-advanceable CodeStable roadmap execution package:

  1. First follow the cs-roadmap spec to clarify the requirement and create / update a roadmap, run cs-roadmap-review and process it until it passes.
  2. After the user confirms the roadmap, for each sub-feature in the roadmap items run cs-feat-design, generate design + checklist, run cs-feat-design-review and process it until it passes.
  3. After the user confirms all feature designs, output a directly pasteable /goal instruction.
  4. /goal The session loops through executing each feature in order:cs-feat-impl → cs-code-review → review-fix if necessary → cs-feat-qa → after qa-fix if necessary, rerun review/QA → cs-feat-accept → update status → next feature.
  5. After all features are accepted, do a final audit of the entire roadmap; only print the completion marker if the audit passes.

Note: do not stuff long task bodies into the /goal parameter. Write long protocols and feature execution specs into the roadmap's own directory;/goal only references these files and the termination marker.

Directory conventions

Reuse the directory of cs-roadmap , do not create a separate top-level directory.

Add goal execution files under the existing roadmap directory:

.codestable/roadmap/{slug}/
├── {slug}-roadmap.md
├── {slug}-items.yaml
├── {slug}-roadmap-review.md
├── goal-plan.md          # 本次 goal 执行总览：假设 / 风险 / feature 顺序 / 验证命令
├── goal-state.yaml       # goal 会话实时状态
├── goal-protocol.md      # 从 references/protocol*.md 复制并按 slug 落地
├── goal-protocol-feature-loop.md
├── goal-protocol-gates.md
├── goal-protocol-audit.md
├── goal-audit.md         # goal 会话结束前生成的最终 roadmap 审计报告
└── goal-features/
    └── {feature-slug}.md # 每个 feature 的执行规格，指向 design/checklist

Ordinary features still go in the standard directory:

.codestable/features/{YYYY-MM-DD}-{feature-slug}/
├── {feature-slug}-design.md
├── {feature-slug}-checklist.yaml
├── {feature-slug}-design-review.md
├── {feature-slug}-review.md       # goal 执行时生成
├── {feature-slug}-qa.md           # goal 执行时生成
└── {feature-slug}-acceptance.md   # goal 执行时生成

Two-confirmation gate

This skill must advance through two confirmations and cannot skip them.

First confirmation: roadmap

First complete the cs-roadmap new / update flow, and pass the pre-human-review review gate:

  • Clarify the large requirement's goal, scope, explicit non-goals, and success criteria.
  • Read .codestable/attention.md, related requirements / architecture / compound / history features.
  • Write {slug}-roadmap.md and {slug}-items.yaml。
  • self-check module decomposition, interface contracts, dependency DAG, minimal closed loop, safety net / polish / harden, verification entry points, deliverables, knowledge write-back candidates.
  • Run cs-roadmap-review, if there is blocking / blocked, first revise or wait for the reviewer; do not give the user a roadmap that has not passed the review gate for confirmation.
  • Give the complete roadmap + items.yaml + {slug}-roadmap-review.md to the user for review.

Only after the user explicitly confirms the roadmap, enter the all-feature design phase.

Second confirmation: all feature designs

For each planned sub-feature in the roadmap items, complete the candidate design phase of cs-feat-design one by one in dependency order:

  • Create the feature directory.
  • Write {feature-slug}-design.md, with frontmatter carrying roadmap / roadmap_item, and write the body to disk according to .codestable/attention.md 's report language (default Chinese).
  • Write {feature-slug}-checklist.yaml。
  • Run cs-feat-design-review; when a Task agent is available, every design-review must have an independent reviewer result. Batch-generating multiple features is not a reason to degrade to local-only; when there is blocking / blocked / pending, first revise, wait for the reviewer, or have the user explicitly authorize degradation, and do not enter the user's second confirmation.
  • According to the existing cs-feat-design convention, update the corresponding entry in items.yaml to in-progress and fill in the feature field.
  • design must include: baseline pre-check, mandatory verification commands, deliverables, acceptance scenario evidence types, cleanliness rules, and independently verifiable steps.

Here, cs-feat-design the single-feature overall user review in normal mode is deferred to this skill for unified handling: keep each design as draftfirst, and do not change approvedone by one. cs-feat-design-reviewfor substantive changes. Only after the user explicitly confirms all designs, output /goal。

After the user confirms all designs, first change each {feature-slug}-design.md 's frontmatter status from draft to approved, then generate the goal execution package.cs-feat-impl and cs-feat-accept both require the design to be approved; do not hand a draft design to the goal session.

Generate the goal execution package

Within .codestable/roadmap/{slug}/ , write:

goal-plan.md

Include:

  • roadmap path and items.yaml path
  • feature execution order
  • one-sentence deliverable for each feature
  • nature of each feature: functional / non-functional / mixed
  • roadmap-level core acceptance paths: user / API / CLI / backend / e2e / smoke scenarios that must actually be run; if none, write none and explain why this is a purely non-functional roadmap
  • key assumptions
  • Top 3 risks and mitigations
  • set of mandatory verification commands
  • final aggregated test command set: build / typecheck / lint / unit / integration / e2e / smoke that must be rerun before roadmap completion; purely non-functional roadmaps may substitute static / consistency / schema / documentation checks, but the reason must be stated
  • pre-check strategy
  • DoD Policy、Gate Policy、Provider Policy
  • Provider Policy must state that archguard / meta-cc unavailable records fallback and does not automatically block; provider warnings must be explained by review / QA / audit
  • recovery strategy when verification tools are missing: only test dependencies, lockfiles, or existing runner configuration may be added; do not add same-named shims or fabricate verification results
  • deliverable types that the final audit will verify
  • the final audit must run codestable-goal-consistency-gate.py --roadmap {roadmap-path}
  • the final audit will aggregate goal-evidence-summary, provider warnings, E/C/H summary, and H-only core checks

goal-state.yaml

Before generation, the git baseline must be probed first:

  1. Run git rev-parse --is-inside-work-tree。
  2. When it returns true , run git rev-parse HEAD, and write the resulting SHA into baseline_ref。
  3. When it returns non-git repository,baseline_ref: no-git。
  4. When inside a git repository but HEAD cannot be obtained, stop first and fix the baseline (for example, there are no commits yet), do not write no-git to disguise it as a non-git repository.

Format:

roadmap: "{slug}"
status: ready-to-dispatch
baseline_ref: "{git rev-parse HEAD 或 no-git}"
current_feature_index: 0
features:
  - slug: "{feature-slug}"
    roadmap_item: "{feature-slug}"
    feature_dir: ".codestable/features/YYYY-MM-DD-{feature-slug}"
    design: ".codestable/features/YYYY-MM-DD-{feature-slug}/{feature-slug}-design.md"
    checklist: ".codestable/features/YYYY-MM-DD-{feature-slug}/{feature-slug}-checklist.yaml"
    review: ".codestable/features/YYYY-MM-DD-{feature-slug}/{feature-slug}-review.md"
    qa: ".codestable/features/YYYY-MM-DD-{feature-slug}/{feature-slug}-qa.md"
    acceptance: ".codestable/features/YYYY-MM-DD-{feature-slug}/{feature-slug}-acceptance.md"
    status: pending

current_feature_index is 0-based, pointing to features the next element to process in the array; the first feature must be 0. After each feature is accepted, scoped-commit and confirm the working tree is clean, then add 1. The Feature: N/总数 shown to the user still uses 1-based. If a roadmap item is marked droppedbefore execution, do not write goal-state.features; entries already in goal-state.features must go to accepted or fallback repair.

goal-protocol*.md

From references/protocol.md、protocol-feature-loop.md、protocol-gates.md、protocol-audit.md copy to the roadmap directory, and replace {roadmap-slug} / {roadmap-path} / {roadmap-file} / {items-file} with the actual values for this run. Do not replace <feature-slug> runtime placeholders of this kind; they must be reserved for the goal session to fill in at each feature boundary.

goal-protocol-gates.md is the runtime authoritative entry point for Gate Policy;scope-gate、dod-runner、evidence-pack and other specific scripts are installed by cs-onboard into the project .codestable/tools/. When scripts are missing, first refresh the onboard skeleton; do not treat missing scripts as gate passed.

goal-features/{feature-slug}.md

One per feature, containing:

  • Corresponding roadmap item
  • design / checklist / design-review / review / QA / acceptance paths
  • Dependencies
  • Feature nature: functional / non-functional / mixed
  • Core runtime path: required for functional features; for non-functional features write none + alternative evidence
  • Required commands to run
  • Feature DoD, stage gates, gate input artifacts, failure recovery paths
  • Acceptance evidence
  • Deliverables
  • Cleanliness rules
  • Failure recovery boundaries

Self-check

Output /goal Before that, you must self-check and correct:

  1. Whether roadmap items form a DAG with no circular dependencies.
  2. Whether each item already has a design + checklist.
  3. Whether a roadmap review exists and status: passed, with no unresolved blocking finding.
  4. Whether each item already has a design-review and status: passed, with no unresolved blocking finding, and record that an independent reviewer has been completed or the user has explicitly downgraded it.
  5. Whether each design has been status: approved, and the frontmatter's roadmap / roadmap_item is consistent with items.yaml.
  6. Whether each checklist step is independently verifiable, and the initial steps.status is pending、checks.status is pending。
  7. Whether each feature has required commands to run / baseline risks / deliverables / cleanliness rules.
  8. Whether each goal-feature spec specifies the design-review / review / QA / acceptance artifact paths, as well as the return paths for review blocking / QA failed.
  9. goal-state.yaml Whether it can resume from a breakpoint, and current_feature_index uses 0-based semantics.
  10. goal-plan.md Whether it specifies the roadmap-level core acceptance path, final aggregate test command, non-functional alternative evidence strategy, DoD Policy, Gate Policy, and Provider Policy.
  11. Whether the user has explicitly confirmed the roadmap and all feature designs.
  12. goal-protocol*.md Whether all are under 300 lines, and the roadmap slug has not been mistakenly substituted into feature markers;Feature: lines must use <feature-slug> or the real current feature slug.
  13. If verification commands depend on external test tools, whether the goal-plan / goal-feature spec explains the real runner or dependency installation method; it must not be bypassed by adding a same-named shim such as pytest.py、jest、go .
  14. Whether the final audit can verify each deliverable from repository facts, run the goal consistency gate, and will persist to {roadmap-path}/goal-audit.md。

The goal instruction output to the user

After confirmation passes, read references/goal-command-template.md, replace {slug}, print a fenced /goal, then stop.

Only output the instruction; do not execute it on the user's behalf; the slash command can only be triggered by the user pasting it.

Completion criteria

This skill phase is complete when: the user has received a directly pasteable /goal instruction.

The actual roadmap completion is handled by the goal session and must satisfy:

  • All goal-state features have status accepted
  • All roadmap items are done or have a reason dropped
  • Each feature has a review report, with no unresolved blocking findings
  • Each feature has a QA report, with no unresolved failed / blocked items
  • Each feature has an acceptance report
  • {roadmap-path}/goal-audit.md exists, recording the final aggregated test, roadmap-level core acceptance path, skipped items, re-verified / trust-prior, and conclusion
  • architecture / requirement / roadmap write-back completed
  • Final audit passed
  • Learning reflection done: pitfall / knowledge candidates identified, and the user suggested to run after confirmation cs-keep
  • User has been prompted that they can run cs-docs-neat, sync .codestable/、README/docs、CLAUDE.md / AGENTS.md and agent memory
  • transcript print CS_ROADMAP_GOAL_COMPLETE

Note: the goal session only automatically does learning-point reflection and candidate identification, and does not automatically write .codestable/compound/. Long-term knowledge base archiving must be triggered by the user after confirmation cs-keep, executed according to its own deduplication, refinement, review, and archiving process.

Resources

When writing goal-protocol*.md , read references/protocol.md、references/protocol-feature-loop.md、references/protocol-gates.md、references/protocol-audit.md. When outputting a slash command, read references/goal-command-template.md。