implementation-planning

A planning workflow that turns an approved software specification into decisions, ordered tasks, checks for completion, and a handoff for the developer who will implement it.

In plain words
What is it for?
Use it after a specification is drafted to record decisions, break the work into tasks, define verification checks, and prepare implementation instructions.
Why use it?
It gives coding work a written sequence and agreed decisions before anyone edits code. It also prevents planning from starting while important questions in the specification are unresolved.

Skill for Claude CodeCodex

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add skills/fusebase-dev/fusebase-flow/implementation-planning
Any agent
npx skills add fusebase-dev/fusebase-flow --skill implementation-planning
Clone the repo
git clone --depth 1 https://github.com/fusebase-dev/fusebase-flow

Made for: Claude Code, Codex.

Per session 49 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,378 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00049 $0.02378
Opus 5 $0.00024 $0.01189
Sonnet 5 $0.00010 $0.00476
Haiku 4.5 $0.00005 $0.00238

Measured 2d ago against content hash 09e39f95ae68, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

implementation-planning scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.agents/skills/implementation-planning/SKILL.md · 122 lines

How it starts

The opening of the file, as written. The whole thing — 122 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Implementation Planning

Purpose

Convert a drafted spec into the artifacts an AI Developer session needs to execute: a letter-decision matrix, a numbered task chain, a verification-gate contract, and a saved handoff prompt.

When to invoke

  • Active phase is Plan or Decisions (per FLOW_RULES state announcement)
  • A spec exists at docs/specs/<slug>/spec.md with status DRAFT and clarify questions resolved
  • Operator says "plan this" / "draft decisions" / "let's break this into tasks"

Do not invoke when

  • Spec status is still DRAFT with unresolved clarify questions (re-invoke requirements-specification instead)
  • decisions are locked (decisions.md Lock status: LOCKED) and decisions/tasks already exist (use code-review or validation-and-qa instead)
  • Operator wants to skip planning and start coding directly — STOP. FR-02 (plan before edit) requires written tasks.

Documentation tier gate (FR-23)

Before drafting any planning artifact, apply the tier from flow-skills/documentation-budget/SKILL.md (don't duplicate it). Create each artifact ONLY when its trigger holds:

Artifact Create only when
decisions.md a real decision exists — alternatives with rejection reasons or a locked tradeoff to preserve. No real decision → omit the file (do not write single-option "decisions") and record the literal line no real decisions in spec.md's Clarify summary — greenlight-implement + required-artifacts.yml: optional_when consume it.
tasks.md Tier 3/4 (multi-file Full-lane work). Reference ACs by pointer (spec.md AC1..ACn); do not reprint them.
verification-gate.md Full lane or policies/required-artifacts.yml / policies/gate-contracts.yml requires it for this tier.
implement handoff a fresh AI Developer session will execute the chain. Point to canonical spec/decisions/tasks; do NOT reprint them.

Fail-safe: when unsure, choose the higher tier. Never weaken a safety artifact required by policy to "save docs". (Lightweight-eligible work should not reach this skill — it takes the change-note path in requirements-specification.)

Read the full file on GitHub · 122 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 122 lines · 49 tokens per session scan A 09e39f95ae68

Subscribe to this mod's changes

implementation-planning is a skill published in the GitHub repository fusebase-dev/fusebase-flow (9 stars, last pushed 7d ago), licensed MIT. It adds 49 tokens to every session and 2,378 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.

Related

Other skills, from other repositories

adobe-express-core

Adobe Express environment essentials, two-runtime architecture, project setup, and MCP server configuration. Use when starting add-on development, understanding iframe vs sandbox boundaries, configuring MCP servers, setting up local projects, or validating manifest configuration.

Sandgrouse/adobe-express-dev-skill · 50 tokens

adobe-express-monetization

Monetize Adobe Express add-ons with subscriptions and payments. Use when designing checkout flows, defining subscription tiers, implementing webhook verification, managing entitlements, or securing backend billing logic.

Sandgrouse/adobe-express-dev-skill · 44 tokens

adobe-express-spectrum-ui-ux

Build or review Adobe Express add-on panel UI with Spectrum patterns, stack selection guidance (raw SWC, swc-react, React Spectrum), Express theme setup, state and navigation design, and actionable UX quality checks. Use when implementing or auditing panel layouts, interaction states, multi-screen flows, and…

Sandgrouse/adobe-express-dev-skill · 70 tokens

adobe-express-cors-and-backend

Diagnose and fix CORS errors between Adobe Express add-on UI and backend APIs across local development, private listing, and public listing stages. Use when browser requests fail with preflight, Access-Control-Allow-Origin, Access-Control-Allow-Headers, or OPTIONS issues; when moving from localhost to hosted add-on…

Sandgrouse/adobe-express-dev-skill · 92 tokens

adobe-express-document-manipulation

Create and modify document content in Adobe Express add-ons using Document SDK. Use when planning document operations, inserting shapes/text/media, sequencing sandbox commands, or troubleshooting document edits.

Sandgrouse/adobe-express-dev-skill · 43 tokens

adobe-express-oauth-authentication

Implement OAuth 2.0 and authentication flows for Adobe Express add-ons. Use when connecting to cloud providers (Dropbox, OneDrive, Google Drive), managing tokens, storing credentials, or designing login surfaces.

Sandgrouse/adobe-express-dev-skill · 50 tokens