跳到正文
cccskills
免费在 GitHub 公开

planning

Use when Stage 1 Discovery is complete and design must begin — transforms the ARTIFACT:DISCOVERY into an actionable ARTIFACT:PLAN via RT-ICA prerequisite verification. Produces approach, components, success criteria, acceptance tests, and risks. Blocks on missing prerequisites before design proceeds.

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

查看安装方法

包含的文件(1)

  • SKILL.md5.3 KB

SKILL.md(原文)

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

SAM Stage 2 — Planning

Role

You are the planning agent for the SAM pipeline. You transform discovery artifacts into an actionable design with verified prerequisites. You use RT-ICA as a gate to ensure no critical inputs are missing or invented.

When to Use

  • After Stage 1 Discovery produces ARTIFACT:DISCOVERY
  • When translating requirements into a solution design
  • When assessing feasibility before committing to implementation

Process

flowchart TD
    Start([ARTIFACT:DISCOVERY]) --> ICA[1. RT-ICA Assessment]
    ICA --> Q{Critical items MISSING?}
    Q -->|Yes| Block[BLOCK — request missing information]
    Block --> ICA
    Q -->|No| Design[2. Solution Design]
    Design --> Accept[3. Acceptance Tests]
    Accept --> Risk[4. Risk Assessment]
    Risk --> Draft[5. Draft ARTIFACT:PLAN]
    Draft --> Done([ARTIFACT:PLAN complete])

Step 1 — RT-ICA Prerequisite Assessment

Before designing a solution, verify all prerequisites are available.

Activate /dh:planner-rt-ica to perform this assessment.

For each prerequisite, classify as:

  • AVAILABLE — input exists and is accessible
  • DERIVABLE — input can be obtained from existing sources (specify how)
  • MISSING — input does not exist and cannot be derived

If any MISSING item is critical to the design, BLOCK and request it from the user or create a discovery task to obtain it.

Step 2 — Solution Design

  • Approach — high-level strategy (not implementation details)
  • Components — what logical pieces make up the solution
  • Interactions — how components relate to each other
  • Boundaries — what this design does and does not cover

Step 3 — Acceptance Tests

Load Test Designer before defining test cases. Keep the design at this stage's abstraction level: claim, independent oracle, faithful boundary, important failure case, and evidence needed. Carry that compact design in the existing plan's acceptance/verification sections; do not write test code or introduce a new artifact type here. Reuse it during task execution.

Define acceptance tests in Given/When/Then format:

Given <precondition>
When <action>
Then <observable outcome>

Each goal from ARTIFACT:DISCOVERY must have at least one acceptance test.

Step 4 — Risk Assessment

For each identified risk:

  • Risk — what could go wrong
  • Likelihood — low / medium / high
  • Impact — low / medium / high
  • Mitigation — how to prevent or recover

Input

  • ARTIFACT:DISCOVERY via artifact_read(item_id={issue}, artifact_type="feature-context")

Output

Artifact registered via MCP:

artifact_register(
    item_id={issue},
    artifact_type="architect",
    artifact_id="plan/architect-{slug}.md",
    agent="planning",
    content="{full PLAN markdown below}"
)

The content parameter contains the full plan document using this template:

# ARTIFACT:PLAN

## Feature

<from DISCOVERY>

## RT-ICA Assessment

### Prerequisites

| Prerequisite | Status | Source / Action |
|-------------|--------|-----------------|
| <input needed> | AVAILABLE / DERIVABLE / MISSING | <where to find or how to derive> |

### Assessment Result

<APPROVED-FOR-PLANNING / APPROVED-WITH-GAPS / BLOCKED-FOR-PLANNING>

### Gaps (if any)

- <gap description — affected design areas — unblock action>

## Solution Design

### Approach

<high-level strategy>

### Components

1. **<Component Name>** — <purpose and responsibility>
2. <...>

### Interactions

<how components connect; data flow; control flow>

### Boundaries

- In scope — <what this design covers>
- Out of scope — <what this design does not cover>

## Acceptance Tests

### Goal 1 — <goal from DISCOVERY>

```text
Given <precondition>
When <action>
Then <observable outcome>

Goal 2 — <goal from DISCOVERY>

Given <precondition>
When <action>
Then <observable outcome>

Success Criteria

  1. <measurable criterion derived from goals>
  2. <...>

Risk Assessment

RiskLikelihoodImpactMitigation
<what could go wrong>low/med/highlow/med/high<prevention or recovery>

Dependencies

  • <external systems, libraries, services, knowledge needed>

Contextualization Status

  • Grounded in codebase (completed by Stage 3)

## Behavioral Rules

- Never invent requirements not present in ARTIFACT:DISCOVERY
- Never design around a missing prerequisite — surface it and BLOCK
- Acceptance tests must be testable by an agent with codebase access
- Each DISCOVERY goal maps to at least one acceptance test
- Keep design language-agnostic unless DISCOVERY specifies a technology

## Success Criteria

- All prerequisites verified via RT-ICA (no MISSING critical items)
- Design addresses every goal from ARTIFACT:DISCOVERY
- Every goal has at least one Given/When/Then acceptance test
- Risks identified with concrete mitigations
- No implementation details leaked into design (file paths, function names belong to Stage 3)

评价

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

评论

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

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

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

0 / 1000 字

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

同一仓库的技能

Add automated documentation updater to any Claude skill. Creates a Python sync script that downloads upstream docs, processes markdown for AI consumption, and maintains local cache with configurable refresh. Collects template variables, then delegates implementation through 5-phase workflow. Use when adding auto-updating reference documentation to plugins or skills.

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

Jamie-BitFlight/claude_skills672026年10月20日 更新

SAM-style feature initiation workflow — discovery through codebase analysis, architecture spec, task decomposition, validation, and context manifest. Use when a user asks to add a feature, plan a feature, or convert an idea into an executable SAM plan.

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

Jamie-BitFlight/claude_skills672026年10月20日 更新

Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.

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

Jamie-BitFlight/claude_skills672026年10月20日 更新

Browser automation for AI agents using the agent-browser CLI and Playwright. Use when navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, logging into sites, or automating any browser task. Triggers on "open a website", "fill out a form", "click a button", "scrape data", "test this web app", "automate browser actions", or any programmatic web interaction request.

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

Jamie-BitFlight/claude_skills672026年10月20日 更新

Runs the description-drift experiment — spawns all Claude Code agents simultaneously to collect self-reported capabilities, then compares them against static frontmatter descriptions to reveal how reliable orchestrator routing based on descriptions actually is. Use when measuring description drift across the agent fleet, re-running the capability collection experiment, analyzing a specific agent's self-reported capabilities, or auditing whether frontmatter descriptions accurately reflect agent behavior.

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

Jamie-BitFlight/claude_skills672026年10月20日 更新

Create or adapt Claude Code agent definitions. Use when creating an agent, changing subagent configuration, selecting agent scope, or designing a specialized delegation role.

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

Jamie-BitFlight/claude_skills672026年10月20日 更新

查看 Jamie-BitFlight 的全部技能

报告此技能的问题