Implementation Planner

Turn a feature idea into a concrete technical implementation plan.

Security Scan

The skill is an instruction-only implementation-planning helper whose requested resources and runtime instructions match its stated purpose and show no signs of hidden behavior.

Purpose & Capability

Name/description (produce implementation plans) align with the SKILL.md steps and outputs. There are no unexpected binaries, env vars, or config paths requested that would be unrelated to producing design plans.

Instruction Scope

The SKILL.md outlines deterministic, scoped steps (success criteria, modules, data flow, validation, rollout) and example outputs. It does not instruct the agent to read local files, access environment variables, call external endpoints, or exfiltrate data.

Install Mechanism

No install spec and no code files — instruction-only skill. This minimizes disk write/execution risk and is appropriate for a planning/authoring skill.

Credentials

The skill declares no required environment variables, credentials, or config paths. That is proportional for a non-executing, authoring-focused skill.

Persistence & Privilege

always is false (not force-included) and autonomous invocation is the platform default; the skill does not request elevated persistence or to modify other skills' configuration.

Assessment

This skill appears coherent and low-risk: it only contains authoring instructions for producing implementation plans and requests no credentials or installs. Before installing, confirm the publisher identity (registry owner ID differs from the in-file author metadata), and if you plan to allow autonomous invocation, ensure the agent's permissions and logs are acceptable. If you need stronger assurance, ask the publisher for provenance (a homepage or repo) or run the skill in a restricted/test agent first. If future versions add scripts, downloads, or environment access, re-evaluate immediately.

SKILL: implementation-planner

Purpose

Convert a feature idea into a concrete technical execution plan (architecture, modules, interfaces, validations, and rollout).

When to Use

• The request requires design decisions before code.
• Multiple components must be coordinated (frontend/backend/infra/contracts).
• The user asked for an “implementation plan” or “architecture”.

Inputs

• feature_description (required, string): what to build and why.
• constraints (optional, string[]): non-negotiables (security, budget, tooling, timeline).
• environment (optional, object): runtime (OS, container), deploy targets, CI.
• existing_system (optional, string): relevant current architecture and boundaries.

Steps

1. Define success criteria (what “done” means) and explicit non-goals.
2. Identify actors and interfaces (users, services, contracts, external APIs).
3. Choose an architecture that minimizes risk and change surface.
4. Define modules and ownership boundaries (what lives where).
5. Specify data flow (inputs, outputs, persistence, logs/audit trail).
6. Specify validation path:
   • unit tests
   • integration tests
   • security checks (as applicable)
7. Define rollout:
   • feature flags / guarded modes
   • backwards compatibility
   • migration steps (if any)
8. List open questions and assumptions; ask for clarification when risk is material.

Validation

• Plan satisfies all stated constraints.
• Every module has an interface and responsibility.
• Testing/validation is included (not “later”).
• Rollout avoids accidental production impact.

Output

Structured plan (example schema):

overview: "<1 paragraph>"
modules:
  - name: "<module>"
    responsibility: "<what it owns>"
    interfaces: ["<api/events/files>"]
data_flow:
  inputs: ["..."]
  outputs: ["..."]
validation:
  unit: ["..."]
  integration: ["..."]
rollout:
  guardrails: ["..."]
open_questions: ["..."]

Safety Rules

• Do not select tools that violate constraints.
• Do not propose deployments that can impact production without explicit gating.
• Prefer simplest architecture that meets requirements.

Example

Feature: “Add webhook ingestion with idempotency and audit logs.” Output (excerpt):

modules:
  - name: "webhook-controller"
    responsibility: "request validation + signature checks"
  - name: "event-store"
    responsibility: "persist raw payload + processing status"
validation:
  integration: ["replay same event id results in no duplicate side effects"]